Shop OBEX P1 Docs P2 Docs Learn Events
Propellering the Adafruit 16x32xRGB LED array — Parallax Forums

Propellering the Adafruit 16x32xRGB LED array

RaymanRayman Posts: 14,646
edited 2015-01-16 03:34 in Propeller 1
Adafruit gave me a few of these panels and I'm going to get them working with a Prop chip.
I'm hopeful that a single Prop can control several of these panels, giving a simple and relatively
low cost way to create a very large array...

I've started describing what I'm up to here:
http://www.rayslogic.com/propeller/Programming/AdafruitRGB/AdafruitRGB.htm

in case anybody is interested...
«134

Comments

  • Roy ElthamRoy Eltham Posts: 3,000
    edited 2011-09-02 09:42
    I have one of these that I bought from adafruit. I'll be working on a driver soon too.
  • RaymanRayman Posts: 14,646
    edited 2011-09-02 10:18
    Great. I've promised to release my drivers as MIT license, so feel free to use them if you want...
  • Roy ElthamRoy Eltham Posts: 3,000
    edited 2011-09-02 10:28
    I will always release my prop code as MIT too.

    I guess we'll see who get's it working first? :) (unless you already have something?)
  • RaymanRayman Posts: 14,646
    edited 2011-09-02 10:39
    Well your in trouble because I took the day off! I'm at home and on a mission to get it working today!
  • Roy ElthamRoy Eltham Posts: 3,000
    edited 2011-09-02 10:49
    haha :)

    Well I wouldn't call it trouble... If you get it working today, then it saves me work! I'll be starting on my version tonight after work, but I'll check back with you first.
  • RaymanRayman Posts: 14,646
    edited 2011-09-02 14:07
    Well, I got an LED lit! At least I can claim a little bit of victory before going away for the weekend...
  • Roy ElthamRoy Eltham Posts: 3,000
    edited 2011-09-02 15:25
    I noticed that mine had a resister soldered into a spot where there are 3 "spaces" and it was hand soldered in there. Like someone did it after the board was made.
    I'll be working on this in a few hours, if I get something going I'll post here.
  • RaymanRayman Posts: 14,646
    edited 2011-09-02 15:27
    Ok, I figured out how the protection circuit works...

    There are two diodes and some capacitors on the right side of the board.
    They rectify the "A" control line and only enable the de-multiplexor when A is being toggled.
    I imagine they do that to keep from damaging an LED by keeping it on too long...

    Here's a revised version of example code that toggles ABC at the end to enable the output:
  • RaymanRayman Posts: 14,646
    edited 2011-09-02 17:55
    Roy, I do see those resistors too. I haven't figured out what they are for yet...

    Did figure out how that protection circuit is working though (just updated above post and code).
  • Roy ElthamRoy Eltham Posts: 3,000
    edited 2011-09-02 19:42
    Good to know, thanks. I'll be working on a PASM driver this weekend mixed in with other stuff I have to do.
  • Roy ElthamRoy Eltham Posts: 3,000
    edited 2011-09-05 20:54
    Well, I've got some PASM code driving the thing, but it's still not really working as expected. I was hoping I could use PWM and get 8bits per component color (24bit color), but in one cog reading the frame buffer from hub I can't get better than 5bit per color working well. Even that is exhibiting some weird ghosting or something. The problem I see is that I turn on a pixel in the first row, and it lights fine, but I get that same pixel dimly lit in the 7 rows below it.

    I also get weird results if I try leaving output enabled instead of toggling it each time (for each 1/8th update). I'm still futzing with the code, but later (tomorrow night maybe) I'll make another post in this thread with the code attached so you can see what I've done, and use it if you want.

    Roy
  • RaymanRayman Posts: 14,646
    edited 2011-09-06 06:24
    5 bits per color is still pretty good. Also, convenient to have 6 in one long.
    That ghosting issue sounds strange though. I think that has to be a software problem.
    I don't see how the hardware could do that. But, I guess I'll find out soon enough...
  • graffixgraffix Posts: 389
    edited 2011-09-06 07:00
    whats ghosting?I have a led board I couldnt figure out with some ghostly issues lol
  • Dr_AculaDr_Acula Posts: 5,484
    edited 2011-09-06 16:30
    That is one gorgeous looking display. Keep up the good work and please keep us posted with photos. Even one led is a huge achievement. 5 bits per color will be more than enough - even 3 bits gives very good looking pictures so 5 is going to be sweet.

    That display is good value. $79 for 32x16. A bare RGB 8x8 from futurlec is $10.90 and so 32x16 would cost $87.
  • whickerwhicker Posts: 749
    edited 2011-09-06 18:17
    You'll probably need to shut off output enable when changing the row.
    If you do not, there's no guarantee that all the row bits A B C arrive at the same time, and the actively lit row will shake around, probably causing the ghosting.

    Don't worry about the lost time in doing this... for at least my display it is ridiculously bright and needs to spend a lot of time off to not be blinding indoors.

    I too was only able to achieve 5-5-5 RGB in one cog.

    I didn't feel comfortable sharing the object I made because I'm using a weird scanning technique... basically it scanned the rows with a delay between each row at a 1x, 2x, 4x, 8x, and 16x rate corresponding to the magnitude of each of the 5 bits. The LED was either on or off during the row period. This was so that I did only 8x5x32 shift outs instead of 8x32x32 shift outs, 6 bits parallel.

    a row pattern like:

    01234567 0011223344556677 00001111222233334444555566667777 000000001111111122222222....
  • Roy ElthamRoy Eltham Posts: 3,000
    edited 2011-09-06 19:08
    I tried all sorts of output enable variations. The default setup turns output enable off, sets the ABC address, shifts out the bits, latches them, and then turns output enable on. It loops back around and repeats that process 8 times per "scan" and continuously repeats that scanning.

    I'll figure it out eventually.
  • RaymanRayman Posts: 14,646
    edited 2011-09-07 03:48
    I wrote some simple 8bpp code last night and calculated would update at 3 Hz, way to low.

    So, 5-5-5 looks good. Maybe I'll try a more standard 5-6-5...

    On second thought, 555 is probably better. Maybe use the extra bit to indicate a blinking pixel...

    I'm going to try leaving output enable on all the time... Plan is to show section while shifting in the next...

    whicker, I'm still trying to understand you approach... Sounds interesting though.

    Actually, I think there may be a way to do 24 bpp color using an indexed, 256-color palette.
    But, I think 15 bpp is simpler and more versitile...
  • RaymanRayman Posts: 14,646
    edited 2011-09-07 12:41
    whicker, Ok, I think I've figured out what you were doing... Pretty clever actually...

    Just wrote some test code to figure out timing...
    Using whicker's approach and precalculating the output and using counters, I think we can do 24bpp color with ~70 Hz refresh.

    Bad part of this approach is that a pixels color info is spread out over several longs.
    The 555 way is simpler in that pixel data is in a single word...
  • RaymanRayman Posts: 14,646
    edited 2011-09-07 16:28
    Just added this SPIN example that lights up any given led to white.
    (Ok, I'm behind, but I'll be catching up soon...)
  • RaymanRayman Posts: 14,646
    edited 2011-09-19 06:29
    Roy, I'm back on this now (after cleaning up some water damage from Hurricane Irene).

    Just tried an assembly driver and I think I see the ghosting you referred to. Also, I contacted Adafruit and they have seen what I see too.

    I think it's really only an issue when there are a lot of Black pixels, such as when showing text. I don't think it will be a problem for images.

    Here's what I think is happening: The 16-channel LED controller chips seem to output some minimum amount of current once any channel is activated.
    The worst case is when a single pixel is lit and you are quickly changing between the 8 sections. In this case the same position in the other 7 sections
    will show a strong ghost. But, if you turn on more of the 16 channels, the ghost goes away. Also, if you slowly change between sections, you don't see the ghosting either.
    The OE signal does not control this effect.

    So, I'm thinking about countermeasures now. First thing is to switch between the 8 sections as slow as possible. Next, is to advise reducing color depth when showing sparse images, such as text.
  • BTXBTX Posts: 674
    edited 2011-09-19 19:56
    Hey guys, @Ray, I can't understand well what are you going to do with it, maybe some like a led screen module ?
    Tell me which drivers has that module, I did some about that, and I could post or give you my code, to test it and improve.. for me works well in 8bpp showing video through ethernet using UDP...
  • RaymanRayman Posts: 14,646
    edited 2011-09-20 07:06
    Alberto,

    I remember you've done some impressive LED displays before. Where they like these ones?
    I've got some info on these displays here:
    http://www.rayslogic.com/propeller/Programming/AdafruitRGB/AdafruitRGB.htm
  • BTXBTX Posts: 674
    edited 2011-09-20 17:28
    Hi Ray !!
    Your Adafruit modules are very similar that I uded.. but my job was to get work only two of them with a pchip, plus a ethernet connection in the same board.
    I get full video at 30fps in 8bpp mode, obviously recieving the data through ethernet in UDP, anyway I've space in the micro to try more modules as you want. How do you solve the grayscale issue ?? are you interested in my code ? (that is no great) but I used a good trick to get the 8bpp at a high data rate.
  • RaymanRayman Posts: 14,646
    edited 2011-09-20 17:57
    Of course, I'm interested in what you did, especially if the modules are similar.
    By 8bpp do you mean 3 bits for green and red and 2 bits for blue?

    I'm attempting to do 24bpp with 8 bits for all colors. It may not happen, but that's the goal.
    I would like to at least do 9 bpp because that's what Adafruit was able to do with an Arduino.
    I feel somewhat obligated to outperform the Arduino...

    But, for video, an 8bpp driver could very well be the very best because of the high throughput.
    Right now, I'm just working toward static images...
  • BTXBTX Posts: 674
    edited 2011-09-20 18:28
    OK, let me get the code, and tomorrow I'll posting it, or, if you prefeer first, I'll send it to you better.
    I mean I did 24bit RGB. :) So could be interesting for your task.
    Of course !!, if Arduino did it, propeller SHOULD do it better !!! :))
    For static images, you've it easy with my code in 24bit. !!! Your problem will be to understand my poor code..... :(
    Good night.
  • RaymanRayman Posts: 14,646
    edited 2011-09-22 16:34
    Just got 24bpp mode working, flicker-free. I've also managed to eliminate ghosting (by switching between sections in the outermost loop).

    Here's what the main loop looks like and what I mean by "precalculated output"
                            '#0       
                            rdlong  outa,t1
                            or      outa,clkmask  'Toggle the clock
                            add     t1,#4
                            ...
     
                            #31
                            rdlong  outa,t1
                            or      outa,clkmask  'Toggle the clock
                            add     t1,#4
     
     
    

    Basically I read from the pixel array directly to the outa port 32 times. Then, toggle the latch...

    Just tested with an actual photo and the problem I see right now is that it is way, way too bright. I have to dial down the brightness to almost zero to make it look like the computer screen...
  • RaymanRayman Posts: 14,646
    edited 2011-09-24 05:50
    I think I've figured out that I need to add gamma correction...
    So, I've added a little lookup table for that.
    It now looks very nice.
    Here's a screenshot of my test image on LED and monitor:
    Lenna_test.jpg


    BTW: It's hard to get a good photo of an LED display!
    It may look too red, but really it's not...
    1024 x 768 - 64K
  • Roy ElthamRoy Eltham Posts: 3,000
    edited 2011-09-24 13:25
    Looking good Ray.

    I resigned to just waiting for your driver for this, since I had to focus on other things and set this aside.
  • ChorcaChorca Posts: 3
    edited 2011-09-24 23:41
    Awesome to see this, you guys!
    I got one of these too, our hackerspace was doing a group buy from Adafruit and we got a couple, so I decided it'd be a perfect project for the Propeller.

    I have mine hooked into a C3 board, and I'm just now figuring out how to properly drive this display.. I'm still a beginner at Propeller, but I basically just dumped a routine that updates the display constantly (shift 32 pixels, latch, address, repeat) and my main cog altering colors just to give me flashing bars of light. It works pretty good! I noticed Adafruit was doing the same thing, their output routine was tied to a timer interrupt so every so many ms they are updating the display to keep it on.
    It's nice not having to have an interrupt doing this, that way a single cog can just keep updating as fast as it can while the others handle creating graphics.

    I'm going to try making a basic (and probably poorly implemented) pixel buffer to make some graphics, still learning bitwise math and such! I look forward to the drivers you're writing, Ray! Love to see how you're doing things so I can learn more about this chip!
  • RaymanRayman Posts: 14,646
    edited 2011-09-25 05:01
    Ok, here's the current version. It has several example Windows bitmap files embedded in it.

    This shows a bitmap in 24bpp color.
    Using a gamma correction of 2.5
Sign In or Register to comment.