quickest possible and stable serial connx Arduino <=> RaspberryPi ?

Projects General Guidance
12

tito-t:
sorry, but IMO your answer is ambiguous and vague. My cpus are 16MHz AVR (e.g., Nano, Uno or Mega 2560), and as already stated, Zero (M0), Due (M3), and esp8266.

moreover, about it was you yourself who stated
"But be aware that USB can have a surprisingly low throughput for small data packets - i.e. less than 64 bytes.", so now you even contradict to yourself.
But eventually you may not know reliable data, and if so, please let people answer who know more exactly how to set Serial.begin() best of all for max performance together with the Raspi.

@all: Let me rephrase my question.
1st, I am using Serial.begin(), not SerialUSB.begin().
2nd, Serial() UART has to be started for Arduinos by an exact clock rate by Serial.begin() which probably has to be somehow a certain divider of the cpu clock speed (CMIIW).
And 3rd, I already read that 1Mhz UART clock at a 84MHz Due cpu leads to 5% transmission error which is too much.
So after all, the UART clock speed actually seems to matter.
And finally also on the Pi the serial (USB) communication has to be started at an actual clock speed by serialOpen() (in wiringSerial.h), matching the UART clock on the Arduino.

So for the quickest possible UART communication by Serial() on Arduinos via USB to the Raspi USB (dev/ttyACM0) :

16MHz AVR (e.g., Nano, Uno or Mega2560) <=> Raspi,
Zero (M0) <=> Raspi,
Due (M3) <=> Raspi,
and esp8266 <=> Raspi

What exactly has to be chosen?

  1. The USB buffer thing is difficult to control on Arduino. The Serial wrapper intentionally hides that detail from you. Because for 99% of programs, it doesn't matter. And that includes programs that are trying to send a lot of data at high speed. Where it kills the speed is if you send a small amount of data and wait for a response. Then it's an important detail you need to know about. If you just blindly send a lot of data then you get lots of speed from the USB.

  2. The transmission errors are not directly related to the speed. Every speed you choose has an error - it can only pick the nearest divider and can't divide clock speed by 2.63 or any arbitrary number. So there are a few speeds - different for each processor - which aren't perfectly exact. Very rarely when you are trying to get two specific devices to talk together, one is a little fast and the other is a little slow. On their own, they are OK but together those two errors put it too far out of sync.

  3. You have the hardware in front of you. Do the experiment. If you have a frequency counter or oscilloscope you can get a better view of what's going on.