Closed jolivepetrus closed 7 years ago
We actually are thinking of a way to chain hooks like this; it would make sense given the modularity of esp-idf.
Can I ask why you do not use the FreeRTOS timer mechanism, by the way?
We are porting part of our IOT ecosystem solution to the ESP32 platform. Now our efforts are focused on port our Lua RTOS, a RTOS operating system based on the Lua programming language.
Lua RTOS are designed to be portable, and we need to call to our tick management routine inside vApplicationTickHook. This routine manages elapsed time since boot and call to our Lua virtual timers at regular intervals.
Sorry, I reply your comment from another github user.
:(
Fyi, yesterday we pushed another solution into master. You can use esp_register_freertos_idle_hook and esp_register_freertos_tick_hook to register multiple idle/tick hooks now. If you really need it, you can also re-enable the classic FreeRTOS tick/idle hook mechanism, esp-idf doesn't use it for itself anymore.
Does that satisfy your use case?
Nice! I will try it in a few hours ...
It works perfect. Thanks for this addition.
FreeRTOS define the vApplicationTickHook callback as a convenient place for applications to implement timer functionality.
Currently vApplicationTickHook are used by esp-idf to implement WDT checks, and are not available for user applications.
I think that will be better to move WDT checks to specific esp-idf routines, call it from the convenient places, and left vApplicationTickHook available for user applications.
For example, in our case we need to change esp-idf sources to implement virtual timers in this way:
... in _newTick we process virtual timers ...
A more elegant solution (in our opinion) will be:
In this case, configUSE_WDT_XXX / vApplicationTickHookZZZ are esp-idf especific, preserving the expected behaviour.