In FreeRTOS v8.0.1 standard CM0 port, xTimerCreate(..) allows the software timer API calls to be made before the scheduler starts because xTimerCreate(..) calls prvCheckForValidListAndQueue() that actually creates the timer.c static xTimerQueue. Things like xTimerStart(...) can then be used as per the API documentation. Once the scheduler starts then the timer queue command is processed and the the commands are executed.
In comparison xTimerPendFunctionCall(...) can only be called once the xTimerQueue has been created. I can force xTimerQueue to have been created by creating and then deleting a timer before using xTimerPendFunctionCall(...) prior to starting the scheduler. As far as my limited abilities go this appears to be safe for v8.0.1 and would have worked for v7.5.2 that I was previously using (if it had such an API).
My workaround is a bit of a bodge; am I fundamentally misusing the xTimerPendFunctionCall(...) functionality by wanting to call it prior to starting the scheduler???
(Naturally I could create a task to call my function if this approach is fundamentally unsafe.)
Given the advertised ability to configure timers before the scheduler starts, it appears to me that xTimerPendFunctionCall(...) falls into a similar class of functionality. What was the original intention for the FreeRTOS API usage prior to the scheduler starting???
I found that many API calls could me made in v7.5.2 which worked as expected despite there not being an explicit comment in the documentation that it was safe to do this and I am concerned about using such API calls in a blase manner that could blow up in the future. Is there a list on the website API pages (that I have failed to find) which records which are expected to always be safe???
Thank you for your help,
While it was not envisioned that xTimerPendFunctionCall() needed to be called before the scheduler was started I don't see any reason why the code could not be updated to make it safe to do so. I would need to look at it in more detail to ensure it didn't add any unnecessary bloat though. I would suggest adding a feature request through sourceforge for this. There will be a new release relatively soon (I'm waiting on other people before I can make it so don't know when exactly) but it might be that it can get done for that.
With regards to calling functions before the scheduler has started. The most important thing is not to call anything that is going to block or cause a context switch. A context switch might be attempted unexpectedly if, for example, a tasks priority was changed and that task happened to be the task that would run first when the scheduler was started. As a blanked rule of thumb, API functions other than those that create objects or explicitly say can be used before the scheduler is started should be used. In reality there are more functions that can be, but there are too many permutations and scenarios to be able to document it in a comprehensible way.
Its a bit like the rule that says "don't call any API functions when the scheduler is suspended". It is simple to have this as a global rule, whereas in reality for an expert user at least, you would find that there were several API functions that were safe to call when the scheduler is suspended - but it is much simpler from a usability point of view to have the global rule.
Thanks for the Reply.
Feature request submitted: https://sourceforge.net/p/freertos/feature-requests/83/
Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.