ucos痛苦，到底该怎样学ucos ii

UCOS最强能做到什么程度

uC/OS-II是一种基于优先级的可抢先的硬实时内核。

自从９２年发布以来，在世界各地都获得了广泛的应用，它是一种专门为嵌入式设备设计的内核，目前已经被移植到４０多种不同结构的CPU上，运行在从８位到６４位的各种系统之上。

尤其值得一提的是，该系统自从２.51版本之后，就通过了美国FAA认证，可以运行在诸如航天器等对安全要求极为苛刻的系统之上。

嵌入式实时操作系统ucos-ii怎么样

ucos ii的特点 1．ucos ii是由Labrosse先生编写的一个开放式内核，最主要的特点就是源码公开。

这一点对于用户来说可谓利弊各半，好处在于，一方面它是免费的，另一方面用户可以根据自己的需要对它进行修改。

缺点在于它缺乏必要的支持，没有功能强大的软件包，用户通常需要自己编写驱动程序，特别是如果用户使用的是不太常用的单片机，还必须自己编写移植程序。

2．ucos ii是一个占先式的内核，即已经准备就绪的高优先级任务可以剥夺正在运行的低优先级任务的CPU使用权。

这个特点使得它的实时性比非占先式的内核要好。

通常我们都是在中断服务程序中使高优先级任务进入就绪态（例如发信号），这样退出中断服务程序后，将进行任务切换，高优先级任务将被执行。

拿51单片机为例，比较一下就可以发现这样做的好处。

假如需要用中断方式采集一批数据并进行处理，在传统的编程方法中不能在中断服务程序中进行复杂的数据处理，因为这会使得关中断时间过长。

所以经常采用的方法是置一标志位，然后退出中断。

由于主程序是循环执行的，所以它总有机会检测到这一标志并转到数据处理程序中去。

但是因为无法确定发生中断时程序到底执行到了什么地方，也就无法判断要经过多长时间数据处理程序才会执行，中断响应时间无法确定，系统的实时性不强。

如果使用μC/OS-II的话，只要把数据处理程序的优先级设定得高一些，并在中断服务程序中 使它进入就绪态，中断结束后数据处理程序就会被立即执行。

这样可以把中断响应时间限制在一定的范围内。

对于一些对中断响应时间有严格要求的系统，这是必不可少的。

但应该指出的是如果数据处理程序简单，这样做就未必合适。

因为ucos ii要求在中断服务程序末尾使用OSINTEXIT函数以判断是否进行任务切换，这需要花费一定的时间。

3．ucos ii和大家所熟知的Linux等分时操作系统不同，它不支持时间片轮转法。

ucos ii是一个基于优先级的实时操作系统，每个任务的优先级必须不同，分析它的源码会发现，ucos ii把任务的优先级当做任务的标识来使用，如果优先级相同，任务将无法区分。

进入就绪态的优先级最高的任务首先得到CPU的使用权，只有等它交出CPU的使用权后，其他任务才可以被执行。

所以它只能说是多任务，不能说是多进程，至少不是我们所熟悉的那种多进程。

显而易见，如果只考虑实时性，它当然比分时系统好，它可以保证重要任务总是优先占有CPU。

但是在系统中，重要任务毕竟是有限的，这就使得划分其他任务的优先权变成了一个让人费神的问题。

另外，有些任务交替执行反而对用户更有利。

例如，用单片机控制两小块显示屏时，无论是编程者还是使用者肯定希望它们同时工作，而不是显示完一块显示屏的信息以后再显示另一块显示屏的信息。

这时候，要是ucos ii即支持优先级法又支持时间片更加合适。

4．ucos ii对共享资源提供了保护机制。

正如上文所提到的，ucos ii是一个支持多任务的操作系统。

一个完整的程序可以划分成几个任务，不同的任务执行不同的功能。

这样，一个任务就相当于模块化设计中的一个子模块。

在任务中添加代码时，只要不是共享资源就不必担心互相之间有影响。

而对于共享资源（比如串口），ucos ii也提供了很好的解决办法。

一般情况下使用的是信号量的方法。

简单地说，先创建一个信号量并对它进行初始化。

当一个任务需要使用一个共享资源时，它必须先申请得到这个信号量，而一旦得到了此信号量，那就只有等使用完了该资源，信号量才会被释放。

在这个过程中即使有优先权更高的任务进入了就绪态，因为无法得到此信号量，也不能使用该资源。

这个特点的好处显而易见，例如当显示屏正在显示信息的时候，外部产生了一个中断，而在中断服务程序中需要显示屏显示其他信息。

这样，退出中断服务程序后，原有的信息就可能被破坏了。

而在μC/OS-II中采用信号量的方法时，只有显示屏把原有信息显示完毕后才可以显示新信息，从而可以避免这个现象。

不过，采用这种方法是以牺牲系统的实时性为代价的。

如果显示原有信息需要耗费大量时间，系统只好等待。

从结果上看，等于延长了中断响应时间，这对于未显示信息是报警信息的情况，无疑是致命的。

发生这种情况，在μC/OS-II中称为优先级反转，就是高优先级任务必须等待低优先级任务的完成。

在上述情况下，在两个任务之间发生优先级反转是无法避免的。

所以在使用ucos ii时，必须对所开发的系统了解清楚，才能决定对于某种共享资源是否使用信号量。

学习UCOS III有必要买这个板子吗

个人感觉还是有必要的。

之前在stm32移植过ucos II 学习ucos感觉有2个方面，一是移植，二是使用 对于移植来说，这个牵扯到底层，调度部分是用汇编代码写的。

只有亲自去移植，在开发板上调试过后，才能更深入的掌握。

使用的话，一方面可以去阅读源码，大部分c语言写的，容易理解。

另一方面可以参考例程或者网上的代码进行学习。

另外有开发板的话，完全可以在上面搞一下自己的DIY，比如ucos+ucgui，有触摸屏的话，完全可以搞个收音机，MP3播放器等等。

ucos isr是什么意思

ucOS 时钟中断（ISR） 1 系统中断与时钟节拍 1.1 系统中断 中断是一种硬件机制，用于通知CPU有个异步事件发生了。

中断一旦被系统识别，CPU则保存部分(或全部)现场(context)，即部分(或全部）寄存器的值，跳转到专门的子程序，称为中断服务子程序(ISR)。

中断服务子程序做事件处理，处理完成后执行任务调度，程序回到就绪态优先级最高的任务开始运行（对于可剥夺型内核）。

中断使得CPU可以在事件发生时才予以处理，而不必让微处理器连续不断地查询(polling)是否有事件发生。

通过两条特殊指令：关中断 (disable interrupt)和开中断(enable interrupt)可以让微处理器不响应或响应中断。

在实时环境中，关中断的时间应尽量的短，关中断影响中断响应时间，关中断时间太长可能会引起中断丢失。

中断服务的处理时间应该尽可能的短，中断服务所做的事情应该尽可能的少，应把大部分工作留给任务去做。

1.2 系统时钟节拍 时钟节拍是特定的周期性中断（时钟中断），这个中断可以看作是系统心脏的脉动。

操作系统通过时钟中断来确定时间间隔，实现时间的延时及确定任务超时。

中断之间的时间间隔取决于不同的应用，一般在10～200 ms之间。

时钟的节拍式中断使得内核可以将任务延时若干个整数时钟节拍，以及当任务等待事件发生时提供等待超时的依据。

时钟节拍频率越快，系统的额外开销就越大。

系统定义了32位无符号整数OSTime来记录系统启动后时钟滴答的数目。

用户必须在多任务系统启动以后再开启时钟节拍器，也就是在调用 OSStart()之后。

%26mu;C/OSII中的时钟节拍服务是通过在中断服务子程序中调用OSTimeTick()实现的。

时钟节拍中断服务子程序的示意代码如下： void OSTickISR(void) { 保存处理器寄存器的值； 调用OSIntEnter ()或是将OSIntNesting加1; 调用OSTimeTick (); 调用OSIntExit (); 恢复处理器寄存器的值; 执行中断返回指令; } 2 时钟管理系统 2.1 ucos ii时钟管理系统 ucos ii原有的时钟管理系统类似于Linux，但是比Linux简单得多。

它仅向用户提供一个周期性的信号OSTime，时钟频率可以设置在 10～100 Hz，时钟硬件周期性地向CPU发出时钟中断，系统周期性响应时钟中断，每次时钟中断到来时，中断处理程序更新一个全局变量OSTime。

ucos ii时钟中断服务程序的核心是调用OSTimeTick ()函数。

OSTimeTick ()函数用来判断延时任务是否延时结束从而将其置于就绪态。

其程序伪代码如下： void OSTimeTick(void) { OSTimeTickHook();// 调用用户定义的时钟节拍外连函数 while { (除空闲任务外的所有任务) OS_ENTER_CRITICAL();//关中断 对所有任务的延时时间递减； 扫描时间到期的任务，并且唤醒该任务； OS_EXIT_CRITICAL();//开中断 指针指向下一个任务； } OSTime++；//累计从开机以来的时间 } 在ucos ii的时钟节拍函数中，需要执行用户定义的时钟节拍外连函数OSTimeTickHook ()，以及对任务链表进行扫描并且递减任务的延时。

这样就造成了时钟节拍函数OSTimeTick ()有两点不 足： ① 在时钟中断中处理额外的任务OSTimeIickHook ()，这样增加了中断处理的负担，影响了定时服务的准确性； ② 在关中断情况下扫描任务链表，任务越多所需要时间越长，而长时间关中断对中断响应有不利影响，是中断处理应当避免的。

2.2 改进的时钟管理系统 针对上述OSTimeTick ()的不足之处，需加以改进来优化时钟节拍函数。

在Linux中一般对中断的响应分为两部分：立即中断服务和底半中断处理（bottom half）。

立即中断服务仅仅做重要的并且能快速完成的工作，而把不太重要的需要较长时间完成的工作放在底半处理部分来完成，这样就可以提高中断响应速度。

ucos ii不支持底半处理，为了减轻时钟中断处理程序的工作量来提高ucos ii的时钟精确度，可以将一部分在每次时钟中断需处理的工作内容放在任务级来完成。

这样就可以减少每次时钟中断处理的CPU消耗，从而提高中断响应速度和ucos ii的时钟精确度。

为此，定义任务OSTimeTask ()，由它来处理原来在OSTimeTick()中需要处理的操作。

因为%26mu;C/OSII采用基于优先级的抢占式调度策略，而每次时钟中断处理程序结束后需要首先调度该任务执行，因此让任务OSTimeTask()具有系统内最高优先级。

由它执行用户定义的时钟节拍外连函数OSTimeTickHook ()，以及对所有任务的延时时间进行递减，并把到期的任务链入到链表OSTCBRList中，OSTCBRList管理所有到期任务。

OSTimeTask()函数伪代码如下： void OSTimeTask() { OSTimeTickHook()//用户定义的时间处理函数 while { (除空闲任务外的所有任务) 对所有任务的延时时间进行递减； 把所有要到期的任务链入到OSTCBRList链表中； } 任务状态改为睡眠，调用OSSched ()进行任务调度； } 在任务OSTimeTask()中，执行原来在时钟中断处理的用户函数OSTimeIickHook ()，并实现将延时到期的任务链入到OSTCBRList链表中，这样在时钟中断程序中就只需要扫描任务到期的链表而不需要扫描整个链表，减少了关中断的时间。

OSTCBRList为新建链表，它管理所有到期的任务。

同时，需要减少OSTimeTick ()的执行工作量，只对OSTCBRList链表扫描，这样也减少了关中断时间。

OSTimeTick ()伪代码如下： void OSTimeTick(void) { OSTime++; OS_TCB* ptcb=OSTCBList;// OSTCBRList指向所有到期任务的链表 while(ptchb!=null){ 关中断； 唤醒任务； 开中断； 指针指向下一个任务； } } 3 小结 本文以开源的嵌入式操作系统ucos ii为例，分析了操作系统的中断机制和中断应满足的条件。

介绍了ucos ii系统时钟节拍，探讨了时钟中断函数中存在的不足，并且给出了解决方案，从而有效提高了中断响应速度和ucos ii的时钟精确度。

本文来自CSDN博客，转载请标明出处：/jianshe999/archive/2008/03/11/2171484.aspx

学习UCOS用哪种软件好，

您选的那本教材不错。

对于处于入门级的您来说，推荐您从ARM7开始学，周立功NXP LPC2000系列的开发板就是基于ARM7内核的。

ARM7的应用比起ARM9和ARM11广泛的多。

而且，当您熟练掌握ARM7后，再学ARM9和ARM11相对简单很多，因为都是属于ARM的体系结构，换汤不换药。

系统方面，不知道您听谁说uC/OS-II做不了项目，但这句话说我听来，纯属瞎扯。

uC/OS-II是个既简单又优秀的开源实时嵌入式系统，您要相信它存在必有它的优势，作为你入门学习非常合适。

uC/OS-II的缺点可能就是它的文件系统需要收费，但是，文件系统完全可以自己实现的。

同样，在你理解了uC/OS-II后再学习Linux等操作系统会简单很多。

希望能帮到您。

^-^ －－鼎嵌技术

痛苦，到底该怎样学ucos ii

《嵌入式实时操作系统uCOS-II》这本书非常不错，作者是Jean J.Labrosse，中文版是邵贝贝翻译的。

这本书很适合初学者学习，但是作为一个初学者，仅仅看这本书是不够的，你可以按照书中提到编译器来编写你在书中看到的每一个程序，或者先找一款单。