《嵌入式实时操作系统μCOS原理与实践4知识分享》由会员分享，可在线阅读，更多相关《嵌入式实时操作系统μCOS原理与实践4知识分享（49页珍藏版）》请在金锄头文库上搜索。
1、嵌入式实时操作系统C/原理与实践,教材 ：嵌入式实时操作系统C/OS原理与实践 电子工业出版社 作者:卢有亮 电子科技大学能源科学与工程学院,第4章 事件管理,4.1 事件管理重要数据结构 4.2 事件管理程序 4.3 信号量管理 4.4 互斥信号量管理 4.5事件标志组管理 习题,C/OS-II作为实时多任务操作系统，是事件驱动的，支持信号量，消息等机制。 事件主要包括信号量和互斥信号量，而事件的组合可以用事件标志组来管理。 本章的内容包括事件管理中数据结构，事件管理程序，信号量管理，互斥型信号量管理，以及事件标志组管理。,4.1 事件管理重要数据结构,4.1.1 事件控制块ECB,事件控制
2、块ECB在事件管理中占据着举足轻重的作用。虽然事件控制块ECB并没有任务控制块TCB的内容丰富，但是在事件处理中仍然是核心的数据结构，频繁被访问。ECB的定义出现在操作系统的头文件ucos_ii.h中。,上图没有任务等待事件的发生，因此就绪组为0，就绪表的内容也是全0。假设有优先级为20和32的任务在等待事件的发生，那么就绪组和就绪表应如下图所示：,4.1.3事件控制块空闲链表,事件管理中，将空闲的事件块链接为一个单向的链表，事件控制块空闲链表。这个链表的形式和任务块TCB的空闲链表的形式是完全相同的。 当创建一个事件的时候，要在事件控制块ECB空闲链表查找是否有空闲的ECB可用。如果有就从链
3、表中取出分配给事件。要做这件事，首先要找到链表的表头，因此声明了一个重要的全局变量OSEventFreeList指示表头的地址，称之为事件空闲链表指针。 OSEventFreeList的定义为： OS_EVENT *OSEventFreeList; 在事件控制块初始化程序结束的时候，该链表如图所示。,4.2.1 事件控制块ECB初始化,事件控制块的初始化在操作系统初始化函数OS_Init中被调用事件控制块的初始化函数是OS_InitEventList 表4.3 ECB初始化函数OS_InitEventList解析 ECB初始化函数OS_InitEventList首先清空了所有的ECB块，也就是
4、清空了事件表。然后从0到OS_MAX_EVENTS - 1u)循环对除最后一个ECB块之外的所有ECB块进行初始化，并顺便构建了单向的链表。循环结束后最后一个ECB 块OSEventTblOS_MAX_EVENTS - 1进行初始化。最后一个事件控制块OSEventTblOS_MAX_EVENTS - 1的OSEventPtr域指向空地址0，构造完成了如图4-3所示的空闲事件控制块链表。 然后将ECB空闲链表的表头地址给OSEventFreeList，初始化完成,4.2 事件管理程序,4.2.2 事件等待表初始化,当建立一个事件或消息，如信号量、邮箱、消息队列时，如信号量的建立函数OSSemC
5、reate等，需要对事件等待表进行初始化。 表4.4事件等待表初始化函数为OS_EventWaitListInit解析 pevent-OSEventGrp = 0u; /* 清空任务等待组*/ for (i = 0u; i OSEventTbli = 0u; /* 采用循环模式清空任务等待表*/ ,4.2.3设置事件等待,当任务等待事件发生，并获得事件控制块ECB后，需要在ECB中标记任务在等待事件的发生，才可以在事件发生时取消任务的阻塞。 表4.5事件等待函数OS_EventTaskWait解析 OS_EventTaskWait做了两件事情： 1.标记。在ECB中登记本任务，即在ECB的事件
6、等待表中对应优先级处标记为1，事件等待组中对应位标记为1。 2.取消标记。在就绪表和就绪组中取消对该事件就绪的标记，将就绪表中对应优先级处标记为0，如果就绪表该任务所在的一组没有任务就绪，将就绪组中的对应位标记为0。,4.2.4取消事件等待,OS_EventTaskRemove 是与OS_EventTaskWait相反的操作，当一个事件由于某种原因不再需要等待事件需运行OS_EventTaskRemove 。 void OS_EventTaskRemove (OS_TCB *ptcb, OS_EVENT *pevent) INT8U y; y = ptcb-OSTCBY; pevent-OSE
7、ventTbly /*删除事件等待组的事件等待标志*/ ,4.2.5将等待事件的任务就绪,任务因为等待事件而在ECB中登记自己的等待，当事件发生的时候，如果该任务是事件等待表中优先级最高的任务，就绪被取消等待而回到就绪状态。等待的事件发生的函数为OS_EventTaskRdy 表4.8将等待事件的任务就绪函数OS_EventTaskRdy的声明 表4.9将等待事件的任务就绪函数OS_EventTaskRdy解析 OS_EventTaskRdy的流程为： 1.在事件等待表和事件等待组中找到最高优先级的等待任务的优先级。 2.根据优先级查优先级指针表，找到该任务的任务控制块TCB指针。 3.对任务
8、控制块的相关参数进行赋值。 4.判断任务是否被挂起，如果未被挂起就将任务就绪。完成从阻塞态到就绪态的转移。 5.调用OS_EventTaskRemove在ECB的事件等待表中删除该任务。 6.返回任务的优先级。,4.3 信号量管理,信号量在资源共享管理，任务同步与通信等方面都有广泛的应用。C/OS-II单独为信号量管理编写了C文件os_sem.c。,4.3.1 信号量的建立OSSemCreate,信号量在操作系统初始化的时候并不存在。这时操作系统中的事件管理数据结构事件控制块ECB为全空，所有的事件控制块都在ECB空闲链表中排队。信号量的建立函数OSSemCreate将使用一个并配置一个ECB
9、，使其具备信号量的属性。 表4.11创建信号量函数OSSemCreate解析 假设信号量值为5，则赋值后的ECB应该如图4-4所示。,宏OS_EVENT_TYPE_SEM的值是3，所以ECB中的OSEventType的值为3。假设该信号量为创建的第一个事件，那么图4.3的事件空闲任务链表将去掉第一个事件控制块，变为如图4.5所示。,4.3.2 信号量的删除OSSemDel,信号量如果不再使用了就应该尽快删除，否则很快系统就没有可用的事件块可用。 信号量的删除函数是OSSemDel。 删除信号量比创建一个信号量更复杂 。 表4.12删除信号量函数OSSemDel解析,4.3.3 请求信号量OSS
10、emPend,请求信号量也称为等待信号量。等待信号量的参数为3个，分别是ECB的指针pevent，32位无符号整数超时时间timeout，和用来返回结果的指向整型的指针perr。 表4.13等待信号量函数OSSemPend解析,4.3.4 提交信号量,当任务A获得信号量之后将信号量数字减1，然后就可以访问资源R。这时，如果信号量的值为0，任务B如果也要访问资源R，必须等待信号量，因此将任务B阻塞。任务A在对资源的访问完成之后，应将信号量的值加1。因为资源已经可以被其他的任务访问了，因此应该将任务B唤醒，使任务B就绪。 当访问资源的任务有2个以上，资源R可同时被N个任务访问，因此信号量的值在最开
11、始创建的时候应该等于N。当任务A访问信号量，信号量值变为N-1,任务B又访问，信号量等于N-2，当第M个任务访问，信号量等于N-M。当N-M=0的时候，也就是当N=M的时候，当第N+1也要访问该资源R,第N+1个任务必须等待。当任何一个任务(例如第2个)访问资源完成，应该唤醒第N+1个任务让其访问资源。当第N+1个任务访问完成之后，因为没有其他的任务等待信号量，只需简单地将信号量值加1。 表4.14提交信号量函数OSSemPost解析,4.3.5 无等待请求信号量,在中断服务程序和有些用户任务中，需要无等待的请求信号量。也就是说，使用信号量请求资源，当没有可用的资源，信号量为0的时候，并不阻塞
12、自己，而是继续执行其他代码。OSSemAccept就是无等待的请求信号量函数 。 表4.15无等待地请求信号量函数OSSemAccept解析 1进行参数检查 2将信号量的值赋值给局部变量cnt，如果cnt 0说明资源有效或信号量有效，因此将信号量的值减1然后哦返回cnt，可以执行访问资源的代码了。如果函数返回值为0，不能执行访问资源的代码。,4.3.6 放弃等待信号量,放弃等待信号量并非放弃本任务对信号量的等待。 如果是放弃本任务对信号量的等待，那么本任务在等待信号量，那么本任务应该处于阻塞状态，一个处于阻塞状态的任务得不到运行，怎么能执行放弃等待信号量的代码呢？因此，一定是放弃其他任务对一个
13、信号量的等待。 表4.16放弃等待信号量函数OSSemPendAbort解析 1.参数检查，如果ECB指针无效或ECB的类型不是信号量类型，返回参数检查错误信息。 2.如果pevent-OSEventGrp为0说明没有任务等待信号量，返回0。 3.否则根据参数opt(选项)进行分支转移，如果为OS_PEND_OPT_BROADCAST，使用while语句循环地将等待该信号量的每个任务用OS_EventTaskRdy来取消等待并使其就绪（除非任务还被挂起）；如果为其他值则只将最高优先级的任务取消等待并就绪之。两种情况下都返回取消等待信号量的任务数。,4.3.7 信号量值设置,操作系统提供了直接设
14、置信号量值的函数OSSemSet。一般情况下无需使用该函数设置信号量的值，应该在信号量创建的时候初始化信号量的值。当一个信号量的值在创建之后为N，每次有任务请求信号量就将该值减1，反之将该值加1，一般情况下是不允许随便修改的。但是，在极其特殊的情况下，因为某种特殊的需要，例如突然增加了其他的资源，需要修改资源数N，可采用OSSemSet直接对信号量赋值，但条件是这时没有任务在等待该信号量。 表4.17设置信号量值函数OSSemSet解析,4.3.8 查询信号量状态,信号量状态查询将ECB中关于信号量的信息拷贝到另一个数据结构信号量数据OS_SEM_DATA，信号量数据OS_SEM_DATA的声
15、明见下表。 表4.19查询信号量状态函数OSSemQuery解析,4.3.9 信号量应用举例,假设有共享资源R，允许2个任务分时访问R，那么信号量的值应设置为2。系统中有3个用户任务访问资源R，分别为任务A、B、C，优先级分别为7、6、5。三个任务在操作系统初始化和启动多任务之前被创建。任务A运行后创建信号量，并访问R，访问完成后任务A将自己阻塞1000个时钟周期，也就是10秒。任务B先阻塞300个时钟周期，然后操作步骤同任务A。任务C先阻塞400个时钟周期，然后操作步骤同任务A。假设三个任务才做资源R需要的时间都是1000个时钟周期，对资源R的操作可以用延时语句虚拟完成。 表4.20操作资源
16、R的三个任务的实现代码,4.3 互斥信号量管理,互斥信号量是一种特殊的信号量，取值只能是0或1。也就是说，只能有一个任务访问的独占资源，应采用互斥信号量来管理。独占资源在系统中是非常常见的，例如各种IO端口如串口、USB设备、网络设备等。为了保证系统的实时性，拒绝优先级反转，对互斥信号量的管理采用了优先级继承机制。 优先级继承机制： 优先级继承机制对优先级升级的机制以优化系统的调度。例如当前的任务的优先级是比较低的，如优先级为50。优先级为3的任务请求互斥信号量的时候因为信号量已被占有所以只有阻塞。这时有优先级为20的任务就绪，而不请求该互斥信号量。因此优先级为20的任务会先运行。如果又有优先级为30、40的任务运行，那么优先级为50的任务总也得不到运行也就不能释放信号量，更可怕的是优先级为3的任务还在苦苦等待信号量。这样，就发生了优先级反转。代码中的解决办法为将占有信号量的任务的优先级提高，例如提高为2，这样保证他对互斥资源处理
