Hi,
I am working at the moment on a port of RIOT to the wsn430, a sensor node developed by INRIA. 1024 nodes of this type can be used by their senslab (http://senslab.info).
This node is driven by a msp430f1611 which is really close to the msp430f1612 used in the msp-430h.
I got already a working Hello-World and a shell, but now I have troubles with the vtimer.
The hwtimer seems to work ok, when using hwtimer_wait(1000*1000) for 1sec or hwtimer_wait(1000*1000*10) for 10sec.
But whenever I use vtimer_sleep the thread never gets back.
As soon as I init vtimer I see an Interrupt for timer 2 fired every ~35 ticks.
Before I set the vtimer_sleep I will output the current time.
vtimer, NOW : 4096 199022815
When I try to use vtimer_sleep for 1 sec I get:
vtimer_set(): New timer. Offset: 1 0
vtimer_set(): Absolute: 20480 995892037
vtimer_set(): NOW: 32768 1591793952
vtimer_set(): setting long_term
The printf for the vtimer_now is executed right after the output of the absolute.
A second thread wich was paused 1sec with the hwtimer_wait() and started before the vtimer_sleep says
2nd THREAD: vtimer, NOW : 6987776 135797637
I am really unsure what the problem could be. In general the timer should work on the msp430f1611 the same way it works on the msp430f1612. I hope I set the ACLK the right way, but if it would be that high hwtimer_wait would not really pause a thread.
Regards,
Milan
Hi Milan!
But whenever I use vtimer_sleep the thread never gets back.
As soon as I init vtimer I see an Interrupt for timer 2 fired every
~35 ticks.
Do you get any compiler or linker warnings?
I am really unsure what the problem could be. In general the timer
should work on the msp430f1611 the same way it works on the
msp430f1612. I hope I set the ACLK the right way, but if it would be
that high hwtimer_wait would not really pause a thread.
Have you tested your code on a MSB-430-H?
Cheers,
Oleg
Hi,
But whenever I use vtimer_sleep the thread never gets back.
As soon as I init vtimer I see an Interrupt for timer 2 fired every
~35 ticks.
Do you get any compiler or linker warnings?
yes a lot of integer overflows,
vtimer.c: In Funktion �update_shortterm�:
vtimer.c:64:42: Warnung: Ganzzahl�berlauf in Ausdruck [-Woverflow]
vtimer.c: In Funktion �vtimer_tick�:
vtimer.c:79:93: Warnung: Ganzzahl�berlauf in Ausdruck [-Woverflow]
vtimer.c: In Funktion �normalize_to_tick�:
vtimer.c:135:22: Warnung: Ganzzahl�berlauf in Ausdruck [-Woverflow]
vtimer.c:138:21: Warnung: Ganzzahl�berlauf in Ausdruck [-Woverflow]
vtimer.c:139:22: Warnung: Ganzzahl�berlauf in Ausdruck [-Woverflow]
vtimer.c: In Funktion �vtimer_init�:
vtimer.c:202:49: Warnung: Ganzzahl�berlauf in Ausdruck [-Woverflow]
unfortunally they did not disappeared when I tried to increase the integer type.
Any ideas?
I am really unsure what the problem could be. In general the timer
should work on the msp430f1611 the same way it works on the
msp430f1612. I hope I set the ACLK the right way, but if it would be
that high hwtimer_wait would not really pause a thread.
Have you tested your code on a MSB-430-H?
No, I just assumed that the vtimers are working on the MSB-430H.
But I realised that the code has may changed a lot since the last use of the MSB-430H.
Regards,
Milan
Some times you need to send an email to get the solution,
after increasing the type of the constants the warnings went away
I still did not resolved the whole problem, because i am getting this now
vtimer, NOW : 4096 198984289
vtimer_set(): New timer. Offset: 1 0
vtimer_set(): Absolute: 4096 199984327
vtimer_set(): NOW: 4096 198984352
vtimer_set(): setting short_term
2nd THREAD: vtimer, NOW : 4096 199001347
2nd THREAD: vtimer, NOW : 4096 199018331
2nd THREAD: vtimer, NOW : 8192 397937075
2nd THREAD: vtimer, NOW : 8192 397954059
2nd THREAD: vtimer, NOW : 8192 397971043
2nd THREAD: vtimer, NOW : 8192 397988027
2nd THREAD: vtimer, NOW : 12288 596906771
2nd THREAD: vtimer, NOW : 12288 596923756
2nd THREAD: vtimer, NOW : 12288 596940741
2nd thread pulls the vtimer every second, main thread did not wake up again.
However looks like a small progress 
Regards,
Milan
MICROSECONDS_PER_TICK is 4096000000.
In the vtimer_init() function the longterm tick is set to 4096000000,
so set_shortterm() will also be set to 4096000000.
vtimer_tick() is now called and tries to set the microseconds + MICROSECONDS_PER_TICK.
This is now 2 times 4096000000, however the microseconds are stored as a uint32_t, so an overflow occur. Since a uint32_t has a maximum value of 4294967295. This should happen on every platform, is it planned?
When the update_shortterm function is called it tries to set the hwtimer to 4096000000, but on the msp430 hwtimer stores the counter in the register TAR which has 16bit and maximum value of 65535.
In the hwtimer_arch_set this value is converted to a unsinged int, so the next overflow happens.
Also SECONDS_PER_TICK is set to 4096, so everytime vtimer_tick is called the seconds increase by 4096.
To me it sounds as both MICROSECONDS_PER_TICK and SECONDS_PER_TICK are defined with completly wrong values. But I don't get how they could work on another platform.
At a 32768 Hz Crystal I should have around 31 MICROSECONDS_PER_TICK, whenever I reach 1000000 microseconds I have to overflow them to seconds. But I think the vtimer_ticks don't need that frequent as the hwtimer ticks?
Regards,
Milan
Hi,
I got the vtimer working on the wsn430, however would be nice if somebody could have a look if the attached patch breaks the vtimer on other mcu's.
When the update_shortterm function is called it tries to set the hwtimer to 4096000000, but on the msp430 hwtimer stores the counter in the register TAR which has 16bit and maximum value of 65535.
In the hwtimer_arch_set this value is converted to a unsinged int, so the next overflow happens.
To avoid this i had to virtually increase the hwtimer max ticks on the msp430 from 0xFFFF to 0xFFFFFFFF.
To get this happen i had to waste one timer (No. 0), but this timer was not useable for me before.
At a 32768 Hz Crystal I should have around 31 MICROSECONDS_PER_TICK, whenever I reach 1000000 microseconds I have to overflow them to seconds. But I think the vtimer_ticks don't need that frequent as the hwtimer ticks?
I needed to inlcude at a few places a conversion from ticks to us and vice versa.
Since an unsigned long is not everywhere 32bit, it is hard to display such a value like uint32_t with printf.
I have nowhere seen this in the code but in inttypes.h are some macros defined which will output an unint32_t e.g. with PRIu32.
Is a reason given not to use them?
Regards,
Milan
vtimer-msp430.patch (7.04 KB)