John,
Forgive me if I'm missing something about your questions and this is
insulting your intelligence.
But here's what's really happening. Your app code *except your
callback function* is executing "above" the interrupt level. So it's
statements 1, 2, 3, ... N are executing. As MIke said, *DURING* one of
your statements executing the timer interrupt can happen. Your callback
function is then called from the timer interrupt handler. It can see
your program's variable, etc, and when the callback's statements are
completed and the callback function returns control comes back out of
the interrupt handler and the CPU picks back up executing your program's
statements, starting with completion of any current one that's "in the
middle" of completion for an a/rbitrary definition of "middle"/. This
includes being in the middle of updating the two halves of a variable's
value that can't be updated with a single memory write. So, for example,
if your callback code was manipulating double precision floats along
with your non-interrupt code, then it would be very possible to have one
half of the float value glued into another half by messed up order of
memory operations. But again, as Mike described, there are many other
ways where there can be trouble if your non-interrupt code is making a
library call and then your callback code tries to use the same library
but there is no awareness that both threads of control are sharing some
memory.
I'm still not sure what you mean by "sequential" below, but hope this
helps.
-Pete
On 1/27/21 4:28 PM, John Vaughters via TriEmbed wrote:
Rodney,
Ok so does the os_timer_arm use interrupts? That is the part that confuses me.
If so than it is not sequential as I expected. But can be made practically
sequential with the bool flag concept. In my case the tasks are definitely
simple now. What kind of time frame would one expect to be acceptable in an
interrupt task?
Thanks,
John Vaughters
On Wednesday, January 27, 2021, 3:55:49 PM EST, Rodney Radford
<[email protected]> wrote:
I just looked at the Ticker library routines and they are only a few lines and
basically a wrapper around os_timer_arm which is supposed to have 1 ms
accuracy, plus or minus 1ms.
Arduino/Ticker.cpp at master · esp8266/Arduino (github.com)
The os functions are documented here:
2c-esp8266_non_os_sdk_api_reference_en (espressif.com)
Three is also an os_timer_arm_us that is supposed to be accurate to 500us (so
basically 0.5 ms) so it doesn't really get you much better resolution
But it should be accurate enough for most operations as long as you keep your
interrupt handlers short/simple
_______________________________________________
Triangle, NC Embedded Computing mailing list
To post message: [email protected]
List info: http://mail.triembed.org/mailman/listinfo/triembed_triembed.org
TriEmbed web site: http://TriEmbed.org
To unsubscribe, click link and send a blank message:
mailto:[email protected]?subject=unsubscribe
_______________________________________________
Triangle, NC Embedded Computing mailing list
To post message: [email protected]
List info: http://mail.triembed.org/mailman/listinfo/triembed_triembed.org
TriEmbed web site: http://TriEmbed.org
To unsubscribe, click link and send a blank message:
mailto:[email protected]?subject=unsubscribe
