64bit OS time
Posted: Mon Oct 09, 2017 11:34 am
Hi,
as I mentioned earlier, I need high-resolution but unique timestamps for my application. More precisely, I want to allow µs precision but using 32 or even 16 bit timers results in overflows every 71.5 minutes or 65.5 milliseconds respectively. Since it is crucial for me that these timestamps are unique, I require 64 bit resolution instead. Please note that the actual frequency of underlying hardware timers does not need to be 1MHz! This is just about unique timestamps that can represent a high resolution if required and which are some kind of hardware independent, so that they can be used for communication with other systems (e.g. connected via CAN).
I have built my current solution on top of ChibiOS/RT, using an additional hardware timer (GPT) but this is not very efficient and suffers from several issues. Most importantly, I can not use the 64 bit timestamps for any timeout values of the ChibiOS functions, which still use systime_t, which is 16 or 32 bit. What I would like to do is to integrate my solution deeper into the ChibiOS/RT system tick structures, but I need some help on where to put all that code and how to do the stuff the clean way.
My plan is first to decouple the time structure used in the OS (i.e. ChibiOS/RT) from the one used by the hardware and LLDs (i.e. ChibiOS/HAL). Currently systime_t is used throughout the project and hence all high-level code depends on the underlying hardware resolution. By introducing a new structure (e.g. ostime_t) this issue could be resolved. While CH_CFG_ST_RESOLUTION would then define the width of ostime_t, the type of systime_t would depend on the port (which actually is the correct place, imo). The underlying hardware timer (STM32_ST_TIM) is still running with the frequency defined by CH_CONF_ST_FREQUENCY and suffers from the same overflows. However, this can be solved by using an interrupt that fires whenever the hardware timer is about to overflow (depends on CH_CFG_ST_TIMEDELTA). On this interrupt, a callback updates the ostime_t accordingly (mingles with the various combinations of resolutions). In order to handle timeouts and such, which would now be set as ostime_t values, the callback also has to set an alarm, if required. It basically has to check whether the next upcoming timeout will occur before the next overflow and if so configure an according alarm.
The major challenges to realize this will be to keep it configurable, implement it efficiently and to resolve all dependencies correctly. For the latter, the most difficult part is, that many timeout functions are handled within the LLDs, which are part of ChibiOS/HAL and thus either need to know ostime_t, or the mapping ostime_t -> systime_t must be handled before in another layer of ChibiOS/RT. Maybe you can give me some advice where to start and how to do all the stuff, as well as list of components that must be modified and checked. I hope I can keep the final solution quite simple so it can be integrated into the project without many troubles
Best regards,
Thomas
PS @ Giovanni: I know you have your doubts about my idea in general, but I would just like to try nevertheless and see what I can achieve
as I mentioned earlier, I need high-resolution but unique timestamps for my application. More precisely, I want to allow µs precision but using 32 or even 16 bit timers results in overflows every 71.5 minutes or 65.5 milliseconds respectively. Since it is crucial for me that these timestamps are unique, I require 64 bit resolution instead. Please note that the actual frequency of underlying hardware timers does not need to be 1MHz! This is just about unique timestamps that can represent a high resolution if required and which are some kind of hardware independent, so that they can be used for communication with other systems (e.g. connected via CAN).
I have built my current solution on top of ChibiOS/RT, using an additional hardware timer (GPT) but this is not very efficient and suffers from several issues. Most importantly, I can not use the 64 bit timestamps for any timeout values of the ChibiOS functions, which still use systime_t, which is 16 or 32 bit. What I would like to do is to integrate my solution deeper into the ChibiOS/RT system tick structures, but I need some help on where to put all that code and how to do the stuff the clean way.
My plan is first to decouple the time structure used in the OS (i.e. ChibiOS/RT) from the one used by the hardware and LLDs (i.e. ChibiOS/HAL). Currently systime_t is used throughout the project and hence all high-level code depends on the underlying hardware resolution. By introducing a new structure (e.g. ostime_t) this issue could be resolved. While CH_CFG_ST_RESOLUTION would then define the width of ostime_t, the type of systime_t would depend on the port (which actually is the correct place, imo). The underlying hardware timer (STM32_ST_TIM) is still running with the frequency defined by CH_CONF_ST_FREQUENCY and suffers from the same overflows. However, this can be solved by using an interrupt that fires whenever the hardware timer is about to overflow (depends on CH_CFG_ST_TIMEDELTA). On this interrupt, a callback updates the ostime_t accordingly (mingles with the various combinations of resolutions). In order to handle timeouts and such, which would now be set as ostime_t values, the callback also has to set an alarm, if required. It basically has to check whether the next upcoming timeout will occur before the next overflow and if so configure an according alarm.
The major challenges to realize this will be to keep it configurable, implement it efficiently and to resolve all dependencies correctly. For the latter, the most difficult part is, that many timeout functions are handled within the LLDs, which are part of ChibiOS/HAL and thus either need to know ostime_t, or the mapping ostime_t -> systime_t must be handled before in another layer of ChibiOS/RT. Maybe you can give me some advice where to start and how to do all the stuff, as well as list of components that must be modified and checked. I hope I can keep the final solution quite simple so it can be integrated into the project without many troubles
Best regards,
Thomas
PS @ Giovanni: I know you have your doubts about my idea in general, but I would just like to try nevertheless and see what I can achieve
