Hi, there's a group of xTimer... functions defined in FreeRTOS that can be called from an ISR:
xTimerStartFromISR
xTimerPendFunctionCallFromISR
but it appears they're not included in ESP-IDF version of FreeRTOS. Not included at all, or can be enabled by some configuration settings?
The reason for asking this question: i need something like a deferred function call (DPC) that is initiated from an ISR and performed after ISRs are done. And if possible then with some little time delay, for example 2ms after the ISR. This would be used for debouncing switch or encoder inputs. Dont want to use hardware timer - these should be saved for more important stuff.
PS it appears that xTimerPendFunctionCall() is not available too?
xTimer...FromISR functions availability - FreeRTOS
Re: xTimer...FromISR functions availability - FreeRTOS
need some clarification here
in the components\freertos\xtensa\include\freertos\FreeRTOSConfig.h file there is this definition
this #define controls availabilit of some xTimer.... APIs, not only xTimerPendFunctionCall.
and still, xTimerPendFunctionCall is not defined and compilation throws an error
Same thing for xTimerPendFunctionCallFromISR
So why these functions aren't there, according to FreeRTOSConfig.h they should be enabled - am i doing something wrong or is it maybe hidden in some configuration options?
in the components\freertos\xtensa\include\freertos\FreeRTOSConfig.h file there is this definition
Code: Select all
#define INCLUDE_xTimerPendFunctionCall 1
and still, xTimerPendFunctionCall is not defined and compilation throws an error
when i try to use xTimerPendFunctionCall.error: implicit declaration of function 'xTimerPendFunctionCall'
Same thing for xTimerPendFunctionCallFromISR
So why these functions aren't there, according to FreeRTOSConfig.h they should be enabled - am i doing something wrong or is it maybe hidden in some configuration options?
Re: xTimer...FromISR functions availability - FreeRTOS
sorry, everything is allright. I'm just suffering from bouts of stupidity. All functions are in place, my code was just messy. please delete whole topic, its useless.
-
- Posts: 4
- Joined: Wed Apr 29, 2020 3:13 am
Re: xTimer...FromISR functions availability - FreeRTOS
Man, if you are stupid, I am too. I have the same problem here: when an interrupt is triggered, I need to write some stuff in the SPI chip clearing one mask. That's very quick job, but don't fit inside the ISR. So I need the same as you, a way to make a callback, right after the interrupt, not allowing other tasks do interfer, because this routine is VERY critical for my application. I am even having an odd problem, where the ESP32 is losing one interrupt after 10-12h of normal operation. So, the resume is that I need to use xTimerPendFunctionCallFromISR and cant compile it. How did you solve it? And do you believe that the callback will execute right after your ISR, garanteed?
Thanks in advance,
Best Regards
Thanks in advance,
Best Regards
Re: xTimer...FromISR functions availability - FreeRTOS
Allright, so lets try to get something from that
1. xTimerPend.... functions are there, i just needed to include "freertos/timers.h" in addition to "freertos/task.h". Browsing esp-idf sources helps.
2. But my intuition about them was wrong. xTimerPendFunctionCall will do what it says, namely it will schedule the function to be called at a later time, when the interrupt handling is done. The problem here is that the delay may be bit unpredictable as it's done on a low priority task. And its not suitable for delaying processing by a specific amount of time because you dont have control over the delay. But I think it's reliable (it doesnt lose scheduled calls).
3. For a controlled delay i tried to use xTimerPendFunctionCall which takes a 'ticks to wait' parameter (so i thought it's the delay) - but no, it's not a delay, it only says how long to wait before giving up if the timer queue is full and function call cannot be scheduled. So when you do xTimerPendFunctionCall the function will be called immediately after ISR is done (with some delay you dont control).
4. So the next possibility was to use FreeRTOS soft timer (xTimerCreate). The problem with these is that the resolution is low, forget about microseconds or even single milliseconds.
5. But here comes ESP-IDF to the rescue with esp_timer high resolution timers (this is based on a single hardware timer used for scheduling mutliple events). These timers run at much greater resolution and much better accuracy than FreeRTOS timer functions (single millisecond precision is good and delays are usually very predictable).
https://docs.espressif.com/projects/esp ... timer.html
I'm using these for debouncing push buttons and rotary encoders - and there's a lot of oscillations and unexpected interrupts in ESP32 compared to Arduinos.
6. So my suggestion for you is to use esp_timer APIs if you need good sub-millisecond resolution. There are some limitations, i think - there might be some variation in the timing (as the callback happens outside of timer ISR and there might be other timer events scheduled for the same time slot) and possibly there are some limits to the number of timer events you can schedule. The advantage is that you're free to call any FreeRTOS functions from your timer handlers as it's not in an ISR (and you can do logging).
7. For time-critical, microsecond-level stuff (like a communication protocol) i think the only option is to use a dedicated hardware timer.
1. xTimerPend.... functions are there, i just needed to include "freertos/timers.h" in addition to "freertos/task.h". Browsing esp-idf sources helps.
2. But my intuition about them was wrong. xTimerPendFunctionCall will do what it says, namely it will schedule the function to be called at a later time, when the interrupt handling is done. The problem here is that the delay may be bit unpredictable as it's done on a low priority task. And its not suitable for delaying processing by a specific amount of time because you dont have control over the delay. But I think it's reliable (it doesnt lose scheduled calls).
3. For a controlled delay i tried to use xTimerPendFunctionCall which takes a 'ticks to wait' parameter (so i thought it's the delay) - but no, it's not a delay, it only says how long to wait before giving up if the timer queue is full and function call cannot be scheduled. So when you do xTimerPendFunctionCall the function will be called immediately after ISR is done (with some delay you dont control).
4. So the next possibility was to use FreeRTOS soft timer (xTimerCreate). The problem with these is that the resolution is low, forget about microseconds or even single milliseconds.
5. But here comes ESP-IDF to the rescue with esp_timer high resolution timers (this is based on a single hardware timer used for scheduling mutliple events). These timers run at much greater resolution and much better accuracy than FreeRTOS timer functions (single millisecond precision is good and delays are usually very predictable).
https://docs.espressif.com/projects/esp ... timer.html
I'm using these for debouncing push buttons and rotary encoders - and there's a lot of oscillations and unexpected interrupts in ESP32 compared to Arduinos.
6. So my suggestion for you is to use esp_timer APIs if you need good sub-millisecond resolution. There are some limitations, i think - there might be some variation in the timing (as the callback happens outside of timer ISR and there might be other timer events scheduled for the same time slot) and possibly there are some limits to the number of timer events you can schedule. The advantage is that you're free to call any FreeRTOS functions from your timer handlers as it's not in an ISR (and you can do logging).
7. For time-critical, microsecond-level stuff (like a communication protocol) i think the only option is to use a dedicated hardware timer.
-
- Posts: 4
- Joined: Wed Apr 29, 2020 3:13 am
Re: xTimer...FromISR functions availability - FreeRTOS
Thanks for the response. I actually have a slighly different problem. My interrupts are digitally generated by other IC and are slow, so dont need extra cares with debouncing, etc. I was endeed able to use xTimerPendFunctionCallFromISR, and the errors was really just foolish of mine when declaring the functions, but in the end I discovered that the xTimerPendFunctionCallFromISR is in fact used in a centralized Deferred Interrupt Handling, and, as I dont have many have interrupts, was not a advantage for me. So, I'm using a descentralized Deferred Interrupt Handling as a light weight binary semaphore to a high priority task and I believe that it is in fact unblocking the DIH just after the interrupt. I have putted it under the oscilloscope probes and could see that the IRQs have always the same period, and was called always from the same time intervals.
There is two usefull links here:
https://www.freertos.org/deferred_inter ... ssing.html
https://www.freertos.org/RTOS_Task_Noti ... phore.html
Best regards, my friend!
Gabriel Duarte
There is two usefull links here:
https://www.freertos.org/deferred_inter ... ssing.html
https://www.freertos.org/RTOS_Task_Noti ... phore.html
Best regards, my friend!
Gabriel Duarte
Re: xTimer...FromISR functions availability - FreeRTOS
thanks, this may come handy in future. The wealth of RTOS functions related to synchronization and message passing can be confusing.
And you know what i use for 'deferred interrupt handling' in Arduino? A boolean flag that is set in the ISR and periodically checked in the main loop (logic so trivial that it doesnt even deserve a specific name).
Would be great if we could do same thing in ESP32. I'm not recommending to use a global bool variable, but if we had an atomic compare-and-set operation then it would be easy to do lock free signaling from ISR to the task main loop.
So, can anyone provide some info about atomic operations in ESP32 and thread-safe operations on variables (increment, compare and set, etc) - what is supported, on what data types, what APIs?
[Edit: stdatomic.h standard library is available so I think we have it all]
And you know what i use for 'deferred interrupt handling' in Arduino? A boolean flag that is set in the ISR and periodically checked in the main loop (logic so trivial that it doesnt even deserve a specific name).
Would be great if we could do same thing in ESP32. I'm not recommending to use a global bool variable, but if we had an atomic compare-and-set operation then it would be easy to do lock free signaling from ISR to the task main loop.
So, can anyone provide some info about atomic operations in ESP32 and thread-safe operations on variables (increment, compare and set, etc) - what is supported, on what data types, what APIs?
[Edit: stdatomic.h standard library is available so I think we have it all]
Who is online
Users browsing this forum: cdollar, Gaston1980 and 115 guests