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?