Hello,
I would like to be able to make an xTimerPendFunctionCall(...) call to queue up a pending function before the FreeRTOS scheduler has started.
My own use case is rather obtuse but a more general one would be to use the software timer queue also as a pending event queue (a la Node.js) so that you can have many state machines running without rolling your own functionality / having many threads (and their stacks + thread safe queues). Such systems often require some initialisation 'kicks' to get them going and since many FreeRTOS API calls can only be made after the scheduler has started, many 'kicks' can't be done until afterwards. This then provides the impetus to 'queue up' some pending function calls before the scheduler starts so that they get executed just after it does.
I would be quite happy with an optional FreeRTOS_optional_init(...) call that was required to enable this to work. As discussed on https://sourceforge.net/p/freertos/discussion/382005/thread/4f806228/ the apparent current limiting factor is that xTimerPendFunctionCall(...) is not currently capable of creating the xTimerQueue in the same way that xCreateTimer(...) can.
Thank you for providing FreeRTOS for all to use; I greatly appreciate your efforts and ability,
Richard
To record my response to an out-of-thread-suggestion that I use co-routines / roll my own event queue / use interrupt vectors:
Note that using co-routines is a distinct programming model from using events (1 event / interrupt / software timer execution could spawn 0+ events; i.e. potentially >1 which you would have to track).
Implementing an event queue in a new task means you ~double the task and stack space overhead (assuming you use software timers which need a comparable stack size).
For my case the execution time is sufficiently short (but far too long for an interrupt context other than a single priority dedicated to long duration processing) and I want to maintain the event ordering so I can't use interrupts.
Either way you require more synchronisation if you have timer and event functionality in different tasks / contexts.
Last edit: Richard 2014-07-07
It has been decided not to make this extension for the following reasons:
While prvCheckForValidListAndQueue() is called when a timer is created it is likely that most timers will be created at initialisation time, or at least infrequently, so there is little run time overhead. On the other had xTimerPendFunctionCall() is likely to be called often at run time so would incur a larger run time penalty.
There are a couple of low impact work arounds. One already mentioned (create a timer first, then delete the timer if it is not required) and second to perform all initialisation from an 'init' task rather than from main - at which pointer the timer queue will have been created. Some RTOSes actually force you to do that anyway, they have no concept of a context prior to the scheduler being started.
Thank you for the update.
Have a happy new year