[riot-devel] vtimer implementation

Milan Babel babel at inf.fu-berlin.de
Wed Aug 21 16:57:52 CEST 2013

Hi Kaspar,

On 21.08.2013 16:35, Kaspar Schleiser wrote:
> Hi,
> On 08/21/2013 03:53 PM, Milan Babel wrote:
>> * vtimer is not tickless (through long_term)
> When I hacked vtimer together, I tried to make the code usable also on 
> platforms with 16bit timers. With any decent resolution, I had to 
> build everything around using at least two ints for holding the timer 
> values.
But this is not working at the moment. When using a very common crystal 
for time measurements with 32kHz a 16bit timer can only count 2 seconds, 
far away from the 4096 seconds for a long_term that is needed now.
> I also thought that the virtual timer implementation should scale 
> timers to longer periods (days, weeks?), maintaining a high resolution.
> Might be stupid.
No, I think the same, but i do not know why they shouldn't be in the 
queue the same way a timer which is triggered in a half second.
>> I would prefer to not use long_term updates at the behavior it is used
>> now. I would suggest to only use a long_term update before the hwtimer
>> overflows.
> You mean, tick on overflow? I remember trying that and running into 
> problems.
Yes, at least in theory I do not know why a 
hwtimer_set_absolute(HWTIMER_MAXTICKS-1), should be run into more 
problems than hwtimer_set(4096 seconds in ticks).

> I decided to use seconds + µs as timer variables (for the API) as all 
> my use cases were like "wait n µs", never "wait n timer ticks at 
> resolution A".
I do not want to change this in the API. But depending on how accurate 
the vtimer should be and to reduce computation when updating seconds, it 
is maybe worth to think if 2^20 is close enough to a million.
> I chose to "tick" long_term updates in full seconds as I did not find 
> a nice way to map the API to timer ticks back then.
> I remember trying to avoid any kind of division or modulo (other than 
> powers of two), as these operations are very expensive on most 
> platforms. But that made some things really messy where you'd usually 
> just do "ticks = microsecs / MICROSECONDS_PER_TICK"...
hwtimer.h has to macros HWTIMER_TICKS and HWTIMER_TICKS_TO_US which does 
the conversation in both directions. I do not see a chance to avoid 
using them, the most devices will not have a 1MHz crystal. When using 
2^20 instead of one million it will be a diversion of two numbers that 
are the power of two, because most crystals use a power of two.


More information about the devel mailing list