[TriEmbed] ESP8266 Programming tip

Wed Jan 27 17:41:56 CST 2021

Yes Mike, and now I realize I only sent the email below to Pete. It shows the library I was looking at that caused my confusion and also how I learned to look up the actual library I am using via the PlatformIO IDE. A very nice feature. I am really starting to like VS Code too. Played around with it several years ago, Wow! has it come along.

Totally on page with what everyone was saying now. Not fully competent in it, but I can see how it relates to the same issues as threading, so I have a feel for it, just not fully sure how to deal with it. But I think my current application escapes the dragons `,~)

Thanks,

John Vaughters

**************** Email meant for the group**************************

Pete,

Yes, ok! that all clears it up, but I am not going to say I have a handle on all you said. So it does interrupt the code, that is that is the part I was missing. I originally looked at this one below, which is why I kept thinking it was just millis() and micro() in some sequential arrangement. But that is not event the correct library for ESP. So just another wrench in my thinking. But I also learned in this exercise how to get to the code through the PlatformIO IDE a little more efficiently. So that should solve looking at inapplicable LIbs.

https://github.com/sstaub/Ticker/blob/master/Ticker.cpp

And definitely not torture, I appreciate all the depth of this crowd. I wish I had more time to do this stuff. Oh wait... did I just wish for more torture `,~)

All I am curious about now is what is an acceptable interrupt time. To me the using the timer with a flag is less effective for what I was going for, although it does work, but why not just use millis() directly. The whole point of using the library was because I like how easy Timer code looks and reads. In higher level programming with full OS support. Timers are very nice to use and the traps less ominous. 

Good Stuff all the way around and very enlightening.

Again I appreciate all the discussions.

Thanks,

John Vaughters

On Wednesday, January 27, 2021, 6:06:38 PM EST, Michael Monaghan via TriEmbed <triembed at triembed.org> 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 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.  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 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 arbitrary 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> 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
>> 
>> 
> 
> _______________________________________________
> 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
> 
> 

_______________________________________________
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