On 1/27/21 6:05 PM, Michael Monaghan via TriEmbed wrote:
Pete and John,
I'm suspecting we are referencing different libraries. Sure enough
there are several Arduino libraries that answer to Ticker. The most
popular is the one the Pete referenced above. It is a thin wrap
around the os_timer_setrfn, os_timer_arm and os_timer_disarm
functions from ExpressIf. See Chapter 3.1
<https://www.espressif.com/sites/default/files/documentation/2c-esp8266_non_os_sdk_api_reference_en.pdf>
for, um, "documentation?". Assuming this is the version John is
using, it is similar to the implementation I'm using in Micropython.
We've been extensively trained to treat these as software interrupts
with all the "here there be dragons" warnings.
Pete I respectfully disagree about stack and reentry. As with any
type of interrupt, the return address has to go somewhere, and if it
gets called more than once while a previous copy is
Nested interrupts store state and registers on the stack the same as the
original one. Nested interrupts happen all the time with some processors.
But not at the same priority level! Come to think of it, I don't think a
second timer interrupt is possible, is it? Isn't it the case that an
interrupt at a given priority level would be disabled until there was a
return from that interrupt? I'm leaning toward the crash having been
caused by the callback code stepping on something. But I confess I
haven't been very close to the metal with ARM compared to some other
processors.
-Pete
executing, chances are you're in a run away state with no chance of
recovery. I'm super curious as to what is calling these now. Is
there service code running below us or additional checks places in by
the compiler?
John you might want to look at something like Scheduler
<https://www.arduino.cc/en/Tutorial/MultipleBlinks>. It is yield
based round robin scheduling. In other words when you execute a yield
or delay, the eldest process in queue gets the processor. By design,
you won't be modifying anything at these times. It is designed to
work in a way that may be more in line with your expectations and will
allow all sorts of activities forbidden in other pseudo threading
libraries. You don't have to worry at all about smashing variables.
You just have to remember to yield. There are patches to extend it to
the ESP8266 <https://github.com/srmq/esp8266-scheduler> within Arduino
land.
Discussion based on confusion often leads to learning in my
experience. I have a ton of admiration and respect for you both. I
learn something new almost every time I read your posts.
Mike
On Wed, Jan 27, 2021 at 4:43 PM Peter Soper via TriEmbed
<[email protected] <mailto:[email protected]>> wrote:
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]> <mailto:[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
<http://github.com>)
The os functions are documented here:
2c-esp8266_non_os_sdk_api_reference_en (espressif.com
<http://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] <mailto:[email protected]>
List info:http://mail.triembed.org/mailman/listinfo/triembed_triembed.org
<http://mail.triembed.org/mailman/listinfo/triembed_triembed.org>
TriEmbed web site:http://TriEmbed.org <http://TriEmbed.org>
To unsubscribe, click link and send a blank
message:mailto:[email protected]?subject=unsubscribe
<mailto:[email protected]?subject=unsubscribe>
_______________________________________________
Triangle, NC Embedded Computing mailing list
To post message: [email protected] <mailto:[email protected]>
List info:
http://mail.triembed.org/mailman/listinfo/triembed_triembed.org
<http://mail.triembed.org/mailman/listinfo/triembed_triembed.org>
TriEmbed web site: http://TriEmbed.org <http://TriEmbed.org>
To unsubscribe, click link and send a blank message:
mailto:[email protected]
<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
_______________________________________________
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
