[riot-devel] Question about hwtimer_now implementation..

Hauke Petersen hauke.petersen at fu-berlin.de
Wed Oct 15 11:44:07 CEST 2014

Hi Michael and everyone,

the timer structure we are using in RIOT at the moment is subject to 
some ongoing discussions at the moment. I think most of us agree, that 
we want to give the timer system a major overhaul, to make it cope 
better with the different requirements that arise from heterogeneous 
hardware support and wider time-spans.

For the current system it is important to understand the role of the 
different timers that we have at the moment:
- vtimer: timer to be used in actual user application and networking code
- hwtimer: not suited for long intervals, should be used by the vtimer 
and some device drivers that have strict timing requirements
- periph/timer: very light weight abstraction of the actual MCU hardware 
- cpu/hwtimer.c: This file simply maps peripheral timers to the channels 
of the hwtimer (you can map more than 1 peripheral timer to the hwtimer...)

Hope this helps for now, I hope we get to re-designing the timer 
infrastructure soon...


On 15.10.2014 02:27, Michael Burg wrote:
> Hello folks,
> Thanks for the replies. My problem was the timer code wasn't quite 
> making sense to me in terms of using a counting up value, and the low 
> overflow threshold.
> The FRDM-KL46Z is very similar to the Kinetis boards. The PIT module 
> has two 32-bit channels each running at 24mhz. The channels can be 
> chained together.
> The solution I came up with is to use one channel for the time now 
> value, and the other channel to provide the RIOT timer. Also, I 
> modified vtimer, hwtimer, and board timer code to use 64-bit unsigned 
> integers for the tick values - now a overflow doesn't happen until 
> some 59,000+ years from boot, not in a few seconds as was previously 
> happening.
> I highly suggest going with a different implementation for the higher 
> level timers to use a larger integer, or split it into seconds & 
> microseconds (like timex_t). A 32-bit value is just way too low since 
> a 1-mhz timer will overflow in just over a hour, or in a few seconds 
> for boards like the KL46Z or Kinetis which have a higher clock rate.
> The particular project I want to use this on has the requirement of 
> both using short timers, in microseconds & seconds, and long timers 
> that have durations in hours.
> Thanks again for the help,
> -- Michael
>> Hello Michael, Joakim and list,
>> On Tue, 14 Oct 2014 22:06:53 +0200
>> Joakim Gebart <joakim.gebart at eistec.se> wrote:
>>> Hello Michael and list,
>>> 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 work currently also on a Kinetis Cortex-M4. All PITs are down 
>> counting. My
>> temporary solution is to chain the PITs.
>>> 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
>> As I understand, the peripheral is common to all Kinetis. Who is 
>> still working
>> with the Kinetis? Can we work on cpu/kinetis_common together?
>>> 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.
>> Greetings
>> Johann
> _______________________________________________
> devel mailing list
> devel at riot-os.org
> http://lists.riot-os.org/mailman/listinfo/devel

More information about the devel mailing list