Hello,
I'm trying to port RIOT to a FRDM-KL46Z board (ARM cortex m0-plus based), and having a some trouble understanding how the hardware timer code is supposed to be implemented.
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?
Thanks,
-- Michael
Hi Michael,
Hello,
I'm trying to port RIOT to a FRDM-KL46Z board (ARM cortex m0-plus based), and having a some trouble understanding how the hardware timer code is supposed to be implemented.
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.
In case you didn't notice, there's documentation in core/include/hwtimer.h which says:
"The current tick count of the hardware timer"
Did you see this and found it inconclusive?
In that case would try to improve the documentation, so don't hesitate
to "yes" here 
Cheers, Ludwig
Hi Michael,
Hello Michael and list,
Hi Michael,
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@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Best regards, Joakim
Hello Michael, Joakim and list,
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
Hi Jaokim,
I try to answer your questions to the best of my knowledge...
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.)?
I am actually not sure this specified (yet).
Is the hwtimer module expected to be able to keep any particular precision?
There is no official RIOT-wide requirement on hwtimer precision so far. There are however some device (i.e. radio) drivers, that do need a certain precision. Unifying this over all platforms is however still work in progress.
Does the hwtimer module need to be able to wake the CPU from sleep?
Depends on the answer of your first question...
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.
In general the hwtimer is allowed to overflow and there is no specification on the period this happens. Providing a timer abstraction that can cope with different overflow intervals and different timer-widths is something we are working on, though.
Cheers, Hauke