<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 1/27/21 6:05 PM, Michael Monaghan
      via TriEmbed wrote:<br>
    </div>
    <blockquote type="cite"
cite="mid:CAGToJnb_nW9h9zoU1KfNaE=_Bz45Y=FhZ-PZPFDnr5yHkK-H=Q@mail.gmail.com">
      <meta http-equiv="content-type" content="text/html; charset=UTF-8">
      <div dir="ltr">Pete and John,
        <div><br>
        </div>
        <div>I'm suspecting we are referencing different libraries. 
          Sure enough there are several Arduino libraries that answer to
          Ticker.  The most popular is the one the Pete referenced
          above.  It is a thin wrap around the os_timer_setrfn,
          os_timer_arm and os_timer_disarm functions from ExpressIf. 
          See <a
href="https://www.espressif.com/sites/default/files/documentation/2c-esp8266_non_os_sdk_api_reference_en.pdf"
            moz-do-not-send="true">Chapter 3.1</a> for, um,
          "documentation?".  Assuming this is the version John is using,
          it is similar to the implementation I'm using in Micropython. 
          We've been extensively trained to treat these as software
          interrupts with all the "here there be dragons" warnings.<br>
          <br>
          Pete I respectfully disagree about stack and reentry.  As with
          any type of interrupt, the return address has to go somewhere,
          and if it gets called more than once while a previous copy is
        </div>
      </div>
    </blockquote>
    <p>Nested interrupts store state and registers on the stack the same
      as the original one. Nested interrupts happen all the time with
      some processors. <br>
    </p>
    <p> But not at the same priority level! Come to think of it, I don't
      think a second timer interrupt is possible, is it? Isn't it the
      case that an interrupt at a given priority level would be disabled
      until there was a return from that interrupt? I'm leaning toward
      the crash having been caused by the callback code stepping on
      something. But I confess I haven't been very close to the metal
      with ARM compared to some other processors.<br>
    </p>
    <p>-Pete<br>
    </p>
    <blockquote type="cite"
cite="mid:CAGToJnb_nW9h9zoU1KfNaE=_Bz45Y=FhZ-PZPFDnr5yHkK-H=Q@mail.gmail.com">
      <div dir="ltr">
        <div>executing, chances are you're in a run away state with no
          chance of recovery.  I'm super curious as to what is calling
          these now.  Is there service code running below us or
          additional checks places in by the compiler?<br>
        </div>
        <div><br>
        </div>
        <div>John you might want to look at something like <a
            href="https://www.arduino.cc/en/Tutorial/MultipleBlinks"
            moz-do-not-send="true">Scheduler</a>.  It is yield based
          round robin scheduling.  In other words when you execute a
          yield or delay, the eldest process in queue gets the
          processor.  By design, you won't be modifying anything at
          these times.  It is designed to work in a way that may be more
          in line with your expectations and will allow all sorts of
          activities forbidden in other pseudo threading libraries.  You
          don't have to worry at all about smashing variables.  You just
          have to remember to yield.  <a
            href="https://github.com/srmq/esp8266-scheduler"
            moz-do-not-send="true">There are patches to extend it to the
            ESP8266</a> within Arduino land.</div>
        <div><br>
        </div>
        <div>Discussion based on confusion often leads to learning in my
          experience.  I have a ton of admiration and respect for you
          both.  I learn something new almost every time I read your
          posts.</div>
        <div><br>
        </div>
        <div>Mike</div>
      </div>
      <br>
      <div class="gmail_quote">
        <div dir="ltr" class="gmail_attr">On Wed, Jan 27, 2021 at 4:43
          PM Peter Soper via TriEmbed <<a
            href="mailto:triembed@triembed.org" moz-do-not-send="true">triembed@triembed.org</a>>
          wrote:<br>
        </div>
        <blockquote class="gmail_quote" style="margin:0px 0px 0px
          0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
          <div>
            <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>On 1/27/21 4:28 PM, John Vaughters via TriEmbed wrote:<br>
            </div>
            <blockquote type="cite">
              <pre>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 href="mailto:ncgadgetry@gmail.com" target="_blank" moz-do-not-send="true"><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 (<a href="http://github.com" target="_blank" moz-do-not-send="true">github.com</a>)

The os functions are documented here:

2c-esp8266_non_os_sdk_api_reference_en (<a href="http://espressif.com" target="_blank" moz-do-not-send="true">espressif.com</a>)

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 href="mailto:TriEmbed@triembed.org" target="_blank" moz-do-not-send="true">TriEmbed@triembed.org</a>
List info: <a href="http://mail.triembed.org/mailman/listinfo/triembed_triembed.org" target="_blank" moz-do-not-send="true">http://mail.triembed.org/mailman/listinfo/triembed_triembed.org</a>
TriEmbed web site: <a href="http://TriEmbed.org" target="_blank" moz-do-not-send="true">http://TriEmbed.org</a>
To unsubscribe, click link and send a blank message: <a href="mailto:unsubscribe-TriEmbed@bitser.net?subject=unsubscribe" target="_blank" moz-do-not-send="true">mailto:unsubscribe-TriEmbed@bitser.net?subject=unsubscribe</a>

</pre>
            </blockquote>
          </div>
          _______________________________________________<br>
          Triangle, NC Embedded Computing mailing list<br>
          <br>
          To post message: <a href="mailto:TriEmbed@triembed.org"
            target="_blank" moz-do-not-send="true">TriEmbed@triembed.org</a><br>
          List info: <a
            href="http://mail.triembed.org/mailman/listinfo/triembed_triembed.org"
            rel="noreferrer" target="_blank" moz-do-not-send="true">http://mail.triembed.org/mailman/listinfo/triembed_triembed.org</a><br>
          TriEmbed web site: <a href="http://TriEmbed.org"
            rel="noreferrer" target="_blank" moz-do-not-send="true">http://TriEmbed.org</a><br>
          To unsubscribe, click link and send a blank message: mailto:<a
            href="mailto:unsubscribe-TriEmbed@bitser.net"
            target="_blank" moz-do-not-send="true">unsubscribe-TriEmbed@bitser.net</a>?subject=unsubscribe<br>
          <br>
        </blockquote>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <pre class="moz-quote-pre" wrap="">_______________________________________________
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>