Large RGB Led Screen Project Feasibility

Alright so me and a few of my college electrical engineering friends have a summer project where we are going to be designing from scratch an RGB led display, using some of the information we learned in our classes this past semester. This would include PCB's, schematics, the works. We've drafted quite a few design specs so far for what we want, but are slightly concerned about the feasibility of it, and are looking for a little bit of guidance for anyone out there who may have done something to this scale before.

Currently, the design is planned to make 4 boards of surface mount rgb leds that are in a 16x24 matrix. That's 384 RGB leds per board, or a total of 1536. These are inter-connectable so that you can get several sizes of displays (16x24, 32x24, 16x48, 16x96, 32x48). Each board can run on it's own or be daisy chained with another. Rows and columns will be accessed through shift registers. I realize there are better options out there for accomplishing this, but our group wanted to use something we learned about in class, and one of those was a shift register. So shift registers it is.

The first issue I feel like we would run into is obviously memory capabilities. The chip we want to use is the Atmega328, and we will have our own custom circuit boards for the processors rather than use the standard arduino boards. There are various reasons for this, but none important to the scope of this thread. Anyways, the 328 only holds a max of 32kB of flash and 2kB of SRAM, and I realize that's honestly not enough to hold all the information for the matrix. The plan is to expand the flash (for animation/image storage) and SRAM (for manipulating the matrix data) to 64kB and 16kB respectively, and interface this through SPI. This is quite a large amount of memory, mainly to accommodate possible future expansions of the project.

The second issue I believe is clock frequency. Sadly we are limited to 16MHz, though I wish it could go higher. Either way, this will limit the refresh rate of the screen and considering how much data has to be sent out, I'm a tad concerned that the clock frequency will be our main bottleneck in this project. Our group considered moving up to the 48MHz 32 bit ARM processor the Due uses, but did not feel like the difficulty in making the circuit board and programming it would be worth the effort. Either way, we are stuck with a 16MHz processor. Currently our design goal is to get a refresh rate of 60Hz across the entire screen. I honestly do not feel like a single 328 could handle a RGB 1536 led matrix, simply because I'm not sure it can get all the data out in time for that. In addition to that, we are wanting to use 8 bit Bit Angle Modulation to gain a 0-255 step control of the brightness of every single led color. So not only does the processor have to send out all the data for the screen, it has to process and calculate the data to be sent out in between interrupts. I'm not sure one chip could do that, but perhaps I'm wrong.

Anyways, my solution to the clock frequency issue was to split up the display into more manageable pieces and have a 328 controlling each piece. All data communications between the processors would happen through I2C as the SPI channels are taken with the memory expansions. Hopefully I2C would be fast enough. There would be one central processor to control the peripheries....this central processor would split up the data into chunks and send it out among the various display processors. Also the central processor would issue interrupts to the other chips so that the entire display can send out the data at the same time. Hopefully using this "splitting the load" technique would solve the clock frequency issue.

What do you all think? Sound like a good start? What issues can you possibly perceive us coming across? Are there any major design flaws we might be missing?

The ShiftPWM library would be perfect for a project like this. The page above includes a calculator that will help you figure out how many LEDs you can run from a single 16MHz micro.

codex653:
Anyways, my solution to the clock frequency issue was to split up the display into more manageable pieces and have a 328 controlling each piece. All data communications between the processors would happen through I2C as the SPI channels are taken with the memory expansions. Hopefully I2C would be fast enough. There would be one central processor to control the peripheries....this central processor would split up the data into chunks and send it out among the various display processors. Also the central processor would issue interrupts to the other chips so that the entire display can send out the data at the same time. Hopefully using this "splitting the load" technique would solve the clock frequency issue.

Not so sure that is a good idea. You are now making the job of the individual processors somewhat more complex by having them implement a communications protocol in addition to their other tasks. The central processor will still have to process and "sift" all the dynamic data to send it out. And I think you misunderstand the concept of "interrupts" somewhat as so frequently happens here.

What I think you need, is proper matrix driver chips which handle the multiplexing and PWM. But maybe I am talking through my hat ...

Chagrin:
The ShiftPWM library would be perfect for a project like this. The page above includes a calculator that will help you figure out how many LEDs you can run from a single 16MHz micro.

Ah yes I have seen that and was going to use it, however the way he sends out his data is slightly non-intuitive to me. Not to mention I THINK he uses the SPI pins...maybe....and those are taken up by my external memory. Unless I missed something, he has no configuration option for sending out data on multiple pins. Meaning that the way my screen is configured, all the reds are together, then all the greens, then the blues, but they are all their own separate system. The end of the red shift registers don't connect to the beginning of the green, etc. I don't want to input my data serially for all the colors like that. I've considered going in and modifying his source code though to adjust for that. Thanks for the suggestion!

Paul__B:
Not so sure that is a good idea. You are now making the job of the individual processors somewhat more complex by having them implement a communications protocol in addition to their other tasks. The central processor will still have to process and "sift" all the dynamic data to send it out. And I think you misunderstand the concept of "interrupts" somewhat as so frequently happens here.

What I think you need, is proper matrix driver chips which handle the multiplexing and PWM. But maybe I am talking through my hat ...

More complex is no issue here when it comes to the data handling. A little extra work, no big deal. However I don't believe you understand the way our project is working. I stated above that our group only wanted to use something that we learned in class this past semester, so this means no special dedicated chips that take all the fun out of building the projects. The point here is to LEARN how all this stuff works and really get a good handle on it, not put off all the work to a dedicated chip. Yes it will be harder by not using the chip, but who cares! It's an intellectual pursuit. That being said, we are using Bit Angle Modulation, not PWM to gain our brightness control. It's a heck of a lot easier than doing software PWM in my opinion. Less strain on the processing time too. And as for the interrupts, they are what time the Bit Angle Modulation to work properly. I've already been using the interrupts for BAM in some other matrices to control the brightness of some leds, so I think I got a pretty decent handle on it.

You could switch from the 328P to the more-of-the-same 1284P and run at 20 MHz.
More of the same is more pins, RAM, flash, and 1 extra hardware serial port capable of master-mode SPI.
You might need to change some pin numbers but 328P code runs fine on a 1284.

Arduino is a development board. You don't need to apologize for making stand-alones as that is "the idea".

This blog tells How to make an Arduino-compatible minimal board using a 328P or a 1284P.

Also you might look around for off-the-shelf digital RGB led strips, but price may be an object unless your time has enough value. How do you feel about soldering 100's to 1000's of leds and other components for maybe $1 or $2 an hour? Don't forget, you have to buy the leds and all the other bits if you don't buy the strips.

GoForSmoke:
You could switch from the 328P to the more-of-the-same 1284P and run at 20 MHz.
More of the same is more pins, RAM, flash, and 1 extra hardware serial port capable of master-mode SPI.
You might need to change some pin numbers but 328P code runs fine on a 1284.

Arduino is a development board. You don't need to apologize for making stand-alones as that is "the idea".

This blog tells How to make an Arduino-compatible minimal board using a 328P or a 1284P.
Gammon Forum : Electronics : Microprocessors : How to make an Arduino-compatible minimal board

Also you might look around for off-the-shelf digital RGB led strips, but price may be an object unless your time has enough value. How do you feel about soldering 100's to 1000's of leds and other components for maybe $1 or $2 an hour? Don't forget, you have to buy the leds and all the other bits if you don't buy the strips.

Ahhh very nice! I had not heard of the 1284 before! I'll be sure to check it out in depth. I certainly like that built in 16K of ram though...that's looking rather enticing. Wouldn't running it at 20MHz run into some issues with timing of some of the software??? I had read somewhere on the forums that there were some pretty big reasons why the developers decided to keep the 328 running at 16MHz even though it can do 20MHz.....But I don't remember what exactly.

Mmm yeah I already bought all the led's and resistors off ebay, so my group is in for a fun time with soldering. Yay. But that's alright. It'll be a good time to practice our SMD soldering skills.

You could consider shifting out byte-wide, so have 8 shift-registers in parallel
sharing a clock. Using a Mega you'd devote a single 8bit port to the data and
use direct port I/O.

How multiplexed are the boards going to be - remember multiplexing reduces
brightness (and power requirements), although it reduces complexity.

Look at the cost of 16-way LED drivers - these are basically shift registers with
open-drain constant-current output buffers, some have built-in PWM and take
8 bits of brightness per output channel, some do one bit per output.

And of course consider NeoPixels.

codex653:
Not to mention I THINK he uses the SPI pins...maybe....and those are taken up by my external memory. Unless I missed something, he has no configuration option for sending out data on multiple pins.

With SPI you just need separate "enable" (AKA Slave Select, Chip Select or Latch) lines for each device on the bus. All devices share the Clock, MOSI (data out), and MISO (data in) lines but only listen to those SPI signals when their enable pin is pulled high (or sometimes low). As long as you can ensure there's no conflict on that enable pin everything should be happy.

ShiftPWM allows you to use the hardware SPI or software SPI (which can use any of the digital pins). Using software SPI is 2.5x slower, however.

MarkT:
You could consider shifting out byte-wide, so have 8 shift-registers in parallel
sharing a clock. Using a Mega you'd devote a single 8bit port to the data and
use direct port I/O.

Ditto with a 1284 or even a 32 (a 328 with 40 pins).

MarkT:
You could consider shifting out byte-wide, so have 8 shift-registers in parallel
sharing a clock. Using a Mega you'd devote a single 8bit port to the data and
use direct port I/O.

How multiplexed are the boards going to be - remember multiplexing reduces
brightness (and power requirements), although it reduces complexity.

Look at the cost of 16-way LED drivers - these are basically shift registers with
open-drain constant-current output buffers, some have built-in PWM and take
8 bits of brightness per output channel, some do one bit per output.

And of course consider NeoPixels.

Hmmm yeah I could use the whole port and then possibly shift out the data for an entire row in the same time it would take to shift out a single byte. Good thought. I'll consider it in the design plans! What do you mean by "how multiplexed"?? I thought multiplexing was multiplexing and that you could just expand the matrices for larger ones. Ooh neopixels look cool!! I might have done that if I hadn't already bought my leds....

Have you seen the 16x32 and 32x32 RGB matrix panels at Adafruit?

Link: http://www.adafruit.com/products/420

These do exactly what you're looking at building, which may be a plus (it's done, and it essentially does exactly what you were talking about -- shift registers driving RGB LEDs), or a minus (it's already built, and if design and implementation is the purpose of your project, this negates this point.)

They already have demo code that drives one panel from an Arduino Uno (so, a '328) using some optimized graphics routines and a tiny bit of inline assembly. Interestingly, while the raster drawing routines are optimized, the framebuffer implementation itself is actually designed to be generic. That means it can be used for other displays, or can be optimized further for better speed on one particular display. (Mostly, this has to do with color depth.) Still, it's pretty fast as-is. Check out the plasma demo. It's shocking how smoothly it runs.

The panel has no native dimming control, so all of that is done with PWM just like you were saying. The routine used in the Adafruit code is an implementation of an existing algorithm designed for speed and takes advantage of regular interrupt intervals. Worth an afternoon of reading some articles and blog posts, and poking at the code, just to learn a neat new trick. :slight_smile:

Same goes for the gamma correction -- technically a slight misnomer, but forgivable for its clarity. Again, dedicate a couple hours to read up on LED brightness curves as it applies to RGB luminance.

Ooh!! :slight_smile: Thanks for the link! I'm definitely going to be spending some quality time with that code. I have heard of those matrices before thanks to people using them in their projects on Instructables, however I had not seen that website. Sadly part of the design is actually making the board ourselves from scratch. We've already got all the resistors/leds/shift registers/etc. All smd of course!

So you arrange parts on panels and cook em in place? What do you cook em with?

Next year make a parts-placing robot.

GoForSmoke:
So you arrange parts on panels and cook em in place? What do you cook em with?

Next year make a parts-placing robot.

Cook em with the soldering iron of course! :wink: Yeah for real. That would be a lifesaver to have right now. Eh oh well. I need to practice smd soldering skills anyways.

Some people use toaster ovens and some use electric fry pans to solder (a) board(s) at a time, but I don't try SMD.

I can solder DIP and through-hole and need magnifiers for that, thank you.

codex653:
Cook em with the soldering iron of course! :wink: Yeah for real. That would be a lifesaver to have right now. Eh oh well. I need to practice smd soldering skills anyways.

Wowza! I understand wanting / needing to reinvent the wheel for the sake of the experience (hey, I do that with regularity!), but man.. you HAVE to find a better way than soldering all of those components manually. :cold_sweat: Definitely go snag a toaster oven from your local thrift shop, and a thermocouple probe, and start practicing SMD reflow.

Those panels are logically simple devices. You should consider duplicating their signalling -- maybe even buy one panel as a reference and design yours to work the same way. That way you can use known-good code to drive your displays, and a known-good display to test your code. 8)

Oh yes I'm definitely considering doing it, assuming the panels actually fit in the oven. What will probably end up happening in real life is I'll solder a few hundred, get really good at it, and then flip the rest of the job over to the oven like you said.