[TriEmbed] ESP8266 Programming tip

Michael Monaghan mike at chipworks.net
Tue Jan 26 12:38:56 CST 2021


John,

I've been down this road.  Watch for the potholes.  Ticker Tasks are
interrupt like (no matter what you might read). Tasks are not guaranteed to
be re-entrant safe and you must feed the dogs if you dwell in the routine.
Use single bit flags to avoid code collisions.

Get the job done quickly and return.  If a second instance fires off, then
chances are good stack space will be exhausted.  (Because if the first call
didn't finish and the second call is just starting, chances requests are
firing too frequently to ensure a timely completion.)  There are some
tactics depending on use case.  When you enter your service code, disable
Tickers and Interrupts to prevent re-entry, then enable them on exit.  In
this state you can hang out until the Software or Hardware Watchdog
timeout.  When a watchdog fires, the exception report will have something
like *rst cause:4* or *rst cause:2* to indicate the Hardware or Software
watchdog caused reset.  You can work around that by disabling Tickers,
Interrupts and feeding the dogs.  You could also disable to dogs, but I
really don't recommend it.  That can cause a lock with no way out.  Use
care when feeding the dogs by hand.

Because we have no idea where we are in code when one of these fires,
modifying variables and allocating memory are frowned upon.  You could be
processing a variable character by character in your main code and write
over the whole thing from the Ticker Task creating an unknown state.  They
reason bits flags are recommends is they compile to a single offensive
instruction.  Worst case your Task sets the flag while the main code is
still processing the previous request.  That can be detected and handled if
it becomes an issue.  I use something like this:

Main loop {
  if flag_double_dip {
    // log an error so we know we are calling mainline service code too
quickly
  }
  if flag_doet {
    // reset the flag FIRST so the Ticker Task can set it again if needed
    clear flag_doet
    do some stuff
  }
}

Task_callback {
  if flag_doet {
    // Houston we have a problem, set an error flag
    set flag_double_dip
  }
  set flag_doet
}

Alternate_task_callback{
  //disable Ticker and IRQ
  //do the things
  //feed the dogs
  //do more things
  //feed the dogs
  //enableTicker and IRQ
}

Another way you can handle this is to run up to your delay but instead of a
delay, schedule another Ticker Task and carry on code from there.  Best of
luck!

Mike

On Tue, Jan 26, 2021 at 12:23 PM John Vaughters via TriEmbed <
triembed at triembed.org> wrote:

>
> You see that, now you guys are making me dig and I was happy with my
> solution. `,~)
>
> ticker lib uses millis() and micro() and not interrupt, but with your
> obsessed curiosities, now I may have found the real problem. You are not
> supposed to use delay() in the task. And I did use delay(), so I probably
> need to change the long task to do a task with set number of ticks at my
> delay time instead of using the delay. Which is much more responsible
> programming anyway. This will solve it for sure, now that I know how Ticker
> works.
>
> Back to the testing with me. Oh well, in the end you guys are making me
> better.
>
> Thanks,
>
> John Vaughters
>
>
>
>
>
> On Tuesday, January 26, 2021, 11:49:44 AM EST, Carl Nobile <
> carl.nobile at gmail.com> wrote:
>
>
>
>
>
> I wonder if your code used an interrupt that couldn't handle the 25 ms
> time period.
> ~Carl
>
> On Tue, Jan 26, 2021 at 11:10 AM John Vaughters via TriEmbed <
> triembed at triembed.org> wrote:
> > Pete,
> >
> > There is a debug port on the board for sure, not sure if it qualifies as
> JTAG. I've never actually used a debugger on a micro-processor, only on
> regular desktop/server programming. I never invested the time or money to
> get that up to speed. I will say it dumps a bunch of hex code to the serial
> port when it crashes and I did not really look at that either. The reason
> being that I never ran into a limitation that prevented my pragmatic
> application results and I'm more interested in the end result than the
> finer details. I just hack until I get it to work. Same goes for
> oscilloscopes and electronics, I just use basic concepts and practices and
> usually get it to work. However, I definitely want to gear up with
> oscilloscopes and logic analyzers one day. But until I have the time to
> play, no need in putting out the dough for it to sit on the shelf. This
> attitude is from experience of too many things sitting on the shelf.
> >
> > There are two timers on the board, but one is used for wifi. The other
> one is available, and I might be able to use that with better results, but
> the Ticker library does magic in the background and appears to act like a
> simple task scheduler. So in the code it appears you are setting tasks, but
> behind the scenes I have not investigated what it is actually doing. For
> sure if you use the single timer you are limited to one task or a tight
> management of tasks on that timer. I'm not quite sure because I did not go
> that route, I am just parroting my perception of what I read. So I opted
> for the code appearance of tasking through the Ticker library to make my
> code more readable. It seems to work great so far and I am close to being
> done with my wifi modbus device. The next application will be a very simple
> wifi serial to tcp converter to be able to use with micro-processors that
> have no network connections. This will allow modbus over TCP via serial
> conversion. You get the sense I like modbus? `,~) What I found so far is
> that the serial to tcp application is already solved and out there in
> multiple forms, so I just need to pick one and give it a go.
> >
> > I never really exposed my end applications; it is for my home SCADA
> system that monitors energy use for the goal of reducing energy while
> remaining comfortable. Basically, I am trying to use technology to "Stick
> it to the Man" `,~) Oh and have fun learning along the way. I'm pretty sure
> on just the electric controls implemented on the hot water heater alone I
> have saved enough to pay for my electronics. So anything above that is pay
> dirt.
> >
> > For Robotics, I am really liking the ESP32 combined with some nano
> arduinos as specialized processors. Top priority being a weed eater head
> remote controlled lawnmower to minimize allergen exposure. And for the
> record that has been on the task list for years and I wouldn't be surprised
> if it waits years longer, but hey the technology keeps making the idea
> easier as time flies by.
> >
> > Dreams are good, jobs are better! `,~)
> >
> > Bottom line is I am loving the ESP line of products.
> >
> > John Vaughters
> >
> >
> >
> >
> >
> >
> > On Tuesday, January 26, 2021, 10:20:04 AM EST, Pete Soper via TriEmbed <
> triembed at triembed.org> wrote:
> >
> >
> >
> >
> >
> > Does ESP-12E support JTAG debugging? It might be interesting to figure
> > out what the crash is about (maybe there isn't actually a task scheduler
> > present and if you don't "yield" back you've violated the API
> > contract?). But you've stuck with the pragmatic approach, John. Thanks
> > for the tip.
> >
> > Getting  SparkFun "Micromod" boards with ESP32 and ESP8266 (no idea what
> > flavors) and the "All the Pins" carrier board today. But these go on the
> > shelf as I wait for the RP2040 Micromod board, and my stack is pushed
> > anyway. Particle Land, here I come. :-)
> >
> > -Pete
> >
> > On 1/26/21 10:03 AM, John Vaughters via TriEmbed wrote:
> >> In my playing around with the ESP-12e's that I have, I found something
> that may save someone some time. Using the Ticker library to schedule a
> task, I quickly found out that the task better be quick or it will crash
> the program. To define quick, my task was maybe 25ms, which was enough to
> crash the program. To get around this I found on the web a quick tip that
> made alot of sense. Just use the Ticker task to flip a bool and then have
> an if statement run the task and reset the bool.
> >>
> >> It's not what I consider a great programming technique, but I consider
> it a valid workaround on the limitation. And it still beats running the
> task on every loop cycle.
> >>
> >> I am certainly open to other suggestions, but it works quite well and I
> will be sticking with it for now.
> >>
> >> 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
> >
> >
> >
> > _______________________________________________
> > 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
> >
> >
>
>
> --
>
> -------------------------------------------------------------------------------
> Carl J. Nobile (Software Engineer)
> carl.nobile at gmail.com
>
> -------------------------------------------------------------------------------
>
>
> _______________________________________________
> 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/20210126/3cc554f5/attachment.htm>


More information about the TriEmbed mailing list