I have a project where I would possibly like to have some serial data (CSV values) output at a regular interval (about 10 Hz). Because of the way the program is currently structured, it is not feasible for me to poll millis() to check if 100 milliseconds has passed, but I have read a lot of people say to not use serial output in interrupt routines.
I have configured a baud rate of 115200 bps. The amount of serial data to output is about 17 bytes. I also have a pair of interrupts to handle wheel count sensors (I will probably have to implement some hardware to reduce the frequency of this - this part is easy).
If you are comfortable generating timer interrupts (sounds so from your post) you can just set a global variable (itsTimeToPrint or something) to 1 in the interrupt routing, then in your main code check for this variable being set to 1 and print at that time.
--
The Gadget Shield: accelerometer, RGB LED, IR transmit/receive, speaker, microphone, light sensor, potentiometer, pushbuttons
If you are comfortable generating timer interrupts (sounds so from your post) you can just set a global variable (itsTimeToPrint or something) to 1 in the interrupt routing, then in your main code check for this variable being set to 1 and print at that time.
It is a bit hard to see how that is any easier than polling the timers...
It is a bit hard to see how that is any easier than polling the timers...
I agree, I'm having trouble conceiving a program in which the timers can't be polled, so I assumed they were being repurposed for something else and millis() would not return useful data.
I guess seeing the actual code would be helpful at this point.
The code is lengthy, but I will abbreviate it for analysis.
void setup()
{
//setup serial
//set pins for digital read/write as required
//install interrupts for wheel count sensor (attachInterrupt)
}
void loop()
{
//wait for external signal to start
//timed serial output would start here in current organization
for (int i = 0; i < NUM_TASKS; i++)
{
switch(i)
{
case whatever:
//call function that does something, returns when task is completed
break;
//more cases to check for
}
//programmed set of tasks has been completed
}
In its current state this is what happens:
loop() does not repeat until the entire set of programmed tasks has been completed. Each task function only returns when that task has been completed.
In order to use polling on millis() I would have to restructure the code so that every task function exits immediately instead of exiting when the task has been completed.
Is it worth my while to reorganize the code to what would essentially be a big state machine in order to use polling for serial output?
I think the only limiting factors for using serial output in an interrupt routine would be the use of PWM outputs and external interrupts for the wheel sensors (looks like I will use 4 external interrupts total). Serial input is not a big concern as I am only interested in one-way serial communication (the code is runs autonomously once started)
Yes. Regardless of what you are trying to do, long delays are never a good thing. You should structure your code so loop is executed as often as possible, changing the action that it performs on each pass, as required.
Adding interrupts to manage poorly written code is a recipe for disaster.
uglyoldbob:
In order to use polling on millis() I would have to restructure the code so that every task function exits immediately instead of exiting when the task has been completed.
Is it worth my while to reorganize the code to what would essentially be a big state machine in order to use polling for serial output
How long do the tasks take? Could you do your serial operations between them, i.e. inside the for loop?
At this point, only you can say whether it's worth your while to convert to a state machine. Generally, you'll get a more responsive app that way though. I'd do it.