KurtE
Senior Member+
Suppose, I have an interval timer that does some interpolation and updates a set of Dynamixel servos N times per second (default 50). I will have a host computer send packets of data with which includes servo ids and new positions and how long to take to get from their current position to the new position.
So there is always the question of when I get a packet of data and the interval timer is running, the best way to maintain data consistency.
On Linux systems ore the like, I would probably use something like a critical section or ...
What I have done in the past is to have a global variable that the interval timer sets for what time the next interval will happen and then have my setting code loop if there is less than N (usually 2) MS before the next trigger time. As I know that should give me plenty of time to complete the update before it triggers for the next time.
I know there are probably several other options:
a) Update function does an end on the timer, and when it finishes does a new begin... But that would probably break having reasonably consistent timings
b) Disable interrupts - Sort of like using a sledgehammer.
c) Maybe only disable the IRQ_PIT interrupt temporarily... Don't see any clean way on this one with the current class definition.
d) Edit: Another approach I am considering is to have the IntervalTimer process the data. That is maybe the main code parses the data into some easy format and then have the ISR, check for this and then process it. Would need to handle a few cases of timing to not have a deadloack
Other thoughts? currently I will probably go with the make sure I have time before next interrupt approach, but thought I would see if there was another obvious solution I was missing...
So there is always the question of when I get a packet of data and the interval timer is running, the best way to maintain data consistency.
On Linux systems ore the like, I would probably use something like a critical section or ...
What I have done in the past is to have a global variable that the interval timer sets for what time the next interval will happen and then have my setting code loop if there is less than N (usually 2) MS before the next trigger time. As I know that should give me plenty of time to complete the update before it triggers for the next time.
I know there are probably several other options:
a) Update function does an end on the timer, and when it finishes does a new begin... But that would probably break having reasonably consistent timings
b) Disable interrupts - Sort of like using a sledgehammer.
c) Maybe only disable the IRQ_PIT interrupt temporarily... Don't see any clean way on this one with the current class definition.
d) Edit: Another approach I am considering is to have the IntervalTimer process the data. That is maybe the main code parses the data into some easy format and then have the ISR, check for this and then process it. Would need to handle a few cases of timing to not have a deadloack
Other thoughts? currently I will probably go with the make sure I have time before next interrupt approach, but thought I would see if there was another obvious solution I was missing...
Last edited: