ChibiOS Free Embedded RTOS

Hi,

It is experimental and not yet tested:



Time stamps should be synchronized with system time and have the same resolution, the returned type is 64 bits wide. There are some constraints:

1) chVTGetTimeStampI() must be called at least once per system time "period" (before it wraps). This can be ensured by generating a stamp from within a VT callback or a thread or some interrupt source.
2) The counter is large but not infinite, applications should call chVTResetTimeStampI() in order to reset it if the uptime is meant to be large enough.
3) Not tested yet, there could be something wrong.

Giovanni

Giovanni,
Thanks for that. Thoughts...
To avoid the need for a special VT would it work to:
a) In tickless mode in hal_st_lld.c enable UIE in the STM32 TIM and then check for UIF in st_lld_serve_interrupt() and call chVTGetTimeStampI() to update.
ARR is already initialized to relevant full count for 16/32 TIM so UIF would be at systime 0.

b) In classic tick mode @384 of chvt.c do...

Of course I probably missed something critical
--
Bob

Plus a few changes required in other places in hal_st_lld.c so UIE and UIF are not clobbered...

The problem is that it would require yet an other service from the port layer, which is already complex, in addition, you cannot just assume a TIMx, it would require new interfaces in chcore_timer.h and in the ST driver.

I also suspect that updating on the 0xFFFFFFFF -> 0x0000000 transition would not work, the counter would be already restarted by the time it is read by the ISR. It would be better to place a counter in the middle, you need an extra comparator of course.

It could be optimized in tick mode with automatic update or by just increasing the time stamp at each tick but that would mean that the behavior would be different in tick and tick-less modes, I am not sure to want that too or magic problems could appear by switching mode.

Giovanni

OK on the complications.

So if using a "stamp VT" is the way to go it could be:
a) handled at the system level.
e.g. put the virtual_timer_t inside ch_virtual_timers_list struct and have it initialized/(re)started by chVTResetTimeStampI(...).
The CB func for the VT would be inside chvt.c and simply re-arm the timer?

OR

b) Require the application layer to allocate the VT, the CB func. and manage the init/start?
--
Bob

I think it should be the application, there are scenarios where the reloading is not even required, for example if the application keeps generating stamps in a periodic thread.

Giovanni

Hi Giovanni.
All good on the preferred method having the application layer be responsible for the update "tick".

So I've gone ahead and used the new timestamp in the trace messages feature of an application.
FYI I use Trace messages extensively in that application so the wrap case is always being handled/updated by the call to chVTGetTimeStampI() within the trace messages module.

Now when using 16 bit systime there won't be any wrap in the trace messages time stamp.
Excellent outcome.

Thanks
--
Bob