最近对实时操作系统比较感兴趣,然后就仔细阅读了一番uC/OS-II的代码,之前也初略的阅读过,但是这次阅读确实有不少的收获。
uC/OS-II是经典的实时操作系统,开源的优点就是可以使用者自己去分析和裁剪。我就简单的说明一下uC/OS-II中的任务挂起以及任务唤醒操作。
在uC/OS-II中任务之间的切换比较简单,就是运行态-就绪态-挂起态(等待态)-中断服务态-睡眠态,其中睡眠态主要是指没有被创建的任务,也就是我们可以定义很多的任务,但是不一定全部创建,当然也可以是被删除以后的任务,我们也可以称之为睡眠态,这也是我们不经常使用的任务。其他的中断服务态实际上就是在中断服务中,他的运行级别是最高的。就绪态就是已经做好运行准备的状态,运行态永远只有一个任务处于运行态。而挂起态或者称等待态是最复杂的过程,其中牵涉到很多中不同的挂起状态。
几种典型的挂起态我做一下总结:
1、任务的挂起操作,一般都是采用OSTaskSuspend()将任务挂起,这种挂起的操作一般都是比较简单的将就绪表中优先级对应的位和组分别清除即可,而这种挂起的方式被唤醒的方式有且只有一种,即采用OSTaskResume()函数将就绪表中优先级对应的位和组就绪即可。这也应该说是最准确的挂起,而不是所谓的等待态。
2、任务中调用时间延迟函数的挂起方式,准确的说这种挂起就是等待态,我们所谓的延迟等待,基本的实现原理就是通过节拍服务函数OSTimeTick()减小延迟等待时间,这个实际上就是对任务控制块OS_TCB中的变量OSTCBDly操作而实现的。在OSTCBDly>0期间将任务在就绪表中的位和组分别清除,是任务处于挂起操作,这种挂起实质和任务的挂起方式相同。但是OSTimeTick()的实现过程会检测任务是否是被OSTaskSuspend()挂起,也就是真正的挂起态,只有当任务不是被OSTaskSuspend()挂起时才能被唤醒,这是需要注意的。
3、关于通信机制、同步过程中的任务挂起,这种任务挂起实质上是任务等待状态,实现的过程中会涉及到两个续表,其中一个就是任务就绪表,另一个是任务等待续表,另外为了实现等待超时等问题,将OSTCBDly也考虑了进来,这样也就使得这种任务的等待比之前的两种挂起方式要复杂。但是等待超时与等待延迟有一定的相似之处,但不同的地方就是需要将等待续表中对应的优先级位置清除,再设置就绪表中的位置位1,返回超时错误,这样就能实现超时的挂起操作,而一般的事件等待机制,都是涉及到中断、任务与任务之间的通信或者同步问题,挂起操作首先将任务在就绪表中的就绪标志位清除,同时设置任务的状态为某种形式的挂起,然后设置等待续表中的相关位置,最后实现任务的调度。任务的唤醒操作是另一个任务发出信号,然后从等待续表中清除最高优先级的任务,然后设置该任务在就绪表中的位置,并设置任务的状态,最后实现任务的调度操作。一行就能实现任务的挂起操作。
综合上面的总结可以知道uC/OS-II的任务挂起操作主要是3种,其中前两种相比而言比较简单,只是简单的依靠就绪表或者时间延迟变量即可实现。而当涉及到任务的同步等机制时就会依靠就绪表,等待续表,以及时间延迟变量。但是任务的挂起和睡眠本质上也是存在差别的,并不是同一种概念,因此我们在学下uC/OS-II的过程中需要特别注意。
关键字:uCOS-II 任务挂起 实时操作系统
引用地址:
关于uC/OS-II中的任务挂起讨论
推荐阅读最新更新时间:2024-03-16 14:00
缩短μC/OS-II实时内核中断关闭时间的方法设计
引 言 在实时操作系统中,由于是多任务的并发运行,所以在进入一些临界区时为了保证多任务的正常运行要关中断。而最大关中断时间是衡量一个实时操作系统性能的重要指标,因为外部的输入一般都是通过中断方式来通知系统的,系统如果关中断时间长,必然不能及时接收中断,对中断的及时处理就更谈不上。 更重要的是,有些应用场合对关中断的时间有非常严格的要求。例如,在电力系统微机继电保护装置中,对电流A/D采样时,为了保障对采样值的正确处理,定时中断的每一个周期时间都必须及时采样。试想,如果定时器设置的周期时间到,定时器中断产生,但恰恰这时系统处于关中断时间,系统就不能及时进行采样;而当关中断时间过长,超过一定的值时,系统再来进行采样,依
[单片机]
基于Small RTOS51的肠营养液输液系统设计
引言 随着各种电子系统在各个领域中应用的不断深入,对电子系统本身的要求也越来越高,尤其对于控制系统软件设计的可靠性、实时响应等各个方面的性能有了更严格的要求。单片机的程序设计不再是前后台的运行模式,而是采用多任务实时操作系统的设计思想。由于使用嵌入式操作系统,可以将具体应用分解成多个任务,简化了应用系统软件的设计,使控制系统的实时性得到保证,使其达到理想状态。良好的多任务设计,还有助于提高系统的稳定性和可靠性。 目前,国内应用最多的是以51系列单片机为主的8位单片机。在51系列单片机系统中,可以进行移植的嵌入式操作系统为数不多。其中,Keil自带的RTX51没有源代码,使用起来很不方便;uC/OSII虽然有源代码,也有
[医疗电子]
基于RTX51的排爆机器人嵌入式控制器固件开发
排爆机器人(EODrobot)是一种遥操作地面移动机器人,操作机主体一般是由一个机械手和一个可移动平台组成,主要用于拆除疑似爆炸物品,以减少作业现场人员伤亡,是军警部门必须装备的设施。目前国际上主要流行美国Remotec公司的Andros系列排爆机器人、法国Cybernetics公司研制的TRS200中型排爆机器人等。但是国外的排爆机器人价格过高,出现故障后维修特别不方便。因此国家863专家组已经将高性能排爆机器人的研发及国产化列入了重点支持的课题。 由于种种原因,目前的排爆机器人很多只采用PLC实现点动控制,功能有限且操作性较差。研究高性能控制器成为排爆、消防等各种遥操作地面移动机器人的共同课题。利用先进的嵌入式系统技术可以较
[单片机]
一种基于实时操作系统μC/OS-II的嵌入式UPS系统控制方案
针对数字化UPS,给出了系统总体设计框图,为提高系统控制程序的实时性,提出一种基于实时操作系统μC/OS-II的嵌入式UPS 系统控制方案。通过对UPS控制系统结构与功能的分析,实现了μC/OS-II在TMS320LF2407A上的移植,对UPS系统控制项目以任务的形式进行设计并实现调度,给出了部分参数设定和主程序清单。实验结果证明,本文的设计有效的增强了系统控制软件的模块性、实时性,提高了系统运行的可靠性与稳定性。 1 引言 随着信息技术的发展,不间断应急 电源 (UPS)向着数字化、智能化、网络化、大容量多机冗余化和绿色化的方向发展。高性能专用DSP芯片为UPS的数字化提供了良好的硬件基础,而嵌入式实时软件操作
[电源管理]
Silicon Labs收购RTOS Micrium
Silicon Labs (芯科科技) 宣布收购物联网(IoT)即时作业系统(RTOS)软体供应商Micrium。此一策略性收购整合业界商业级嵌入式RTOS 与Silicon Labs在物联网的专业与解决方案,有助于开发者简化其物联网产品设计。 Micrium的RTOS和软体工具将持续供应全球的晶片合作伙伴,为客户提供广泛的选择,包括非Silicon Labs的硬体。 Micrium也将持续全力支援现有以及新客户。 结合RTOS与多协议晶片、工具和软体堆迭,让开发者获得完整的物联网嵌入式解决方案。 Micrium公司的旗舰产品 C/OS RTOS系列以稳定性、效能、可靠性,及无可挑剔的原始程式码和丰富的手册著称。
[物联网]
嵌入式操作系统任务切换方法对比分析
引言 嵌入式系统在航天、军事、工控以及家电等方面得到了广泛应用。大量的嵌入式系统具有实时性的要求,但是由于体积、能耗、价格等方面的约束,其处理器速度往往比较慢,存储器容量也有限。而传统的实时操作系统难以简单地移植到嵌入式系统中,所以需要重新开发针对嵌入式系统特性的实时操作系统。任务调度策略是实时系统内核的关键部分,如何进行任务调度,使得各个任务能在其期限之内得以完成,是实时操作系统的重要研究领域。而不同的操作系统对任务调度的机制也有所不同,本文对目前比较流行的操作系统——VxWorks、μClinux、μC/OS-II、Windows CE的任务切换机制进行分析和比较。 1 操作系统介绍
1.1 VxWor
[嵌入式]
借力高扩展性RTOS环境 穿戴式医疗设备开发面面俱到
总有一天,可佩戴的可携式医疗设备将在我们的日常生活中随处可见。事实上,我们不会再将它们视为「设备」,而是更在意它们提供的各种服务。随着无线连接的持续发展,以及医疗行业向门诊服务模式的转变,设备研发人员如果能够提前预测到未来需求并充分加以利用,则将迎来真正的时代。 当然,设备研发人员必须满足非常严格的制造要求。可穿戴医疗设备必须外形小巧,能够持续保持连接,并且具有较长的电池续航时间,并能提供更多计算资源。市场竞争日趋复杂且日益激烈,而设备研发人员必须在这样的市场中生存下来。为了达到这个目标,设备研发人员必须构建快速、灵活、轻巧而又具成本效益的平台(图1)。
图1 软件平台必须覆
[医疗电子]
RTOS的必备特性
随着信息家电的普及,智能化、网络化将会无所不在,所有这些都离不开嵌入式软件,而在嵌入式软件只中最核心的莫过于RTOS(Real Time Operating System,实时操作系统)。我们都非常熟悉Windows这样的操作系统,但却不一定熟悉嵌入式系统中常用的RTOS。如今,微软已经推出了Windows的嵌入式版本——Windows CE。而风靡一时的Linux也在嵌入式系统中扮演着重要角色。这样看来,传统桌面操作系统和嵌入式操作系统的界线似乎也在淡化。事实究竟如何呢?让我们来听听在嵌入式软件领域颇有造诣的专家是怎么说的。
用于嵌入式环境的操作系统RTOS与桌面操作系统有很多本质的不同。这些不同的特性导致产品开发的不同结果。
[嵌入式]