|
How about only sending changed bytes each 20 ms? You'd need an additional 9 bits for addressing, but if you stuffed that bit in the empty bit in your 15-bit color data, you could do it with just one extra byte per LED. Depending on how fast your display is changing colors, that might work well. You could make a threshold, so if the color changes by less than X, you wait for the next round to send that data. Or maybe try interlacing the data? Send even rows and odd rows in alternating sequence? Or use 4 Arduinos in parallel? Or control the LEDs through a shift register, and then send 15 bits to 15 Arduino pins via a parallel port (assuming you can find a PC with a parallel port)? |
|||
|
|
|
The limiting factor is likely your computer's serial port, drivers and/or the Arduino library. If I recall correctly, the AVR UART can go up to its clock rate divided by 8 or 16, and an FTDI chip can be at arbitrary baud rates equally high (3 Mbaud for this FT232RL on my desk). Most shields are going to communicate over the AVR UART, so if the Arduino library is limiting you then they won't help. |
|||
|
|
|
I do not know what shields are available, I am only a microcontroller guy in general. As your baud rate goes higher a synchronous protocol makes a very large amount of sense. SPI is very simple and will allow baud rates in excess of 1Mbps very easily. However, if you just need to get to 300kBaud or even 1MBaud and are okay with UART the FTDI chip line is the real deal. One of the chips that can do this specifically is the FT2232H. These do not support SPI, but can handle very fast UART. From their specs:
|
|||||||||||
|
|
With proper hardware, Windows can handle serial communication up to 921600bps (115200 x2, x4, x8). There are PCI communication cards that support this baudrate, but more popular are USB<>RS232 convertors. If I remember well, all FTDI based convertors can handle it. The bigger problem is AVR side, where you will not be able to do anything else while data is received. RX should be the only interrupt allowed on AVR side. You will also probably have to clock your AVR as high as you can (16 or 20MHz depending on the model, 14.746 Mhz if you want to have 921600 exactly). Then you will send from PC the whole communication packet, AVR does the job after receiving it, and sends acknowledge byte that it is ready for next packet. When PC gets acknowledge then it can send another packet. And so on... Simple timers on PC side are (because of multitasking in windows) very bad at handling 10ms like resolution and they are not accurate at all (except multimedia timers when handled properly), so using simple acknowledge byte already described is a much better option. |
||||
|
|
|
Arduinos are awesome, but they have their limitations. Unless you are programing In C and just making use of the arduino bootloader they will tend to run a lot slower. Im not a big guru on data rates etc but i would expect that at 50hz you would be hitting the wall for the arduinos capabilities. I would suggest looking at programing in C (hackaday.com has just done a great set of tutorials on this) or trying another microcontroller, my favorite for projects like this is the parallax propellor essentially 8 microcontrollers in one. |
|||
|
|
