<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p>John,</p>
    <p>  Forgive me if I'm missing something about your questions and
      this is insulting your intelligence.</p>
    <p>   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 a<i>rbitrary definition of "middle"</i>. 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.<br>
    </p>
    <p>  I'm still not sure what you mean by "sequential" below, but
      hope this helps.</p>
    <p>-Pete<br>
    </p>
    <div class="moz-cite-prefix">On 1/27/21 4:28 PM, John Vaughters via
      TriEmbed wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:1321137503.377635.1611782926170@mail.yahoo.com">
      <pre class="moz-quote-pre" wrap="">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 <a class="moz-txt-link-rfc2396E" href="mailto:ncgadgetry@gmail.com"><ncgadgetry@gmail.com></a> 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: <a class="moz-txt-link-abbreviated" href="mailto:TriEmbed@triembed.org">TriEmbed@triembed.org</a>
List info: <a class="moz-txt-link-freetext" href="http://mail.triembed.org/mailman/listinfo/triembed_triembed.org">http://mail.triembed.org/mailman/listinfo/triembed_triembed.org</a>
TriEmbed web site: <a class="moz-txt-link-freetext" href="http://TriEmbed.org">http://TriEmbed.org</a>
To unsubscribe, click link and send a blank message: <a class="moz-txt-link-freetext" href="mailto:unsubscribe-TriEmbed@bitser.net?subject=unsubscribe">mailto:unsubscribe-TriEmbed@bitser.net?subject=unsubscribe</a>

</pre>
    </blockquote>
  </body>
</html>