Implementation of the hardware timers / case of MSP430

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,

Hi,

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] https://github.com/OlegHahm/boards/tree/telosb     https://github.com/OlegHahm/RIOT/tree/telosb