Does Serial.write() bock until the byte is written out of the Arduino? If so, is there a non-blocking approach?
Also, if it does block, can an ISR execute while waiting for the Serial.write to complete?
Does Serial.write() bock until the byte is written out of the Arduino? If so, is there a non-blocking approach?
Also, if it does block, can an ISR execute while waiting for the Serial.write to complete?
It only blocks if the output buffer is already full or becomes full.
How long is the output buffer?
Typically 64 bytes.
Can the Serial.AvailableForWrite() function be used to determine whether output buffer is not full? And does that function block for any reason?
sthudium:
Can the Serial.AvailableForWrite() function be used to determine whether output buffer is not full? And does that function block for any reason?
What does the documentation for the function say?
Does Serial.write() bock until the byte is written out of the Arduino? If so, is there a non-blocking approach?
More help might be available if you described the problem that you are trying to solve rather than inferences having to be made from the question.
I'm sorry for the confusion; I guess it's easy for me to be cryptic when I am close to an issue.
My issue is this: I want to make voltage measurements every 100 usec, which are triggered by a timer interrupt. I also want to be able to communicate with a PC over the USB port. So, I want to be able to send data strings while not interfering with the on-going, 100-usec measurement intervals. The worst-case scenario would be sending these strings every 100 msec at 9600 baud. This would be equivalent to sending up to 96 bytes every 100 msec.
Thanks.
How long are the strings, and what speed are you running the serial line?
If you use the analog inputs of the Arduino, you get a integer (two byte) value for a reading. At 9600 baud, it takes roughly 2 milliseconds to transmit those two bytes. At 115200 baud, it will take roughly 200 microseconds. You can do the calculations for other baudrates; once you get under 100 microseconds, there will be no risk of choking due to the buffer filling up.
If you go the text route, sending the integer value as text can be up to 4 bytes (and possibly a CR or LF). But you asked about Serial.write and not Serial.print; Serial.write should be OK.
Now the question is for how long you want to sample; if you only take e.g. 10 samples at 100 microsecond interval, that will only be 20 bytes. If you want to sample forever, your only way out is high baudrates or a different means of transport of the data.
Lastly, I suspect that you're very close to the limits of an AVR based Arduino (Uno, Mega etc) if you sue the analog inputs; one analogRead takes approximately 100 microseconds.
PS
You can indeed use AvailableForWrite to stop the sampling if there is not enough space in the buffer.
sterretje:
Lastly, I suspect that you're very close to the limits of an AVR based Arduino (Uno, Mega etc) if you sue the analog inputs; one analogRead takes approximately 100 microseconds.
What's the analogRead (ADC) time for a DUE?
I'm guessing that since the DUE clock is 5 times faster than the UNO's, that the analog measurement time is 100/5 = 20 usec.
No idea.
Part of the fun of Arduino is to dig through specifications and datasheets to find information that you need ![]()
sterretje:
No idea.Part of the fun of Arduino is to dig through specifications and datasheets to find information that you need
Great suggestion, thanks. Where do I find specifications and datasheets for the Due? I haven't been able, so far, to locate the code for Serial.print() or the Due schematic. Does Arduino publish this information? If so, I wish it was more readily visible on their webpages.
Sorry for the dumb question. I am just starting to look into Arduino.
I found an Atmel document that says that the microprocessor for the Due is capable of converting up to 1 million samples per second (ksps).
I found this statement in the ADC application note for the SAM3 processor.
http://www.atmel.com/Images/Atmel-42298-SAM3-4S-4C-Analog-to-digital-Converter-ADC_ApplicationNote_AT06860.pdf
The Due product description lists the Atmel SAM3X8E ARM Cortex-M3 CPU.
Does 1 million ADC conversion per second seem reasonable for the Due?
@reply #13
The datasheet states "1 MHz conversion rate". I did not dig further to see if there are limitations.
That is, by the way, 1Msps, not 1 ksps.
@reply #12
The product page does provide a link to the datasheet; it's in the first sentence under the 'overview' tab and you copied part of it in reply #13 ![]()
Note:
no experience with a Due.
sterretje:
@reply #13
The datasheet states "1 MHz conversion rate". I did not dig further to see if there are limitations.That is, by the way, 1Msps, not 1 ksps.
Oops, regarding the ksps vs. msps confusion:
I did a direct copy from the said application note and it said "1 million conversions per second" AND had "ksps." There is a typo somewhere in that sentence from the application note.
You are correct, the datasheet for SAM3 CPU (not the Due datasheet) does list 1 msps. So which is correct, "ksps" or "msps?" I suspect msps because the app note mentions 1 million conversions and the CPU datasheet mentions msps.
I wish I could make a timing measurement on the Due to find out, but unfortunately, I am vexed with an IDE problem where it doesn't recognize the serial port (see No Mac serial ports - IDE 1.x - Arduino Forum).