Timer Task Force

Timer Task Force

This page is used to collect requirements and suggestions concerning a hwtimer/vtimer/RTC redesign.

requirements

• very efficient timers for use in time-critical drivers
• easy-to-use interface

API

• Wait for a time period
• Await a point in time
• Wait for a (past) time + x
• (use RTC if available for super-long-time timers)

design questions

• what granularity to use? msec,usec,nsec, timer ticks, a combination?

current state:

• timer.h: timer hardware abstraction, using ticks

• hwtimer: low-level timer multiplexing, one timer.h timer using the same ticks

• vtimer: higher-level timer multiplexing, using one hwtimer, usecs

• first two look OK, are stable

• vtimer sucks

observations

• at 70Mhz ticks, theoretical timer granularity can reach 14ns. Factor 10 speed increase is probable before the next timer revamp. That means that we have to use nanoseconds granularity (in the API) if we want to not waste hardware potential now or in the future. That also means that 32bit timer values would overflow in seconds.
• using microseconds, 32bit can hold 71 minutes. Sounds like not much to me.
• using miliseconds, 32bit can hold 49days.
• a 64bit unsigned value can hold >584years in nanoseconds.
• using 64bit values simplifies code a lot (we could use signed values for easy comparision or the representation of negative time values, in code "c=a-b" looks a lot more readable than "c.sec=a.sec-b.sec, c.nsec=a.nsec-b.nsec" and handling overflows
• not sure how much this affects code size (one 32bit value vs. a struct with two 32bit values vs. one 64bit values) or how 8bit systems handle 64bit integers