Closed IACU closed 1 week ago
Hi IACU,
But if this is important for you, you can calculate relative delay from _tx_timeget(). I don't see any reason to have implemented API like osDelayUntil().
Jan
Hi IACU,
But if this is important for you, you can calculate relative delay from _tx_timeget(). I don't see any reason to have implemented API like osDelayUntil().
Jan
Hi @Hnz2 Thanks for reply. I do implement relative delay using _tx_time_get api. Sometimes i meet this problem, when thread executes nearly 1 tick, using tx_thread_sleep to enter sleep state, but tx_thread_sleep is interrupted by systick handler(1ms/1000HZ) before _tx_thread_system_suspend. It causes the thread may delay one more tick because it misses systick handler to calculate time_slice. TX_DISABLE and TX_RESTORE is called before _tx_thread_system_suspend, may cause such problem?
Hi @IACU, I don't believe that RTOS sleep at any type of RTOS was designed for such precision timing. Even with FreeRTOS you will see jitter near to RTOS tick when osDelayUntil() API is used. For more precisions timing should be used another approaches (e.g. hardware timers with semaphore, events or message queue). Jan
Hi @IACU, I don't believe that RTOS sleep at any type of RTOS was designed for such precision timing. Even with FreeRTOS you will see jitter near to RTOS tick when osDelayUntil() API is used. For more precisions timing should be used another approaches (e.g. hardware timers with semaphore, events or message queue). Jan
OK, thanks for your reply
closing this item as answered.
osDelayUntil is the CMSIS RTOSv2 API, other OS such as FreeRTOS support this function.tx_thread_sleep support Relative-delay not Absolute-delay in thread function.It means there is a deviation in the running cycle of periodic-threads.