Hi there,
I would like to know how fast the Arduino Uno R3 communicates with computer.
What i mean is that if I run this code:
void setup()
{
Serial.begin(9600);
}
void loop()
{
Serial.print("Hello world");
}
How fast does the hello world gets printed out in the real world time?
I just need to know this to plot a graph of a signal for my project.
Or is there anyway to setup a clock?
Thank you in advance 
baud rate for serial communication
Serial.begin(9600);
9600 bits per second.
Serial.begin(115200);
115200 bits per second
You are using 9600 baud so letters get pushed out at 960 per second.
You can make it faster by using a faster baud rate.
so the "hello world" actually gets printed 960 times per second? It doesn't seem that fast to me though..
so the "hello world" actually gets printed 960 times per second?
No, each character is printed in 1/960th of a second.
No, each character is printed in 1/960th of a second.
And, since there are 11 of them, the whole thing takes about 11 milliseconds to send. So, you could send that amount of data 87 times a second.
Of course, loop() takes some time to iterate, and the PC takes some time to deal with the data, so the overall throughput will be less.
If you are planning to create a real-time plot, the biggest bottleneck will not be serial. It will be converting the value to plot to a string and back to a value. So, don't do that. Use Serial.write() to write the individual bytes, and convert the bytes back to a value on the PC.
You can probably send and receive stuff to/from the PC at 500,000 baud and maybe at 1,000,000 baud.
I have been experimenting with sending a request character from the Arduino to the PC which causes the PC immediately to send a short string back (11 bytes, 44 bytes, 88 bytes (with modified HardwareSerial code) ). I have repeated this 500 times and measured how long it takes. The best round-trip time seems to be about 4 millisecs and it makes no appreciable difference which quantity of bytes is sent. In other words it is more efficient to send more bytes in each transmission.
...R
The best round-trip time seems to be about 4 millisecs and it makes no appreciable difference which quantity of bytes is sent
Are you including a Serial.flush() in the timed part of the code? Writing to the outgoing buffer doesn't take long. Actually shifting the bytes out is what takes the time. flush() waits for that to happen.
PaulS:
Are you including a Serial.flush() in the timed part of the code? Writing to the outgoing buffer doesn't take long. Actually shifting the bytes out is what takes the time. flush() waits for that to happen.
No.
As far as I know there is nothing getting in the way of performance apart from the normal O/S stuff (on the PC) and the USB system.
The 4 msecs is the average time it takes for the Arduino to send "" and for the PC to reply with several bytes.As soon as the Arduino receives them it asks for more.
Answering your question has prompted another question in my mind - what triggers the Arduino USB code to send stuff over USB? - perhaps it waits for a certain load or a timeout (all in the background). I must investigate. The same question probably also arises on the PC side. I read a lot about this a couple of years ago while trying to figure out how to get an FTDI UM245R board to work. Perhaps I should re-learn it.
...R
what triggers the Arduino USB code to send stuff over USB? - perhaps it waits for a certain load or a timeout (all in the background).
Periodically, an interrupt checks for data in the outgoing buffer. If there is anything., a byte is shifted out. One byte or a buffer full doesn't matter.
PaulS:
what triggers the Arduino USB code to send stuff over USB? - perhaps it waits for a certain load or a timeout (all in the background).
Periodically, an interrupt checks for data in the outgoing buffer. If there is anything., a byte is shifted out. One byte or a buffer full doesn't matter.
Are you referring to the code in the Atmega 328 or in the Atmega 16U2?
I haven't managed to find all of the 16U2 source code yet, but I would be surprised if it sends every byte over USB as a separate item - very poor use of the USB system.
...R
Are you referring to the code in the Atmega 328 or in the Atmega 16U2?
the Atmega 16U2
but I would be surprised if it sends every byte over USB as a separate item - very poor use of the USB system.
Paul didn't say that.
The bytes are shifted into the 16U2 over conventional serial data. Once there it gets polled by the USB software. That is at a rate set by the driver but typically is 1mS or so.
Then when it is polled it transfers all the data in the buffer.
A USB client can not initiate communications with the host it has to be asked.
Grumpy_Mike:
Once there it gets polled by the USB software. That is at a rate set by the driver but typically is 1mS or so.
That was my understanding. Then there will be another 1ms delay when the PC decides to send stuff back. Plus whatever actual time the PC code takes and, of course, the actual time for the 16U2 to send stuff to the Atmega 328 at the chosen baud rate. Hence the round trip time of about 4ms.
I'm guessing that it is the Serial Monitor that sets the baud rate for the 16U2 (just idle curiosity).
...R
Then there will be another 1ms delay when the PC decides to send stuff back.
That depends on the drivers, some will send when the buffer is full, others on a round robbin (no pun intended).
As the buffer can be up to 1K then it is difficult to say how this will affect the overall time.
On something like the Leonardo the baud rate does not affect the transfer rate. I did measure it once but I can't recall the results now. A lot depends on the software on the incoming machine.
PaulS:
No, each character is printed in 1/960th of a second.
Of course, loop() takes some time to iterate, and the PC takes some time to deal with the data, so the overall throughput will be less.
No, the time taken by loop() and the software overheads in the PC will be swallowed up
by the software and hardware buffering at each end, so you can expect full speed. I/O
subsystems are designed to be clever like that.
For instance if you call "Serial.print ("Hello World!") ;" that call will returrn long before
all the characters have been pushed out on the serial line by the ISR that drives UART
transmission. Some future call of Serial.write() will have to wait for the software
buffer if its full up - as soon as there's space for another character its put in the buffer.
Similar stuff happens all along the I/O chain deep into the PC's kernel...
MarkT:
PaulS:
Of course, loop() takes some time to iterate, and the PC takes some time to deal with the data, so the overall throughput will be less.No, the time taken by loop() and the software overheads in the PC will be swallowed up
by the software and hardware buffering at each end, so you can expect full speed. I/O
subsystems are designed to be clever like that.
This is only partially true.
It is true if the comms is only a small part (in terms of time) of the Arduino application.
If the PC (or Arduino) can only respond after it has received all the data the processing can't be swallowed up. It may be possible to arrange the sequence of things so one lot of data is processed while another is being transmtted - but that depends on the application.
If you are sending small quantities of data (a few bytes) the USB system is very obstructive due to managing tasks in 1 msec timeslots. That's why people still like to use old-fashioned parallel ports.
...R