Hi,
actually the long-term, high resolution abstime_t is the thing I need for my project
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!