Hello,
I want to get timestamps whenever an interrupt fires. I am using sntp client to sync the time and tx_time_get() function to calculate the number of ticks since last sync.
As per the default configuration in threadx, TX_TIMER_TICKS_PER_SECOND resolves to 10ms. If I redefine the TX_TIMER_TICKS_PER_SECOND to resolve to 1us, how does it impact the working of the software? Is there any negative impact?
Thank you.
You'll obviously have more overhead processing these more frequent timer interrupts. Also, any sleeps or waits that you do are in terms of timer ticks, so if you are trying to sleep or wait for a certain number of microseconds rather than timer ticks, you'll need to adjust these sleep/wait values. Besides just adjusting the TX_TIMER_TICKS_PER_SECOND define, make sure you also adjust your hardware timer to tick at this same rate (e.g. for Cortex-M, you can adjust the SYSTICK_CYCLES defined here https://github.com/azure-rtos/threadx/blob/e11c166a4045d80ea74fe917e5608474754f5067/ports/cortex_m4/gnu/example_build/tx_initialize_low_level.S#L42)
@ScottAzureRTOS Thanks for the quick response. Should the TX_TIMER_TICKS_PER_SECOND and SYSTICK_CYCLES be configured such that they tick at the same rate?
For the Cortex-M, SYSTICK_CYCLES is what is used to configure the hardware (SysTick timer). The TX_TIMER_TICKS_PER_SECOND define is what tells all the firmware how many ticks per second there are. This doesn't really have any effect on the ThreadX kernel, however it is useful for the middleware like NetX Duo and FileX to know how fast the timer is running.
Edit: yes, you should make TX_TIMER_TICKS_PER_SECOND be the same as how you configure the hardware timer.
7 people are following this question.
