64bit OS time

Discussions and support about ChibiOS/RT, the free embedded RTOS.
User avatar
Giovanni
Site Admin
Posts: 10134
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 205 times
Been thanked: 183 times
Contact:

Re: 64bit OS time

Postby Giovanni » Thu Oct 12, 2017 9:59 am

About your proposed abstime_t, the concept is interesting but implementation complex:

Would the following limitations be acceptable?
- Not updated every uS but when a (any) virtual timer expires, the value would be updated in that moment.
- User could setup a continuous VT for continuous updates at a fixed rate.
- It would be a separated thing , it is not "system time", maybe "uptime".

Giovanni

Thargon
Posts: 46
Joined: Wed Feb 04, 2015 5:03 pm
Location: CITEC, Bielefeld University, germany
Has thanked: 3 times
Been thanked: 2 times

Re: 64bit OS time

Postby Thargon » Thu Oct 12, 2017 10:32 am

Hi,
actually the long-term, high resolution abstime_t is the thing I need for my project :D

Giovanni wrote:Would the following limitations be acceptable?
- Not updated every uS but when a (any) virtual timer expires, the value would be updated in that moment.
- User could setup a continuous VT for continuous updates at a fixed rate.
- It would be a separated thing , it is not "system time", maybe "uptime".

It is ok that it is not updated every us (especially since CH_CFG_ST_FREQUENCY could be lower than 1MHz), but it must not be related to VTimers. If no timer would expire within one period (between two register overflows) the abstime_t is not updated and everything is screwed. Using another timer that fires periodically is actually what I am doing right now, but that does not solve the issue of long term timeouts and such.
Making it a separate thing that can be enabled/disabled via chconf.h and calling it "uptime" is absolutely fine.

Regarding your previous post, I still don't see where you want to abstract the hardware dependent types to a more general form. systime_t strongly depends on the hardware timer, and sysinterval_t "may be" wider? So if I set a long timeout, which can not represented by systime_t the OS has to handle the overflows anyway, so why not directly use SI units? Furthermore, if my target architecture is 32 bit, but I want to use 64 bit sysinterval_t there must be an additional lock mechanism to make any calculation atomic. If the width of sysinterval_t is <= architecture, you would want to omit such locks.

Overall, I think your solution may turn out to be more complex that what I proposed and lead to cumbersome application code. However, keeping long-term times aligned with systime_t by using system ticks as unit makes sense. Nevertheless, I would get rid of such "could be", "may be" definitions and rather provide a well defined and hence fully portable interface and let the OS handle all the required conversions. Basically, that is something I had in mind with my previous post, where systime_t depends on the timer hardware (usually 16 or 32 bit), interval_t depends on the processor architecture (usually 32 bit), and abstime_t is defined to be 64 bit.

- Thomas

PS: Maybe you should rename "chTimeSubtactX()" to "chTimeDiffX()" since that better describes the intention of that function, I guess. Even though it comes down to a subtraction internally, if it was my INTENTION to subtract two values, I would simply use the '-' operator. ;)

Edit: PPS: Thanks for your efforts on this topic! I very much appreciate that!

User avatar
Giovanni
Site Admin
Posts: 10134
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 205 times
Been thanked: 183 times
Contact:

Re: 64bit OS time

Postby Giovanni » Thu Oct 12, 2017 10:45 am

To answer your question, I don't want quantization errors in time handling, this is why I am planning to stay with ticks.

An uptime not driven by the VTs would require yet another abstraction for something that has to provide the counter, there is already something like this, it is the realtime counter, just make it 64bits and drive it with your timer implementation. The concept could be expanded and the size made configurable.

Giovanni

Thargon
Posts: 46
Joined: Wed Feb 04, 2015 5:03 pm
Location: CITEC, Bielefeld University, germany
Has thanked: 3 times
Been thanked: 2 times

Re: 64bit OS time

Postby Thargon » Thu Oct 12, 2017 11:50 am

Giovanni wrote:To answer your question, I don't want quantization errors in time handling, this is why I am planning to stay with ticks.

Yes, that makes sense. However, I guess most people (me included) do most of their time calculations in SI units and use the ST2XX() and XX2ST() conversion macros, which imply such quantization errors anyway. But I totally agree that from a best practice and consistency point of view, everything should be in native system ticks.

Giovanni wrote:An uptime not driven by the VTs would require yet another abstraction for something that has to provide the counter, there is already something like this, it is the realtime counter, just make it 64bits and drive it with your timer implementation. The concept could be expanded and the size made configurable.

I had another look into the code, and it should be possible to use a VT for the time accumulation. However, I could not find the priority with which the callback function is executed. If its just the timer ISR priority, it's fine, but is should not be lower or depend on any thread priorities. So, if a VT can be used for accumulation, I think there should be an option to activate such right within ChibiOS/RT via the chconf.h file, so users do not need to build their own VT themselves (which requires to understand the whole system time components of ChibiOS). Furthermore, some periodic update/checking function must be integrated into the OS the one way or another in order to allow timeouts. sleeps, etc. larger than systime_t can represent.

With "realtime counter" you mean "realtime clock" RTC? The current implementation only supports millisecond precision and some controllers might not even feature RTC hardware but only general-purpose timers. Then again we end up with multiple hardware dependencies, which I just want to avoid.

User avatar
Giovanni
Site Admin
Posts: 10134
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 205 times
Been thanked: 183 times
Contact:

Re: 64bit OS time

Postby Giovanni » Thu Oct 12, 2017 1:33 pm

Hi,

Virtual Timers, unlike other RTOSes you may have heard of, are handled in ISR context and timers callbacks also are invoked from ISRs. Priority is the one assigned to the ST (systick) driver and, of course, is not affected by threads priorities.

The only way threads could affect this is via unusually long critical sections, but that would be a problem in itself.

By realtime counter I meant functions:
rtcnt_t chSysGetRealtimeCounterX()
bool chSysIsCounterWithinX(rtcnt_t cnt, rtcnt_t start, rtcnt_t end);
void chSysPolledDelayX(rtcnt_t cycles);
etc

Which use an HW counter usually clocked at the same CPU frequency, it is used for cycle-accurate delays. Not sure if it could help with your application.

Giovanni

Thargon
Posts: 46
Joined: Wed Feb 04, 2015 5:03 pm
Location: CITEC, Bielefeld University, germany
Has thanked: 3 times
Been thanked: 2 times

Re: 64bit OS time

Postby Thargon » Fri Oct 13, 2017 4:51 pm

Hi,

Giovanni wrote:Virtual Timers, unlike other RTOSes you may have heard of, are handled in ISR context and timers callbacks also are invoked from ISRs. Priority is the one assigned to the ST (systick) driver and, of course, is not affected by threads priorities.

That's perfect!

Giovanni wrote:By realtime counter I meant functions:
rtcnt_t chSysGetRealtimeCounterX()
bool chSysIsCounterWithinX(rtcnt_t cnt, rtcnt_t start, rtcnt_t end);
void chSysPolledDelayX(rtcnt_t cycles);
etc

No, that is not what I need. The requirement for my application is to have unique (non-wrapping), high precision (I decided for µs resolution) time stamps that can be exchanged between multiple modules (in a heterogeneous setup of several microcontrollers and SoCs) e.g. via CAN. I want to apply such time stamps to system wide events, so that each module knows the exact origin time of that event.

I just read your recent post here (awesome work btw!) and it sounds as if it would be quite trivial to introduce an additional system uptime. By introducing a global sysinterval_t variable, which is updated each time the counter wraps (time gets accumulated to this variable), this variable would describe the interval since system startup. Of course, if the type of sysinterval_t is too small it will overflow nevertheless, but as long as I can configure it to be of uint64_t I am happy :)

Thank you very much again for this great support!
- Thomas


Return to “ChibiOS/RT”

Who is online

Users browsing this forum: No registered users and 1 guest