[TriEmbed] ESP8266 Programming tip

[Peter Soper]

There's one more detail that finally percolated from Mike's mention of 
garbage collection (GC). The situation with interrupt handlers and 
Python has extra wrinkles vs the typical C/C++ environment. Are 
variables, even simple bool variables objects in Python? Objects can 
move as a side effect of GC. So even with what might seem like an 
"atomic" assignment like "somebool = true", if this is being executed in 
a callback that interrupted the GC while it was compacting or otherwise 
shifting stuff around the assignment might not actually be safe. It 
would just be in the category of very elusive bug. (The kind that 
manifests every 21 years or when you're showing off or really depending 
on your creation, whichever comes first.)

Does the GC disable interrupts appropriately to avoid this kind of 
situation or does it just assume nobody would mutate an object while the 
GC is in a delicate stage of relocating it? Is there an intrinsic of 
some sort to tell the Python runtime that somebool must not be moved? 
Somebody familiar with the guts of the Python implementation can 
hopefully address this.

-Pete

On 1/27/21 5:27 PM, John Vaughters via TriEmbed wrote:
> Pete,
>
> A confusion is never insulting. And I am a Mechanical Engineer, so my programming depth is not up to the level of most in this group. So the way I understand and describe can be confusing to this group I am sure. Sequential programming is just that. Every step has a place and no instruction is ever out of sequence. So there is no such thing as an interrupt in a purely sequential program and no problems with all the fun threading and interrupts. My confusion came from the idea that Ticker was simply using a method to trigger the task when the sequence location was reached. Not switch a context in the middle of anything else. So all those problems from threading and interrupts go away. So in my mind I thought Ticker was just allowing the task to be run when the time had passed and the location was reached. So in my mind, I could not see any issue with memory writes from other operations, because it would not exist in a sequential program. every action completes and moves to the next action. That was my confusion. Now I understand, it's not sequential so watch out for boogey mans.
>
> Part of that logic was due to the looking at the wrong library. The other part of the problem is not having the depth of this crowd. As you clearly pointed out and I have made clear in other discussion, I am an empirical programmer through and through, but I certainly love to learn more all the time when I have time. Of which I spent more than I expected on this, but well worth it.
>
> Thanks,
>
> John Vaughters
>
>
>
>
>
>
>
>
> On Wednesday, January 27, 2021, 4:43:47 PM EST, 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
>