Qsys与uCosii任务切换.docxVIP

Qsys与uC/OS-II学习笔记5：任务切换????????上个笔记提到调用任务延时函数后，系统将会进行任务切换，否则当前运行任务就会一直霸占着CPU的使用权。那么这个任务延时函数中到底有什么奥秘？调用它为什么能够让任务切换自如？这个笔记咱就要揭开uC/OS-II的一大设计精髓——任务切换。???????? 特权同学并非软件工程或是计算机科班出身，还真没学过什么操作系统，对于CPU内部架构和工作机制的理解和认识完全靠自身的实践、摸索加一些教科书的研读。对于一些概念的阐述或许不够专业，如果有些偏差也非常欢迎大家提出来加以纠正，但是我想这些“草根”式的图文或许多少能够帮助大家快速的理解和认识一些工作机理，但愿“八九不离十”应该是形容这种状态比较合适的词汇吧。其实如果能起到这样的效果，那么对这些文章而言也就足够。毕竟一板一眼、中规中矩的教科书我们看得太多了，真的是有些审美疲劳了。???????? 因为要说任务调度的机理，那么我们不得不先把几乎所有嵌入式处理器相关的书籍中都会提及的中断概念再提一下。虽然讲中断的书满大街都是，但是我想像图1这样一个简单示意图就能够把中断说清楚的还真不多（怎么有点“王婆卖瓜自卖自夸”的嫌疑，脸红中~~）。一个“裸奔”的CPU软件，无非就是一个main函数里面while(1)中包办所有功能，偶尔来个中断响应一些实时性要求较高的处理，仅此而已。那么，很显然，中断响应时有一个脱离当前main函数的举动发生，想要让中断响应前后CPU回到原有的main函数执行状态，则必须有一些额外的工作要干，第3和6步的出栈、入栈便是。这个示意图中，大家需要明白，当某个函数或某些指令占用CPU时，意味着CPU中的寄存器存储着和当前处理状态相关的各种中间数据信息；同样的道理，当中断函数占有CPU数据时，CPU中的寄存器存储着和中断函数相关的各种中间数据。堆栈是专门开辟的一片存储空间，用于和CPU寄存器相映射。一个在main函数中运行着的程序（包括在它的子函数中运行），如果被一个中断信号打断后去执行中断处理，最后返回，这样一个过程，发生了以下一些事情：1.?????? 应用程序（即Main函数）中执行某条指令，此时应用程序控制CPU的使用权，表现为占有CPU寄存器。2.?????? 一个中断源产生，应用程序停下了CPU的使用。3.?????? 应用程序停下来那一刻的CPU寄存器内容被copy到堆栈中，即我们称之为入栈操作。4.?????? 程序转到中断处理函数执行，表现为即将到来的下一时刻中断处理函数占有CPU使用权。5.?????? 中断处理函数拥有CPU使用权，表现为占有CPU寄存器，直到中断处理函数执行完成。6.?????? CPU寄存器恢复执行入栈操作前的状态，即从堆栈中copy之前入栈的信息，我们称之为出栈。7.?????? 应用程序回到中断前的下一条指令开始执行，虽然经过2-6步的“意外事件”，但是除了应用程序比预期延时了一小段时间执行外，好像这个“意外事件”没有发生过一样。图1???????? 再来看uC/OS-II中的任务切换是如何实现的，应该说，和传统CPU的中断机制有着异曲同工之妙。说白了，uC/OS-II其实也是假借中断之名偷梁换柱般完成了任务的切换。因为uC/OS-II中的每个task都好比“裸奔”着的软件程序中的main函数，他们都有机会独立的占用CPU的使用权。Task的写法通常有两种：voiduser_task(void* pdata){?while (1)?{??? //用户代码?}}或者voiduser_task(void* pdata){?//用户代码?OSTaskDel(OS_PRIO_SELF);?//删除当前任务}????????? 前者我们已经接触过，在用户代码的最后我们通常也会加上任务延时函数，让出CPU的控制权。而后者相当于一次性完成的任务，执行过一次该任务后，自我删除，从此销声匿迹，除非该任务在其他任务函数中被重新建立恢复。OSTaskDel();函数INT8U???????? OSTaskDel?????????????? (INT8U??????????? prio);???????? 当任务创建并由OSStart()函数启动后，要么处于运行态（同一时刻有且只有一个运行态的任务），要么处于就绪态，如果处于某个正在运行的任务使用OSTaskDel()函数删除了该任务本身或者其他任务（空闲任务OSTaskIdle()是唯一不能被删除的任务），那么被删除的任务并不是从存储代码的程序中物理消失了，这段代码还在，只不过它已经不在任务切换优先级列表中了，以后的任务切换中不会考虑运行该任务，我们说这种状态叫做休眠态，如果要从休眠态唤醒到就绪态，则需要重新创建该函数。OSTaskIdle()函数