Is there a way to get the information of all the timers in the Timer queue? I’m thinking of something along the lines of uxTaskGetSystemState where you can get the state of all the Tasks in the system. I’ve been poking around in the Timers.c/.h files but I don’t see anything that would give me similar functionality. If I’m correct in reading the code (and I might not be), it also seems like if a Timer is stopped it gets removed from the list so no record is kept of it anywhere in the OS? If I don’t keep track of my timers and I stop one it seems like I’ll lose all visibility of it?
I recently found and fixed a memory leak revolving around how I was using timers in one specific instance and it occurred to me that is a section of our system that I have no visibility into. I have debug commands that I can enter over our communication interface to view ISR timings, Task runtime and stack usage and well as heap usage and availability, but I have nothing for the Timer Service. I’m trying to rectify that deficiency but I’m not having luck so far. Any help would be greatly appreciated.
I think you are right - there is no programmatic way of querying timers that are in the list. The StateViewer plug-ins for IAR and Eclipse may give a graphical view though.
Timers are created by the application and referenced by a handle. You can’t start, stop, reset, etc. them if you don’t have the handle - the kernel itself doesn’t maintain a list of every created timer. We could introduce a timer registry, similar to the queue registry, where you can manually add a timer to the registry, and give it a name, after creating it.
Well that’s a bummer but thanks for the speedy response!
I didn’t even know there was a queue registry Some people might find it useful, but we were already keeping tracking of our the timers anyways so it wouldn’t provide any benefit for us. I mostly just confirming that I was reading the code correctly.
Just came across this thread. We would find a mechanism to get a snapshot of all timers very useful.
This could be in the form of:
a) task list type snapshot, all timer info returned in 1 function call into a supplied buffer; or
b) iterator type mechanism returning all info for a single timer at a time into the supplied buffer.
Our environment is predominantly ESP32 based using ESP-IDF, although that should not make a difference since all timers handler would run under the timer task, whichever MCU that is running on.
Even if this functionality could, in the short/interim period, be handled with a temporary #include at the end of timers.c, until it makes its way through the GitHub processes, much appreciated.
Primarily used during development and testing stage to report of status of all timers to keep track of status (armed/running or not), type (periodic or auto) etc to monitor and check when something should fire.
We are using the task snapshot functionality to produce task reports as per screenshot.
Similarly we are using ESP-IDF memory iteration reporting to produce memory type report, se other screenshot.
You can create an issue describing this feature at GitHub · Where software is built. I cannot provide a specific timeline for implementation. If you would like to implement it, we always welcome contributions .
Some people might find it useful, but we were already keeping tracking of our the timers anyways so it wouldn’t provide any benefit for us. I mostly just confirming that I was reading the code correctly.
.