So: I've got a Teensy doing PID at 2KHz, triggered by an interrupt.
I need to handle communications as well - reading new setpoints into one of my buffers, and sending out requests for more data when necessary.
Ideally, I'd like to stick this in the same interrupt as the PID. There are no timeconsuming operations; all the serial comms is handled byte by byte so I'm never waiting for anything.
Any gotchas here? Any reason I can't have an empty loop() function? I like the simplicity of having this sort of thing:
Now I think about it, perhaps I should just stick everything in the main loop instead, and rely on this:
.... Hmm.
Suppose my question is, for the least jittery timing, does it make a difference, interrupt driven, vs an ordinary loop with elapsedMicros providing timing?
***** UPDATE *****
Arrgg... I *knew* there was a reason I wanted to do it on an interrupt: if I have a load of Teensys hooked up together, I'll need to have one generate a clock pulse and the rest can do all their PID stuff (as above) in an interrupt. Makes sense to have them all work on an interrupt, then, just that the master Teensy will be using a timer, and the rest will be watching for a clock pin.
So - any gotchas stuffing everything in an interrupt?
I need to handle communications as well - reading new setpoints into one of my buffers, and sending out requests for more data when necessary.
Ideally, I'd like to stick this in the same interrupt as the PID. There are no timeconsuming operations; all the serial comms is handled byte by byte so I'm never waiting for anything.
Any gotchas here? Any reason I can't have an empty loop() function? I like the simplicity of having this sort of thing:
Code:
void myInterruptHandler() {
calcPID(); // do this at the start of each cycle so we don't get jitter
handleIncomingSerialByte(); // only ever handle one byte per cycle
checkBuffersAndSendRequestForMoreDataIfNecessary();
prepareNextSetpoint(); // this interpolates the next setpoint
// from the buffered data
}
Now I think about it, perhaps I should just stick everything in the main loop instead, and rely on this:
Code:
void loop() {
if (myElapsedMicros > 500) {
myElapsedMicros -= 500);
calcPID etc etc etc
.... Hmm.
Suppose my question is, for the least jittery timing, does it make a difference, interrupt driven, vs an ordinary loop with elapsedMicros providing timing?
***** UPDATE *****
Arrgg... I *knew* there was a reason I wanted to do it on an interrupt: if I have a load of Teensys hooked up together, I'll need to have one generate a clock pulse and the rest can do all their PID stuff (as above) in an interrupt. Makes sense to have them all work on an interrupt, then, just that the master Teensy will be using a timer, and the rest will be watching for a clock pin.
So - any gotchas stuffing everything in an interrupt?
Last edited: