STM32 uC/OS_II 实践 之 任务调度过程理解及查询式事件

//任务优先级
#define APP_TASK_START_PRIO 10

#define Task_Test1_PRIO 7
#define Task_Test2_PRIO 8
#define Task_Test3_PRIO 9

//任务堆栈大小
#define APP_TASK_START_STK_SIZE 64

#define Task_Test1_STK_SIZE 128
#define Task_Test2_STK_SIZE 128
#define Task_Test3_STK_SIZE 128

可以看到，任务APP_TaskStart的优先级最低，所以在这个任务里创建其他的任务的时候他就会被更高优先级的任务把CPU的占有权抢去，在uC/OS_II里每建立一个任务后都会产生一次任务的调度，如果这个建立的任务优先级更高，则系统就会去执行这个刚创立的任务，如果低就只能等着了。所以在建立Task_Test1任务后，就会跳转执行此任务，现在我们来看下这三个测试任务的源代码来自文件app.c    

/*******************************************************************************
* Function Name : Task_Test1
* Description : 任务1
* Input : None
* Output : None
* Return : None
*******************************************************************************/
void Task_Test1(void* p_arg)
{
(void) p_arg ;
while(1)
{
if(KEY_WKUP == 0)
{
LED1_HIGH;
}
else
{
LED1_LOW;
}
OSTimeDlyHMSM(0,0,0,100); // 延时，为其他低优先级的任务执行留有空间
}
}
/*******************************************************************************
* Function Name : Task_Test2
* Description : 任务2
* Input : None
* Output : None
* Return : None
*******************************************************************************/
void Task_Test2(void* p_arg)
{
(void) p_arg ;
while(1)
{
LED2_HIGH;
OSTimeDlyHMSM(0,0,0,500);
LED2_LOW;
OSTimeDlyHMSM(0,0,0,500);
}
}
/*******************************************************************************
* Function Name : Task_Test3
* Description : 任务3
* Input : None
* Output : None
* Return : None
*******************************************************************************/
void Task_Test3(void* p_arg)
{
(void) p_arg ;
while(1)
{
LED3_HIGH;
OSTimeDlyHMSM(0,0,0,500);
LED3_LOW;
OSTimeDlyHMSM(0,0,0,500);
}
}

刚才说到哪里了？对，现在开始执行Task_Test1的任务了，很显然，这个任务是对一个按键的检测，检测完成后进入一个100ms的延时函数，在uC/OS_II里延时函数的作用要比以前的大得多，在uC/OS_II里任务中调用了延时函数时，该任务就被退出了任务就绪表，然后调用一次系统调度OS_Sched()，重新寻找最高优先级的任务去执行，这个时候咱们的系统只注册了两个任务，这样就只能继续执行任务APP_TaskStart了，刚才在这个函数里建立第一个测试任务就被抢去了CPU的占用权，现在回来继续创建Task_Test2第二个测试任务，这第二个测试任务优先级也比开始任务高，所以自然的它又被人抢去了CPU的占用权，在第二个测试任务里大家又会看到有延时函数，功能肯定是相同的，以此类推第三个测试任务也就清晰的多了。这时还有一个问题就是延时结束后系统操作，刚才测试任务1进入延时后，不会被系统调用，他的延时变量OSTCBDly是随着系统的心跳进行递减的，如果有两个任务同时在延时中只要他们的任务控制块里的延时变量不是0就会在心跳中断服务函数里减1，等到他被减为0，系统会把这个任务重新放到任务就绪表里，并且运行一次系统调度函数OS_Sched()，通过这种机制来保证系统始终在运行着最高优先级的任务。这样系统的调度问题就解释完了，在后面关于中断和信号量使用时，他们对系统的执行顺序也是有影响的，他们是如何参与到系统的调度里，就看后面的讲解了。

刚才我们说了延时函数的作用，如果我把上面的代码里黄色高亮的部分注视掉会有什么样的效果，结果就是其他的3个任务都无法运行了，系统将一直处理任务Task_Test1，再加入我们如果把黄色高亮部分的延时参数调大一些，调整到1s，结果也不令人满意，虽然我给了提起任务充足的运行时间，但是由于每检测一次我都会等待很长时间，导致我的检测精度大大降低，按键变的极为难用。这时候我们就应该思考，在uC/OS_II这样一个实时的嵌入式操作系统里面，最可怕的就是无目的的等待，所以我们尽量使用中断这样方式去处理接口信息，中断和实时系统是相得益彰的。