I have a system that uses an ST-ARM processor, Cube32MX, and True Studio with FreeRTOS 10.0.1 as included.
It’s a mixed C, C++ system where the “main” program starts an RTOS task from within C++. That task creates all the required subtasks.
My problem (and I could structure the program a bit differently, but I’m looking for the cleanest solution), is that creating an RTOS Task and immediately suspending it does not work in the C++ environment. The RTOS task is started when called, but gets too far and runs into uninitialized variables. Obviously enough, a solution would be to split the task creation from the initialization/install routine, which is likely what I’ll do.
What I would like is a method of creating a task, within another task, that allows the creation of a task in the suspended state.
I can’t see a way, within FreeRTOS, of doing this.
Might this be added as a feature?
I can see that creating a task and not having it run at all until enabled could be useful.
If you are doing this after the scheduler has already been started then ensure the priority of the task being created is lower than the the task calling xTaskCreate(), then suspend the task, then set the priority of the task to whatever it should be.
Why not using your own startup synchronization matching your specific use case ?
E.g. use and block on a task notification on entering the task routine and proceed entering the forever task loop when getting signaled by task create/start code.
Or maybe use a class wrapper for tasks supporting RAII…
For the startup synchronization, I’ve always had a bit of difficulty with a task referring back to the owning class’ variables. So I did try it, but the task is referring to something, somewhere that doesn’t seem to be what I need (not sure where it goes…). So startup synchronization is not working as well as I’d like.
Personally, I try to create all my tasks (if at all possible) before starting the scheduler. In fact, with C++, I create most of them as global classes before main even starts. As Richard Barry says, you can also create them at a lower priority then yourself if the scheduler is running, and ten raise the priority higher later if needed.
Another option, would be to have the task perform as its very first action, a wait on a direct to task notification that isn’t sent until things are ready.
The best method I know is to begin the task with a wait for notification, (or something similar), and then send it the notification when things are ready.
A framework that doesn’t give you a hook to set everything up before starting the scheduler doesn’t sound very good to me.
As I said, such a framework doesn’t sound good to me. Personally, I avoid such frameworks, and if that is the only option for the processor, I don’t use that processor. Admittedly, you need to be in a position to makes such decisions.
One brute force hammer method would be to just begin by suspending the scheduler or enter a critical section, create what you need, and then resume the system.