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 <[email protected]> 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 <[email protected]> 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: [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 _______________________________________________ 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
