You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Currently the system clock _tx_timer_system_clock is defined as an ULONG variable, so it's 32-bits unsigned, maximum value is 4294967295. With standard configuration using a 10ms timer tick, this means the timer will overlap avec 497 days only.
While it's maybe not a problem, it can be very nice to set the system time with the current epoch time.
That means currently taking the epoch time and multiply by TX_TIMER_TICKS_PER_SECOND to call tx_time_set function
Problem is actually with such resolution this overlap the ULONG internal system time.
Example: Thursday 8 August 2024 20:00:00 GMT is 1723147200 so multiply by 100 this means 172314720000 which is larger than 4294967295.
Describe the solution you'd like
I would like the internal system clock _tx_timer_system_clock to be defined as an ULONG64 so that there is no overlap at all to consider and we can set the wanted system time with the wanted timer tick resolution. tx_timer_set should take an ULONG64 type. tx_timer_get should returns an ULONG64 type as well.
I can propose a Pull Request if this is appreciated. In my opinion we can safely change the type of the system time as it will be larger than the existing type. Existing applications will just have implicit casts in case they still use an ULONG variable.
Describe alternatives you've considered
Maintaining myself the system time outside of ThreadX. Not very convenient.
Additional context
My application has an SNTP client that periodically check for NTP time. It would be great to set have such feature so that the SNTP client just update the ThreadX system time and then other modules of the application just call the ThreadX API to get system time.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Currently the system clock
_tx_timer_system_clock
is defined as an ULONG variable, so it's 32-bits unsigned, maximum value is 4294967295. With standard configuration using a 10ms timer tick, this means the timer will overlap avec 497 days only.While it's maybe not a problem, it can be very nice to set the system time with the current epoch time.
That means currently taking the epoch time and multiply by
TX_TIMER_TICKS_PER_SECOND
to calltx_time_set
functionProblem is actually with such resolution this overlap the ULONG internal system time.
Example: Thursday 8 August 2024 20:00:00 GMT is 1723147200 so multiply by 100 this means 172314720000 which is larger than 4294967295.
Describe the solution you'd like
I would like the internal system clock
_tx_timer_system_clock
to be defined as an ULONG64 so that there is no overlap at all to consider and we can set the wanted system time with the wanted timer tick resolution.tx_timer_set
should take an ULONG64 type.tx_timer_get
should returns an ULONG64 type as well.I can propose a Pull Request if this is appreciated. In my opinion we can safely change the type of the system time as it will be larger than the existing type. Existing applications will just have implicit casts in case they still use an ULONG variable.
Describe alternatives you've considered
Maintaining myself the system time outside of ThreadX. Not very convenient.
Additional context
My application has an SNTP client that periodically check for NTP time. It would be great to set have such feature so that the SNTP client just update the ThreadX system time and then other modules of the application just call the ThreadX API to get system time.
The text was updated successfully, but these errors were encountered: