0

I hope to find some answers or pointers to a boggling task of mine:

Having an Arduino DUE that I want to push to its serial limits, I came up with the idea of hooking it up to my rPi via serial at least at 921600 baud.

Technically both seem capable of that. A loopback test with the rPi was successful up to 921600 and I've managed to get a "good" quality transmission up to 576000 bps already (error-rate should be around 1,3%), but anything higher gets problematic.

Problems:

  • DebugConsole, CuteCom and minicom don't have support for any speeds in-between, so either 921600 works or it doesn't

  • minicom supports 1.000.000 baud, but this would still mean a ~5% error-rate, which is according to my calculations and tests, but they are in question here as well ...


From the Atmel Doc I've got

BaudRate = MCK ⁄ CD × 16

From that I've derived that with the 84MHz Due a baudrate of 1.050.000 would be the actual rate I should aim for, as CD must(?) be an INT.

1050000 = 84000000 / 5 * 16

Questions:

  • Is my assumption of an optimal 1.050.000 baudrate right?
  • Is it possible to use a different clock for the baudrate generator than the 84MHz?

Remarks:

A Clock of 14,7456MHz should be optimal as it is equal to 921600 * 16.

I am using TXD/RXD1 on the Due.

The Due is transmitting on 921600 but the data is scrambled due to the errors.

In case somebody is wondering, my hope is that it is easier to adjust the arduino to 921600 baud than it is to setup a tool and configure the rPi to support 1050000 baud - but I am working both ways, only that with the rPi I know what to do ..

  • 1
    Localization note for this question: decimal points are shown as comma. thousands separator is shown as dot. yes? – jdr5ca Dec 6 '14 at 20:50
  • oh, yes, that is correct – Jook Dec 6 '14 at 20:58
  • Why not use SPI to communicate between Due and rPi? You would support higher rates, and that would not be much more difficult to implement. – jfpoilpret Dec 7 '14 at 7:54
  • @jfpoilpret thanks, but the rPi is more like a verification device, the true challange is the arduino serial port, I am aware of SPI and USB, but I need to do this via serial or at least find out if this is possible or not – Jook Dec 7 '14 at 22:27
2

The clock of the transmitter and receiver have to be matched.

In theory, the worst case error tolerable is 1/2 bit per byte. For the 10 bit byte (1 start, 8 data, 1 stop) that leads to a +/- 5% clock error tolerance that you will find reported. Note that this actually depends on the specific UART implementation, either chip or internal. There are various methods of sampling that make some UART's better than others. It is common to sample in the middle, but some chips have methods to improve noise rejection.

For the receiver side, do not rely on what the terminal program is showing you. Few applications would manipulate the clock directly; they commonly just call an API with an enumerator for the speed. You need to know exactly what hardware the receiver side has and its clock.

In practice, the theoretical limit is not going to work. At high data rates, the noise on the cable will eat away at that safe margin. More common recommendations will say +/- 1% which allows for noise on the edges of the bit transitions.

The noise on the signal is important at these data rates. You indicate you are using TXD/RXD which is just logic level. You cannot connect logic level any significant distance. If the two are directly next to each other with excellent attention to wiring, you might have a chance. Adding transceivers will help your chances significantly.

Also, note that changing to 7 bits helps. Do you need 8 bit data?

So in summary: - The receiver is more important than the transmitter, but they both have to match. If you can't find a match of clocks to 1%, you will have data errors. - At these speeds, the cabling and connection is critical.

This article at Maxim is a good starter Maxim "Determining Clock Accuracy Requirements for UART Communications.

| improve this answer | |
  • wires are like 10cm max; the arduino is powered by the rPi as there is no extra GND line; need 8 bit; used init_uart_clock=14745600 on the rPi; am aware of the +/-1%; the situation is clear, but how to solve it?! how to practically align the clocks and baudrates of the rPi and due to 921600 or anything else in the neighbourhood – Jook Dec 6 '14 at 21:23
0

Yes you can set the Master clock slightly slower and use Serial.begin(921600) and it will come out close enough to work with a HC05 bluetooth module set to 921600. // multiplier 0x25 , divider 0x3 REG_CKGR_PLLAR=0x20253F03;// works at 921600 this will throw all other timings off but you can always compensate by changing the master clock definition in the Due ? .h file. if you want to print out of Serial0 port this will need to be set to 921600 also and you can monitor it with something like realterm that can do higher baud rates.

Atmel-11057-32-bit-Cortex-M3-Microcontroller-SAM3X-SAM3A.pdf

| improve this answer | |
  • May be a little formatting and some punctuation might help understand your answer... – Roberto Lo Giacco Sep 27 '16 at 17:53
  • I had to put this project aside for quite a while but will check the answers when it will restart – Jook Nov 11 '16 at 13:11

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.