About ucosii task switching problem

ziffyppo

About ucosii task switching problem [Copy link]

I called taskCreate() in main() to create two tasks, the code is as follows static void taskCreate (void){ // DispSem = OSSemCreate(1); OSTaskCreate (taskA, (void *)0, &Task_AStk[TASK_A_STK_SIZE-1], 1); OSTaskCreate (taskB, (void *)0, &Task_BStk[TASK_B_STK_SIZE-1], 2); } static void taskA(void *parg){ init_LCD(); InitUART0(); InitUART1(); ScanKeyInit(); MainTask(); } static void taskB(void *parg){ UARTPrintStr("hello OK"); Mcard_Init(); while(1) { Cika_task(); } } taskB In the code, the card is swiped and the GUI is displayed in taskA. There is no system delay or waiting event in taskA. Originally, this code was burned into the board for experimentation, but the card number data can be displayed when the card is swiped. According to my understanding, the system runs taskB first, waits for the system clock to schedule the task, switches the task, and runs taskA. Because taskA has a high priority, the system clock task scheduling will not switch taskB. Even if the card is swiped by interrupt processing, the track information processing is done in taskB, so the card number data should not be displayed. Please explain the principle. Thank you

daicheng

The first problem is: ucos reserves the highest 4 priorities (0, 1, 2, 3) and the lowest priority OS_LOWEST_PRIO-1 for statistical tasks. The second problem is that the above code alone cannot explain your problem.

ziffyppo

Thank you very much for your answer.
First: The top four priorities are reserved, but they can be used. The statistics task is the second lowest priority, the lowest priority is the idle task that does nothing in an infinite loop, and the statistics task can be unloaded. Second: Maybe my writing ability is not good enough. In fact, the functions called in tasks A and B are all drivers and other modules, which should have nothing to do with the ucosii task. [ This post was last edited by ziffyppo on 2011-3-2 09:37 ]

ziffyppo

Actually, I have not figured out how the tasks are switched
. Let's ignore the contents of tasks A and B for now.
Can anyone tell me how the tasks are done? Thank you very much
:)

daicheng

daicheng

If the content in the task is ignored: Then task A task B When system tasks A and B are established, task A has a higher priority, so execute A. When there are (semaphores, event markers, message queues, etc. and OSTimeDly), execute the lower-level task B. When (semaphores, event markers, message queues, etc. and OSTimeDly, interrupts), if task A enters the ready queue at this time, A will be executed, otherwise the idle task will be executed.

ziffyppo

Thank you very much
for your answer!
I got the answer I wanted.
I just found a ucos simulator to remove the content in the task and only print the debugging information, which also confirmed the conclusion. I
understand the mechanism, but I am more confused, because the ucos framework I use now is ready-made, I just make adaptive changes, and the task does not have the conditions for switching tasks at all. The gui uses ucgui, so I can only continue to study the source code.
Thanks again!!! :)

莫妮卡

Daicheng is such a warm-hearted person!

CCTV-10

Originally posted by daicheng on 2011-3-2 10:08 If the content in the task is ignored: then task A task B When system tasks A and B are established, task A has a higher priority, so execute A when there are (semaphores, event markers, message queues, etc. and OSTimeDly) execute the lower-level task B, when (semaphores, event markers, message queues, etc. and OSTimeDly ...

May I ask: How does a task switch from an idle task to execute another task?

wstrom

I have already answered this question in the UCOS FAQ. Please refer to it for reference!

qqatscau

When a clock interrupt occurs, the system scans the task ready table and switches if there is a ready task.

降龙十巴掌

Originally posted by CCTV-10 on 2011-3-21 23:11 May I ask: How does a task switch out of the idle task to execute another task?

This question is quite interesting. Generally speaking, once the system is executing the idle task TaskIdle, it means that other tasks have been suspended or deleted (because the idle task has the lowest priority) and are waiting for delays, semaphores, messages, etc. In addition, we also see that the actual processing in the code of the idle task TaskIdle is a simple continuous self-increment processing of a 32-bit variable (OSIdleCtr++), and there is no task scheduling switching function OS_Sched(), mainly considering the CPU burden, and there is no need for it. So if you want to switch out of the idle task, you can only do it through the interrupt level. This interrupt can be a clock beat interrupt (delay timeout processing), or an external asynchronous trigger event interrupt processing (I/O, exception fault processing), etc., rather than actively switching tasks at the task level (such as xxxPost, etc.), because all other tasks are suspended at this time. Here is a very interesting question. If all user application tasks (except idle tasks) are not suspended because of their own calls to the Dly delay function, they may be suspended because of waiting for events, semaphores, messages, etc., then there may be a problem, which is often called "deadlock". At this time, you can only wait for timeout processing. Therefore, when designing the system, you should pay attention to prevent this situation as much as possible. On the contrary, if it is not because of the above situation to enter the idle task TaskIdle, there is no big problem. After the delay is over, when the clock beat interrupt exits, OSIntExit() will be called to determine the task scheduling switch, so as to make a decision on whether to perform task switching.