Propellering the Adafruit 16x32xRGB LED array
Rayman
Posts: 14,646
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...
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...
Comments
I guess we'll see who get's it working first? (unless you already have something?)
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.
I'll be working on this in a few hours, if I get something going I'll post here.
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:
Did figure out how that protection circuit is working though (just updated above post and code).
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
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...
That display is good value. $79 for 32x16. A bare RGB 8x8 from futurlec is $10.90 and so 32x16 would cost $87.
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....
I'll figure it out eventually.
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...
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...
(Ok, I'm behind, but I'll be catching up soon...)
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.
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...
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
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.
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...
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.
Here's what the main loop looks like and what I mean by "precalculated output"
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...
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:
BTW: It's hard to get a good photo of an LED display!
It may look too red, but really it's not...
I resigned to just waiting for your driver for this, since I had to focus on other things and set this aside.
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!
This shows a bitmap in 24bpp color.
Using a gamma correction of 2.5