一步一步教你利用uCOSII.docx
《一步一步教你利用uCOSII.docx》由会员分享，可在线阅读，更多相关《一步一步教你利用uCOSII.docx（15页珍藏版）》请在冰豆网上搜索。
一步一步教你利用uCOSII
第一篇UCOS介绍第一篇UCOS介绍这个大家都知道。
呵呵。
考虑到咱们学习的完整性还是在这里唠叨一下。
让大家再熟悉一下。
高手们忍耐一下吧！
uC/OSII（MicroControlOperationSystemTwo）是一个可以基于ROM运行的、可裁减的、抢占式、实时多任务内核，具有高度可移植性，特别适合于微处理器和控制器，是和很多商业操作系统性能相当的实时操作系统（RTOS）。
为了提供最好的移植性能，uC/OSII最大程度上使用ANSIC语言进行开发，并且已经移植到近40多种处理器体系上，涵盖了从8位到64位各种CPU（包括DSP）。
uC/OSII可以简单的视为一个多任务调度器，在这个任务调度器之上完善并添加了和多任务操作系统相关的系统服务，如信号量、邮箱等。
其主要特点有公开源代码，代码结构清晰、明了，注释详尽，组织有条理，可移植性好，可裁剪，可固化。
内核属于抢占式，最多可以管理60个任务。
μC/OS-II的前身是μC/OS，最早出自于1992年美国嵌入式系统专家Jean在《嵌入式系统编程》杂志的5月和6月刊上刊登的文章连载，并把μC/OS的源码发布在该杂志的BBS上。
μC/OS和μC/OS-II是专门为计算机的嵌入式应用设计的，绝大部分代码是用C语言编写的。
CPU硬件相关部分是用汇编语言编写的、总量约200行的汇编语言部分被压缩到最低限度，为的是便于移植到任何一种其它的CPU上。
用户只要有标准的ANSI的C交叉编译器，有汇编器、连接器等软件工具，就可以将μC/OS-II嵌人到开发的产品中。
μC/OS-II具有执行效率高、占用空间小、实时性能优良和可扩展性强等特点，最小内核可编译至2KB。
μC/OS-II已经移植到了几乎所有知名的CPU上。
严格地说uC/OS-II只是一个实时操作系统内核，它仅仅包含了任务调度，任务管理，时间管理，内存管理和任务间的通信和同步等基本功能。
没有提供输入输出管理，文件系统，网络等额外的服务。
但由于uC/OS-II良好的可扩展性和源码开放，这些非必须的功能完全可以由用户自己根据需要分别实现。
uC/OS-II目标是实现一个基于优先级调度的抢占式的实时内核，并在这个内核之上提供最基本的系统服务，如信号量，邮箱，消息队列，内存管理，中断管理等。
uC/OS-II以源代码的形式发布，但并不意味着它是开源软件。
你可以将其用于教学和私下研究（peacefulresearch）；但是如果你将其用于商业用途，那么你必须通过Micrium获得商用许可。
虽然uCOS-II在商业上使用时需要的得到授权并且费用也是一笔不小的数字，但是他的开源毕竟带领我们走入了内核的世界。
在此我代表嵌入式工程师向MrJean致谢。
任务治理uC/OS-II中最多能够支持64个任务，别离对应优先级0～63，其中0为最高优先级。
63为最低级，系统保留了4个最高优先级的任务和4个最低优先级的任务，所有效户能够利用的任务数有56个。
uC/OS-II提供了任务管理的各种函数调用，包括创建任务，删除任务，改变任务的优先级，任务挂起和恢复等。
系统初始化时会自动产生两个任务：
一个是空闲任务，它的优先级最低，该任务仅给一个整形变量做累加运算；另一个是系统任务，它的优先级为次低，该任务负责统计当前cpu的利用率。
在系统初始化完毕后启动任务时必须创建一份用户任务，也就是说必须有一个应用程序（用户任务，使用应用程序对于我们经常使用Windows用户容易接受一些。
呵呵），否则系统会崩溃。
当然还有一些其他的要求，咱们后续再说，下面简要概述一下任务管理相关的函数1：
成立任务OSTaskCreat（）/OSTaskCreatExt（）若是想让UCOS治理用户的任务，必需先成立任务。
能够通过将任务的地址和其他参数传递到以下两个函数之一来成立任务。
当挪用OSTaskCreat（）时，需要四个参数：
OSTaskCreate（void（*task）（void*pd）,void*pdata,OS_STK*ptos,INTUprio）Task：
是指向任务代码的指针，pdata：
是任务开始执行是，传递给任务的参数的指针，ptos：
是分派给任务的堆栈的栈顶指针，prio是分派给任务的优先级。
也能够用OSTaskCreatExt（），只是该函数需要9个参数，前四个参数与OSTaskCreat（）一样，例如：
INT8UOSTaskCreateExt（void（*task）（void*pd）,void*pdata,OS_STK*ptos,INT8Uprio,INT16U id,OS_STK *pbos,OS_STK *pbos,OS_STK *pbos,INT16U opt）id参数为要成立的任务创建一个特殊的标识符。
pbos是指向任务的堆栈栈底的指针，用于堆栈的查验。
stk _size用于指定堆栈成员数量的容量。
pext是指向用户附加的数据域的指针，用来扩展任务的OS_TCB。
opt用于设定OSTaskCreateExt（）的选项，指定是不是许诺堆栈查验，是不是将堆栈清零，任务是不是要进行浮点操作等等。
2：
任务堆栈OS_STK（）每一个任务都有自己的堆栈，堆栈必需申明为OS_STK类型，而且由持续的内存空间组成。
能够静态分派堆栈空间，也能够动态分派堆栈空间。
3：
堆栈查验OSTaskStkChk（）有时确信任务实际需要的堆栈空间的大小是很有必要的，因为如此就能够够幸免为任务分派过量的堆栈空间，从而减少应用程序代码所需的RAM空间。
4：
删除任务OSTaskDel（）有时需要删除任务，删除任务，是说任务返回并处于休眠态，并非是说任务的代码被删除，只是任务的代码再也不被UCOS挪用。
删除任务前应保证所删任务并非空闲任务。
5：
请求删除任务OSTaskDelReq（）有时，任务会占用一些内存缓冲或信号量一类的资源。
这时，假设另一个任务试图删除该任务，这些被占用的资源就会因为没有被释放而丢失。
在这种情形下，需想方法拥有这些资源的任务在利用完资源后先释放资源，再删除自己。
6：
改变任务的优先级OSTaskChangePrio（）在成立任务时，会分派给任务一个优先级。
在程序运行期间，能够通过挪用该函数改变任务的优先级。
也确实是说，UCOS许诺动态的改变任务的优先级。
7：
挂起任务OSTaskSuspend（）任务挂起是一个附加功能，也确实是说，若是任务在被挂起的同时也在等待延迟时刻到，那么，需要对任务做取消挂起的操作，而且等待延迟时刻到，任务才能转让就绪状态。
任务能够挂起自己或其他任务。
8：
恢复任务OSTaskResume（）挂起的任务只有通过该函数才能被恢复。
9：
取得任务的信息OSTaskQuery（）通过挪用该函数，来取得自身或其他应用任务的信息
时刻治理uC/OS-II的时刻治理是通过按时中断来实现的，该按时中断一样为10毫秒或100毫秒发生一次（那个时刻片段是OS的作者推荐的，大伙儿能够参考邵贝贝翻译的《嵌入式实时操作系统ucos-II》这本书），时刻频率取决于用户对硬件系统的按时器编程来实现。
中断发生的时刻距离是固定不变的，该中断也成为一个时钟节拍。
那个地址隐含的意思确实是你选择的芯片若是想利用UCOS系统，前提条件必然要有一个Timer。
uC/OS-II要求用户在定时中断的服务程序中，挪用系统提供的与时钟节拍相关的系统函数，例如中断级的任务切换函数，系统时刻函数。
uCOS时刻治理的相关函数1：
任务延迟函数OSTimeDly（）Ucos提供一个可以被任务调用而将任务延时一段特定时间的功能函数，即OSTimeDly（）.任务调用OSTimeDly（）后，一旦规定的时刻期满或有其他的任务通过挪用OSTimeDlyResume（）取消了延时，他就会进入就绪状态。
只有当该任务在所有就绪态任务中具有最高的优先级，它才会当即运行。
2：
按时，分，秒延时函数OSRimeDLyHMSM（）与OSTimeDly（）一样，调用OSRimeDlyHMSM（）函数也会是UCOS进行一次任务调度，并且执行下一个优先级最高的就绪任务。
当OSTimeDlyHMSM（）后，一旦规定的时间期满，或者有OSTimeDlyResume（），它就会马上处于就绪态。
同样，只有当该任务在所有就绪态任务中具有最高的优先级，他才开始运行。
3：
恢复延时的任务OSTimeDlyResume（）延时的任务可以不等待延时的期满，而是通过其他任务取消延时而使自己处于就绪态，可以通过该函数来实现，实际上，OSTimeDlyResume（）也能够唤醒正在等待的事件。
4：
系统时刻OSTimeGet（）和OSTimeSet（）
内存治理在ANSIC中是利用malloc和free两个函数来动态分派和释放内存。
例如在Linux系统中确实是如此。
但在嵌入式实时系统中，多次如此的操作会致使内存碎片，因为嵌入式系统尤其是uCOS是实地址模式，这种模式在分派任务堆栈时需要整块持续的空间，不然任务无法正确运行。
且由于内存治理算法的缘故，malloc和free的执行时刻也是不确信。
这点是实时内核最大的矛盾。
基于以上的原因uC/OS-II中把持续的大块内存按分区治理。
每一个分区中包括整数个大小相同的内存块，但不同分区之间的内存快大小能够不同。
用户需要动态分派内存时，系统选择一个适当的分区，按块来分派内存。
释放内存时将该块放回它以前所属的分区，如此能有效解决碎片问题，同时执行时刻也是固定的。
同时uCOS-II根据以上的处理封装了适合于自己的动态内存分配函数OSMemGet（）和OSMemPut（），但是使用这两个函数动态分配内存前需要先创建内存空间，也就是第二段咱们介绍的内存分块。
呵呵，不罗嗦了，具体的关于内存管理的函数如下：
内存控制块的数据结构Typedefstruct{
void *osmemaddr ;指向内存分区起始地址的指针。
Void *osmemfreelist ;指向下一个空余内存控制块或者下一个空余内存块的指针，Int32u osmemblksize ;内存分区中内存块的大小，是建立内存分区时定义的。
Int32uosmemnblks ;内存分区中总的内存块数量，也是建立该内存分区时定义的。
Int32u osmemnfree ;内存分区块中当前获得的空余块数量。
}os_mem;1；建立一个内存分区，OSMemCreate（）2：
分配一个内存块，OSMemGet（）应用程序通过调用该函数，从已经建立的内存分区中申请一个内存块。
该函数唯一的参数是指向特定内存分区的指针。
3：
释放一个内存块，OSMemPut（）当应用程序不再使用一个内存块时，必须及时的把它释放，并放回到相应的内存分区中，这个操作就是通过调用该函数实现的。
4：
查询一个内存分区的状态，OSQMemQuery（）。
任务间通信与同步对一个多任务的操作系统来讲，任务间的通信和同步是必不可少的。
uC/OS-II中提供了4种同步对象，别离是信号量，邮箱，消息队列和事件。
所有这些同步对象都有创建，等待，发送，查询的接口用于实现进程间的通信和同步。
对于这4种同步对象将在后面一一讨论。
任务调度uC/OS-II采用的是可剥夺型实时多任务内核。
可剥夺型的实时内核在任何时候都运行就绪了的最高优先级的任务。
uC/os-II的任务调度是完全基于任务优先级的抢占式调度，也就是最高优先级的任务一旦处于就绪状态，则立即抢占正在运行的低优先级任务的处理器资源。
为了简化系统设计，uC/OS-II规定所有任务的优先级不同，因为任务的优先级也同时唯一标志了该任务本身。
UCOS的任务调度在一下情况下发生：
1）高优先级的任务因为需要某种临界资源，主动请求挂起，让出处理器，此时将调度就绪状态的低优先级任务获得执行，这种调度也称为任务级的上下文切换。
2）高优先级的任务因为时钟节拍到来，在时钟中断的处理程序中，内核发现高优先级任务获得了执行条件（如休眠的时钟到时），则在中断态直接切换到高优先级任务执行。
这种调度也称为中断级的上下文切换。
这两种调度方式在uC/OS-II的执行过程中非常普遍，一般来说前者发生在系统服务中，后者发生在时钟中断的服务程序中。
调度工作的内容可以分为两部分：
最高优先级任务的寻找和任务切换。
其最高优先级任务的寻找是通过建立就绪任务表来实现的。
uC/OS中的每一个任务都有独立的堆栈空间，并有一个称为任务控制块TCB（TaskControlBlock）的数据结构，其中第一个成员变量就是保存的任务堆栈指针。
任务调度模块首先用变量OSTCBHighRdy记录当前最高级就绪任务的TCB地址，然后调用OS_TASK_SW（）函数来进行任务切换。
第二章搭建UCOS-II版的调试平台在这一章中咱们要紧讨论UCOSII的源码调试环境，为了给大伙儿一个一起的学习平台，我搜集整理了一写资料，确实是以X86为平台，利用BC31（那个可谓骨灰级的编译器）来调试UCOSII源码。
固然你也能够用BC45或更高版本的编译器，具体方式大同小异，我在此就再也不啰嗦。
本章节的主要内容包括四点：
1、下载并安装BC31编译器2、下载并安装版本源代码3、使用BC31编译UCOS-II源码4、让OS的第一个任务RUN起来
本部份内容设定了隐藏,需要答复后才能看到
让自己的第一个任务Run起来前面已经给大伙儿介绍了如安在PC机上调试UCOS，方式和需要的软件都介绍给大伙儿了，相信有爱好的朋友已经安装调试了，下面咱们就让自己的第一个任务在PC上Run起来。
OK，下面我就分步介绍建立自己的第一个任务第一步：
CopyC:
\SOFTWARE\uCOS-II目录下的EX1_x86L文件夹。
作为咱们的工程模板第二步：
修改工程模板的名字为：
HelloEEWorld第三部：
按照咱们前面的《使用BC31工具编译UCOS‐II的源码进程 》修改配置文件；第四步：
修改文件，建立自己的第一个任务具体的内容我就不再帖子上写了。
大家可以参考附件里面的文件。
然后编译OK，第一个任务就Run起来了，显示如下界面
（48K）下载次数:
3关于UCOS任务的明白得UCOS的运行是基于任务运行的，为了能够好的利用UCOS咱们先要对UCOS的任务的概念做一个明白得在学习ＵＣＯＳ任务前我们先对我们以前使用的模式做一个回顾－－前后台模式。
这种系统可称为前后台系统或超循环系统（Super-Loops）。
应用程序是一个无穷的循环，循环中挪用相应的函数完成相应的操作，这部份能够看成后台行为（background）。
中断效劳程序处置异步事件，这部份能够看成前台行foreground。
后台也能够叫做任务级。
前台也叫中断级。
时刻相关性很强的关键操作（Criticaloperation）必然是靠中断效劳来保证的。
因为中断效劳提供的信息一直要等到后台程序走到该处置那个信息这一步时才能得处处置，这种系统在处置信息的及时性上，比实际能够做到的要差。
那个指标称作任务级响应时刻。
最坏情形下的任务级响应时刻取决于整个循环的执行时刻。
因为循环的执行时刻不是常数，程序通过某一特定部份的准确时刻也是不能确信的。
进而，若是程序修改了，循环的时序也会受到阻碍。
这种系统是在我们上学时和做小项目时经常用到，很多工程师称这种方式为“裸奔”。
哈哈！
我大学毕业后的钱三年写的项目都是在裸奔。
UCOS-II是基于任务运行的。
一个任务，也称作一个线程，是一个简单的程序，该程序可以认为CPU完全只属该程序自己。
实时应用程序的设计过程，包括如何把问题分割成多个任务，每个任务都是整个应用的某一部分，每个任务被赋予一定的优先级，有它自己的一套CPU寄存器和自己的栈空间（如下图所示）。
能够这么明白得，UCOS-II的每一个任务都有一个CPU，任务在运行时占用CPU的全数资源，同时拥有自己的一套寄放器，当任务执行完毕后（时刻片到），他把自己的CPU寄放器所有内容保留到自己的堆栈中，同时把CPU让给别的任务，那么取得CPU利用权的任务把自己的CPU寄放器从自己的堆栈中放到真正的CPU寄放器中开始运行，就如此周而复始。
大家一定不要把任务的运行当成是函数的调用，这完全是两回事。
这个我们到后面的任务调度时在细说。
每个任务都是一个无限的循环。
每个任务都处在以下5种状态之一的状态下，这5种状态是休眠态，就绪态、运行态、挂起态（等待某一事件发生）和被中断态（参见下图） 休眠态相当于该任务驻留在内存中，但并不被多任务内核所调度。
就绪意味着该任务已经准备好，可以运行了，但由于该任务的优先级比正在运行的任务的优先级低，还暂时不能运行。
运行态的任务是指该任务掌握了CPU的控制权，正在运行中。
挂起状态也可以叫做等待事件态WAITING，指该任务在等待，等待某一事件的发生，（例如等待某外设的I/O操作，等待某共享资源由暂不能使用变成能使用状态，等待定时脉冲的到来或等待超时信号的到来以结束目前的等待，等等）。
最后，发生中断时，CPU提供相应的中断服务，原来正在运行的任务暂不能运行，就进入了被中断状态。
如下图表示μC/OS-Ⅱ中一些函数提供的效劳，这些函数使任务从一种状态变到另一种状态。
简单的咱们能够把每一次任务的切换当做一次中断，那个中断不同于咱们在利用前后台模式时的中断，那个中断是硬件中断，中断时需要保留的CPU寄放器是由硬件实现的，而在UCOS中的任务切换是软中断，CPU保留了必要的寄放器后在切换时系统会在保留任务利用的寄放器。
补充知识-可剥夺型内核和不可剥夺型内核不可剥夺型内核不可剥夺型内核要求每个任务自我放弃CPU的所有权。
不可剥夺型调度法也称作合作型多任务，各个任务彼此合作共享一个CPU。
异步事件还是由中断服务来处理。
中断服务可以使一个高优先级的任务由挂起状态变为就绪状态。
但中断服务以后控制权还是回到原来被中断了的那个任务，直到该任务主动放弃CPU的使用权时，那个高优先级的任务才能获得CPU的使用权。
不可剥夺型内核允许每个任务运行，直到该任务自愿放弃CPU的控制权。
中断可以打入运行着的任务。
中断服务完成以后将CPU控制权还给被中断了的任务。
任务级响应时间要大大好于前后系统，但仍是不可知的，商业软件几乎没有不可剥夺型内核。
不可剥夺型内核的工作过程见下图：
可剥夺型内核 当系统响应时间很重要时，要使用可剥夺型内核。
因此，μC/OS-Ⅱ和绝大多数商业上销售的实时内核都是可剥夺型内核。
最高优先级的任务一旦就绪，总能取得CPU的操纵权。
当一个运行着的任务使一个比它优先级高的任务进入了就绪态，当前任务的CPU利用权就被剥夺了，或说被挂起了，那个高优先级的任务立刻取得了CPU的操纵权。
若是是中断效劳子程序使一个高优先级的任务进入就绪态，中断完成时，中断了的任务被挂起，优先级高的那个任务开始运行。
利用可剥夺型内核，最高优先级的任务何时能够执行，能够取得CPU的操纵权是可知的。
利用可剥夺型内核使得任务级响应时刻得以最优化。
可剥夺型内核的工作过程是这样的：
UCOS-II任务调度任务调度是内核的主要职责之一，就是要决定该轮到哪个任务运行了。
多数实时内核是基于优先级调度法的，UCOS也不例外。
每个任务根据其重要程度的不同被赋予一定的优先级。
基于优先级的调度法指，CPU总是让处在就绪态的优先级最高的任务先运行。
然而，究竟何时让高优先级任务掌握CPU的使用权，有两种不同的情况，这要看用的是什么类型的内核，是不可剥夺型的还是可剥夺型内核。
上一次咱们已经介绍了可剥夺型内核和不可剥夺型内核的工作过程了。
在此不再赘述！
当多任务内核决定运行另外的任务时，它保存正在运行任务的当前状态，即CPU寄存器中的全部内容。
这些内容保存在任务的当前状况保存区，也就是任务自己的栈区之中，上一次讨论的内容中有这个图示。
入栈工作完成以后，就是把下一个将要运行的任务的当前状况从该任务的栈中重新装入CPU的寄存器，并开始下一个任务的运行。
这个过程叫做任务切换。
任务切换过程增加了应用程序的额外负荷。
CPU的内部寄存器越多，额外负荷就越重。
做任务切换所需要的时间取决于CPU有多少寄存器要入栈。
实时内核的性能不应该以每秒钟能做多少次任务切换来评价。
而是要看OS总的关中断时间。
总的关中断时间越短说明这个内核的实时性越好。
这个问题在前面一个坛友的问题中我做了详细的描述，有兴趣的朋友可以在UCOS这个版块找找这个帖子。
任务调度的算法有很多种。
一种是基于优先级的。
一种是基于时间片的。
这两种算法在邵贝贝教授翻译的《UCOS-II内核详解》这本书中有详细解释。
我就不再重复。
如果坛子里有朋友对此有什么不明白。
可以在这里留言。
咱们再讨论。
UCOS-II的文件结构前面咱们对UCOS的基础知识做了了解，其中有些地址由于邵贝贝翻译的树上讲解的很少我就没有班门弄斧，大伙儿能够结合那本书来看。
有问题或不明白的在那个地址讨论，欢迎大伙儿剔除问题。
这次我们主要了解UCOS-II的文件结构。
等对UCOS文件结构了解以后，我们就逐一的去讲解其各章的重点和难点，达到在短时间内学会使用UCOS。
咱们利用这张图片把UCOS的内部做一个解剖，咱们能够清楚的看到UCOS内核的结构及层次，在那个图的最下面是咱们利用的硬件，确实是咱们的移植平台，比如STM32F103XX系列的最小系统版、51最小系统版。
呵呵，我本人感觉把UCOS移植到51上的意义不大。
只是学习能够，利用我就不建议了！
从图中咱们能够明白，要想移植UCOS你的硬件平台必需具有一个按时器，也确实是上图中的TIMER。
那个TIMER是用来给UCOS提供时钟节拍的，相当于咱们人的心跳。
若是没有那个TIMER，通通就无法运行。
再往上就是软件了，软件的第一层是我们移植的重点，这三个文件内主要包括一些与处理器相关的代码，在后面我们我们再讲解移植过程的时候会详细的讨论到这三个文件。
在往上左侧就是系统内核源码的各个文件。
有兴趣的坛友可以参考邵贝贝教授翻译的书进行深入学习，由于我在这里的主要任务是告诉大家如何使用UCOS，故不再过多的讲解源码部分，只是告诉大家如何使用即可。
当然，如果你在研究过程中遇到问题可以拿出来和大家共同讨论，右侧是系统的配置文件，相对比较简单，主要涉及到一些功能的裁剪。
最上层是我们的应用软件，相当于我们在电脑上使用的Office软件等，当然这里是你自己的任务代码。
UCOS的任务及状态任务的资源要紧包括以下几部份，ECB操纵块、任务堆栈、任务代码及与CPU共用的寄放器和CPU的利用权
这是一个讲解任务的详细资料，提供给大伙儿参考
（787K）下载次数:
1
关于UCOS信号量一：
信号量的明白得：
（1）信号量可以分为两种：
一种是二值信号量（0和1），一种是N值信号量（计数式信号量）。
二值信号量的意思是可以有多少任务同时享用这个信号量。
比如二值信号，就是只有1个任务可以使用。
当有一个任务使用该信号量的时候，那么其他需要使用该信号量的任务就必须等待，直到该任务释放该信号量。
这种信号量可以看作一把钥匙。
对于N值信号量（计数式信号量），就是说可以同时有N-1个任务同时使用该信号量。
对于二值信号量，N=1。
（2）建立信号量的工作必须在任务级代码中或者多任务启动之前完成。
二：
任务如何得到信号量的问题：
想得到信号量的任务，必须执行等待操作（pend）。
在信号量的建立的时候，我们首先确定了该信号量可以被共享的资源数（N），并将其赋值给pevent->OSEventCnt。
如果信号量有效（非0），即pevent->OSEventCnt>0，则信号量减1，任务得以继续运行。
如果信号量无效，即pevent->OSEventCnt==0，则等待信号量的任务就被列入等待信号量的任务表中。
许多内核允许定义等待超时，当等待时间超过了设定值，该信号量还是无效，则等待该信号量的任务进入就绪态，准备运行，并返回出错代码（等待超时错误）。
三：
任务对信号量的释放问题：
任务执行发信
升级会员 