Serial transfer rate vs. CPU speed

Hello,

I would like to clarify my understanding of how the arduino transfers information and executes code.

For example, if I set the serial transfer bit rate to 100 bits/s, I would assume this would hold up the CPU until the data is transferred. In other words, code execution would be halted until all of the data has been sent at 100 bits/s, since this is slower than the Arduino’s maximum transfer rate.

Instead of the CPU just dumping the data, it would send a bit, wait some amount of time, send another bit, wait, etc.

Is this correct?

Thanks.

-John

Instead of the CPU just dumping the data, it would send a bit, wait some amount of time, send another bit, wait, etc.

Well, that IS how it "dumps the data".

The arduino does not have an output buffer so your code will wait until the last byte of code is in the output buffer then it will resume the execution of your sketch. It does not wait until the last byte is finished being sent. On the input side there is an input buffer so your code can grab each byte as it is available. Communication between the USB and the computer happens in bursts at USB speed so there is no need to slow down the data rate from the arduino.

Thanks for the response. I had this particular question because the device I'm building requires a certain transfer rate. The ideal situation would be to know how long a section of code takes to execute so I could have the CPU doing something instead of sitting idle between sending bits.

I could create my own 'virtual buffer' within the code, and continually switch between calculations and data transfer to maximize CPU usage.

I'm guessing this would be more complicated than it's worth.

I'm guessing this would be more complicated than it's worth.

Yes that would be my guess as well.

Another guess is that 100 bits /second sounds like an old Teletype machine. ;)

"The ideal situation would be to know how long a section of code takes to execute so I could have the CPU doing something instead of sitting idle between sending bits."

That shouldn't be hard. When your section starts, capture the time: unsigned long timestart = millis(); // or microseconds if you want

at the end, capture the time again unsigned long timeend = millis();

timeend - timestart is the amount of time in ms or uS.

The hardware serial port of the arduino has a transmitter registers, and a holding register. If you set it up for 100 bits/s (Serial.begin(100), you have set hardware to shift out bits at the 100 per second rate, regardless of the CPU frequency. If you output one byte (Serial.print('A', BYTE)), the function will return immediately, and the 'A' will dribble out the serial port for the next 1/10th of a second or so (each byte takes 10 bits, all together.) If you output two bytes (Serialprint("AB")), the function will still return immediately and your sketch can go off and do other things; the first byte will start dribbling out immediately, and the second one will go into a buffer register waiting for the first byte to finish. In about 1/10 second, the second byte will start transmitting, and the buffer will be empty and ready to receive another byte. if your sketch comes by with 1/5 second or so and provides more characters, the output device will never even see a pause... 1/5 second is a long time by the standards of a 16MHz CPU. If you output three characters (Serial.print("ABC")), the hardware resources will be exhausted, the function will take 1/10th second for the 1st character to be transmitted before it can put the last character into the buffer register, so the sketch will "stick" there. Same thing for more than 3 characters; it will take about (n-2)*0.1 s to return... It is fairly easy to use interrupts to implement an additional set of buffers for output characters in software; there have been a couple of implementations done that change the serial library to do this. In this case, you'd typically be able to output "bursts" of up to 64 bytes without having to wait for the serial port; but there's still a limit. If you try to output continuously, you will eventually not be able to output more than 10 bytes/second.