I cannot get when I should use xTimerPendFunctionCall. Can I use it to make a function to be called after some given time? Can I block in the pended function?
The interrupt safe version xTimerPendFunctionCallFromISR() is really the useful version - that can be used to defer processing that cannot be done in a an interrupt to a task - but as the code runs in the timer task it should not block.
The non interrupt version is just a consequence of the having the interrupt version. I don’t think the non interrupt version is mentioned in the book
As I can get it, deferred function is processed as fast as possible depending on how full is timer command queue and timer priority. To delay a function execution for a given time we should create a timer (or use tick hook with counter). Deferring is done mainly to save memory and not to mess with priority levels. Am I right?
Related, but a bit offtopic question - if there can be a block (on semaphore or queue), is it FreeRTOS-ish to do in such a way: in a task that shouldn’t block, i.e. timer callback or interrupt handler, call xTaskNotify to wake up handler task which can be blocked?
Really offtopic question: is there a code review section in this forum? I’m new to FreeRTOS. Currently I write code that compiles and does what I want, but I’m not sure I do it in a way suggested or most convenient way.
To keep the ISR as small as possible. When an ISR is running, all the interrupts of lower priority are blocked, so you want to keep ISRs as short as possible.
You can call
xTaskNotify from the timer callback and
xTaskNotifyFromISR from the interrupt handler.
If you have a FreeRTOS related question about a piece of code, you can post it here but there is no dedicated code review section.
One use of the non-ISR version of xTimerPendFunctionCall is to serialize sections of code that are short and won’t block. Since all invocations of these Pended Functions will be executed in the Timer Task, you know they will run in a serialized order, and with no possibility of being interleaved. Thus multiple task can pend operations and not require anyone to need to block on a mutex/semaphore to enforce serial execution of a sequence.
If the timer task is at (or at least very near) the highest priority, it becomes sort of like bumping the priority of that operation so it will complete before any other lower priority task can get in.