next topic »

[on:]

Hi,

before I buy an arduino DUE I would like to ask the following:

I intend to use an arduino DUE to read data on a serial channel (UART) at a rate of 921600bps, perform some easy calculations on them (e.g. a checksum calculation) and send them on another serial channel (UART) again with 921600bps. I cannot afford to "loose" bytes, so the connection has to be very robust. The data amount to be read is not very high: an external device is sending them in "bursts" to the arduino due, i.e. 15bytes at the beginning of every millisecond. In the same way the DUE has to output the data on onother serial channel.

Would you say that this task is very challenging for the arduiono DUE or is it rather an easy and feasible task?
Regarding the processor specs that mentioned rates are no problem but perhaps there are limitations caused by the implementation of the serial library.
 

[Reply #1 on:]

The old serial protocol was never intended for such high speeds.  It contains no clock information.
You can always try & see.
I would use SPI which includes a clock line and intended for up to 4Mhz.  I 've used it between  328's at 2Mhz with no problem.  The main weaknesses of SPI are: 1.no official slave support (but plenty of hacks)  2. Slave cannot initiate a message.   I2C might be another alternative.

[Reply #2 on:]

15bytes at the beginning of every millisecond.

That is 15 *10 * 1000 = 150.000 baud.
921600bps is a factor 6 above that (quite some safety margin

I have successfully used 345600 baud on an UNO so I expect no problem with the DUE as it is faster but I have not enough DUE experience.

[Reply #3 on:]

DUE processore spec docs here - http://www.atmel.com/devices/sam3x8e.aspx?tab=documents -

[Reply #4 on:]

Do your other devices (the ones you wanna communicate with) support hardware handshake (RTS/CTS)? For speeds going that high I would at least recommend using hardware handshake, better is a clocked protocol like SPI (as joe mcd suggested) but you don't specify if your devices would support this.

[Reply #5 on:]

regarding spi, i2c:

the device that will send the data to my arduino DUE uses two wire rs485 (wires having a length of approx. 2m). it is an eye tracker camera that outputs the pupil coordinates and some additional information at a rate of 1000Hz (equidistant in time). In other words, I cannot use spi or i2c as suggested nor can I use any additional clock signals to make the transmission more reliable.

So far, I used a RS485/USB adaper to read the data with a windows pc. There were no problems. So the data quality seems to be ok. the only limiting factor appears to be the UART of the arduino due - to be more precise, the library functions dealing with the serial interface.  Would you agree? If not, what determines the maximum speed?

I plan to use MAX485 to convert the data to TTL level. Any bad experience with this circuit?
Do you see any problems arising when trying to send data with 921600bps on another serial line of the DUE?

[Reply #6 on:]

When you said serial I assumed the old RS232.  RS485 is a modern protocol designed to handle longer distances and higher speeds.  Provided the hardware is really RS485 compliant, you should be OK.  Does the Arduino DUE library support RS485?

[Reply #7 on:]

When you said serial I assumed the old RS232.  RS485 is a modern protocol designed to handle longer distances and higher speeds.  Provided the hardware is really RS485 compliant, you should be OK.  Does the Arduino DUE library support RS485?

No, it is not supported as far as I know. Thats why I intend to use a MAX485 converter.