malacay wrote on Thursday, November 24, 2011:
Do I define as a task?
void vTaskCode( void * pvParameters )
{
for( ;; )
{
// Task code goes here.
}
}
Do I need the endless loop?
What purpose they met?
Can I create the task without the endless loop?
davedoors wrote on Thursday, November 24, 2011:
This is a really fundamental question to the whole concept of writing a mult threaded application. I suggest reading around the subject before dipping your toe into the multi tasking world. Starting with Richard FreeRTOS book would probably be a good option.
richard_damon wrote on Thursday, November 24, 2011:
While strictly speaking, a task doesn’t need to be an infinite loop, in practice it is almost always the best way to define it. If a task doesn’t contain an infinite loop, then it need to have a call to delete itself at the end, as tasks are not allowed to return.
The key thing is unless the task is really only going to be run once ever, it is better to have the task wait for its next request rather than have to rebuild the task context for every use of it,
malacay wrote on Thursday, November 24, 2011:
How can I rebuild the task contex if the scheduler is already started?
richard_damon wrote on Thursday, November 24, 2011:
You can call create task while the scheduler is running. That function builds up the context for the task to run in (TCB and stack).
malacay wrote on Thursday, November 24, 2011:
I have five tasks. Three will start at the same time t = 0 After these three are processed, starts the fourth. Now the other three are to repeat task. And finally starts the fifth task. And now it will start again.
Is this feasible? Should I do the Taskbody in an endless loop?
piero74 wrote on Thursday, November 24, 2011:
My suggestion:
- add to all tasks an FSM inside a while(1), with states: RUN and IDLE
RUN state will execute what you want, and can go by itself on IDLE state when ends its work
IDLE state do nothing, except waiting messages on queue with a timeout (i prefer this approach instead of using infinite timeout, normally i add a SW watchdog to verify that tasks are not blocked, but it is up to you)
- to synchronize task’s works as you want, use messages between tasks: for example 4th task will go in RUN only after receiving messages for all the first 3 tasks (you can choose policy you want)
i think thsi is the correct way to use tasks in RTOS
bye
Piero
malacay wrote on Thursday, November 24, 2011:
Thank you.
How should the scheduler to access it?
Could you perhaps outline should look like that?
richard_damon wrote on Thursday, November 24, 2011:
It isn’t clear to me from your description what is starting the fifth task, do the first 3 tasks alternate starting task 4 and 5?
In either case, what I would probably do is setup a semaphore between the tasks. When each of the first 3 complete they give the appropriate semaphore, and wait to be informed it is time to start again. When all 3 have given their semaphores, task 4, which has been waiting on takes for them, starts up.
No need for an FSM, what was the idle state is just waiting for the semaphore, when that returns the semaphore you are now in RUN, until you finish and go to get the semaphore again.
malacay wrote on Thursday, November 24, 2011:
I would like do this:
T1 | | T1 |
T2 | | T2 |
T3 | | T3 |
T4 | | T4 | | T4 |
T5 | | T5 |
--|--------------|-----------------------|-------------------------------> t
t=0 t=50ms t=100ms
and after 100ms repeat all.
richard_damon wrote on Thursday, November 24, 2011:
To do this I would use a counting semaphore for T1 (to count up to 3), and a binary semapore for T4 and T5
T2, T3, T4 start up automatically
When they finish, each gives the counting semaphore for T1.
T2, T3 then vTaskDelayUntil for the next cycle, T4 waits on its semaphore
T1 takes is counting semaphore 3 times to get the flags from each of the task T2, T3, T4,
When it is done it gives the semaphore for T4
T4 then restarts, and does its second set of actions, and when done give the semaphore for T5, and then does a vTaskDelayUntil (if these are the same as its first, then you can use a flag to determine which end of operation to do at the end of processing)
T5 gets its semaphore and does its operations, and loops back to wait again.
malacay wrote on Thursday, November 24, 2011:
I’ll turn translated it a try.
Thank you for the first time.