uC/OS-II初级程序员指南

uC/OS-II初级程序员指南　　（一）uC/OS-II概述　　uC/OS-II是一种基于优先级的可先行的硬动态内核。自从９２年公布以来，在世界各地都取得了普遍的应用于，它是一种专门为嵌入式设备设计的内核，目前早已被重制到４０多种不同结构的CPU上，运营在从８位到６４位的各种系统之上。特别是在值得一提的是，该系统自从２.51版本之后，就通过了美国FAA证书，可以运营在诸如航天器等对安全性拒绝十分严苛的系统之上。

鉴于uC/OS-II可以免费取得代码，对于嵌入式RTOS而言，自由选择uC/OS毫无疑问是最经济的自由选择。　　（二）uC/OS-II　应用程序基本结构　　应用于uC/OS-II，大自然要为它研发应用程序，下面阐述基于uC/OS-II的应用程序的基本结构以及注意事项。

　　每一个uC/OS-II应用于最少要有一个任务。而每一个任务必需被写无限循环的形式。

以下是引荐的结构：　　voidtask（void*pdata）　　{　　INT8Uerr;　　InitTimer（）;//可选　　For（;;）　　{　　//你的应用于程序代码　　。　　。.　　OSTimeDly（1）;//可选　　}　　}　　以上就是基本结构，至于为什么要写无限循环的形式呢？那是因为系统不会为每一个任务保有一个堆栈空间，由系统在任务转换的时候换完全恢复上下文，并继续执行一条reti指令回到。

如果容许任务继续执行到最后一个花上括号（那一般都意味著一条ret指令）的话，很可能会毁坏系统堆栈空间从而使应用程序的继续执行不确认。换句话说，就是跑完飞来了。所以，每一个任务必需被写无限循环的形式。程序员一定要坚信，自己的任务是不会退出CPU使用权的，而不管是系统强迫（通过ISR）还是主动退出（通过调用OSAPI）。

　　现在来谈论上面程序中的InitTimer（）函数，这个函数应当由系统获取，程序员有义务在优先级最低的任务内调用它而且无法在for循环内调用。留意，这个函数是和所用于的CPU涉及的，每种系统都有自己的Timer初始化程序。在uC/OS-II的协助手册内，作者特地特别强调意味著无法在OSInit（）或者OSStart（）内调用Timer初始化程序，那不会毁坏系统的可移植性同时带给性能上的损失。

所以，一个折衷的办法就是象上面这样，在优先级最低的程序内调用，这样可以确保当OSStart（）调用系统内部函数OSStartHighRdy（）开始多任务后，首先继续执行的就是Timer初始化程序。或者专门进一个优先级最低的任务，只做到一件事情，那就是继续执行Timer初始化，之后通过调用OSTaskSuspend（）将自己悬挂一起，总有一天仍然继续执行。不过这样不会浪费一个TCB空间。

对于那些RAM严重不足的系统来说，还是不必为好。　　（三）一些最重要的uC/OS-IIAPI讲解　　任何一个操作系统都会获取大量的API供程序员用于，uC/OS-II也不值得注意。由于uC/OS-II面向的是嵌入式研发，并不拒绝大而全，所以内核获取的API也就大多和多任务息息相关。

主要的有以下几类：　　１）任务类　　２）消息类　　３）实时类　　４）时间类　　５）临界区与事件类　　我个人指出对于初级程序员而言，任务类和时间类是必需要首先掌控的两种类型的API。下面我就来讲解较为最重要的：　　１）OSTaskCreate函数　　这个函数应当最少再行main函数内调用一次，在OSInit函数调用之后调用。起到就是创立一个任务。

目前有四个参数，分别是任务的入口地址，任务的参数，任务堆栈的首地址和任务的优先级。调用本函数后，系统不会首先从TCB空闲列表内申请人一个机的TCB指针，然后将不会根据用户得出参数初始化任务堆栈，并在内部的任务准备就绪表内标记该任务为准备就绪状态。

最后回到，这样一个任务就创立顺利了。　　２）OSTaskSuspend函数　　这个函数很非常简单，一看名字就该明白它的起到，它可以将登录的任务悬挂起。如果悬挂的是当前任务的话，那么还不会引起系统继续执行任务转换先导函数OSShed来展开一次任务转换。

这个函数只有一个参数，那就是登录任务的优先级。那为什么是优先级呢？事实上在系统内部，优先级除了回应一个任务继续执行的先后次序外，还起着分别每一个任务的起到，换句话说，优先级也就是任务的ID。

所以uC/OS-II不容许经常出现完全相同优先级的任务。　　３）OSTaskResume函数　　这个函数和上面的函数正好忽略，它用作将登录的早已悬挂的函数完全恢复成准备就绪状态。

如果完全恢复任务的优先级低于当前任务，那么还为引起一次任务转换。其参数类似于OSTaskSuspend函数，为登录任务的优先级。必须尤其解释是，本函数并不拒绝和OSTaskSuspend函数成对用于。　　４）OS_ENTER_CRITICAL宏　　很多人都以为它是个函数，其实不然，仔细分析一下OS_CPU.H文件，它和下面立刻要谈及的OS_EXIT_CRITICAL都是宏。

他们都是牵涉到特定CPU的构建。一般都被更换为一条或者几条嵌入式编撰代码。

由于系统期望向上层程序员隐蔽内部构建，故而一般都声称继续执行此条指令后系统转入临界区。只不过，它就是关口个中断而已。

这样，只要任务不主动退出CPU使用权，别的任务就没闲置CPU的机会了，比较这个任务而言，它就是独霸了。所以说道转入临界区了。这个宏能少用还是较少用，因为它不会毁坏系统的一些服务，特别是在是时间服务。

并使系统对外界号召性能减少。　　５）OS_EXIT_CRITICAL宏　　这个是和上面讲解的宏设施用于另一个宏，它在系统手册里的解释是解散临界区。

只不过它就是新的进中断。必须留意的是，它必需和上面的宏成对经常出现，否则不会带给意想不到的后果。

最坏的情况下，系统不会瓦解。我们引荐程序员们尽量少用于这两个宏调用，因为他们的确不会毁坏系统的多任务性能。　　６）OSTimeDly函数　　这应当程序员们调用最少的一个函数了，这个函数已完成功能很非常简单，就是再行悬挂当起当前任务，然后展开任务转换，在登录的时间来临之后，将当前任务完全恢复为准备就绪状态，但是不一定运营，如果完全恢复后是优先级最低准备就绪任务的话，那么运营之。

非常简单点说道，就是可以任务延时一定时间后再度继续执行它，或者说，继续退出CPU的使用权。一个任务可以不显式的调用这些可以造成退出CPU使用权的API，但那样多任务性能不会大大降低，因为此时意味着依赖时钟机制在展开任务转换。一个好的任务应当在已完成一些操作者主动退出使用权，好东西要大家共享嘛！。

本文来源：金沙最新官方网站-www.sndiagnosticcentre.com