<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hi Oleg, hi everyone,<br>
    <div class="moz-cite-prefix"><br>
      first of all +1 for rethinking the current timer implementation. I
      was also having some thoughts over the last weeks on how we could
      improve the current situation (without a good solution yet,
      though).<br>
      <br>
      This mail got also rather long, so here is a short abstract:<br>
      I tried to analyze the use cases for timers in RIOT and put the
      needed functions into groups. I further put in some ideas about
      possible implementations.<br>
      <br>
      ----------<br>
      full text:<br>
      <br>
      Before thinking of the concrete structure of a remodeled timer, I
      think we should elaborate on the list of use cases for timers that
      Pakka posted below.<br>
      <br>
      I see 4 different classes of timer-related functional groups:<br>
      <br>
      1. Hardware peripherals:<br>
      This groups contains all functions that are covered directly by
      hardware peripherals. These should in my opinion be covered by
      low-level drivers. In this group I see<br>
        - PWM (already in RIOT)<br>
        - PFM (I don't know this, can it done by HW directly?)<br>
        - Input pulse lenth measurement (I have an interface started,
      but no PR for it yet)<br>
        - Watchdog (interface needed)<br>
      The accuracy of these modules depends heavily on the underlying
      hardware and should be controlled by the low-level driver
      interface (at it is done for the PWM so far).<br>
      <br>
      2. Waiting/Sleeping<br>
      This group covers the typical situation that something has to
      simply wait a certain amount of time until execution is continued.
      It can be further split into two  sub-groups:<br>
      - High resolution: waiting for for a (precise) short amount of
      time. Typically in the order of micro or even nano seconds. This
      is used i.e. for device drivers and often used in interrupt
      context. Due to the constraints and depending on the uC speed this
      might be only possible with active waiting loops, as running the
      scheduler in between might take too much time, callbacks on top of
      the low-level timer driver might work in other cases.<br>
      - Low resolution: waiting for for a mid-to-long term of time
      (speaking from a millisecond to many seconds) and used in
      thread-context. This I would imagine can be implemented by putting
      the calling thread to sleep. For a wider time span this behavior
      could be based on the low-level timer and rtt/rtc peripherals
      (basically what the vtimer is doing at the moment).<br>
      <br>
      3. Timeouts<br>
      Some threads (e.g. protocol implementations) need to react to
      timeouts, while doing other tasks when waiting. The resolution is
      typically rather low(?), in the order of mili to more seconds. For
      implementing this behavior I would imagine this can be done using
      RIOTs messaging system. Maybe a central timeout thread that is
      responsible to send timeout messages to certain tasks is a
      solution here? <br>
      <br>
      4. Periodic triggers<br>
      I think we can all agree, that RIOT to its tickless scheduling
      paradigm is not very friendly to periodic tasks at the moment. In
      this group I would see again two sub-groups:<br>
      - high resolution: these need to be very exact and are in the
      range of milli to 10s of micro seconds. Typical applications are
      control loops, as e.g. in PID controllers for motor control or
      similar. I could imagine implementation could be done by either a)
      sending regular messages to a high priority thread or b) having a
      means of periodically scheduling a task. I would vote for option
      a) which could be added to the timeout thread discussed above.<br>
      - low resolution: I would imagine this type for periodic tasks
      that do not have to be exactly precise and have periods in the
      range of 10s of milliseconds to seconds. Applications could be
      e.g. measure some temperature every 3 seconds and send value via
      network or blink an LED every 250ms or so. Implementations wise
      this could also be solved by periodic messages from a central
      timeout thread?<br>
      <br>
      To conclude: I think we should be able to create a generic timer
      infrastructure with 3 submoules:<br>
      - directly used low-level timer drivers for high-res, short
      periods<br>
      - something like our vtimer for mit to long-term waiting<br>
      - a central timer thread based on the above for sending messages
      on timeouts and for periodic triggers<br>
      <br>
      Sorry for this rather long mail, but looking forward on this
      discussion!<br>
      <br>
      Cheers,<br>
      Hauke<br>
      <br>
      <br>
      <br>
      On 18.09.2014 07:08, Pekka Nikander wrote:<br>
    </div>
    <blockquote cite="mid:AF0783DB-CF94-4EA3-A040-2CBA7E334450@iki.fi"
      type="cite">
      <blockquote type="cite">
        <pre wrap="">
There are a number different use cases where I've seen timers/counters being used:

1. PWM and PFM generation
2. Device driver helpers
3. Protocol timeout helpers
4. Input pulse length measurement
5. Real time clock, including RTC-based events such as calendar alarms
6. Periodic or delayed tasks
7. Watchdog

The API for PWM and PFM generation is likely to be quite different from a "timer" API, and therefore they probably do not apply to this discussion.  Ditto for watchdog.

The device driver helper case can be divided further into the timeout case, which is pretty similar to the protocol timeouts (see below), and other needs.  Some of the other needs have hard real time requirements, sometimes to a nanosecond-level accuracy, therefore usually requiring interrupts and sometimes counting the clock cycles for the interrupt delay, too.

Protocol timeouts have varying real-time requirements, but most of the time the accuracy is in the millisecond-scale or coarser.  (Of course, if you need to implement a (slow) serial interface completely in software, that is a different case.)  Hence, most probably most of them can be folded to the "delayed task" category, and should be implemented with the help of the scheduler (see below).

Input pulse measurement usually requires accuracy, but when exactly the value is then read from the counter may be delayed, depending on the reaction time requirements.  Furthermore, the API is likely to be different from a timer API.

RTC is a chapter of its own, and usually requires its own API.

Periodic or delayed tasks usually need to be implemented in the scheduler API, the scheduler using an underlying timer.

So, at least to me emerges the question of whether RIoT needs a "timer API" or a "timeout API" for those device drivers, protocols, and other modules that need timeouts.  

Furthermore, I am not really understanding what the "user space" is in the RIoT case.  I could imagine an "application" needing periodic tasks, real time clock, and real-time events, at least.  But "timers" as such, hmm.

So, to me, the question seems to boil down in a different way, whether there is any real need for a "generic timer" API to the user space at all.  Maybe there is, but I wasn't able to come up with any good examples that wouldn't fall into a slightly different category when thinking more closely.

(A hardware-abstraction level API is a completely different story, of course.)

--Pekka Nikander

</pre>
      </blockquote>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
devel mailing list
<a class="moz-txt-link-abbreviated" href="mailto:devel@riot-os.org">devel@riot-os.org</a>
<a class="moz-txt-link-freetext" href="http://lists.riot-os.org/mailman/listinfo/devel">http://lists.riot-os.org/mailman/listinfo/devel</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>