High-Resolution Timer proposal

[bobc]

I apologize if my previous message didn't make sense, I am still getting to grips with Chibios and had misunderstood the documentation. The GPT seems to do exactly what I want, I had the impression the GPT only works with system ticks (CH_FREQUENCY) but this seems not the case.

I am still unsure of the function/use of the other timer/virtual timer functions, but I think I am good with the GPT driver.

Personally I have found there is too much overhead handling timer queues with resolution much below 1ms, so that is a route I would not go down.

[skute]

Wouldn't pausing decrease the precision in time of events?

Giovanni

Yes, pausing the timer will decrease the precision in time of events. The timer is only paused to atomically read the amount of time that has currently elapsed since the it was started, and then take action based on that. For example, when starting a new timer; if there is a timer currently running, to decide whether the new timer will expire before or after the running timer, we pause the timer. There are also situations in which you need to know if the timer interrupt is pending and you have blocked it because of a call to chSysLock(). To accurately/atomically detect this situation, you need to pause the timer.

This precision loss can be accounted for in the low-level driver if it were to timestamp when pausing or when the isr triggers then using this information to subtract the required microseconds when starting the next timer.

[billr]

I need a delay with 10 us resolution and came across this post. Has any further work been done on a high resolution timer?

[Giovanni]

You can already do that: halPolledDelay() or, alternatively, gptPolledDelay().

High resolution timers are being considered for ChibiOS 3.0, too much of a change for the current major version.

Giovanni

[billr]

Thanks, I'll check out those functions. There's so much capability in ChibiOS, it's hard to know it all.