I am trying to implement a program where I am pausing some task and then re-enabling it later.
I am working with an esp32 board using platformio and android framework, but I am quiet sure the issue is not with the board or with the library but with my c++ knowledge.
I also tried that I am creating the xTaskHandle in the Controllers constructor and pausing the task right away and it worked. So both FreeRTOS and the esp32 board works as expected.
The way I am doing it this way is because in real world I am going to have many tasks and I will want to pause and restart them from various places in the code, so it looks straightforward to me to store them in a central class and get them once I need. If this is not the c++ way(probably not) I am happy to learn how should I do it
Honestly there is not much reason. Iâve used xTaskHandle instead of TaskHandle_t because Iâve seen that one in multiple tutorials and it was working when everything was in one file.
I tried to modify the code according to your advises but still no luck.
Iâve actually tried two things(and updated the repo):
1: Just pasted what you advised, strangely after this the exception went away but the timerTask() continued to write to the output.
2: added these two lines to the TaskHandles constructor:
timerHandle = new TaskHandle_t();
timerStopHandle = new TaskHandle_t();
I am suprised that the exceptions didnt occure anymore in the option 1 because as I see I was just passing null pointers arround. To overcome this I tried to give value to them but this resulted in the very same exception.
Something seems strange here. First, TaskHandle_t is itself a pointer to the Task Control Block, (an opaque pointer as the definition of that structure is never made public), so using ânewâ to create one of these on the heap is not very useful. This means that your timerHandle is a pointer to a pointer to the TCB, and everywhere you access it you are going to need an extra level of indirection. The ONLY major use for something like this would be if you had a task that you kept on creating and deleting, so the value of the handle kept changing, but you want to be able to pass to some function WHICH of these tasks that you kept on creating ad deleting you wanted to work with.
Let me describe my use case here, maybe my whole approach is wrong.
So I am going to read multiple sensor values, for example I will read from gps module, I will read from a joystick module, I will update screen and another task will update a ble characteristic.
What I am aiming for is to create these tasks and be able to access to their handles from different places in the code.
For example create the joystick reading task but only actually start after my ble connection callback fired. Generally I would like to start and pause my tasks responding to various events. To be able to achieve this it seemed convenient to hold task handles in a central location and just get the handler once I want to do something with the task.
this sounds like a problem that I am currently trying to solve:
Create TaskManager (as a task with itâs own queue)
Pass TaskManagerQueue to tasks we want controlled (pass in setup data i.e. pvParameters)
This is so that they can place a message on the TaskManagerQueue to say that it needs registering
TaskManager stores the TaskHandle_t in an array
Some task sends a âSuspendâ message to the TaskManagerQueue
TaskManager loops over TaskHandle_t array calling vTaskSuspend for each handle
Some task sends a âResumeâ message to the TaskManagerQueue
TaskManager loops over TaskHandle_t array calling vTaskResume for each handle
Since the FreeRTOS Kernel can do what you are trying to do, why not let it take care of âstartingâ (resuming) and âstoppingâ (suspending) tasks?
Since you are waiting for events in each task, why not use Event Groups? That way, you can signal multiple event and the task blocked on the event will be resumed by the FreeRTOS kernel.
Does that seem apt? Did I understand your problem correctly?
IMO (asynchronously) suspend/resuming tasks from an other task is not the best approach to design a robust and modular application. Why not just signaling events to tasks and process the events in the task (state machine) ? I donât really understand the benefit of using async. suspend/resume for task synchronization.
I agree with Hartmut here. Why do you need to actually suspend the tasks. They will block on their queues waiting for data, thatâs as good (or better) then suspending them.
when the battery voltage drops below a certain threshold we want to suspend all tasks and then resume them again when the battery has charged to another threshold
this scenario will come into play if there is not much sunlight, for example, and the solar panel is not charging the battery as quickly as it is discharged.
The point I think you are missing is that if the task just blocks because it isnât getting data, it will save just as much power as suspending it.
In fact suspending a task save NO power, just gives other tasks more time, just as blocking does. To save power you need to get the processor to be able to drop into a low power mode for it.
The point I think you are missing is that if the task just blocks because it isnât getting data, it will save just as much power as suspending it.
You might be right there -as in I may have overlooked that nugget!
The power saving from suspending a task itself is negligible for sure, however when the tasks are running sensors/components which do draw power, suspending those tasks (be it by not receiving data, or by a call to vTaskSuspend) will have the desired effect of reducing power drain
Though youâve definitely given me cause to reconsider my approach to this, since task suspending/resuming is feeling more and more like the wrong way to manage this.
Be aware that suspending/resuming the sensor task can happen e.g. right in the middle of an I/O sequence because itâs not synchronized to task execution. That might cause side effects. Iâd tell the sensor task to stop polling the sensors by a command or event and waiting for a resume command/event to continue.
I will point out that suspending a task doesnât reduce any power consumption of the task, unless the I/O that task is doing is costing the power. The issue is the processor will still be executing instructions just as fast, as if nothing else is running, the idle task will be.
What can be done, is use some of the Hooks is to let the idle task detect that things wonât need work for awhile and then have that move to a lower power mode. One simple one is to just add a Wait For Interrupt instruction for some modest savings. Beyond that, it depends on what other lower power modes the processor has.
It is also much better to program the task to understand when it needs to âpower downâ and take the appropriate actions, and then block until needed. This then allows it to communicate a busyness to the idle task to allow it to properly decide about low power modes.
@bill-richards I would love to see your project if you can share it!
@kanherea This actually sounds great, I am definitely going to give it a try, thanks!
@hs2 The idea was to have something like this. This is a freertos task in the end and it calls a ble method which writes to the characteristic. The idea was to not let it run until there is alive BLE connection. So I create the task and pause it and after the BLE callback tells me that there is a connection I just unpause it and it starts to do its job. Actually I was kind of reinventing wheel and trying to do something event groups are for.
@richard-damon the idea was to create all the tasks at the beginning and then manage them when I actually need them. So to create the ble characteristic publisher task and then just enable its running once we have ble connection. I am going to dig myself into event groups as that seems to be the way it should be solved.
Yes, rather than have an external agent suspend the task, make the task know when it should be doing its job and just block when it doesnât have something useful to do.
