Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define system clock as ULONG64 #401

Open
joelguittet opened this issue Aug 8, 2024 · 0 comments
Open

Define system clock as ULONG64 #401

joelguittet opened this issue Aug 8, 2024 · 0 comments
Labels
feature New feature or enhancement request

Comments

@joelguittet
Copy link

joelguittet commented Aug 8, 2024

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.

@joelguittet joelguittet added the feature New feature or enhancement request label Aug 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or enhancement request
Projects
None yet
Development

No branches or pull requests

1 participant