As you can see, setting up a nice and big LED-display doesn't need any mad FPGA or DSP skills; you can throw a few simple and universal 8-bit microcontrollers towards it for about the same effect. If you can get the LEDs plus the board for the basic control of them for cheap, it's even possible to make a nice screen on a small budget.

Is this design expandable? It should be: the bottleneck in this design is the way the AVRs get their pixel data. Just daisychaining all of them won't work for larger screens. One solution would be to use an USB2.0-hub and multiple FT232s; in theory, you could expand the display to use the complete USB2.0 480Mb/s that way, but you'd need an awful lot of FT232s for that. For small displays, this would work OK, though.

In case you can get your hands on multicolor displays (e.g. the bicolor red-green ones, or if you're really lucky and/or rich, the RGB ones), the way to control them would be exactly the same, but with three times as much LEDS. You might want to implement the logic with more powerful microcontrollers or turn down the amount of greyscales, then.

For anyone who's interested: the AVR firmware for my boards is downloadable here. Please understand that if you don't have exactly the boards I have, you'll have to modify the code to accommodate for any changes. The modifications to MPlayer and aalib are such ugly hacks, I'd rather not release them. If you really want them, you can contact me via the link on the bottom of this page.

« Prev 7 


Afnan wrote at 7 Sep 2012, 14.08:

Nice Work and very beautifully defined...may i have your email or fb id pls?

DeathMerchant wrote at 16 Jul 2011, 16.22:

very inspirational, I trying to do something similar with a 32 by 16 led matrix which has mbi5024 led drivers, and i need your help please!!

XHACK wrote at 26 Jul 2010, 1.23:

please tell me from where you got this LED????????????

Nathan wrote at 17 Jul 2010, 0.13:

Brenin: Maybe you could use an Arduino MEGA to get started, it\'s a little bit pricy at $65, but it has 4 UARTs. Granted you\'d need some RS-232 to RS-485 converters, but having hardware serial would be good. Although I suppose you could just get a hefty microcontroller and just use RS-485 interface chips and directly connect them to the microcontroller (quite a bit cheaper I\'d expect)/

Sprite_tm wrote at 2 May 2010, 13.26:

Brenin: That\'s 23040 pixels. Take a refresh rate of 25Hz and 8bit/pixel and you have to shift roughly 5 mbit over the line. The max485 can take that, but the AVRs can\'t... so I reccomend splitting the board in pieces of e.g. 5 led-boards with each their dedicated serial line, and one microcontroller with 5 uarts (sw or otherwise) to shift the data out to those boards.

brenin wrote at 2 May 2010, 0.12:

I\'m trying to do something close to what you did, but I having some trouble to decide what should I use, basically in the communication part. In my project I\'d like to have 30 nodes (each one with a microcontroller controlling a matrix of 24x32) with a similar result to what u got. What would you recommend me to use? I was thinking of a RS485 network, but I not pretty sure from what I\'m reading if it will be capable to handle the frequency necessary for video effect in the whole matrix. Do u have any suggestions or ideas?

eddy wrote at 27 Mar 2010, 18.27:

This is really awesome! Playing a video on a LED-Board :D How geeky is that? Very cool... :-) Keep up the good work, dude :-)

Sprite_tm wrote at 3 Jun 2009, 23.01:

You can probably replace the component by a standard shift-register plus an ULN2803 or something. There may be other shiftregister-on-steroids-ICs like that too, I don't know.

Christian wrote at 3 Jun 2009, 15.14:

Incredible!. MIC5821 component I could not find. Why component can be replaced?. Since you and I appreciate the help. Christian

Atilla wrote at 15 Dec 2008, 9.23:

This is a wild compo-winner in any demoscene party! Yay for sprite!

Crazy Cellist wrote at 13 Dec 2008, 20.16:

I've been doing LED firmware for 10 years. Cool video choice.

wladston wrote at 6 Dec 2008, 5.07:

GREAT hack man. LED-display O W N E D :D Congrats.

HuB wrote at 18 Nov 2008, 2.39:

I'm really impressed! As always when some new project appears on your site. Thanks for sharing code for inspiration to others.

PlastBox wrote at 17 Nov 2008, 8.51:

I always enjoy your hacks and this was no exception! I just really, really hope you'll do this one with RGB-leds. You know.. a totally over-the-top project that would bring a tear or two to the eyes of geeks all over the world. Heh.. =P Nice work!

srimech wrote at 16 Nov 2008, 16.01:

This is brilliant. I had a go at this myself a while ago (http://srimech.blogspot.com/2003/04/led-message-board-hacking.html) but I only got as far as scrolling text.

Brett_cgb wrote at 15 Nov 2008, 20.15:

The way I see it, the only real bottleneck is how fast can a master controller communicate video data to the array controllers? Here are a few thoughts: At the start of each video frame, just send each controller in the array the data for the first row to be displayed rather than all the data it needs for the entire frame. When all the controllers have received the first row, start sending the remaining rows - as long as this is completed before the last row is displayed, the data rate can be reduced. After all the rows have been sent, the array controller can start thinking about the next video frame while the array controllers handle the "PWM" work. These may reduce the peak baud rate required. Use 4 bit pixel data rather than 5 bit. Two pixels per byte can be sent instead of one, and storage requirements can be halved. This one change doubles the rate pixel data is sent, unless you are already packing data for 8 pixels into 5 bytes. An alternative PWM process with a higher "flicker" rate - Assuming 4-bit pixel data, for each pixel, assign a register (accumulator) for each pixel, and initialize it to 0x0. For each "PWM" cycle, add the pixel brightness value to its accumulator. If there is a carry out of the 4th bit (an overflow), turn on the pixel, otherwise turn it off. The carry does not need to be stored. If four bit data is used, most controllers offer a digit carry status flag used for BCD additions - this can be tested instead of a bit in the result and may allow faster processing. The result is that the pixel flickers at a higher rate, but the ON time is the same as for traditional PWM.

clearscreen wrote at 15 Nov 2008, 16.36:

you are great!!!!!!!!!!

koensa wrote at 15 Nov 2008, 14.39:

very nice!

me wrote at 15 Nov 2008, 13.28:

The BB video is just awesome.

Sprite_tm wrote at 15 Nov 2008, 9.07:

It is, unfortunately. That's the risk of buying used led boards.

confusis wrote at 15 Nov 2008, 8.43:

I see a '10:1' on the bottom middle segment? possible burn-in from previous use of display?

kt wrote at 15 Nov 2008, 5.17:

This was a great write-up! I've been pondering how to create grayscale displays.

Leave a comment:

Your name:

What does this picture say?
Sorry, this is a captcha

Your comment:

© 2006-2022 Sprite_tm - Contact