4
\$\begingroup\$

I need to send 800 bytes of data from a computer to an arduino board every 20ms (approximately). I began with the serial library which works nicely but it is too slow even at its highest rate (115200 baud) for interfacing with a computer.

What other interfaces are available that can send at a faster rate? Can I use usb or spi? I can't seem to find libraries for these. I need something with about a 320 kBaud rate.

edit

Are there any shields that might be able to do this? Bluetooth or wifi?

\$\endgroup\$
5
  • 1
    \$\begingroup\$ What are you doing with this data? The AVR isn't designed to handle a huge amount of data, if you could optimize your communications that would be preferable regardless of how you talk with the thing. Buffering 800 bytes may not even be possible. \$\endgroup\$
    – Nick T
    Nov 11 '10 at 19:40
  • \$\begingroup\$ 800 bytes is the minimum I can send I believe. I have 400 LEDs hooked up an arduino and each one has its own 15bit color. I'm not compressing the 800 bytes yet, I guess I could do that if I had an efficient way to do it. Is there an arduino library for that? \$\endgroup\$
    – wcmartin
    Nov 11 '10 at 19:49
  • 1
    \$\begingroup\$ So a 20x20 RGB array at 50 Hz? \$\endgroup\$
    – Nick T
    Nov 11 '10 at 20:18
  • 1
    \$\begingroup\$ Precisely but I could probably drop down to around 30ms (~33hz) if 50 Hz is too ambitious. \$\endgroup\$
    – wcmartin
    Nov 11 '10 at 20:24
  • \$\begingroup\$ If you aren't doing with AVR anything else during data receive, then AVR can handle it without problems, if fed with data over 921600 or 460800 bps serial connection. \$\endgroup\$
    – avra
    Nov 12 '10 at 11:59
2
\$\begingroup\$

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)?

\$\endgroup\$
3
\$\begingroup\$

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.

\$\endgroup\$
2
\$\begingroup\$

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.

\$\endgroup\$
1
\$\begingroup\$

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:

RS232/RS422/RS485 UART Transfer Data Rate up to 12Mbaud. (RS232 Data Rate limited by external level shifter).

\$\endgroup\$
8
  • \$\begingroup\$ Hmmm interesting, I'll have to look at that chip. Unfortunately I can't use SPI because I am already using it to control the LEDs hooked to the arduino (via pins 11 and 13). \$\endgroup\$
    – wcmartin
    Nov 11 '10 at 21:24
  • \$\begingroup\$ Sorry, I miss-communicated. The FT2232H chip is UART. I shall correct my post. \$\endgroup\$
    – Kortuk
    Nov 11 '10 at 21:45
  • \$\begingroup\$ Are you using programmable drivers to actually control the LEDs or are you using shift registers? How much processor time are you using up just manipulating the data to send out the SPI? \$\endgroup\$
    – Nick T
    Nov 11 '10 at 22:33
  • \$\begingroup\$ @NickT, I am very confused by your comment. He can use UART to get the data and set the LEDs, I am sure it is a full workload. \$\endgroup\$
    – Kortuk
    Nov 12 '10 at 3:18
  • \$\begingroup\$ I was curious how he was driving the 1200 LEDs; there's no way I could see it being done with an AVR without auxiliary controllers. He said he was using the SPI to communicate, so it might be a controller but possibly a basic shift register(s). \$\endgroup\$
    – Nick T
    Nov 12 '10 at 3:55
0
\$\begingroup\$

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.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.