[TriEmbed] ESP8266 Programming tip

Wed Jan 27 13:51:33 CST 2021

John,

You are correct.  The ESP8266 is not multi-threading.  The Task is however
interrupting execution of the assembly code when it times out.  So instead
of getting a nice clean break at the end of your current code line, this
can occur anywhere.  An example might be strcpy.  It's several assembly
instructions long.  So when the timer runs out, we don't know the status of
that copy.  Are the pointers updated?  Are we half way through?  Is a
garbage collection in progress?  We simply don't know.  By contrast, bit
operators compile to a single offencive instruction.  Chances of collision
are much lower, and thus why they make the recommendation to use them.
Despite the differences, the implementation behind C, C++ and Python are
almost identical.

Best of luck!
Mike

On Tue, Jan 26, 2021 at 4:41 PM John Vaughters <jvaughters04 at yahoo.com>
wrote:

> Mike,
>
> Maybe I am misunderstanding. To my knowledge the ESP8266 is not
> multi-threading. If this library is working as I expect, it is all
> happening sequential through millis() and micro(). Now I admit that I based
> that statement off the Ticker Lib from Arduino and this library is
> different, so I have not verified this still to be the case. But assuming
> it is, we should not get any kind of race condition if it is sequential. If
> my tasks are fast enough, the watchdog should be happy too.
>
> I ended up making a task for every second to create a 1 ms task to fill an
> array of 20 values with a constant looping increment var and a scheduled
> task to fire 25 ms later to shut off the 1 ms task. So every second it
> fires two tasks the first task is shut down by the second task 25 ms later
> and then averages the 20 readings. All global vars which I use generously
> in such small programs. I have a feeling the Ticker folks are covering
> their bases on the flag setting concept, just to help people be successful.
> I think if you use it within certain parameters, you should be ok.
>
> Never made the jump to python, C is my go to, but I muddle through C++
> pretty good. However, every time I delved into python, I liked it alot.
> Maybe REPL will be the motivation to stick with it a bit. Truth is I am
> kind of language confused. I use so many so often that I cannot keep it all
> straight. But I always feel comfortable in C. But references are your
> friend when bouncing the way I do. To me, it's the basics. I know what
> programming can do, I just need to find the syntax. But I am quite amazed
> by the newer languages and how they make things so easy. C# being a great
> example. I always find PHP manageable. Python REPL may be the thing for my
> robots, I love the concept.
>
> So far the new timer method is working like a charm, but I will let it
> soak. Now I have to give back some time to work. `,~)
>
> John Vaughters
>
>
>
> On Tuesday, January 26, 2021, 3:39:49 PM EST, Michael Monaghan via
> TriEmbed <triembed at triembed.org> wrote:
>
>
>
>
>
> John,
>
> > I am not sure why you could not change a variable if it is global and
> done fast.
>
> Because we have no idea what state the variables were in when the service
> routine was called.  Were they being inspected by main code?  Or modified?
> Perhaps Garbage collection is in progress?  Without a bit of blocking code
> to demand a known state, we're flying blind.
>
> > I may try that when I get around to the Robotics with the ESP32. That is
> very interesting for sure. I like the REPL concept alot.
> Robotics are on the wish list... I just have about 3 million lines of code
> before I can take on another hobby.
>
> Python is my go-to language.  Only rarely do I have to use C++ to force
> the solution.
>
> Mike
>
> On Tue, Jan 26, 2021 at 2:45 PM John Vaughters via TriEmbed <
> triembed at triembed.org> wrote:
> > Carl,
> >
> > I do not NEED the delay, I just need to read the A0 at 1 ms intervals. I
> don't need to stop the processor for that, I need to code it responsibly if
> I want it to work the best way I want. I was being lazy expecting my time
> frame to be well within the parameters required for the desired end result.
> And the solution I finally did does work, but I have now been motivated to
> make it better.
> >
> > Mike,
> >
> > Good info thanks. I have not verified, but yes I am thinking I may have
> violated the watch dog. I am not sure why you could not change a variable
> if it is global and done fast. I also dug a little deeper and the ticker I
> am using is not the same that you find in Arduino. The one I am using is
> suggesting the flag concept as I pointed out in the first post and is
> working and the idea you also reinforced. I guess in general it is the
> simplest guarantee for accurate loop integrity. It definitely works quite
> well. I have looked at the micro-python. I may try that when I get around
> to the Robotics with the ESP32. That is very interesting for sure. I like
> the REPL concept alot.
> >
> > I can spend a little more time for a better solution. Dang it and I
> thought I was done with this part. `,~)
> >
> > Thanks,
> >
> > John Vaughters
> >
> > _______________________________________________
> > 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.triembed.org/pipermail/triembed_triembed.org/attachments/20210127/f3f882b8/attachment.htm>