Hello guys,
Here is another silly question:
What do you think it might be more efficient regarding the use of FreeRTOS resources: Setting few big tasks or many smaller tasks?
I guess it is different for every project, but in general, would it be better to split a big task into multiple smaller tasks or the other way around?
Thank you
I am confused about what you mean by “splitting.” A task by definition models a (generally infinte) strand of execution that (and this is the critical point) can run concurrently with other such strands. If your project is well modelled, further splitting a task would be pointless as you will at best define coroutines that will deterministically pass the baton back and forth to each other, thus not benefit from concurrency but on the downside will make the code less efficient and more error prone.
Maybe you would like to sketch a sample project and present one or more ideas of “splitting?” Simply pondering the pros and cons will already tell you a lot about how good your model works.
Every task imposes a degree of overhead, so breaking up a single operation into multiple task just for the sake of breaking it up is generally bad.
The opposite can also cause a problem, combining two operations that are fundamentally independent into a single task means you need to add “overhead” code to determine which of them should be done at any given time.
What often IS good, is to take a task written as one giant function and factor it into a single task built with smaller functions all called by the main task function.
I find that generally I can get my list of tasks that should be in the system by looking at the list of external inputs that the system needs to respond to, and these become POSSIBLE tasks. External input that only provide responses to requests that occur in response to other inputs, (like many Serial Ports, I2C Ports that we master, or SPI Bus that we master) don’t get a “task” but a driver function that a task will call with the request and the task blocks while the driver gets the answer which it returns.
Note, Serial Points that we get “commands” from, not just responses will tend to get a task, but that task will use the same sort of low level serial driver, just that the task will normally be waiting on the serial port for the next command.
The full processing from external request to do something until the response is given will be a single task, unless there is a step that takes a significant amount of I/O time and it is useful to get back to looking for the next input before the operation finishes.
I am sorry, the idea was not clear.
I did not mean split a task into smaller tasks, but split a project into several small tasks rather than a few bigger tasks
Thank you for your detailed reply.
You completely got my idea behind the question
Regards.
The same arguing applies to both.