[TriEmbed] ESP8266 Programming tip

Michael Monaghan mike at chipworks.net
Wed Jan 27 17:05:47 CST 2021


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 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 <
triembed at triembed.org> 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 <ncgadgetry at gmail.com> <ncgadgetry at gmail.com> 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: TriEmbed at triembed.org
> 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:unsubscribe-TriEmbed at bitser.net?subject=unsubscribe <unsubscribe-TriEmbed at bitser.net?subject=unsubscribe>
>
> _______________________________________________
> Triangle, NC Embedded Computing mailing list
>
> To post message: TriEmbed at triembed.org
> 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:
> unsubscribe-TriEmbed at bitser.net?subject=unsubscribe
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.triembed.org/pipermail/triembed_triembed.org/attachments/20210127/4563345b/attachment.htm>


More information about the TriEmbed mailing list