[riot-devel] Question about hwtimer_now implementation..

Joakim Gebart joakim.gebart at eistec.se
Tue Oct 14 22:06:53 CEST 2014

Hello Michael and list,

On Tue, Oct 14, 2014 at 7:36 PM, Thomas Eichinger
<thomas.eichinger at fu-berlin.de> wrote:
> Hi Michael,
> On 14 Oct 2014, at 19:26, Ludwig Ortmann <ludwig.ortmann at fu-berlin.de> wrote:
>>> Specially, what should be hwarch_now()/hwtimer_arch_now be returning?
>>> Is it supposed to be the ticks from boot, or the current value of the timer
>>> from when hwtimer_arch_set*() called?
>> hwtimer_arch_now should return the "system time".
>> As the timer may overflow, this is the tick count since boot in the
>> first iteration.
> To be more specific, hwtimer is started by RIOT during startup by auto_init. It is expect to run from this point on in upcounting mode. Optimally the underlying timer is 32bit wide and driven by a 1MHz clock.

This is a problem that I ran into as well when porting RIOT to another
Freescale CPU (K60, Cortex-M4). I have 4x 32 bit timers (called the
PIT module), all running at 48 MHz, which means it will overflow after
only 90-ish seconds, or another timer running at 32.768 kHz (called
the LPTMR module), but it is only 16 bit, so it will overflow after 2
seconds. Another trivial problem is the fact that many timers on the
K60 are down counting. It is however possible to chain the PIT timers
to each other to achieve a frequency lower than 48 MHz by using two or
more timers/counters together.

I don't know how much alike the KL46Z and the K60 are, I guess that
there are many major differences (Cortex-M4 vs. Cortex-M0+), but maybe
you could find something of use for your porting efforts in my WIP
branch. I have been meaning to change the hwtimer implementation to
use the LPTMR module instead of the PIT module in order to keep
running even during STOP modes to conserve power, but I haven't gotten
around to it yet. I only work on this project when I have some spare
time in the evenings or weekends.

I have some other hwtimer questions too:

Is the hardware timer module expected not to halt when the CPU is
entering low power modes (STOP etc.)?
Is the hwtimer module expected to be able to keep any particular precision?
Does the hwtimer module need to be able to wake the CPU from sleep?

> But as Ludwig mentioned, hwtimer_arch_now() is expected to return this free running counter value.

What are the assumptions made by the OS on this timer implementation?
Is it expected to not overflow in less than X seconds? There has been
some discussions on the mailing list and the Github tracker about some
platforms with only 16 bit counters for timers and the problems that
comes with it.

> Best, Thomas
> _______________________________________________
> devel mailing list
> devel at riot-os.org
> http://lists.riot-os.org/mailman/listinfo/devel

Best regards,

More information about the devel mailing list