Hello,
I was wondering how much hwtimers were used by the RIOT OS core for its internal needs.
As I am working on implementations of MAC/RDC protocols, I will probably need to use some hardware timers (for timing/synchronisation purposes). I was wondering whether there would be enough hwtimer instances available...
In that sense, I see that in the case of the MSP430F16x MCU (that is used in TelosB motes), the hwtimer module is implemented using the TimerA module, which offers 3 compare registers ("TimerA3").
However, these MCUs also offer a "TimerB7" module (with a more comfy amount of 7 compare registers). Is there a reason not to use this TimerB?
Regards,
Hi K�vin,
I was wondering how much hwtimers were used by the RIOT OS core for
its internal needs.
since RIOT's scheduler is tickless, the kernel itself does not require any
hwtimers.
As I am working on implementations of MAC/RDC protocols, I will
probably need to use some hardware timers (for
timing/synchronisation purposes). I was wondering whether there
would be enough hwtimer instances available...
Several drivers (e.g., for the SHT11 or the SD card) are using hwtimers, but
there should be usually enough timers left.
In that sense, I see that in the case of the MSP430F16x MCU (that is
used in TelosB motes), the hwtimer module is implemented using the
TimerA module, which offers 3 compare registers ("TimerA3").
However, these MCUs also offer a "TimerB7" module (with a more comfy
amount of 7 compare registers). Is there a reason not to use this
TimerB?
I'm not aware of any reason not to use the TimerB module, it's just not
implemented yet, but that shouldn't be too difficult.
Cheers,
Oleg
Le 21/08/2013 11:55, Oleg Hahm a �crit :
Hi K�vin,
I was wondering how much hwtimers were used by the RIOT OS core for
its internal needs.
since RIOT's scheduler is tickless, the kernel itself does not require any
hwtimers.
As I am working on implementations of MAC/RDC protocols, I will
probably need to use some hardware timers (for
timing/synchronisation purposes). I was wondering whether there
would be enough hwtimer instances available...
Several drivers (e.g., for the SHT11 or the SD card) are using hwtimers, but
there should be usually enough timers left.
That's nice; however, I feel that only 3 or 4 available hwtimer instances (as is the case for most platforms if I understand correctly) may cause a problem if some "timer-hungry" modules (like some MAC protocols I plan to implement) are used together with applications that also need precise timing; doubling that number of available hwtimers may prove useful...
It seems that one of the ARM implementation of the hwtimer module (in 'RIOT/cpu/lpc_common/hwtimer_cpu.c') has been designed to use the comparators of three different timers (allowing for up to 12 hwtimers instance)... Isn't it an interesting lead to follow?
In that sense, I see that in the case of the MSP430F16x MCU (that is
used in TelosB motes), the hwtimer module is implemented using the
TimerA module, which offers 3 compare registers ("TimerA3").
However, these MCUs also offer a "TimerB7" module (with a more comfy
amount of 7 compare registers). Is there a reason not to use this
TimerB?
I'm not aware of any reason not to use the TimerB module, it's just not
implemented yet, but that shouldn't be too difficult.
I think I will submit a pull request to that end.
Cheers,
Oleg
Thank you,
Le 21/08/2013 15:15, Kaspar Schleiser a �crit :
Hi,
It would be interesting to know how precise exactly you need your timing
and whether that goal could be reached using some kind timer
abstraction. (vtimer, I'm looking at you!)
Cheers,
Kaspar
_______________________________________________
devel mailing list
devel@riot-os.org
http://lists.riot-os.org/mailman/listinfo/devel
Well, I need it to be as precise as possible, since the MAC/RDC layer control the behavior of the radio transceiver, thus being reponsible of the accuracy, the performance of the wireless (802.15.4) networking; also, I need to be able to shutdown that transceiver as much as possible (without compromising networking performance) in order to spare energy.
Moreover, since this is a system extension, it is better to implement it with as few overhead as possible; since the 'vtimer' module is implemented by using the 'hwtimer' core system, it is much more "economic" to use the latter.
However, vtimer is certainly an interesting asset for the application-level code: I will try to use it---instead of raw hwtimers---when I build the test applications for my network stack extensions.
Regards,
Le 21/08/2013 14:29, ROUSSEL K�vin a �crit :
Le 21/08/2013 11:55, Oleg Hahm a �crit :
I'm not aware of any reason not to use the TimerB module, it's just not
implemented yet, but that shouldn't be too difficult.
I think I will submit a pull request to that end.
Cheers,
Oleg
Thank you,
Well, I'm working on it right now. While doing this, I stumbled upon something that I find a bit strange.
In the 'hwtimer_msp430.c' module, the TIMERA0 interrupt handler is tasked with incrementing the 'timer_round' variable, which is---if I understand correctly---containing the 16 most significant bits of the hardware timer reference counter (thus being able to count on 32-bit even on a MSP430).
Shouldn't this incrementation be instead done in the TIMERA1 interrupt handler, when the TAIFG flag is set? It seems much more appropriate (we can't even be sure that the CCR0 comparator is set at any time).
Another related problem is that the TAIE/TAIFG mechanism that is supposed to detect that situation is disabled in the init function.
Plus: the 'hwtimer_cc430.c' module seems to handle the counter overflow the way I say above. This one doesn't seem to handle the 32-bit extension to the hardware counter though (maybe is that because this module is lagging behind the msp430gcc one?)
Should I also change all of this while I'm on it?
Hi,
Well, I'm working on it right now. While doing this, I stumbled upon something that I find a bit strange.
In the 'hwtimer_msp430.c' module, the TIMERA0 interrupt handler is tasked with incrementing the 'timer_round' variable, which is---if I understand correctly---containing the 16 most significant bits of the hardware timer reference counter (thus being able to count on 32-bit even on a MSP430).
yes thats correct.
Shouldn't this incrementation be instead done in the TIMERA1 interrupt handler, when the TAIFG flag is set? It seems much more appropriate (we can't even be sure that the CCR0 comparator is set at any time).
No because this interrupt is only enabled when setting a timer, the TIMERA0 is wasted to only count the overflows.
Another related problem is that the TAIE/TAIFG mechanism that is supposed to detect that situation is disabled in the init function.
That's no problem because hwtimer_arch_init does a TA0_enable_interrupt(0) to archive this.
Plus: the 'hwtimer_cc430.c' module seems to handle the counter overflow the way I say above. This one doesn't seem to handle the 32-bit extension to the hardware counter though (maybe is that because this module is lagging behind the msp430gcc one?)
Yes the cc430 does not use the overflow only the msp430-common.
But even there it is broken at the moment:
hwtimer_arch_now does not return the full number with the overflow and in hwtimer_arch_set an unsigned int is too small on a msp430 to hold an unsigned 32bit int.
I am trying to resolve this.
Regards,
Milan
Le 21/08/2013 17:28, Milan Babel a �crit :
Yes the cc430 does not use the overflow only the msp430-common.
But even there it is broken at the moment:
hwtimer_arch_now does not return the full number with the overflow and
in hwtimer_arch_set an unsigned int is too small on a msp430 to hold an
unsigned 32bit int.
I am trying to resolve this.
Regards,
Milan
Hello,
I'm interested into timer-related issues. Is there a thread in the RIOT issue tracker where this matter is discussed?
Regards,
No, not at the moment, while porting RIOT to the wsn430 I also added this overflow mechanism amoung with some smaller changes
https://github.com/RIOT-OS/RIOT/commit/edb34b73c0aaed0bca022580f92f9ff01473bc64
But this week I first noticed that not some lines keep unchanged. As soon as I get an anwswer to the question why it was only partly merged I can start a discussion on how to resolve this issue.
Regards,
Milan
Hi Milan, hi K�vin,
But this week I first noticed that not some lines keep unchanged. As
soon as I get an anwswer to the question why it was only partly
merged I can start a discussion on how to resolve this issue.
most likely you have to blame me. I guess, I wasn't careful enough while
resolving some merge conflicts and it was before the new development
procedures were created. Hence, nobody reviewed the merge.
Sorry for the mess.
Cheers,
Oleg
Hi K�vin,
>>In that sense, I see that in the case of the MSP430F16x MCU (that is
>>used in TelosB motes), the hwtimer module is implemented using the
>>TimerA module, which offers 3 compare registers ("TimerA3").
>>However, these MCUs also offer a "TimerB7" module (with a more comfy
>>amount of 7 compare registers). Is there a reason not to use this
>>TimerB?
>I'm not aware of any reason not to use the TimerB module, it's just not
>implemented yet, but that shouldn't be too difficult.
I think I will submit a pull request to that end.
don't you need on TimerB CCR (CCR1) for the SFD from cc2420 on the TelosB?
Have you already ported RIOT to the TelosB? I've created a basic version (just
with UART) in my fork [1], but perhaps you're already a step further.
Cheers,
Oleg
[1] GitHub - OlegHahm/boards at telosb
https://github.com/OlegHahm/RIOT/tree/telosb