毕业设计（论文）基于uCOSII的嵌入式系统设计.doc

摘 要随着电子技术，信息技术和通讯技术的快速发展，以及互联网的广泛应用，3C (Computer, Communication, Consumer)合一的趋势己经形成，从而导致了计算机工业重心的转移，即从计算机产品转移到信息产品，随着硬件技术的发展及人们对于信息产品功能要求的提高，嵌入式系统也就成为这个行业的热点。同时在计算机本身的领域里面，微型化和专业化是一个新的发展趋势。因此，研究与嵌入式系统有关的关键技术嵌入式操作系统有着相当重要的实际意义。在本论文中详细论述了作者所做的工作：1、对嵌入式系统进行了讨论。2、对RTOS系统的研究。3、对具体的uCOS-II系统内核进行了各方面的探讨和研究。4、对uCOS-II系统内核进行了部分必要的修改，将其移植到了S3C2410高速处理器上。5、在移植的基础上对内核进行了测试。关键词：嵌入式系统；RTOS；内存管理；uCOS-IIAbstractWith the rapid development of electronic technology,computer technology and communication technology in information times and the wide application of internet, it is clear that 3C(Computer,Communication and Consumer) will converge in the near future, which will lead the focus of computer industry from the computation product to information product.With the development of hardware technology and the high demands of the information appliance, Embedded Operation System will be the most favorite in this industry.At the same time, in the field of computer science itself, the micromation and specialization is the new direction of the computer world. So,the research of the critical technique relating to the embedded system is the most important thing.This thesis clearly presents the work of the author:1. Discusstion of the embedded system.2. Research about the RTOS.3. Analasis of all parts of uCOS-II kernel.4. Amending some parts of the uCOS-II system kernel, and migrate it to the S3C2410 processors.5. Testing the kernel after migtate.KEY WORDS: embedded system；RTOS；memory management；uCOS-II目 录摘 要IABSTRACTII目 录1第1章 引 言11.1 嵌入式系统的概述11.2 国内外嵌入式系统现状和发展趋势11.2.1 国外现状和发展趋势11.2.2 国内现状和发展趋势21.3 UCOS-II简介3第2章 嵌入式实时系统简介62.1 嵌入式处理器的要求62.2 RTOS的要求72.2.1 RTOS的概念72.2.2 RTOS的分类方法82.2.3 RTOS的衡量标准82.3 RTOS小结8第3章 UCOS-II内核分析103.1 任务管理103.1.1 建立任务123.1.2 任务堆栈143.1.3 堆栈检验153.1.4 删除任务163.1.5 改变任务的优先级173.1.6 任务的挂起与恢复183.1.7 任务就绪表193.2 内存管理203.2.1 内存控制块203.2.2 建立一个内存分区213.2.3 分配一个内存块223.2.4 释放一个内存块233.3 时间管理233.3.1 任务延时函数243.3.2 按时分秒延时函数243.3.3 结束延时253.3.4 系统时间253.4 任务之间的通讯与同步263.4.1 事件控制块ECB263.4.2 信号量283.4.3 邮箱313.4.4 消息队列32第4章 UCOS-II在ARM上的移植354.1 移植条件354.2 移植工作374.2.1 操作系统头文件384.2.1.1 数据类型定义384.2.1.2 堆栈单位384.2.1.3 堆栈增长方向394.2.1.4 宏定义394.2.2 操作系统C语言文件404.2.2.1 任务堆栈初始化404.2.2.2 系统钩子函数424.2.3 操作系统汇编语言文件424.2.3.1 最高优先级424.2.3.2 任务切换434.2.3.3 中断任务切换434.2.3.4 时钟中断处理464.2.3.5 宏定义函数464.3 串行通信实验测试47第5章 结束语51致 谢53参考文献54附录56第1章 引 言随着各个领域如安全巡检、商业POS、现场数据采集处理、消费电子类等各领域的发展，人们在日常生活中接触到很多嵌入式产品。1.1 入式系统的概述嵌入式系统是以应用为中心、以计算机技术为基础、软件硬件可裁剪、适应应用系统对功能、成本、可靠性、功耗、体积有严格要求的专用计算机系统。是设计完成复杂功能的硬件和软件，并使其紧密耦合在一起的计算机系统1。嵌入式系统这个概念在很早的年代就已经存在了。1960年，在通讯行业上就被用于电子机械电话交换的控制，当时被称为“存储式程序控制系统”2。1970年左右嵌入式系统的概念出现，不过那时，大部分都是用汇编语言来实现的，而且汇编程序有着必须与微处理器匹配的缺点，那么当这种微处理器过时了，这种嵌入式系统就没有用了。开始对新的微处理器写新的嵌入式系统就成了必须的工作。从上个世纪八十年代，开始出现了各种各样的商业用的嵌入式操作系统，这些系统绝大部分都是为专有系统而开发的，从而形成了现在多形式的商用嵌入式系统百家争鸣的局面，例如uC/OS-II、VxWorks、Windows CE、Linux、ARM、HOPEN OS、pSOS等等。1.2 国内外嵌入式系统现状和发展趋势1.2.1 国外现状和发展趋势早在八十年代，国际上就开始进行一些商用嵌入式系统和专用操作系统的开发。他们开发嵌入式系统也有了几十年的历史和经验。当今，应用更是越来越广泛。下面介绍一下著名的嵌入式系统。VxWorks：VxWorks是目前嵌入式系统领域中使用最广泛，市场占有率最高的系统。它支持多种处理器，如x86、Sun Sparc、Motorola MC68xxx、MIPS RX00、POWER PC等等。使用、的是和UNIX不兼容的环境，大多数VxWorksAPI是专有的。采用GNU的编译和调试器。Windows CE：Microsoft Windows CE是一个简洁的、高效的多平台操作系统。它不是削减的Windows95版本，而是从整体上为有限资源的平台设计的多线程，完整优先权，多任务的操作系统。他的模块化设计允许它对于从掌上电脑到专用的工业控制器的用户电子设备进行制定。操作系统的基本内核需要至少200K的ROM。从SEGA的Dream Cast游戏机到现在大部分的高价掌上电脑，都采用了Windows CE，但是无奈价格太高，使得整个产品的成本急剧上升。 Linux：Linux是一套以UNIX为基础发展而成的操作系统。自1991年诞生以来，Linux在很多方面都已经赶上甚至超过了很多商用的UNIX操作系统。它充分利用了x86CPU的任务切割机制，实现了真正的多用户、多任务环境。Linux对硬件配置的要求相当低，能够在4M内存的386机子上很好的运行，而且支持很多种处理器芯片。在应用于嵌入式系统方面，Linux可裁减，甚至放在一张软盘上运行。专为实时系统而开发的变种RT Linux(Real-Time Linux)可以让Linux支持硬实时任务。Linux的开放式开发原则使得Linux下的驱动和升级变得越来越多、越来越快。1.2.2 国内现状和发展趋势国内的嵌入式系统开发已经取得了一定的成绩，包括中科院的EEOS，凯思集团的HOPEN OS等等。但是国内的产品大部分都是外国公司的附属和扩充，其技术含量相对还比较低。介绍如下：EEOS：EEOS是中科院计算所组织开发的开放源代码的嵌入式操作系统。该系统重点支持p-Java，要求小型化并且能复用Linux的驱动和其他模块。E2实时操作系统包括RTOS内核系统和一些支持组件，是一个扩展能力强，功能完善的操作系统，支持POSIX标准。E2实时操作系统强调模块化，其各模块解决方案可移植、可互换。还提供开放源码。E2的工具链基于GUN系列的交叉编译环境，开放多平台，能够支持大多数硬件平台。EEOS专为嵌入式系统设计，代码尺寸小，同时EEOS结构上考虑了实时需求，很高的实时响应速度，因而能够在各种环境下工作，具有良好的可伸缩性。HOPEN OS：HOPEN OS是凯思集团自主研发的嵌入式操作系统。由一个体积很小的内核和一些可以根据需要进行制定的系统模块组成。其内核Hopen Kernel一般为10K左右大小，占用空间小，并具有实时、多任务、多线程的系统特征。该系统目前已能在：X86、PA-RISC、Power PC、ARM、Strong ARM、MIPS、68XXX等多种芯片上运行。使用者可以很容易地对这一操作系统进行定制或作适当开发，该系统不仅可以广泛应用于：移动计算平台(PDA)、 家庭信息环境（机顶盒，数字电视）、通讯计算平台（媒体手机）、车载计算平台（导航器）、工业、商业控制（智能工控设备，POS/ATM机）、电子商务平台（智能卡应用，安全管理）等信息家电上，还可应用于与Internet相联接的一切接入设备，是未来信息家电的核心。从国内外的嵌入式系统发展状况来说，嵌入式系统的应用正从传统的单一应用范围、狭小的应用对象、简单的实现功能向现在和未来社会需要的应用需求方面进行转变。嵌入式系统在信息电器中的应用，则是对嵌入式系统概念和应用范围的一次变革。从而打破了PC时代单一的微处理器厂家和单一的系统厂家垄断的局面。出现一个由多芯片、多处理器占领市场领域的局面。就市场角度来看，信息电器占领很大一部分的可能使用PC机的客户，虽然市场的范围有所重叠，但是发展的余地还是很大。1.3 uCOS-II简介uC/OS-II的创始人是Jean Labrosse,具有下列待点，uCOS-II是一个可移植的、可固化的、抢占式的、实时的、多任务的内核。提供64个优先级，并采用优先级来标识任务，完成进程调度。他提供的时间管理，任务管理，进程间通讯，内存管理等基本功能。适用于几乎所有的8位、16位、32位的芯片。同时它开放源代码是学习和研究一个很好的选择。uCOSII作为嵌入式内核，其优点在于结构简单，代码简洁，可靠性高，稳定性好，容易掌握，且开发出来的产品价格便宜。随着uCOSII的发展，图形接口，文件系统，网络协议栈也逐步完善起来。支持x86、ARM、MIPS、PowerPC等多种体系结构。具有模块化，结构化和基于uCOSII的应用程序接口以及与处理器相关等特点。并且uCOSII可以在Win9x/NT/2000/XP/2003环境下运行。这为基于uCOSII的嵌入式系统设计提供了更广阔的空间。因此它正广泛的应用在嵌入式系统中3。1、公开源代码uCOS-II提供全部源代码。且源码清晰易读且结构协调，注解的也非常详尽。2、可移植性(Portable)绝大部分uCOS-II的源码是用移植性很强的ANSI C写的。和微处理器硬件相关的那部分是用汇编语言写的。汇编语言写的部分已经压到最低限度，使得uCOS-II便于移植到其他微处理器上。只要该微处理器有堆栈指针，由CPU内部寄存器入栈、出栈指令。另外，使用的C编译器必须支持内嵌汇编(inline assembly)或者该C语言可扩展、可连接汇编模块，使得关中断、开中断能在C语言程序中实现。uCOS-II可以在绝大多数8位、16位、32位以至64位微处理器、微控制器、数字信号处理器(DSP)上运行。3、可固化(ROMable)uCOS-II是为嵌入式应用而设计的，采取相应的固化手段(C编译、连接、下载和固化)，uCOS-II就可以嵌入到我们的产品中成为产品的一部分。4、可裁剪(Scalable)可以只使用 uCOS-II中应用程序需要的那些系统服务。也就是说某产品可以只使用很少几个uCOS-II调用，而另一个产品则使用了几乎所有uCOS-II的功能。这样可以减少产品中的uCOS-II所需的存储空间(RAN和ROM)，这种可裁剪性是靠条件编译实现的。只要在用户的应用程序中(用#define constants语句)定义哪些uCOS-II中的功能是应用程序需要的就可以了。程序和数据两部分的存储用量已被最大努力的压低了。5、占先式(Preemptive)uCOS-II完全是占先式的实时内核，它总是运行就绪条件下优先级最高的任务。大多数商业内核也是占先式的，uCOS-II在性能上和它们类似。6、多任务uCOS-II可以管理64个任务，目前2.52版本保留8个给系统。应用程序最多可以有56个任务。赋予每个任务的优先级必须是不同的。7、可确定性全部COS-II的函数调用与服务的执行时间具有其可确定性。也就是说，全部uCOS-II的函数调用与服务的执行时间是可知的。进而言之，uCOS-II系统服务的执行时间不依赖于应用程序任务的多少。8、任务栈每个任务有自己单独的栈，uCOS-II允许每个任务有不同的栈空间。以便压低应用程序对RAM的需求。使用uCOS-II的栈空间校验函数，可以确定每个任务到底需要多少栈空间。第2章 嵌入式实时系统简介2.1 嵌入式处理器的要求嵌入式系统的核心部件是嵌入式处理器。几乎每个半导体厂家都生产自己的嵌入式处理器。嵌入式处理器的功能跨度很广，常用封装从8个引脚到144个引脚，寻址空间从64KB到16MB，处理速度从0.1MIPS到2000MIPS。目前，嵌入式处理器主要可以分为如下几类4：1、嵌入式微控制器(Embedded Microcontroller)嵌入式微控制器又称单片机。它是将一整个计算机系统集成到一块芯片上。一般在单片机里面以一块嵌入式微处理器内核为核心，然后集成上ROM/EPROM、 RAM、总线、总线逻辑、定时/计数器、Watchdog、I/O、串行口、脉宽调制输出、A/D、D/A、Flash RAM、EEPROM等等必要的产品和功能外设。目前的嵌入式微控制器主要有8051、PS1XA、MCS-251、MCS-96/196/296、C166/167、MC68HC05/11/12/16、b8300等等5。2、嵌入式微处理器(Embedded Microprocessor)嵌入式微处理器就是和通用计算机里面对应的CPU。在应用中，一般是将微处理器装配在专门设计的电路板上，在母板上只保留和嵌入式相关的功能即可。这样可以满足嵌入式系统体积和功耗大幅度减小的要求。目前的嵌入式处理器主要包括有AM186/88、386EX、SC-400、PowerPC、ARM、Motorola68000、MIPS系列等等。3、嵌入式DSP处理器(Embedded Digital Signal Processor )在DSP(Digital Signal Processor)里面专门为系统结构和指令系统进行设计，提高了编译效率和执行速度。在数字滤波、FFT、谱分析、图像处理的分析等领域，DSP正在大量进入嵌入式市场。智能化正是DSP的强项。目前采用最多的是TI公司的TMS320系列和Motorola的DSPS6000系列。2.2 RTOS的要求开发嵌入式系统需要一个支持实时多任务的操作系统(RTOS)内核来支持。使用RTOS内核，可以针对使用的处理器进行优化设计，做成一个高效率的实时多任务内核。并且在上面可以根据不同处理器体系结构设计出不同的API接口，这些是RTOS基于设备独立的应用程序开发基础。在RTOS里面最关键的部分是实时多任务内核，需要实现任务管理、定时器管理、存储器管理、资源管理、事件管理、系统管理、消息管理、队列管理、等等。能否实现效率高，体积小，移植功能强大、易于定制的RTOS是开发嵌入式系统的关键问题。2.2.1 RTOS的概念从表现上讲，RTOS是实时嵌入式系统在启动之后运行的一段背景程序。应用程序是运行在这个基础之上的多个任务。RTOS根据各个任务的要求，进行资源管理、消息管理、任务调度、异常处理等工作。在RTOS支持的系统中，每个人任务都有优先级别，RTOS根据各个任务的优先级来动态的切换各个任务，保证对实时性的要求。这种体系结构简化了编程结构，比过去的循环控制的体系结构有了很大的改进。从性能上讲，RTOS和普通的OS存在的区别主要是在“实时”二字上。“在实时计算中，系统的正确性不仅仅依赖于计算的逻辑结果而且还依赖于结果产生的时间。”从这个角度上看，可以把实时系统定义成“一个能够实现在指定或者确定的时间内完成系统功能和对外部或内部、同步或异步时间做出响应的系统”。这个定义要求包括6：系统应该有在事先定义的时间范围内识别和处理离散事件的能力；系统能够处理和存储控制系统所需要的大量的数据。2.2.2 RTOS的分类方法开发RTOS需要更多的关注到将来在其上设计出合适的应用相关的考虑。根据不同的应用，可以有很多种不同的侧重点，不同的侧重点对应了不同的分类方法。下面介绍两种主要是按照实时调度算法来分类方法7。1、周期性和非周期性周期性就是系统通过传感器或者其他周期性设备对外部环境的变化做出探测，对在这个周期内探测到的变化做出反应。非周期性就是外部事件是循环性发生的但不是有规律性的，或者是突发事件。2、硬实时和软实时硬实时和软实时的区别就在于对外界的事件做出反应的时间。硬实时系统必须是对及时的事件做出反应，绝对不能错过事件处理截止时间。软实时系统是指，如果在系统负荷较重的时候，允许发生错过截止时间的情况而且不会造成太大的危害。硬实时系统和软实时系统的实现区别主要是在选择调度算法上。2.2.3 RTOS的衡量标准用来作为RTOS性能衡量标准的指标主要有如下几种8：1、系统响应时间：系统在发出处理要求到系统给出应答信号的时间；2、任务切换时间：多任务之间进行切换而花费的时间；3、中断延迟时间：从接收到中断信号到操作系统做出响应，并完成进入中断服务程序的时间。2.3 RTOS小结实时内核也称为实时操作系统或RTOS。它的使用使得实时应用程序的设计和扩展变得容易，不需要大的改动就可以增加新的功能。通过将应用程序分割成若干独立的任务，RTOS使得应用程序的设计过程大为减化。三种类型的实时系统归纳于下表中，这三种实时系统是：前后台系统，不可剥夺型内核和可剥夺型内核。表2-1 实时系统小结前后台系统不可剥夺型内核可剥夺型内核中断延时（时间）Max(最长指令，用户关中断)+开始执行中断服务子程序的第一条指令Max(最长指令，用户关中断，系统关中断)+开始执行中断服务子程序的第一条指令Max(最长指令，用户关中断，系统关中断)+开始执行中断服务子程序的第一条指令中断响应（时间）中断延迟+保存CPU寄存器中断延迟+保存CPU寄存器中断延迟+保存CPU寄存器+内核的进入中断服务函数的执行时间中断恢复（时间）恢复CPU寄存器+执行中断返回指令恢复CPU寄存器+执行中断返回指令)判定是否有优先级更高的任务进入了就绪态+恢复那个优先级更高任务的CPU内部寄存器+执行中断返回指令任务响应（时间）取决于后台最长的任务+找到最高优先级任务+任务切换找到最高优先级任务+任务切换ROM大小取决于应用代码应用代码+内核代码应用代码+内核代码RAM大小取决于应用代码应用代码+内核RAM+SUM(任务堆栈+MAX(中断堆栈)应用代码+内核RAM+SUM(任务堆栈+MAX(中断堆栈)第3章 uCOS-II内核分析传统操作系统的主要功能有：处理机管理、内存管理、文件管理、设备管理、进程间通信5部分。但uCOS-II是一个实时内核，其功能与传统的操作系统有些差异。为满足实时性及嵌入式系统资源的要求，uCOS-II内核的主要功能有下面几部分：任务管理、时间管理、内存管理、进程间通信4部分。uCOS-II要求用户提供定时中断来实现延时与超时控制等功能。这个定时中断叫做时钟节拍，它应该每秒发生10至100次。时钟节拍的实际频率是由用户的应用程序决定的。时钟节拍的频率越高，系统的负荷就越重。3.1 任务管理uCOS-II可以管理多达64个任务，并从中保留了四个最高优先级和四个最低优先级的任务供自己使用，所以用户可以使用的只有56个任务。任务的优先级越高，反映优先级的值则越低。在最新的uCOS-II版本中，任务的优先级数也可作为任务的标识符使用。任务管理中最重要的数据结构是任务控制块OS_TCB，其定义如下：typedef struct os_tcb OS_STK *OSTCBStkPtr;/*当前栈顶指针*/ #if OSTASK_REATE_EXTes_ENvoid *OSTCBExtPtr;/*指向用户定义数据的指针*/OS_STK *OSTCBStkBottom;/*栈底指针*/INT32U OSTCBStkSize;/*堆栈大小*/INT16U OSTCBOpt;/*任务选项*/INT16U OSTCBId;/*任务ID (065535)*/#endif struct os_tcb *OSTCBNext;/*指向TCB链中下一TCB块的指针*/ struct os_tcb *OSTCBPrev;/*指向TCB链中上一TCB块的指针*/#if (OS_Q_EN&&(OS_MAX_QS>=2)|OS_MBOX_EN|OS_SEM_EN OS_EVNT *OSTCBEventPtr;/*事件控制块指针*/#endif#if (OS_Q_EN&&(OS_MAX_QS>=2)|OS_MBOX_EN void *OSTCBMsg;/*从OSMboxPost()或OSQPost()收到的消息*/#endif INT16U OSTCBDly;/*延迟时间*/INT8U OSTCBStat;/*任务状态*/INT8U OSTCBPrio;/*任务优先级(063)*/INT8U OSTCBX;/*根据任务优先级指出就绪组(07)*/INT8U OSTCBY;/*根据任务优先级指出就绪表*/INT8U OSTCBBitX;/*就绪表的位掩码*/INT8U OSTCBBitY;/*就绪组的位掩码*/#if OS_TASK_DEL_EN BOOLEAN OSTCBDelReq;/*指出一个任务是否要删除本身*/#endif OS_TCB一旦任务建立了，任务控制块OS_TCB将被赋值。当任务的CPU使用权被剥夺时，uCOS-II用它来保存该任务的状态。当任务重新得到CPU使用权时，任务控制块确保任务从当时被中断的那一点继续执行。OS_TCB全部驻留在RAM中。3.1.1 建立任务用户可以通过传递任务地址和其它参数到以下两个函数之一来建立任务：OSTaskCreate()或OSTaskCreateExt()。OSTaskCreate()与uCOS向下兼容，OSTaskCreateExt()是OSTaskCreate()的扩展版本，提供了一些附加功能。在开始任务调度(即调用OSStart()前，用户必须建立至少一个任务。任务不能由中断服务程序(ISR)来建立。OSTaskCreate()需要四个参数：task是任务代码的指针，pdata是当任务开始执行时传递给任务的参数的指针，ptos是分配给任务的堆栈的栈顶指针(参看任务堆栈)，prio是分配给任务的优先级。程序清单OSTaskCreate()INT8U OSTaskCreate (void(*task)(void *pd),void *pdata,OS_STK *ptos，INT8U prio)void *psp;INT8U err;if (prio>OS_LOWEST_PRIO)(1)return (OS_PRIO_INVALID);OS_ENTER_CRITICAL();if (OSTCBPrioTblprio=(OS_TCB*)0)/在规定的优先级上还没有建立任务(2)OSTCBPrioTblprio=(OS_TCB*)1;(3)OS_EXIT_CRITICAL();(4)PsP=(void*)OSTaskStkInit(task,pdata,ptos,0);(5)Err=OSTCBInit(prio,psp,(void *)0,0,0,(void*)0,0);(6)if(err=OS_NO_ERR)(7)OS_ENTER_CRITICAL();OSTaskCtr+;(8)OSTaskCreateHook(OSTCBPrioTblprio);(9)OS_EXIT_CRITICAL();if(OSRunning)(10)OSSChed();(11)elseOS_ENTER_CRITICAL();OSTCBPrioTblprio=(OS_TCB*)0;(12)OS_EXIT_CRITICAL();return(err);elseOS_EXIT_CRITICAL();return (OS_PRIO_EXIST);OSTaskCreate()一开始先检测分配给任务的优先级是否有效，任务的优先级必须在0到OS_LOWEST_PRIO之间，并且在规定的优先级上还没有建立任务。在使用uCOS-II时，每个任务都有特定的优先级。如果某个优先级是空闲的，uCOS-II通过放置一个非空指针在OSTCBPrioTbl中来保留该优先级，这就使得OSTaskCreate()在设置任务数据结构的其他部分时能重新允许中断9。然后，OSTaskCreate()调用OSTaskStkInit()建立任务的堆栈。该函数是与处理器的硬件体系相关的函数。OSTaskStkInit()函数返回新的堆栈栈顶，并被保存在任务的OS_TCB中。注意用户得将传递给OSTaskStkInit()函数的第四个参数opt置0，因为OSTaskCreate()不支持任务的创建过程设置不同的选项，所以没有任何选项可以通过opt参数传递给OSTaskStkInit()。uCOS-II支持的处理器的堆栈既可以从上(高地址)往下(低地址)递减也可以从下往上递增。用户在调用OSTaskCreate()的时候必须知道堆栈是递增的还是递减的，因为用户必须得把堆栈的栈顶传递给OSTaskCreate(),而栈顶可能是堆栈的最高地址(堆栈从上往下递减)，也可能是最低地址。一旦OSTaskStkInit()函数完成了建立堆栈的任务，OSTaskCreate()就调用OSTCBInit()，从空闲的OS_TCB池中获得并初始化一个OS_TCB。如果成功返回，OSTaskCreate()就增加OSTaskCtr(产生的任务数目)。如果OSTCBInit()返回失败，就置OSTCBPrioTblprio的入口为0以放弃该任务。然后，OSTaskCreate()调用用户自己定义的函数OSTaskCreateHook(),用来扩展OSTaskCreate()的功能。OSTaskCreateHook()既可以在OS_CPU_C.C中定义(如果OS_CPU_HOOKS_EN置1)，也可以在其它地方定义。在调用OSTaskCreateHook()时，中断是关掉的，所以应该使函数中的代码尽量简化，因为这将直接影响中断的响应时间。如果OSTaskCreate()函数是在某个任务的执行过程中被调用则任务调度函数会被调用来判断是否新建立的任务比原来的任务有更高的优先级。如果新任务的优先级更高，内核会进行一次从旧任务到新任务的任务切换。如果在多任务调度开始之前，新任务就己经建立了，则任务调度函数不会被调用。3.1.2 任务堆栈每个任务都有自己的堆栈空间。堆栈必须声明为OS_STK类型，并且由连续的内存空间组成。用户可以静态分配堆栈空间(编译时分配)也可以动态地分配堆栈空间(运行时分配)。静态堆栈声明如下，这两种声明应放置在函数的外面。static OS_STK MyTaskStackstack_size;或OS_STK MyTaskStackstack_size;用户可以用C编译器提供的malloc()函数来动态地分配堆栈空间。在动态分配中，要时刻注意内存碎片问题。特别是当反复地建立和删除任务时，内存堆中可能会出现大量的内存碎片，导致没有足够大的一块连续内存区域可用作任务堆栈。必须把堆栈的栈顶传递给以上两个函数，当OS_CPU.H文件中的OS_STK_GROWTH置为0时，用户需要将堆栈的最低内存地址传递给任务创建函数。当OS_CPU.H文件中的OS_STK_GROWTH置为1时，用户需要将堆栈的最高内存地址传递给任务创建函数。这个问题会影响代码的可移植性。如果用户想将代码从支持往下递减堆栈的处理器中移植到支持往上递增堆栈的处理器中的话，用户得使代码同时适应以上两种情况。3.1.3 堆栈检验有时候决定任务实际所需的堆栈空间大小是必要的，这样用户就可以避免为任务分配过多的堆栈空间，减少应用程序代码所需的RAM数量。uCOS-II提供的OSTaskStkChk()函数可以提供这种信息。在图3-1中，假定堆栈是从上往下递减的(即OS_STK_GROWTH被置为1)uCOS-II是通过查看堆栈本身的内容来决定堆栈的方向的。只有内核或是任务发出堆栈检验的命令时，堆栈检验才会被执行，它不会自动检验任务的堆栈使用情况。在堆栈检验时，uCOS-II要求在任务建立的时候堆栈中存储的必须是0值(即堆栈被清零)。另外，uCOS-II还需要知道堆栈栈底(BOS)的位置和分配给任务的堆栈的大小。在任务建立的时候，这两个值储存在任务的OS_TCB中。为了使用uCOS-II的堆栈检验功能，用户必须要做以下几件事情：1、在OS_CFG.H文件中设OS_TASK_CREATE_EXT为1。2、用OSTaskCreateExt()建立任务，并给予任务比实际需要更多的内存空间。3、在OSTaskCreateExt()中，设置检验选项。4、将要验的任务的优先级作为OSTaskStkChk()的参数并调用。图3-1 堆栈检验OSTaskStkChk()顺着堆栈的栈底开始计算空闲的堆栈空间大小，具体实现方法是统计储存值为0的连续堆栈入口的数目，直到发现储存值不为0的堆栈入口。如果堆栈的入口有32位宽，对0值的比较也是按32位完成的。所用的堆栈的空间大小是指从用户在OSTaskCreateExt()中定义的堆栈大小中减去了储存值为0的连续堆栈入口以后的大小。用户应该使自己的应用程序运行足够长的时间，并且经历最坏的堆栈使用情况，这样才能得到正确的数。一旦OSTaskStkChk()提供给用户最坏情况下堆栈的需求，用户就可以重新设置堆栈的最后容量了。3.1.4 删除任务删除任务，是说任务将返回并处于休眠状态，不再被uCOS-II调用。通过调用OSTaskDel()就可以完成删除任务的功能。OSTaskDel()一开始应确保用户所要删除的任务并非是空闲任务，因为删除空闲任务是不允许的。OSTaskDel()不允许R例程中去删除一个任务。调用此函数的任务可以通过指定OS_PRIO_SELF参数来删除自己。接下来OSTaskDel()会保证被删除的任务是确实存在的。一旦所有条件都满足了，OS_TCB就会从所有可能的uCOS-II的数据结构中移除。OSTaskDel()分两步完成该移除任务以减少中断响应时间。首先，如果任务处于就绪表中，它会直接被移除。如果任务处于邮箱、消息队列或信号量的等待表中，它就从表中被移除。接着，OSTaskDel()将任务的时钟延迟数清零，以确保ISR例程不会使该任务就绪。最后，置任务的OSTCBStat标志为OS_STAT_RDY。 OSTaskDel()并不是试图使任务处于就绪状态，而是阻止其它任务或ISR例程让该任务重新开始执行。因为OSTaskDel()会重新打开中断，而ISR可让更高优先级的任务处于就绪状态，这可能会使用户想删除的任务重新开始。要被删除的任务不会被其它的任务或ISR置于就绪状态，它不是在等待事件的发生，也不是在等待延时期满，不能重新被执行。为了达到删除任务的目的，任务被置于休眠状态。正因为这样，OSTaskDel()必须阻止任务调度程序在删除过程中切换到其它的任务中去，因为如果当前的任务正在被删除，它不可能被再次调度!接下来，OSTaskDel()重新允许中断以减少中断的响应时间。这样，OSTaskDel()就能处理中断服务，但由于它增加了OSLockNesting, ISR执行完后会返回到被中断任务，从而继续任务的删除工作。在OSTaskDel()重新关中断后，它通过OSLockNesting减一以重新允许任务调度。接着，OSTaskDel()调用用户自定义的OSTaskDelHook()函数，用户可以在这里删除或释放自定义的TCB附加数据域。然后，OSTaskDel()减少uCOS-II的任务计数器。OSTaskDel()简单地将指向被删除的任务的OS_TCB的指针指向并从优先级表中移除。再接着，OSTaskDel()将被删除的任务的OS_TCB从OS_TCB双向链表中移除。接下来，OS_TCB返回到空