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.