[riot-devel] vtimer on msp430
babel at inf.fu-berlin.de
Thu May 23 10:43:59 CEST 2013
On 22.05.2013 20:17, Milan Babel wrote:
> 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
> However looks like a small progress ;)
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 +
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
More information about the devel