I know the subject is neither creative nor is this a very popular topic, but
since timers are critical to almost every application, I feel that there's a
need for (at least) one more discussion about this issue.
...
New Concept
----------
After thinking about this problem a little bit, I came to the conclusion that
there's only a need for one timer interface at the upper layers (i.e., user
space).
I wouldn't be that sure.
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