Hi everyone For a LED panel project I found myself with the fallowing problem: -Large amounts of data needs to be distributed to the RGB led's (36bits per LED, hundrets or even thousands of LEDs). -Each LED panel has only 64 or 256 leds and I want it to be able to run in a standalone mode -A controller (raspberry PI?) feeds the data to the first panel and the data then runs through all cascaded panel, like in an digital LED strip So what I am looking for is basically a large shift register that can hold the data for one full panel (i.e. 64 x 36bits) that can then be read out (by SPI?) with a simple microcontroller and fed to the LED controllers. The update rate of the LEDs should be about 60 updates per second (for smooth animations) which is no problem for a standard microconroller at 40MHz (I am thinking of using a cortes M0). The problem is clocking the data through to all the panels. I am looking at 3-5MBps for bigger cascades. Now it would be pretty simple using a shift register like structure at 50MHz. How could this be implemented as cheap as possible? I was thinking FPGA but that seems to be a little expensive. A CPLD cannot hold that much data (or can it?). How to get the data actually into the shift registers is a secondary problem. There I could make use of a VGA input or even a HDMI input and run it throug an FPGA since only one controller is needed for this, the price can be higher. It is just a project Idea right now and I do not want to start to go deeper before the basic questions are not answered. Thanks in advance for any tips or hints.
Maybe you can use a uC with two SPI-Ports. The Master-Controller makes a big frame containig Data for all LEDs and starts sending the first byte to the first panel. The panel needs a kind of configuration (maybe DIP-switch) to know, if the reveiced data is addressed to that panel. If yes, it makes a copy of each Byte to it´s memory and sends the byte to the next panel via second SPI. Master starts sending second byte..... At the end of the cycle all data for all LEDs have been "seen" by every panel but because of the configuration each panel has a copy of the data slice addressed to it in it´s memory.
Alternatively you can choose a controller with ethernet-port. Then you connect all panels to a switch and each panel receives a MAC-frame, containig all data for one panel.
Thanks for the input. It could be doable, but I fear that SPI with overhead of receiving AND sending (plus crc maybe and addressing bytes) will be too slow. It may just work if the number of panels is limited to let's say 10 panels but if I later decide I want more it would not work. For a small amount of panels I am thinking of using an NRF24 wireless connection and getting rid of the wiring work. Will do probably just that for first trials and software tests but later I want higher data rates. Another approach I was thinking of was using 8 parallel data lines at lower speed (8MHz). That also is not feasible on a cortex M0, especially on the receiving side...
I think you cannot increase the amount of panels to infinitiy because the amount of data which has to be calculated is getting more and more an therefore the cycle time increases until you reach a point where the transmission time is far less then the time the master needs to update the data. btw. As I know, NRF is reduced to a datarate around something like 2 Mbit/s 10 panels x 256 Leds x 36 Bit/LED x 60cycles/s = appx. 5-6MBit/s :-(
I already did some tests with the NRF24 and it is limited to about 600-700kbps even at 2Mbit transfer rate because of crc and address overhead. I do not want to use Ethernet because of cost and wiring effort (sockets are big, cables expensive and so on). As mentioned in the initial post, a shift register would do the trick but cannot hold that amount of data. I also thougt about using a Propeller uC but for it's 80MHz clock it is pretty slow because most instructions take 4 clocks and therefore does not support fast communication. Think about a display input, that can be full HD with 60 updates per second no problem by using fast communication ICs. A DSP with PPI interface would also be an option but that involves a lot of work in programming for such a "simple" task. Is there a possibility to do something like the TLC5942 does for 16 channels but for even more channels? I know I could just daisy chain all of these ICs of each panel but that makes it impossible to have each panel as a standalone unit and they all only work from one single input. comments on that?
Well, it seems, that you exactly know what you are doing. you want to update every 16ms more than 100kBit via serial connetction. You like to have a solution with almost no cost (shift registers). But unfortunately there is no 100000 Bit ready to go shift register available on the market. You think that a buidling a kind of "shift register" with daisy chained SPI-Controllers is too slow because they have overhead and CRC (it´s up to you to build a proper protocol for your application.. you can do it without a single bit of overhaed) And you think that 1 Euro for Ethernet Cable and another Euro for the jack is too expensive. But you like to do it via nRF which is way to slow and at the end surely more expensive..
If you want to make it with a shif register you can solder several dozen shift registers per panel on a pcb and put loads of components around it to handle emi and clock skews. Or you can impement your own 1000 bit shift register in an FPGA which needs minimum 2 different power supplies and at least a 4 layer micro via pcb. fortunately you get all this for almost no money ;-)
exactly. I do not want to use LAN cables because I want no star wiring. Imagine a wall with 10 panels and each one having a power connection to the next one AND a LAN cable to a hub. thats an awful lot of cables on something I want to look nice and tidy. Oh well, maybe I will just go to something more expensive and load each panel with a WiFi module and a more powerful ARM. Is a huge overkill but at least it looks the way I want it to.
Star wiring with PoE.... only one cable per panel... But I´m sure that you also don´t like this idea, because you LIKE to have it daisy chained ;-)