I wonder if Serial.print/println could be arranged in a way that interrupts from the UNO-UART would make the UNO load the next character to be transmitted. This would make the UNO able to do its work without the "long" delay caused by waiting for the entire message to be transmitted.
Of course, increasing the Baudrate would cut down the "downtime" for sending. However, 9600 is the default and nice to use when switching between different projects.
Doing a lot of real time programming using the Z80 I practised this but I don't know enough about the UNO, how it performs serial I/O.
I wonder if Serial.print/println could be arranged in a way that interrupts from the UNO-UART would make the UNO load the next character to be transmitted. This would make the UNO able to do its work without the "long" delay caused by waiting for the entire message to be transmitted.
Of course, increasing the Baudrate would cut down the "downtime" for sending. However, 9600 is the default and nice to use when switching between different projects.
Doing a lot of real time programming using the Z80 I practised this but I don't know enough about the UNO, how it performs serial I/O.
Regards,
Railroader
What leads you to think it does not work using interrupts?
I use Serial.print for dubugging an ongoing real time actitivty and the serial print affects the real time process.
My question was how to make it run that way, using interrupts. To me it does not look like serial print is doing that.
I use Serial.print for dubugging an ongoing real time actitivty and the serial print affects the real time process.
My question was how to make it run that way, using interrupts. To me it does not look like serial print is doing that.
Ok, you have done your homework. The USB runs at megabit/sec speeds. The code that handles the Serial.print has to feed the USB bytes based on the baud rate you programmed. So it need to wait the number of milliseconds until it can feed in the next byte.
The same procedure occurs on the PC end. The USB receives the byte immediately, but the serial emulator must wait to read it until the baud rate time has gone by. Otherwise normal PC serial program won't work properly.
As long as you are using the USB connection you will always have the problem. The only way to help is to set the baud rate to a really high speed.
In the old days, we used to get an interrupt from the UART/USART chip that indicated the tx buffer was empty and needed another byte or the rx buffer had a byte ready to be read. These so-called UARTS aren't that smart!
@Paul_KD7HB What on earth are you taking about, there are no waits/delays in hardware serial.
@OP interrupts are used. when a byte has been sent an interrupt is used to load the next byte to be sent (this is why you are told not to use serial in an ISR)
holmes4: @Paul_KD7HB What on earth are you taking about, there are no waits/delays in hardware serial.
@OP interrupts are used. when a byte has been sent an interrupt is used to load the next byte to be sent (this is why you are told not to use serial in an ISR)
You are absolutely correct. But we are discussing using the USB connection to a PC. This is NOT the normal serial data connection. Look up USB specifications.
Triggered by the first answer I got I wrote some more test code.
Before calling Serial.print I collected millis1. After the Serial.print was done I collected millis2. If (millis2 - mills1) was greater than 1 I sent a Serial.print of (millis2 - millis1). Sometimes I got a "2", regardless of Printing 5 or 25 characters.
Obviously interrupts are used. Asking for faster printout seems to be too much.
Going deeper, digging into source codes is more than I am prepared to do, Test and accept what I get, and use that is my idea,
Thanks guys!
The moment the serial buffer is full, code does start to slow down big time - I assume this is as the Serial.print() command gets stuck waiting for the buffer to have space, so the characters can be placed in the transmit buffer. The slowdowns are perfectly consistent with the time it takes to transmit data (and setting baud rate to 115200 or higher, instead of the commonly used and very slow 9600, does help a lot).
Paul_KD7HB:
You are absolutely correct. But we are discussing using the USB connection to a PC. This is NOT the normal serial data connection. Look up USB specifications.
Possibly, but the OP talks about an Uno and an Uno uses a UART to communicated with the serial-to-usb chip. So all communication is limited by the UART in the 328P.
If OP needs faster, higher baudrates are the way to go. Or switch to an Arduino with native USB support; in that case, keep in mind that disconnecting the Arduino from the PC (while externally powered) will eventually bring the Arduino to a grinding halt if you do not take precautions.
Paul_KD7HB:
You are absolutely correct. But we are discussing using the USB connection to a PC. This is NOT the normal serial data connection. Look up USB specifications.
Paul
For Arduinos with native USB (Due, Teensy etc) there is no delay. The USB sends at its maximum rate. The baud rate you use in Serial.begin() is ignored. You can test this by selecting a different baud rate in the Serial Monitor. "Incompatible" baud rates can talk to each other over native USB. If you actually try to test the speed, you will see that the speed is identical for every "baud rate."
For Arduinos without native USB, there's a helper chip to provide the USB-to-Serial conversion. (Uno, Mega, Nano...) There's no delay there either. The time it takes to transmit a character is set by the baud rate you selected. If you send a group of characters, they are sent at the exact baud rate. There's no gaps between the characters to make it look slow.