I am working on a project for my work.
All goes well (for the moment) but there is something that puzzles me.
Setup:
Arduino Nano connected via USB to a PC running a program made in Processing. Last one is to visualize some data captured by the Arduino.
Arduino itself is alse connected to some fotocell's in a letter sorting machine.
The Arduino has to keep track of letters. No problem there.
Also the Arduino has to measure the lenght of the letters and the gap between them on different places. (Letters can originate from more than one place ... therefore tracking)
To do this the Arduino interrupts every 300 micro seconds to see if a letter is present (letter length) or not (gap). 300 µs equals 1mm movement.
Every now and then the Arduino has to send the average letterlenght, gaplength and other data to the PC for visualisation and logging. Timing in the latter case is not critical. 5 seconds or 20 seconds between updates is of no importance.
Keeping the interrupts at exactly 300µs for length measurement and tracking however is critical.
My question.
Will serial communication have some effect on those critical interrupts?
If so. What is the best thing to do. 115200 or 300 baud (extremes).
I guess serial communication is purely hardware related, so no impact on interrupts. But I have to sure.
Will serial communication have some effect on those critical interrupts?
Only if the serial communication routine itself is written to disable interrupts.
What is the best thing to do. 115200 or 300 baud (extremes).
Assuming that the serial communication routine does not disable the interrupts (see above) then it is the interrupts that will be affecting the serial routine. In that case it seems to me that any interrupts will affect the lower baud rates less than the higher ones.
I guess serial communication is purely hardware related, so no impact on interrupts.
There's some software involved to get the data to the serial communication subsystem but the actual data transmission is done in hardware.
But I have to sure.
You will have to look into the serial communication routines to be sure.
I have been wandering through HardwareSerial.cpp (as floresta advised) and some fora.
As far as I understand only the receive side is interrupt driven (_rxcie set), and no interrupt disable is used within the serial routines provided by the standard Arduino environment. So sending data with Serial.write() will not mess up time critical interrupts. Keeping in mind ofcourse to never ever invoke Serial.write() in the ISR itself.
For the sake of this topic however I would like to know if the opposite is true. Will timed interrupts have any effect on Serial.write().
Hypothetical case:
Timed interrupt every 100µs with code that takes up to 50µs to finish.
Serial.write(some_variable,DEC) every second invoked in the main loop.
Will the baud rate used be of any importance? Will the timed interrupts really play havoc with it when using high baud rates?
Timed interrupt every 100µs with code that takes up to 50µs to finish.
Serial.write(some_variable,DEC) every second invoked in the main loop.
Will the baud rate used be of any importance?
Yes, it will. At any given baud rate, it takes some amount of time to send a character. The higher the baud rate, the less time it takes.
Since you have, effectively, a fixed time to get the characters out, a higher baud rate will get more characters out in the available time.
Indeed .. the higher the baud rate the more you can send in a given period, that's obvious.
The question however is, will interrupts affect the Serial.write() being in progress.
For instance :
While in de main loop, the command Serial.write("very long text") is executed, several interupts occure.
Ooohh I so dislike speculating from an absence of facts, but still feel I might contribute here, or at least get my wrong ideas rejected.
I have made myself a small serial library that uses active polling and watching millis() to send characters using Serial.print.
My experiments showed Serial.print (and presumably Serial.write) to BLOCK when sending more than one char.
It takes "no" time to send a single character, but you can not send another until that one has pulsed its way out of the serial line, ie I have to wait for second/baudrate before attempting the next character send, or I will block again.
So I simply call my serial output package in the loop() and have a different output routine that simply stacks the characters strings in a buffer (that the active poll routine will output in due time).
This is simple singlethreaded code, no interrupts, no reentrant code nor locking datastructures to worry about
