I’m not very clear how this particular scenario is handled. What happens once the xTickCount reaches its upper limit. I don’t see a call back provided that application will use once the xTickCount has overflown.
Why am I interested in this? I want to add a time-service (that has a resolution in ms). I would use the Tick hook function anyways for that. But, I was curious and saw that xTickCount is reset back to zero. Is there something that I’m missing here?
Thanks in advance for answering😊
The raw tick count is usually not used directly. All time/out related FreeRTOS functions like xTaskCheckForTimeOut handle overflows gracefully as documented.
To add to HS2’s answer:
The kernel’s internals are designed to cope with overflows seamlessly, but the application writer does need to consider overflows in their own code. As HS2 points out, there are API functions provided for that purpose. Also the tick count is an unsigned value so you can calculate elapsed time by doing “time now minus a time in the past” arithmetic provided either zero or one overflow has occurred between the two times.
Thanks Richard and Hartmut,
There is a reactive approach that handles this scenario! I’ll give the docs another reading. Just as a side is there any plan to implement time-system just like the one threadx has got? If not is there a approach that everybody used is working great?
I’m not familiar with that but - please give an overview of the functionality you would like to see in FreeRTOS in this regard.
@rtel, I just saw why this cannot be implemented. At least when the configTICK_RATE is left user configurable. Also threadx doesn’t have this feature our company guys have added this by freezing the tick rate there. Sorry, to post incorrect information here.