Precision periodic timer using virtual timers

[electronic_eel]

A periodic timer is a common pattern I use. The accumulating error when rescheduling is something that has forced me several times to use a hardware timer instead of a virtual timer.

So I would really appreciate it if that feature were available.

[Giovanni]

It is the next thing

Giovanni

[Giovanni]

After some thinking, rather than implement something like chVTSetWithReload(vt, n, cb, par) which would start a continuous timer, I prefer to implement an chVTReload(vt, n) to be called from the callback, timers would still be one-shot without calling this function.

Reasoning:

The 1st solution would require to store, for each timer, the "last" time the timer has been triggered and a "reload" value.

The 2nd solution would only require the "last" time with the bonus that the reload could be different each time. Reloading would be based on the "last" time so it would not accumulate errors anyway. I could also consider making it not optional.

Potential other change:

Make the timer callback pass the timer itself as function parameter, the timer parameter would be available in the structure. This would break compatibility but would allow callbacks called by multiple timers, all other callbacks in ChibiOS are done this way, they pass the object as 1st parameter.

Giovanni

[steved]

Potential other change:

Make the timer callback pass the timer itself as function parameter, the timer parameter would be available in the structure. This would break compatibility but would allow callbacks called by multiple timers, all other callbacks in ChibiOS are done this way, they pass the object as 1st parameter.
Giovanni

Are you saying that the callback would still pass just one parameter, but that it would be the timer itself (rather than the parameter)? If so, I can see this could occasionally be useful, without any performance hit.
I've always found one parameter to the callback is sufficient, even with a shared callback.

I'd hope that you'd change the function name and/or parameters sufficiently that existing code throws an error with the new API.

While you're attacking virtual timers, could I suggest that vtReset() (or maybe a new routine) returns the unexpired part of the time. Use case is watchdog-type situations, where that allows you to determine how close you are to the limit.

[FXCoder]

I guess the original intent was to have a hybrid of #1 & #2 behave like this...
chVTSetWithReload(vt, n, cb, par) stores the n and cb and initial last in VT data but also sets an internal flag (perhaps last != 0 fills the requirement) in the VT data to distinguish itself as a periodic timer.
On expiry VT knows (by the flag) to call an internal chVTReload(vt) function which first calls the defined cb with par and upon return from cb calculates the next T/O for vt using last and n.

Correct?
If there was a need to change n add a new function chVTSetReload(vt, n) which allows for such change to be made from within the cb.

If so that seems OK to me and I prefer not to break any existing API.
--
Bob

[Giovanni]

The point is that I don't want to add too many extra fields to the structure, using a reload function it is possible to do it with just one extra field.

Fields in that structure take space from all thread stacks (timeout functions) not just timers.

Giovanni

[electronic_eel]

The 2nd solution would only require the "last" time with the bonus that the reload could be different each time. Reloading would be based on the "last" time so it would not accumulate errors anyway.

Do you plan to store the "last" time the moment the timer expires? Or do you plan to store the system time the timer is expected to fire beforehand, in the moment you set the timer?

Setting the expected time beforehand would have the positive side effect that you could now easily create a chVTGet function which would return the time the timer will fire at. This is something that is currently missing and that would have been handy for me in the past.

Otherwise I can understand your reasoning that saving ram is important. The reload values will very often be fixed, so they can be in the code and don't need to be stored in the timer structure in ram.

Make the timer callback pass the timer itself as function parameter, the timer parameter would be available in the structure. This would break compatibility but would allow callbacks called by multiple timers, all other callbacks in ChibiOS are done this way, they pass the object as 1st parameter.

I think making the callback functions be usable for different timers is a good idea. I value this enhancement over compatibility.

[FXCoder]

The point is that I don't want to add too many extra fields to the structure, using a reload function it is possible to do it with just one extra field.

Understood. Perhaps to eliminate storing n in VT data then maybe a new VT CB definition is added that returns n for the periodic case?
So the cb in chVTSetWithReload(vt, n, cb, par) is different but stored in the VT struct in a union with the normal CB.
The VT code knows which CB to call based on last being non zero.
Perhaps there is an issue with systime wrapping and last being calculated as zero to be dealt with - maybe round up/round down from zero depending on current odd/even value of systime so it nets out over time.

Anyway just some thoughts to add to the discussion.
--
Bob

[Giovanni]

I will look into returning the elapsed time from chVTReset().

Giovanni

[Giovanni]

Hi,

Auto-reload and remaining-time features have been committed, callback changes not yet. It passes "VT storm" and obvious tests but, please, give it a try.

Callback changes will require going through the whole code base and find all places where to adjust code.

Giovanni