uCOS-II内核架构解析
uCOS-II内核原理
![uCOS-II内核原理](https://img.taocdn.com/s3/m/0ad291333968011ca30091e0.png)
uC/OS-II是一个源码公开应用于嵌入式的小型的RTOS(实时),由于其内核精简,可理解性和可移植性强,因此广泛应用于小型的嵌入式系统中.
内核工作原理:
实时嵌入式操作系统mC/OS-II内核的工作原理如图1所示。首先,在主程序中对操作系统进行初始化,完成 uC/OS-II所有变量和数据结构的初始化,包括任务控制块(TCB)初始化,TCB优先级表初始化,TCB链表初始化,事件控制块(ECB)链表初始化以及空闲任务的创建等。
在理解了处理器和C编译器的技术细节后,uC/OS的移植只需要修改与处理器相关的代码就可以了。具体有如下内容:
·OS_CPU.H中需要设置一个常量来标识堆栈增长方向;
·OS_CPU.H中需要声明几个用于开关中断和任务切换的宏;
·OS_CPU.H中需要针对具体处理器的字长重新定义一系列数据类型;
程序进入Task1()后,首先初始化时钟和启动时钟节拍源开始计时。此节拍源给系统提供周期性的时钟中断信号,实现延时和超时确认。然后根据应用程序要求,完成该任务的基本功能。最后,调用OSTimeDly(),将自己挂起,即从就绪表中删除。直到等待延时时间到,才将该任务恢复到就绪表中,并等待调度器的调度。
OSTimeDly()将任务挂起的同时,为其做好延时记号,然后调用OS_Sched()进行任务级的任务调度。若此时没有任何任务进入就绪态,就切换到空闲任务。
当时钟中断来临时,系统进入中断服务程序OSTickISR()。系统把当前正在执行的任务挂起,保护现场,进行中断处理OSTimeTick(),判断有无任务延时到期,若有,则使该任务进入就绪态。最后调用OSIntExit()进行中断级的任务调度,从而切换到优先级最高的任务,若没有别的任务进入就绪态,则恢复现场继续执行原任务
uCOS-II一些入门资料(内核架构解析等)
![uCOS-II一些入门资料(内核架构解析等)](https://img.taocdn.com/s3/m/0fabbc3f5727a5e9856a61e2.png)
嵌入式系统——基础知识操作系统OS控制和管理计算机软硬件资源,合理组织计算机工作流程,方便用户使用计算机的系统软件。
可将OS看成是应用程序与硬件间的接口或虚拟机。
OS功能:进程管理、存储管理、文件管理、设备管理、网络和通信管理等。
嵌入式操作系统EOS运行在嵌入式硬件平台上,对整个系统及其所操作的部件装置等资源进行统一协调、指挥和控制的系统软件。
EOS特点:微型化、可裁剪性、实时性、高可靠性、易移植性重点关注:高实时性、硬件相关依赖性、软件固化、应用专用性、网络功能。
实时操作系统TROS能使计算机及时响应外部事件请求,并能及时控制所有实时设备与实时任务协调运行,且能在规定时间内完成事件处理的OS。
RTOS基本要求:1、逻辑功能正确:RTOS的计算必须产生正确的结果;2、时间正确:RTOS的计算必须在预定的周期内完成。
RTOS应满足条件:1、多任务系统;2、任务的切换时间应与系统中的任务书无关;3、中断延时的时间可预知并尽可能短。
无论在什么情况下,OS完成任务所需的时间应该是在程序设计时就可预知的。
嵌入式实时操作系统ERTOS用于嵌入式系统,对系统资源和多个任务进行管理,且具有高可靠性、良好可裁剪性等优良性能的,为应用程序提供运行平台和实时服务的微型系统软件。
ERTOS最重要的三项服务:1、多任务管理2、内存管理3、外围资源管理嵌入式微处理器(特点)1、对实时多任务OS有很强的支持能力;2、具有功能很强的存储区域保护功能;3、处理器结构可扩展;4、低功耗;微处理器主要发展方向:小体积、高性能、低功耗微处理器分类:MCU、MPU、DSP、SOC嵌入式系统发展方向1、嵌入式开发是一项系统工程,嵌入式系统厂商不仅要提供嵌入式软硬件系统本身,还需要提供强大的硬件开发工具与软件支持包;2、网络化、信息化的要求随着因特网技术的成熟、宽带的提高而日益提高,使得以往单一功能的设备功能不再单一,结构更加复杂;3、网络互连成为必然趋势(IEEE1394、USB、CAN、Bluetooth等网络接口);4、精简系统内核、算法、降低功耗和软硬件成本;5、提供友好的多媒体人机界面。
uCOS-II的核心算法
![uCOS-II的核心算法](https://img.taocdn.com/s3/m/16608a4733687e21af45a935.png)
uCOS核心算法1.任务调度算法每个任务被赋予不同的优先级等级,从0级到最低优先级OS_LOWEST_PR1O,包括0和OS_LOWEST_PR1O在内(见文件OS_CFG.H)。
当μC/OS-Ⅱ初始化的时候,最低优先级OS_LOWEST_PR1O总是被赋给空闲任务idle task。
注意,最多任务数目OS_MAX_TASKS 和最低优先级数是没有关系的。
用户应用程序可以只有10个任务,而仍然可以有32个优先级的级别(如果用户将最低优先级数设为31的话)。
每个任务的就绪态标志都放入就绪表中的,就绪表中有两个变量OSRedyGrp和OSRdyTbl[]。
在OSRdyGrp中,任务按优先级分组,8个任务为一组。
OSRdyGrp中的每一位表示8组任务中每一组中是否有进入就绪态的任务。
任务进入就绪态时,就绪表OSRdyTbl[]中的相应元素的相应位也置位。
就绪表OSRdyTbl[]数组的大小取决于OS_LOWEST_PR1O(见文件OS_CFG.H)。
当用户的应用程序中任务数目比较少时,减少OS_LOWEST_PR1O的值可以降低μC/OS-Ⅱ对RAM(数据空间)的需求量。
为确定下次该哪个优先级的任务运行了,内核调度器总是将OS_LOWEST_PRIO在就绪表中相应字节的相应位置1。
OSRdyGrp和OSRdyTbl[]之间的关系见下图,是按以下规则给出的:当OSRdyTbl[0]中的任何一位是1时,OSRdyGrp的第0位置1,当OSRdyTbl[1]中的任何一位是1时,OSRdyGrp的第1位置1,当OSRdyTbl[2]中的任何一位是1时,OSRdyGrp的第2位置1,当OSRdyTbl[3]中的任何一位是1时,OSRdyGrp的第3位置1,当OSRdyTbl[4]中的任何一位是1时,OSRdyGrp的第4位置1,当OSRdyTbl[5]中的任何一位是1时,OSRdyGrp的第5位置1,当OSRdyTbl[6]中的任何一位是1时,OSRdyGrp的第6位置1,当OSRdyTbl[7]中的任何一位是1时,OSRdyGrp的第7位置1,不妨假设prio的值为13, 即优先级为13. prio>>3 右移3位后值为1, 可以查下表找出OSMapTbl[1] 的值为 0000 0010. 再用 0000 0010 和 OSRdyGrp 进行异或运算OSRdyGrp |= OSMapTbl[prio >> 3];OSRdyTbl[prio >> 3] |= OSMapTbl[prio & 0x07];OSMapTbl[]的值Index Bit Mask (Binary)0 000000011 000000102 000001003 000010004 000100005 001000006 010000007 10000000读者可以看出,任务优先级的低三位用于确定任务在总就绪表OSRdyTbl[]中的所在位。
μCOS-II微小内核分析2
![μCOS-II微小内核分析2](https://img.taocdn.com/s3/m/167876c66137ee06eff91872.png)
R0 R1 … R12 R13 R14 R13 R14
3
PC LR
1
R12 R11 … R1 R0
R15 (PC) CPSR SPSR
2
CPSR OSEnterSum
内部寄存器
指向栈顶
0x??
栈 顶
OSTCBCur OSTCBHighRdy
OSTCBTbl (任务控制块数组) OSTCBStkPtr OSTCBNext OSTCBStkPtr OSTCBNext OSTCBStkPtr OSTCBNext …
时间管理
如果某任务需要申请延时一段时间,系统调用系统服务函数 OSTimeDly()来实现,调用该函数会使C/OS-Ⅱ进行一次任务调度,并 且执行下一个处于就绪态优先级最高的任务.任务调用OSTimeDly()后, 一旦规定的时间期满,它就会马上进入就绪态.OSTimeDly()仅有一个 参数ticks表明任务需要延时的时间,以系统时钟节拍为单位.
OSTimeDly()函数调用关系
最小内核 | C/OS-II微小内核分析 微小内核分析
任务调度
由于任务的并发性,且有多个任务均处于就绪态,到底该哪个任 务先运行呢?为了满足实时性的要求,C/OS-Ⅱ内核采用了"可剥夺 型"任务调度算法,C/OS-Ⅱ总是运行处于就绪态中优先级最高的任 务. 任务级的任务调度是由OS_Sched()函数完成的,而且任务级的调 度要保存所有的状态.中断级的任务调度是由另一个函数OSIntExt()完 成的,在中断级的调度中,一些状态在进入中断前已被保存 .
OSTCBTbl[0] Idle
LDMFD SP!, OSTCBPrioTbl {R0-R12, | SVC32Mode) … LDR R4, [R6] MSR CPSR_c, #(NoIntLR, PC }^ … [0] … [4] ADD SP, R4,[1]#68 … MOV R4 全局变量 #-8] LDR LDMFDLR, [SP, SP!, {R4, R5} LDR R3, =OsEnterSum STR R4, [R3] MSR SPSR_cxsf, R5
图1uCOS-II文件体系结构
![图1uCOS-II文件体系结构](https://img.taocdn.com/s3/m/492901eb6294dd88d0d26bff.png)
0引言在开发嵌入式系统时,一般选择基于ARM和uC/OS-II的嵌入式开发平台,因为ARM 微处理器具有处理速度快、超低功耗、价格低廉、应用前景广泛等优点[1].将uC/OS-II移植到ARM系统之后,可以充分结合两者的优势.如果一个程序在一个环境里能工作,我们经常希望能将它移植到另一个编译系统、处理器或者操作系统上,这就是移植技术.移植技术可以使一种特定的技术在更加广泛的范围使用,使软件使用更加灵活,不局限于某一条件.uC/OS -II是由Jean brosse先生编写的完整的可移植、固化、裁剪的占先式实时多任务内核.uC/OS-II的源代码完全开放,这是其他商业实时内核无法比拟的[2].它是针对嵌入式应用设计的,在设计之初就充分考虑了可移植性,它的大部分源代码都是用高可移植性的ANSIC编写的[3].uC/OS-II可以移植到从8位到64位的不同类型、不同规模的嵌入式系统,并能在大部分的8位、16位、32位、甚至64位的微处理器和DSP上运行.由于uC/OS-II是一个实时操作系统,所以如果将它嵌入到ARM处理器上,就能够进一步简化ARM系统的开发.图1uC/OS-II文件体系结构1uC/OS-II的移植uC/OS-II的文件系统结构包括核心代码部分、设置代码部分、与处理器相关的移植代码部分[4].结构如图1所示.其中最上边的软件应用层是uC/OS-II上的代码.核心代码部分包括7个源代码文件和1个头文件.功能分别是内核管理、事件管理、消息队列管理、存储管理、消息管理、信号量处理、任务调度和定时管理.设置代码部分包括2个头文件,用来配置事件控制块的数目以及是否包含消息管理相关代码.而与处理器相关的移植代码部分则是进行移植过程中需要更改的部分,包括1个头文件OS CPU.H,1个汇编文件OS CPU A. S和1个C代码文件.实际上将uC/OS-II移植到ARM处理器上,需要完成的工作主要是以下三个与体系结构相关的文件:OS CPU.H,OS CPU.C以及OS CPU A.S[5].文件OS CPU.H中包括了用#define语句定义的与处理器相关的常数、宏以及类型.移植时主要修改的内容有:与编译器相关的数据类型的设定;用#define语句定义2个宏开关中断;根据堆栈的方向定义OS STK GROWTH等.在将uC/OS-II移植到ARM处理器上时,首先进行基本配置和数据类型定义.重新定义数据类型是为了增加代码的可移植性,因为不同的编译器所提供的同一数据类型的数据长度并不相同,例如int型,在有的编译器中是16位,而在另外一些编译器中则是32位.所以,为了便于移植,需要重新定义数据类型,如INT32U代表无符号32位整型.typedefunsigned int INT8U,就是定义一个8位的无符号整型数据类型.其次就是对ARM处理器相关宏进行定义,如ARM处理器中的退出临界区和进入临界区的宏定义,退出临界区宏定义[5]:#define OS EXITCRITICAL()ARMDisable Int()//关中断,进入临界区宏定义#define OS ENTER CRITICAL()AR2MEnableInt()//开中断.最后就是堆栈增长方向的设定.当进行函数调用时,入口参数和返回地址一般都会保存在当前任务的堆栈中,编译器的编译选项和由此生成的堆栈指令就会决定堆栈的增长方向[6],定义为#define OS STK GROWTH1.图2堆栈增长方向1.2OS CPU.C的移植OS CPU.C的移植包括任务堆栈初始化和相应函数的实现.在这里,共有6个函数:OSTaskStkInit(),OSSTaskCreateHook(),OSTaskDelHook(),OS2TaskSwHook() ,OSTaskStatHook(),OSTimeTickHook().其中后面的5个HOOK函数又称为钩子函数,主要是用来对uC/OS-II进行功能扩展.这些函数为用户定义函数,由操作系统调用相应的HOOK函数去执行,在一般情况下,他们都没有代码,所以实现为空函数即可.而函数OSTaskStkInit()对堆栈进行初始化,在ARM系统中,任务堆栈空间由高到低依次为PC,LR ,R12,R11, ,R1,R0,CPSR,SPSR.在进行堆栈初始化以后,OSTaskStkInit()返回新的堆栈栈顶指针.OS CPU A.S文件的移植需要对处理器的寄存器进行操作,所以必须用汇编语言来编写.这个文件的实现集中体现了所要移植到处理器的体系结构和uC/OS-II的移植原理[6].它包括4个子函数:OSStartHighRdy(),OSCtxSw(),OSIntCtxSw(),OSTick2ISR().其中难点在于OSIntCtxSw()和OSTickISR()函数的实现,因为这两个函数的实现与移植者的移植思路以及相关硬件定时器、中断寄存器的设置有关.在实际的移植工作中,这两处也是比较容易出错的地方.OSIntCtxSw()函数由OSIntExit()函数调用,而OSIntExit()函数又由OSTickISR()调用.OSIntCtxSw()函数最重要的作用就是它完成在中断ISR中直接进行任务切换,从而提高了实时响应的速度.它发生的时机是在ISR执行到OSIntExit()时,如果发现有高优先级的任务因为等待time tick的到来获得了执行•72•第4期李学桥等:uC/OS-II在ARM系统上的移植与实现的条件,就可以马上被调度执行,而不用返回被中断的那个任务之后再进行任务切换.实现OSIntCtxSw()的方法大致也有两种情况[7]:一是通过调整SP堆栈指针的方法,根据所用的编译器对于函数嵌套的处理,通过精确计算出所需要调整的SP位置来使得进入中断时所作的保护现场的工作可以被重用.二是设置需要切换标志位的方法,在OSIntCtxSw()里面不发生切换,而是设置一个需要切换的标志,等函数嵌套从进入OSIntExit ()=>OS ENTER CRITI2CAL()=>OSIntCtxSw()=>OS EXIT CRITICAL()=>OSIntExit()退出后,再根据标志位来判断是否需要进行中断级的任务切换.其次是对OSTickISR()修改.OSTickISR()首先在被中断任务堆栈中保存CPU寄存器的值,然后调用OSIntEnter().随后调用OSTimeTick(),检查所有处于延时等待状态的任务,判断是否有延时结束就绪的任务.最后调用OSIntExit().如果在中断中(或其他嵌套的中断)有更高优先级的任务就绪,并且当前中断为中断嵌套的最后一层,OSIntExit()将进行任务调度.如果进行了任务调度,OSIntExit()将不再返回调用者,而是用新任务的堆栈中的寄存器数值恢复CPU现场,然后实现任务切换.如果当前中断不是中断嵌套的最后一层,或中断中没有改变任务的就绪状态,OSIntExit()将返回调用者OSTickISR(),OSTickISR()返回被中断的任务.最后就是退出临界区和进入临界区函数.进入临界区时,必须关闭中断,用ARMDisableInt()函数实现.在退出临界区的时候恢复原来的中断状态,通过ARMEnableInt ()函数来实现[7].至于进行任务级上下文切换,则是由汇编子程序OSCtxSw实现.2在ARM系统上的实现以跑马灯和数码管为例,说明uC/OS-II的移植过程:跑马灯是4个小灯轮流变明变暗,很方便看出效果.跑马灯在日常中使用很多,比如状态栏跑马灯、文字跑马灯、图片跑马灯、单片机跑马灯等[8].本文采用的是单片机跑马灯.实现单片机跑马灯的程序中,只有地址口为低电平(接地)时,发光管才会亮.所以只要循环控制地址口的各个引脚的电平高低变化就可使LED循环点亮:首先是全不亮,接着第1个灯亮,第2个灯亮,第3个灯亮,第4个灯亮,第5个灯亮,最后所有的灯一起亮.笔者使用6个共阳极LED数码管来实现在7段数码管上循环显示0~9,A~F字符.每个显示位的段选线与一个8位并行口线对应相连,只要在显示位上的段选线上保持段码电平不变,则该位就能保持相应的显示字符.这里的8位并行口可以直接采用并行I/O口,也可以采用串入/并出的移位寄存器或是其他具有三态功能的锁存器等.当采用动态显示接口时,在多位LED显示时,为了简化电路,降低成本,将所有位的段选线并联在一起,由一个8位I/O 口控制.而共阴(或共阳)极公共端分别由相应的I/O线控制,实现各位的分时选通.由于各个数码管是共用同一个段码输出口分时轮流通电的,从而大大简化了硬件线路,降低了成本.对于数码管的实现分为3个步骤:1)制作LED字符与码段对应表2)扫描控制3((U83)0x02000006)=0x3E;/3使能第一个数码管3/3)段码输出((U83)0x02000004)=seg7table[0];根据上面的LED字符与码段对应表,控制相应的数字进行输出.数码管扫描控制地址为0x02000006,8位访问,比如Bit0控制数码管0,并且低电平有效,Bit5控制数码管5,低电平有效,数码管显示试验系统中采用的是动态显示接口,其中数码管扫描控制地址为0x02000006 ,位0—5分别对应一个数码管,将其中每位清0来选择相应的数码管;地址0x02000004为数码管的数据寄存器,控制数码管的段码输出.3多任务应用程序uC/OS-II的移植及跑马灯和数码管的实现如下[9]:首先是C语言入口函数Main(所有C程序的入口).它里面包括调用函数ARMTargetInit()初始化ARM处理器,调用OSInit ()进行uC/OS-II操作系统初始化,然后调用OSTaskCreate()函数创建任务TaskLED和TaskSEG,最后调用ARMTargetStart()函数启动时钟节拍中断,并且调用OSStart()启动系统任务调度,由于在程序当中使用for(;;),这是一个永无止境的回路,所以装置可以一直进行下去,直到关闭装置.void Main(void){ARMTargetInit();uHALr printf(″uC/OS-II#n″);OSInit();Sem1=OSSemCreate(0);Sem2=OSSemCreate(1);OSTaskCreate(TaskLED,(void3)&IdLED,(OS STK3)&StackLED[STACKSIZE-1],5);OSTaskCreate(TaskSEG,(void3)&IdSEG,(OS STK3)&StackSEG[STACKSIZE-1],6);ARMTargetStart();OSStart();return;}4结语使用创建好的模板Temp新建一个工程Temp,并将模板中的Core和Assemble文件夹中的文件加入到工程Temp中.1)新建一个文件Temp.c,并将其添加到Temp工程的App 文件夹中.2)打开Temp.c文件,添加两个任务,它们的任务处理函数分别为TaskLED()和TaskSEG().3)在TaskLED()函数中每隔50个时钟节拍使所有跑马灯闪烁一次(即按顺序亮,然后全亮,最后全灭,顺序循环).4)在TaskSEG()函数中每隔50个时钟节拍切换一次数码管显示(循环从0~F显示).5)编译工程Temp,如果出错,则进行修改后再编译.6)将Temp 下载并运行,看结果.正确的结果是将每隔1/2s切换一次数码管显示,每隔1/2s使所有跑马灯闪烁一次.经持续了2h试验,没有出现错误,跑马灯和数码管正常运转,结果证明移植成功.。
关于嵌入式操作系统UCOS-II的内核实现研究
![关于嵌入式操作系统UCOS-II的内核实现研究](https://img.taocdn.com/s3/m/9b320c41bceb19e8b9f6baae.png)
关于嵌入式操作系统UCOS-II的内核实现研究摘要:嵌入式操作系统UCOS-II具有多种、多样的系统服务功能,能够实时进行多项任务的管理,并将抢占式调度策略应用其中,高效、顺利的完成各项任务,保障相关应用程序的可靠性和可行性。
基于此,本文结合UCOS-II操作系统的特点进行分析,了解其内核结构,探讨其在任务管理、内存管理、时间管理等方面的优势作用,并对其内核实现进行深入的研究,并为嵌入式操作系统UCOS-II的持续改进和升级提供有价值的参考。
关键词:嵌入式操作系统;UCOS-II;内核实现前言:UCOS-II作为一种嵌入式操作系统,具有小巧、使用便捷的优势,能够能够提供多样化的系统服务,实时管理多个工作任务,在移动电话、GPS、路由器以及智能仪器中有着广泛的应用。
运行UCOS-II系统,添加相关应用程序,执行特定的功能和任务。
该过程中,需要了解UCOS-II的内核结构和运行机制,合理予以运用,高效进行各项任务的管理和处理,在内核中实现。
1.UCOS-II的内核结构1.1临界段实时嵌入式操作系统UCOS-II的工作运行中,能够利用其完全开放的内核源码,同时应用其丰富的资源,高效进行相关程序和任务的处理。
在UCOS-II的内核结构中,其处理核心为oscore.c源码,涉及系统运行、任务调度和事件处理等工作内容。
而任务的建立、删除的恢复中,则是由ostask.c源码进行处理。
完成任务延时,则需要运用到时钟处理源码,即为ostime.c。
在UCOS-II的工作运行中,实时对多项任务进行处理和调度,并实现通讯的同步,加强各项任务之间的联系。
临界段是UCOS-II系统内核结构中的重要组成部分,操作系统的临界段操作功能,主要用于资源共享。
在UCOS-II系统的工作运行中,需要在关中断的情况,进行临界段代码的处理。
该过程中,可以避免其他任务进入其中,防止临界段代码处理工作受到干扰。
完成对临界段代码的处理后,再开中断。
uCOS-II操作系统简介及实验解读
![uCOS-II操作系统简介及实验解读](https://img.taocdn.com/s3/m/78f87235227916888486d748.png)
uC/OS-II操作系统
uC/OS-II操作系统简介 及开发过程
uC/OS-II操作系统
内 容
• • • • • • • •
一、 uCOS-II操作系统简介 二、 uCOS-II操作系统内核结构
三、 uCOS-II操作系统任务管理
四、 uCOS-II操作系统内存管理 五、 uCOS-II操作系统时间管理 六、 uCOS-II操作系统任务间的通讯 七、 uCOS-II操作系统移植 八、 uCOS-II操作系统实验
}任务(task)
•
μC/OS-Ⅱ可以管理多达64个任务。
优先级为0-63 优先级号越低,任务的优先级越高。 每个任务的优先级不能相同。
•
保留优先级:
高优先级:0、1、2、3 低优先级:OS_LOWEST_PRIO-3、 OS_LOWEST_PRI0-2,OS_LOWEST_PRI0-1以及 OS_LOWEST_PRI0
•
用户可以有多达56个应用任务。
uC/OS-II操作系统
删除任务
2.3 任务状态
等待 或挂 起 收 到 消 息
挂 起 时 间 到 任务调度
等 待 消 息
挂 起
中断
创建任务
休眠
删除任务
就绪
任务被抢占
删除任务
运行
中断结束
中断 服务
uC/OS-II操作系统
任务状态
• • • • • •
休眠态 - OSTaskCreate()或OSTaskCreateExt() 就绪态 等待态,就绪态,运行态 - OSTaskDel() - 休眠态 就绪态 - OSStart() - 运行态 运行态 - OSTimeDly()或OSTimeDlyHMSM() , OSSemPend(),OSMboxPend(),或OSQPend() 等待态 等待态 - OSTimeTick() -就绪态 空闲任务 - OSTaskIdle()
uCOS-II内核详解
![uCOS-II内核详解](https://img.taocdn.com/s3/m/9b0220f0f61fb7360b4c65cf.png)
UC/OS-II内核详解一.内核概述:多任务系统中,内核负责管理各个任务,或者说为每个任务分配CPU时间,并且负责任务之间的通讯。
内核提供的基本服务是任务切换。
之所以使用实时内核可以大大简化应用系统的设计,是因为实时内核允许将应用分成若干个任务,由实时内核来管理它们。
内核本身也增加了应用程序的额外负荷,代码空间增加ROM的用量,内核本身的数据结构增加了RAM的用量。
但更主要的是,每个任务要有自己的栈空间,这一块吃起内存来是相当厉害的。
内核本身对CPU的占用时间一般在2到5个百分点之间。
UC/OS-II有一个精巧的内核调度算法,实时内核精小,执行效率高,算法巧妙,代码空间很少。
UC/OS-II的内核还可以被裁剪,Hmax中RTOS的就是一个被高度裁剪过的UC/OS-II。
二.任务控制块 OS_TCB:uC/OS-II的TCB数据结构简单,内容容易理解,保存最基本的任务信息,同时还支持裁减来减小内存消耗,TCB是事先根据用户配置,静态分配内存的结构数组,通过优先级序号进行添加,查找,删除等功能。
减少动态内存分配和释放。
因为依靠优先级进行TCB分配,每个任务必须有自己的优先级,不能和其他任务具有相同的优先级。
typedef struct os_tcb{OS_STK *OSTCBStkPtr;#if OS_TASK_CREATE_EXT_ENvoid *OSTCBExtPtr;OS_STK *OSTCBStkBottom;INT32U OSTCBStkSize;INT16U OSTCBOpt;INT16U OSTCBId;#endifstruct os_tcb *OSTCBNext;struct os_tcb *OSTCBPrev;#if (OS_Q_EN && (OS_MAX_QS >= 2)) || OS_MBOX_EN || OS_SEM_ENOS_EVENT *OSTCBEventPtr;#endif#if (OS_Q_EN && (OS_MAX_QS >= 2)) || OS_MBOX_ENvoid *OSTCBMsg;#endifINT16U OSTCBDly;INT8U OSTCBStat;INT8U OSTCBPrio;INT8U OSTCBX;INT8U OSTCBY;INT8U OSTCBBitX;INT8U OSTCBBitY;#if OS_TASK_DEL_ENBOOLEAN OSTCBDelReq;#endif} OS_TCB;.OSTCBStkPtr是指向当前任务栈顶的指针。
uCOSII实时操作系统通信机制之内核分析
![uCOSII实时操作系统通信机制之内核分析](https://img.taocdn.com/s3/m/aaad9f0502020740be1e9b91.png)
μC/OS-II通信机制之内核分析摘要:本文主要着重对μC/OS-III通信机制的内核分析,研究μC/OS-II内核通信机制的实现方式及实现的技巧,同时分析其中不足之处。
1.引言μC/OS-II是一种可移植的,可植入ROM的,可裁剪的,抢占式的,实时多任务操作系统内核。
它被广泛应用于微处理器、微控制器和数字信号处理器。
uC/OS-II只是一个实时操作系统内核,它仅仅包含了任务调度,任务管理,时间管理,内存管理和任务间的通信和同步等基本功能。
没有提供输入输出管理,文件系统,网络等额外的服务。
但由于uC/OS-II良好的可扩展性和源码开放,这些非必须的功能完全可以由用户自己根据需要分别实现。
μC/OS-II这款操作系统内核简单易学,通过对其源代码的分析,可以加深我们对操作系统内核的理解,为学习linux等大型操作系统打下基础。
2.操作系统中任务间的通信机制内核中多个任务之间不可避免的存在相互协同的关系,来完成一定的内核功能。
这种协同最直观的就是任务间相互通信。
包括VxWorks 等所有的嵌入式操作系统一般都会提供许多任务间通信的方法,通常包括:(1)共享内存,数据的简单共享。
(2)信号量,基本的互斥和同步。
(3)消息队列和管道,同一CPU 内多任务间消息传递。
(4)Socket 和远程调用,任务间透明的网络通信。
(5)Signals,用于异常处理。
在μC/OS-II中设计了五种通讯机制,或者说是同步机制,分别是信号量(semaphore),互斥体(mutual exclusion semaphore),事件组(event flag),邮箱(message box)和队列(queue)。
3. uC/OS-II中通信机制实现的方式分析在uC/OS-II中是如何通信机制呢?这几种通信机制有什么关系?或者说有什么共同点有什么不同点?在实现上有哪些步骤是相同的?下面将就这几个问题进行分析论述。
我们知道通信机制是发生在任务之间的,换句话说任务与通信机制存在着关联。
3-2.UCOS 内核结构
![3-2.UCOS 内核结构](https://img.taocdn.com/s3/m/aceaf00879563c1ec5da7156.png)
任务的状态字。 任务的状态字。当OSTCBStat为0,任务进入就绪态 为 ,
#define OS_STAT_RDY #define OS_STAT_SEM #define OS_STAT_MBOX #define OS_STAT_Q #define OS_STAT_SUSPEND #define OS_STAT_MUTEX #define OS_STAT_FLAG
实时嵌入式操作系统
Real-time Embedded Operating System
艾云峰
aiyunfeng@
College of Computing & Communication Engineering
1
UCOS-II任务管理与调度
学习本节内容的主要目的
了解UCOS-II是如何进行任务调度的 了解UCOS-II和任务相关的初始化过程 了解UCOS-II中断服务程序的编写方法
void YourTask (void *pdata) /* 用户代码 */ OSTaskDel(OS_PRIO_SELF); } 一个任务看起来像其它C的函数一样,有函数返回类型,有形式参 数变量,但是任务是绝不会返回参数的; 任务可以自我删除; 形式参数变量由用户创建任务时传入,允许用户应用程序传递任 任 何类型的数据给任务 {
INT8U OS_TCBInit (INT8U prio, OS_STK *ptos, OS_STK *pbos, INT16U id, INT32U stk_size, void *pext, INT16U opt) 注:UC/OS-II中系统函数的命名 以OS开头的系统函数是提供给用户使用的系统函数 以OS_开头的系统函数是uc/os中的内部函数,一般用户程序不会 使用这些函数
uCOS-Ⅱ分析
![uCOS-Ⅱ分析](https://img.taocdn.com/s3/m/ca460cc1aa00b52acfc7ca95.png)
24
C/OS-II开关中断的方法
当处理临界段代码时,须关中断,处理完毕后,再开中断 关中断时间是实时内核最重要的指标之一。它影响用户系 统对实时事件的相应特性。 在实际应用中,关中断的时间很大程度上取决于微处理器 的结构和编译器生成的代码质量 微处理器通常具有关中断/开中断操作。C编译器须具有某 种机制,能够在c中直接实现关中断/开中断操作
3种不同的方法实现
具体方法取决于用户打算移植到的处理器的性能及所 用的C编译器 用定义(#define)常数OS_CRITICAL_METHOD可以选择 具体使用哪种方法 该常数在与CPU类型有关的移植文件OS_CPU.H中定义
28
C/OS-II中采用了3种开关中断的方法
OS_CRITICAL_METHOD==1
如果在所有挂起类(PEND)调用之前,如:调用OSTimeDel() (挂起时间)功能函数之前关中断,会出现什么现象? 通常,调用C/OS-II功能函数时,中断总应当是开放的。
27
C/OS-II开关中断的方法(续3)
OS_ENTER_CRITICAL( )及OS_EXIT_CRITICAL( )可以用
嵌入式系统
—嵌入式实时操作系统C/OS-Ⅱ分析
2006年5月
1
主要内容
嵌入式操作系统 C/OS-Ⅱ简介 C/OS-Ⅱ内核结构 C/OS-Ⅱ任务管理 C/OS-Ⅱ时间管理
C/OS-Ⅱ任务通信与同步
2
为什么需要操作系统
功能层 应用程序 图形用户 接口
文件系统 软件层
任务管理
7
HAL设计目标
uCOS-II内核架构解析
![uCOS-II内核架构解析](https://img.taocdn.com/s3/m/8518d7ee59eef8c75ebfb36b.png)
目录嵌入式RTOS (3)1。
嵌入式系统基本模型32.RTOS设计原则 (4)3。
GPOS与RTOS 44。
嵌入式开发模式45。
(不)可重入46.互斥条件 (5)7。
临界状态5uC/OS—II基本介绍 (6)1.uC/OS-II文件结构 (6)2.uC/OS—II组成部分 (6)3。
uC/OS-II任务状态7uC/OS—II系统核心 (7)1。
uC/OS-II任务调度7(1)uC/OS—II调度算法 (7)(2)任务就绪表 (7)(3)任务级任务调度8(4)中断级任务调度8(5)调度器上锁与解锁9(6)中断管理函数10(7)中断相关问题 (10)2。
uC/OS—II系统启动11(1)初始化函数OSInit() (11)(2)启动函数OSStart() (12)(3)统计任务OSTaskStat 123.uC/OS-II系统时钟 (12)4。
uC/OS-II事件管理13(1)事件控制块13(2)ECB管理机制 (13)(3)ECB管理函数 (13)uC/OS—II任务管理 (14)1.C可执行代码结构 (14)2。
任务结构143。
任务栈154.任务控制块 (15)(1)TCB描述 (15)(2)TCB主要成员 (15)(3)TCB全局变量155.任务状态切换 (16)6。
任务管理函数16uC/OS-II通信与同步 (16)1.消息邮箱Mbox (16)2。
消息队列msgQ 17(1)msgQ基本内容 (17)(2)msgQ全局变量 (18)(3)msgQ管理函数 (18)(4)msgQ几个问题 (19)3.信号量Sem (19)4。
互斥锁Mutex 20(1)Mutex基本原理 (20)(2)提升/恢复优先级 (20)(3)Mutex管理函数 (20)5。
事件组标志Flag 21(1)Flag基本原理21(2)Flag数据结构21(3)Flag管理函数 (22)6.Task就绪状态判断??? (23)uC/OS—II内存管理 (24)1。
uCOS-II简介
![uCOS-II简介](https://img.taocdn.com/s3/m/ef7acc8cd0d233d4b14e69f7.png)
4.1OC/OS-II简介UC/OS-II 是一种基于优先级的可抢先的硬实时内核。
自从92 年发布以来,在世界各地都获得了广泛的应用,它是一种专门为嵌入式设备设计的内核,目前已经被移植到40 多种不同结构的CPU 上,运行在从8 位到64 位的各种系统之上。
尤其值得一提的是,该系统自从2.51版本之后,就通过了美国FAA 认证,可以运行在诸如航天器等对安全要求极为苛刻的系统之上。
鉴于UC/OS-II 可以免费获得代码,对于嵌入式RTOS 而言,选择UC/OS 无疑是最经济的选择。
需要说明的是,UC/OS-II 作为一个实时操作系统只提供了多任务调度等基本功能,这在实际应用中显然是不够的。
除了移植好的操作系统内核部分,还必须有文件系统,全部硬件的驱动程序,图形API,控件函数,综合提高的消息函数以及几个系统必须的基本任务,象键盘,触摸屏,LCD 刷新等。
有了这些,UC/OS-II 才能实现复杂的功能。
特殊需求的地方还需要像USB通信协议,TCP/IP 协议等更复杂的软件模块。
博创提供的UC/OS-II 库文件中包含了上述大部分功能,基于库的开发变的非常简单,在基本的程序框架下应用我们提供的丰富API 函数即可。
实际开发中,用户的工程中无需包括UC/OS-II 的源代码,只需要包括库文件即可。
当然,用户也可以了解库中部分代码的源文件,可以根据自己的需求就行重新编译,也可以对自己的一系列源文件生成一个专门的库,方便自己后续工作。
UC/OS-II 的开发中,应用程序和操作系统是绑在一起编译的,所生成的system.bin 文件是唯一的可执行文件,其中包括了所需要的UC/OS-II 代码和被用到的驱动程序等函数代码,以及应用程序的代码。
system.bin 文件是存放在平台的16M FLASH 中的,在系统启动时由BIOS依靠文件系统从FLASH 中读入到SDRAM 中,然后把控制转移到该代码上,完成所谓的引导。
UCOS-II系统结构及调用
![UCOS-II系统结构及调用](https://img.taocdn.com/s3/m/318ab7d5770bf78a652954d8.png)
内容介绍1、介绍uC/OS-II嵌入式操作系统2、基于uC/OS-II的用电管理终端软件的设计书籍:《嵌入式实时操作系统uC/OS-II》作者:Jean LabrosseuC/OS-II V2.52 通过了美国航空航天管理局(FAA)的安全认证;安全性、可靠性是得到认证的。
我们为什么会选择uC/OS-II嵌入式操作系统?1、与终端硬件平台相适应全部源代码5500行,可裁减定制,生成的可执行代码占15~20k,可以移植到多种系列单片机上,包括ARM;2、考虑成本,免费的源代码公开;3、uC/OS-II代码简单,容易掌握和使用;具有多任务调度的基本功能;uC/OS-II嵌入式操作系统的缺点:1、缺少技术支持,相关的支持软件少;2、和商业软件比,功能较弱(如不支持时间片轮转,最大任务数为64等);对应用开发的支持不够;uC/OS内核介绍和基于RTOS的设计介绍一、概述●使用嵌入式RTOS的优点1 将复杂的系统分解为多个相对独立的任务,采用“分而治之”的方法降低系统的复杂度。
通过将应用程序分割成若干独立的任务,RTOS使得应用程序的设计过程大为简化;2 使得应用程序的设计和扩展变得容易,无需较大的改动就可以增加新的功能;3 用户给系统增加一些低优先级的任务,则用户系统对高优先级的任务的响应时间几乎不受影响;4 实时性能得到提高。
使用可剥夺型内核,所有时间要求苛刻的事件都得到了尽可能快捷有效的处理;5 通过有效的服务,如信号量、邮箱、队列、延时及超时等,RTOS使资源得到更好的利用;●使用嵌入式RTOS的缺点1 使用RTOS增加了系统的内存和CPU等使用开销,例如任务之间的通讯、RTOS的调度程序等;2 需要采用一些新的软件设计方法,对系统设计人员的要求高一些。
例如驱动程序的设计要考虑到共享资源的互斥问题;3 系统任务的划分是比较复杂的过程,需要设计人员对业务和RTOS操作系统都很熟悉。
●uC/OS操作系统的特点uC/OS是一个完成的,可移植、可固化、可裁减的抢占式实时多任务操作系统内核。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
目录嵌入式RTOS (3)1.嵌入式系统基本模型 (3)2.RTOS设计原则 (3)3.GPOS与RTOS (3)4.嵌入式开发模式 (4)5.(不)可重入 (4)6.互斥条件 (4)7.临界状态 (4)uC/OS-II基本介绍 (5)1.uC/OS-II文件结构 (5)2.uC/OS-II组成部分 (5)3.uC/OS-II任务状态 (6)uC/OS-II系统核心 (6)1.uC/OS-II任务调度 (6)(1)uC/OS-II调度算法 (6)(2)任务就绪表 (7)(3)任务级任务调度 (7)(4)中断级任务调度 (8)(5)调度器上锁与解锁 (9)(6)中断管理函数 (9)(7)中断相关问题 (10)2.uC/OS-II系统启动 (10)(1)初始化函数OSInit() (10)(2)启动函数OSStart() (11)(3)统计任务OSTaskStat (12)3.uC/OS-II系统时钟 (12)4.uC/OS-II事件管理 (12)(1)事件控制块 (12)(2)ECB管理机制 (13)(3)ECB管理函数 (13)uC/OS-II任务管理 (13)1.C可执行代码结构 (13)2.任务结构 (14)3.任务栈 (14)4.任务控制块 (14)(1)TCB描述 (14)(2)TCB主要成员 (14)(3)TCB全局变量 (14)5.任务状态切换 (15)6.任务管理函数 (15)uC/OS-II通信与同步 (16)1.消息邮箱Mbox (16)2.消息队列msgQ (16)(1)msgQ基本内容 (16)(2)msgQ全局变量 (17)(3)msgQ管理函数 (17)(4)msgQ几个问题 (18)3.信号量Sem (18)4.互斥锁Mutex (19)(1)Mutex基本原理 (19)(2)提升/恢复优先级 (19)(3)Mutex管理函数 (19)5.事件组标志Flag (20)(1)Flag基本原理 (20)(2)Flag数据结构 (20)(3)Flag管理函数 (21)6.Task就绪状态判断??? (22)uC/OS-II内存管理 (23)1.memPart基本原理 (23)2.memPart管理函数 (23)3.memPart几个问题 (24)uC/OS-II应用开发 (24)1.开发步骤 (24)2.编写任务函数 (24)3.堆栈设计扩展 (25)4.一些借鉴经验 (25)uC/OS-II内核移植 .................................................................... 错误!未定义书签。
1.uC/OS-II正常运行的条件............................................ 错误!未定义书签。
2.运行态代码分布............................................................ 错误!未定义书签。
3.移植的几个问题............................................................ 错误!未定义书签。
嵌入式RTOS1.嵌入式系统基本模型2.RTOS设计原则采用各种算法和策略,始终保持系统行为的可预测性。
即在任何情况下,在系统运行的任何时刻,OS的资源配置策略都能为争夺资源(包括CPU、内存、网络带宽等)的多个实时任务合理地分配资源,使每个实时任务的实时性要求都能得到满足。
3.GPOS与RTOSGPOS:注重每次执行的平均响应时间,而不是某次特定执行的响应时间。
RTOS:除满足应用功能需求外,还要满足实时性要求,始终保证系统行为的可预测性(predictability)。
与GPOS不同,RTOS注重的不是系统的平均表现,而是要满足每个实时任务在最坏情况下的实时性要求。
也就是说,RTOS注重的是个体表现,更准确地说是个体最坏情况表现。
RTOS与GPOS的差别主要表现在:a)任务调度策略不同;b)内存管理方式不同;c)中断处理方式不同;d)系统管理方式不同;4.嵌入式开发模式单片机系统的前后台程序:不使用OS,将应用程序设计成死循环,系统轮流处理各事件,对时间响应要求高的异步事件采用中断进行处理。
基于任务(进程)的软件设计方法:使用OS,由OS管理硬件资源,任务只是在需要资源时申请即可,至于when/which,完全由OS决定。
5.(不)可重入(1) 可重入函数:指函数代码在运行过程中可以被中断,中断返回后仍能够恢复到原来的状态,并能准确无误执行的函数。
可重入函数可以被一个以上的任务调用,而不必担心数据被破坏。
可重入函数或者只使用局部变量,即变量保存在CPU寄存器或堆栈中;或者使用全局变量,则要对全局变量予以保护。
(2) 不可重入函数:函数在运行过程中不可以被中断。
6.互斥条件实现任务间通信最简便的办法是使用共享数据,但要保证任务在处理共享数据时的排它性。
使共享资源满足互斥条件,最一般的方法有:(1)关中断使用某种实时内核,一般情况下关中断的时间最长不超过内核本身的关中断时间,这样就不会影响系统中断延迟。
(2)使用测试并置位指令Test&Set操作可能是微处理器一条不会被中断的指令,否则应该在程序中关中断做TAS操作再开中断。
(3)禁止做任务切换此时任务切换虽然是禁止的,但仍允许中断。
如果这时中断来了,ISR 会在这一临界区内立即执行。
(4)利用信号量;7.临界状态临界状态指当前程序处于不可中断状态。
一般情况下,在调用不可重入函数前或在修改全局变量数据时,都需要先进入临界状态。
进入临界状态的主要操作是关闭所有可以屏蔽的中断;而退出临界状态的主要操作是恢复到上次进入临界状态时前中断管理的状态。
在uC/OS-II中,宏OS_ENTER_CRITICAL()描述进入临界状态所完成的操作,宏OS_EXIT_CRITICAL()描述退出临界状态的操作。
uC/OS-II提供了3种进入和退出临界状态的办法,可以根据CPU类型由宏OS_CRITICAL_MOTHOD指定具体的临界状态处理办法。
uC/OS-II基本介绍1.uC/OS-II文件结构2.uC/OS-II组成部分uC/OS-II大致可以分成系统核心(包含任务调度)、任务管理、时间管理、多任务同步与通信、内存管理、CPU移植等部分。
(1)核心部分(OSCore.c):uC/OS-II处理核心,包括初始化、启动、中断管理、时钟中断、任务调度及事件处理等用于系统基本维持的函数。
(2)任务管理(OSTask.c):包含与任务操作密切相关的函数,包括任务建立、删除、挂起及恢复等,uC/OS II以任务为基本单位进行调度。
(3)时钟部分(OSTime.c):uC/OS-II中最小时钟单位是timetick(时钟节拍),其中包含时间延迟、时钟设置及时钟恢复等与时钟相关的函数。
(4)多任务同步与通信(OSMbox.c, OSQ.c, OSSem.c, OSMutex.c, OSFlag.c):包含事件管理函数,涉及Mbox、msgQ、Sem、Mutex、Flag等。
(5)内存管理部分(OSMem.c):主要用于构建私有的内存分区管理机制,其中包含创建memPart、申请/释放memPart、获取分区信息等函数。
(6)CPU接口部分:uC/OS-II针对特定CPU的移植部分,由于牵涉到SP等系统指针,通常用汇编语言编写,包括任务切换、中断处理等内容。
3.uC/OS-II任务状态在uC/OS-II中,一个任务就是一个线程,该任务可以认为CPU完全属于它自己。
任务有自己的堆栈和CPU寄存器,并且被赋予一定的优先级。
任务可能处于睡眠、就绪、运行、等待或中断服务状态之一。
uC/OS-II系统核心主要包含在C源文件OS_CORE.C中。
1.uC/OS-II任务调度(1)uC/OS-II调度算法uC/OS-II采用基于优先级的调度算法,总是选择当前处于就绪状态的优先级最高的任务进行调度。
uC/OS-II是可抢占性的强实时性OS,在完成中断后允许进行新的任务调度。
uC/OS-II有两种调度方式:任务级任务调度、中断级任务调度。
(2)任务就绪表INT8U const OSUnMapTbl[256] = {…};OS_EXT INT8U OSRdyGrp;OS_EXT INT8U OSRdyTbl[OS_RDY_TBL_SIZE];添加就绪任务至就绪表;从就绪表删除就绪任务;查找最高优先级就绪任务OS_SchedNew();(3)任务级任务调度指在非中断返回时进行任务调度,一般发生在当前任务因时间延迟或等待某事件而阻塞或被挂起,或有更高优先级的任务处于就绪状态。
任务的基本信息:CPU的PC寄存器:任务当前执行的位置;CPU的通用寄存器:任务当前执行涉及的临时数据;CPU的状态寄存器:存储当前CPU的状态。
任务级任务切换:从一个任务直接切换至另一个任务,不涉及CPU状态的切换,OS_TASK_SW()既保存当前任务上下文,又恢复新任务上下文。
过程:OS_Sched() -> OS_SchedNew() -> OS_TASK_SW()(4)中断级任务调度中断级任务切换:在中断处理完成后,通过OSIntExit()判断是否有更高优先级就绪任务。
如果有,调用OSIntCtxSW()恢复新任务上下文。
注意:在中断处理中,已经保存了被中断任务的上下文,所以这里仅仅恢复。
过程:OSIntExt() –> OSIntEnter() -> ISR –> OSIntExit() -> OSIntCtxSW() (5)调度器上锁与解锁uC/OS-II提供调度器锁定功能,在锁定期间不能进行任务调度。
uC/OS-II 使用全局变量OSLockNesting标识是否锁定了任务调度器。
OS_EXT INT8U OSLockNesting;void OSSchedLock(void);void OSSchedUnlock(void);(6)中断管理函数在中断处理中,不允许进行任务管理、事件管理及任务调度等操作。
uC/OS-II 通过全局变量OSIntNesting标识当前是否处于中断状态。
在所有任务及事件管理的程序中,都有对OSIntNesting进行判断的语句。
void OSIntEnter(void);void OSIntExit(void);(7)中断相关问题OS_ENTER_CRITICAL()OS_EXIT_CRITICAL()关中断使得uC/OS-II能够同时避免有其他任务或中断服务进入临界代码段。