Go Down

Topic: serial rate of 921600 bps with arduino due ?? (Read 943 times) previous topic - next topic

saso


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.

joe mcd

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.

robtillaart

Quote
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.
Rob Tillaart

Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -
(Please do not PM for private consultancy)

robtillaart

Rob Tillaart

Nederlandse sectie - http://arduino.cc/forum/index.php/board,77.0.html -
(Please do not PM for private consultancy)

pylon

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.

Go Up