Hello,
one can choose between 16 or 32 bits width for time type, and time conversion functions chTimeI2xx check for overflow, so overflow bytes after 71 minutes for conversions to µs, and 50 days for conversions to ms.
could this be configurable in chconf.h to enable also 64 bits time type, to avoid overflow for long running systems ?
I know that there is a problem for this : there is an internal calculus on 2 times the width of the data type to detect overflow with dedicated type,(time_conv_t) and in case of 64 bits time type width, there is no possibility to have an 128 bits internal time type, on the other hand, 2⁶⁴ µs is 600.000 years, MCU will probably support 128 bits integer then and in the interval one can imagine 64 bits conversion function that does not check for overflow ?
Alexandre
time conversion overflow Topic is solved
- Giovanni
- Site Admin
- Posts: 14525
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1095 times
- Been thanked: 934 times
- Contact:
Re: time conversion overflow
Hi,
System time is meant to overflow, under some configurations is overflows in under 1 second (tested a 20MHz clock with a 16bits counter just for fun...). It poses no problem using the time and intervals macros/functions and the system continues to work after the overflow.
The only limitations is that you cannot calculate a time interval between 2 system times if there is more than one overflow in the interval.
You can have 64 time stamps too, there is an API for this, it is independent from timer size.
What is exactly your need?
Giovanni
System time is meant to overflow, under some configurations is overflows in under 1 second (tested a 20MHz clock with a 16bits counter just for fun...). It poses no problem using the time and intervals macros/functions and the system continues to work after the overflow.
The only limitations is that you cannot calculate a time interval between 2 system times if there is more than one overflow in the interval.
You can have 64 time stamps too, there is an API for this, it is independent from timer size.
What is exactly your need?
Giovanni
- alex31
- Posts: 400
- Joined: Fri May 25, 2012 10:23 am
- Location: toulouse, france
- Has thanked: 43 times
- Been thanked: 73 times
- Contact:
Re: time conversion overflow
I use a UAV oriented CAN library (libcanard) which tag each message with a monotonic 64 bits time value in µs.
I have set CH_CFG_ST_RESOLUTION to 64, and use chTimeI2US(chVTGetSystemTime())), but chTimeI2US assert that it does not wrap, so when it does, app halts.
So, I need a monotonic 64 bits time value in µs.
As a quick fix, I just add the possibility to set CH_CFG_TIME_TYPES_SIZE = 64, problem is solved, but at the expense of patching the OS ...
Alexandre
I have set CH_CFG_ST_RESOLUTION to 64, and use chTimeI2US(chVTGetSystemTime())), but chTimeI2US assert that it does not wrap, so when it does, app halts.
So, I need a monotonic 64 bits time value in µs.
As a quick fix, I just add the possibility to set CH_CFG_TIME_TYPES_SIZE = 64, problem is solved, but at the expense of patching the OS ...
Alexandre
- Giovanni
- Site Admin
- Posts: 14525
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1095 times
- Been thanked: 934 times
- Contact:
- alex31
- Posts: 400
- Joined: Fri May 25, 2012 10:23 am
- Location: toulouse, france
- Has thanked: 43 times
- Been thanked: 73 times
- Contact:
Re: time conversion overflow
I was not aware of it
I will just need to manually multiplicate by (1000000/CH_CFG_ST_FREQUENCY) to have what I need !
Thanks.
A.
I will just need to manually multiplicate by (1000000/CH_CFG_ST_FREQUENCY) to have what I need !
Thanks.
A.
- FXCoder
- Posts: 393
- Joined: Sun Jun 12, 2016 4:10 am
- Location: Sydney, Australia
- Has thanked: 184 times
- Been thanked: 131 times
Re: time conversion overflow
Hi Alex,
The timestamp needs to be accessed to maintain sync.
So just start a continuous VT in your system init to ensure that...
And there are macros for interval check/calc such as...
which you will find in chtime.h
--
Bob
The timestamp needs to be accessed to maintain sync.
So just start a continuous VT in your system init to ensure that...
Code: Select all
#if (CH_CFG_USE_TIMESTAMP == TRUE)
/**
* @brief Callback to update timestamp counter
*/
static void _ts_update(virtual_timer_t *vtp, void *arg) {
chSysLockFromISR();
(void) vtp;
(void) arg;
(void) chVTGetTimeStampI();
chSysUnlockFromISR();
}
#endif
// And start VT to update TS
#if (CH_CFG_USE_TIMESTAMP == TRUE)
/* Start the VT to keep the timestamp synchronised.*/
chVTSetContinuous(&_timestamp, TIME_MAX_SYSTIME / 2, _ts_update, NULL);
#endif
And there are macros for interval check/calc such as...
Code: Select all
static inline sysinterval_t chTimeStampDiffX(systimestamp_t start,
systimestamp_t end) {
which you will find in chtime.h
--
Bob
- alex31
- Posts: 400
- Joined: Fri May 25, 2012 10:23 am
- Location: toulouse, france
- Has thanked: 43 times
- Been thanked: 73 times
- Contact:
Re: time conversion overflow
Ok, I understand, system time wrapping is detected only when chVTGetTimeStamp is called.
In my case, it's ok, the dronecan protocol(previously named uavcan) imply sending a heartbeat message at a minimum frequency of 1Hz, so system time cannot wrap two times between chVTGetTimeStamp calls.
Alexandre
In my case, it's ok, the dronecan protocol(previously named uavcan) imply sending a heartbeat message at a minimum frequency of 1Hz, so system time cannot wrap two times between chVTGetTimeStamp calls.
Alexandre
Who is online
Users browsing this forum: Bing [Bot], Google [Bot] and 5 guests