ucosii支持多少个任务，UCOSIII真的无限个任务吗

1，UCOSIII真的无限个任务吗

理论上是.因为它支持相同优先级的任务.所以只要有ram.就可以创建任务.

给你解释也没用，自己往后看刚开始都看不懂等遇到了就知道该变量是做什么用的邵贝贝的那本ucos3里面应该有每行的解释

UCOSIII真的无限个任务吗

2，ucos ii 怎么确定建立几个任务

假如有abc三个任务，任务优先级a>b>c，由于a优先级最高，故而一开始ucOS会挑a来先运行。a运行期间，b、c任务都不会被运行，除非a任务主动进行等待(可以是等待：延时、信号、消息等)，a任务调用等待函数时，实际上是把a任务的堆栈给切出去，同时换上次一级的任务b的堆栈环境，然后执行b任务。任务b执行期间，c任务不能被运行，但若a任务可以抢夺其执行权(在a任务等待结束时)。故而并非是每一任务按优先级顺序轮流执行的，而是高优先级的任务独占运行，除非其主动放弃执行，否则低优先级任务不能抢占，同时高优先级可以把放出去给低优先级任务使用的CPU占用权抢回来。所以ucos的任务间要注意插入等待延时，以便ucos切出去让低优先级任务执行。

ucos ii 怎么确定建立几个任务

3，UCOS 支持多种调度算法么

现在这么多操作系统，调度的算法各有千秋，但是很多都生存下来了，。现实生活中的应用种类繁多，众口难调，针对不同的应用有不同的合适的调度算法，各自都有其生存的理由。所以不少比较完善的操作系统都支持好几种调度策略，以期望以一概全，要游走于牛A与牛C之间。。

不支持，UCOS里的任务调度算法还是比较简单的，就绪任务最高优先级的那个，获得CPU使用权。不支持，即使某个任务快运行完了，高优先级的任务来了，还是得退避三舍。这个是个弊端，任务调度应该尽可能的与我们现实生活中的工作合理安排时间类似，这个期待改善。。

是的，chen，其实我想，基于优先级的调度，还有其他的方法，是否可以改进。

UCOS 支持多种调度算法么

4，ucosii操作系统可以允许后台运行多个任务而每个任务都是无限循环的

每个嵌入式操作系统都会牵扯到这个问题。任务调度通俗的讲就是操作系统分配每个任务的运行时间，协调他们的工作。对于每个任务来说，编程者可以认为只有它占用CPU，故而可以写成无限循环的形式，在这个循环中加入系统延时（或请求消息、事件等），当任务运行到系统延时这条语句不会傻傻的等待，而是转而处理其他的任务。操作系统记住了延时时间，当时间到时如果这个任务就绪再引发一次调度，执行本任务，也就是延时之后的程序。操作系统是怎么知道哪个任务应该运行，哪个任务需要等待，哪个任务需要消息的呢？不管哪个操作系统，都要有一个任务控制块，这个控制块要标明任务的优先级、任务的入口地址，并且给任务分别堆栈等。堆栈其实就是保存任务运行信息的，比如在哪个地方调用了系统延时，当系统调度给这个任务运行时就能找到在什么地方运行了。找本ucOS的书看，然后读代码，能很快理解。学习任何一门知识都要扎实，这种问题书上讲解的很清楚，不要上来就问，这不是学习的好态度。祝你好运~

5，ucgui多任务如何实现啊

UCGUI是一种嵌入式应用中的图形支持系统.它设计用于为任何使用LCD图形显示的应用提供高效的独立于处理器及 LCD 控制器的图形用户接口,它适用单任务或是多任务系统环境, 并适用于任意LCD控制器和 CPU下任何尺寸的真实显示或虚拟显示. 它的设计架构是模块化的, 由不同的模块中的不同层组成, 由一个LCD驱动层来包含所有对LCD的具体图形操作, UCGUI可以在任何的CPU上运行, 因为它是100%的标准C代码编写的. UCGUI 能够适应大多数的使用黑白或彩色 LCD 的应用, 它提供非常好的允许处理灰度的颜色管理.还提供一个可扩展的2D图形库及占用极少RAM 的窗口管理体系. uc/OS已更新至最新版uc/OS-III，他是一份非常完美的嵌入式开发系统，在学习 ARM 的基础上，嵌入 ucos系统并增加自己的源码是一件不错的选择，特别是在 arm 和 dsp 的应用当中，已经成为一种主流，虽然和其它的嵌入式系统相比，ucos 不是很完善，如没有内存分配、任务级别不多；但却是一个代码简短、条理清晰、实时性及安全性能很高的嵌入式操作系统。

估计只能运行ucos2了，你移植时都不裁剪的么？像那些没用的统统删掉~~还有，hex文件本来就很大，可以转换成bin文件后再烧录~

6，为什么说操作系统ucos是实时的ucos是多任务的

u C / O S 是一种免费公开源代码、结构小巧、具有可剥夺实时内核的实时操作系统。　　μC/OS-II 的前身是μC/OS，最早出自于1992 年美国嵌入式系统专家Jean J.Labrosse 在《嵌入式系统编程》杂志的5 月和6 月刊上刊登的文章连载，并把μC/OS 的源码发布在该杂志的B B S 上。　　μ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 中最多可以支持64 个任务，分别对应优先级0～63，其中0 为最高优先级。63为最低级，系统保留了4个最高优先级的任务和4个最低优先级的任务，所有用户可以使用的任务数有56个。　　uC/OS-II提供了任务管理的各种函数调用，包括创建任务，删除任务，改变任务的优先级，任务挂起和恢复等。　　系统初始化时会自动产生两个任务：一个是空闲任务，它的优先级最低，改任务仅给一个整形变量做累加运算；另一个是系统任务，它的优先级为次低，改任务负责统计当前cpu的利用率。　　时间管理　　uC/OS-II的时间管理是通过定时中断来实现的，该定时中断一般为10毫秒或100毫秒发生一次，时间频率取决于用户对硬件系统的定时器编程来实现。中断发生的时间间隔是固定不变的，该中断也成为一个时钟节拍。　　uC/OS-II要求用户在定时中断的服务程序中，调用系统提供的与时钟节拍相关的系统函数，例如中断级的任务切换函数，系统时间函数。　　内存管理　　在ANSI C中是使用malloc和free两个函数来动态分配和释放内存。但在嵌入式实时系统中，多次这样的错作会导致内存碎片，且由于内存管理算法的原因，malloc和free的执行时间也是不确定。　　uC/OS-II中把连续的大快内存按分区管理。每个分区中包含整数个大小相同的内存块，但不同分区之间的内存快大小可以不同。用户需要动态分配内存时，系统选择一个适当的分区，按块来分配内存。释放内存时将该块放回它以前所属的分区，这样能有效解决碎片问题，同时执行时间也是固定的。　　任务间通信与同步　　对一个多任务的操作系统来说，任务间的通信和同步是必不可少的。uC/OS-II中提供了4中同步对象，分别是信号量，邮箱，消息队列和事件。所有这些同步对象都有创建，等待，发送，查询的接口用于实现进程间的通信和同步。　　任务调度　　uC/OS-II 采用的是可剥夺型实时多任务内核。可剥夺型的实时内核在任何时候都运行就绪了的最高优先级的任务。　　uC/os-II的任务调度是完全基于任务优先级的抢占式调度，也就是最高优先级的任务一旦处于就绪状态，则立即抢占正在运行的低优先级任务的处理器资源。为了简化系统设计，uC/OS-II规定所有任务的优先级不同，因为任务的优先级也同时唯一标志了该任务本身。　　任务调度将在以下情况下发生：　　1）高优先级的任务因为需要某种临界资源，主动请求挂起，让出处理器，此时将调度就绪状态的低优先级任务获得执行，这种调度也称为任务级的上下文切换。　　2）高优先级的任务因为时钟节拍到来，在时钟中断的处理程序中，内核发现高优先级任务获得了执行条件(如休眠的时钟到时)，则在中断态直接切换到高优先级任务执行。这种调度也称为中断级的上下文切换。　　这两种调度方式在uC/OS-II的执行过程中非常普遍，一般来说前者发生在系统服务中，后者发生在时钟中断的服务程序中。　　调度工作的内容可以分为两部分：最高优先级任务的寻找和任务切换。其最高优先级任务的寻找是通过建立就绪任务表来实现的。u C / O S 中的每一个任务都有独立的堆栈空间，并有一个称为任务控制块TCB(Task Control Block)的数据结构，其中第一个成员变量就是保存的任务堆栈指针。任务调度模块首先用变量OSTCBHighRdy 记录当前最高级就绪任务的TCB 地址，然后调用OS_TASK_SW()函数来进行任务切换。　　μC/OS-II的组成部分　　μC/OS-II可以大致分成核心、任务处理、时间处理、任务同步与通信，CPU的移植等5个部分。　　1) 核心部分(OSCore.c) 　　是操作系统的处理核心，包括操作系统初始化、操作系统运行、中断进出的前导、时钟节拍、任务调度、事件处理等多部分。能够维持系统基本工作的部分都在这里。　　2) 任务处理部分(OSTask.c) 　　任务处理部分中的内容都是与任务的操作密切相关的。包括任务的建立、删除、挂起、恢复等等。因为μC/OS-II是以任务为基本单位调度的，所以这部分内容也相当重要。　　3) 时钟部分(OSTime.c) 　　μC/OS-II中的最小时钟单位是timetick（时钟节拍）。任务延时等操作是在这里完成的。　　4) 任务同步和通信部分　　为事件处理部分，包括信号量、邮箱、邮箱队列、事件标志等部分；主要用于任务间的互相联系和对临界资源的访问。　　5) 与CPU的接口部分　　是指μC/OS-II针对所使用的CPU的移植部分。由于μC/OS-II是一个通用性的操作系统，所以对于关键问题上的实现，还是需要根据具体CPU的具体内容和要求作相应的移植。这部分内容由于牵涉到SP等系统指针，所以通常用汇编语言编写。主要包括中断级任务切换的底层实现、任务级任务切换的底层实现、时钟节拍的产生和处理、中断的相关处理部分等内容。　　uC/OS-II的任务切换机理及中断调度优化　　摘要：μC/OS-II是一种适用于嵌入式系统的抢占式实时多任务操作系统，开放源代码，便于学习和使用。介绍μC/OS-II在任务级和中断级的任务切换原理，以及这一操作系统基于嵌入式系统的对于中断的处理；相对于内存资源较少的单片机，着重讨论一种优化的实用堆栈格式和切换形式，以提高资源的利用率；结合MSP430单片机，做具体的分析。关键词：实时多任务操作系统 μC/OS MSP430 中断堆栈　　引言　　在嵌入式操作系统领域，由Jean J. Labrosse开发的μC/OS，由于开放源代码和强大而稳定的功能，曾经一度在嵌入式系统领域引起强烈反响。而其本人也早已成为了嵌入式系统会议（美国）的顾问委员会的成员。　　不管是对于初学者，还是有经验的工程师，μC/OS开放源代码的方式使其不但知其然，还知其所以然。通过对于系统内部结构的深入了解，能更加方便地进行开发和调试；并且在这种条件下，完全可以按照设计要求进行合理的裁减、扩充、配置和移植。通常，购买RTOS往往需要一大笔资金，使得一般的学习者望而却步；而μC/OS对于学校研究完全免费，只有在应用于盈利项目时才需要支付少量的版权费，特别适合一般使用者的学习、研究和开发。自1992第1版问世以来，已有成千上万的开发者把它成功地应用于各种系统，安全性和稳定性已经得到认证，现已经通过美国FAA认证。　　1 μC/OS-II的几大组成部分　　μC/OS-II可以大致分成核心、任务处理、时间处理、任务同步与通信，CPU的移植等5个部分。　　核心部分(OSCore.c) 是操作系统的处理核心，包括操作系统初始化、操作系统运行、中断进出的前导、时钟节拍、任务调度、事件处理等多部分。能够维持系统基本工作的部分都在这里。　　任务处理部分(OSTask.c) 任务处理部分中的内容都是与任务的操作密切相关的。包括任务的建立、删除、挂起、恢复等等。因为μC/OS-II是以任务为基本单位调度的，所以这部分内容也相当重要。　　时钟部分(OSTime.c) μC/OS-II中的最小时钟单位是timetick（时钟节拍）。任务延时等操作是在这里完成的。　　任务同步和通信部分为事件处理部分，包括信号量、邮箱、邮箱队列、事件标志等部分；主要用于任务间的互相联系和对临界资源的访问。　　与CPU的接口部分是指μC/OS-II针对所使用的CPU的移植部分。由于μC/OS-II是一个通用性的操作系统，所以对于关键问题上的实现，还是需要根据具体CPU的具体内容和要求作相应的移植。这部分内容由于牵涉到SP等系统指针，所以通常用汇编语言编写。主要包括中断级任务切换的底层实现、任务级任务切换的底层实现、时钟节拍的产生和处理、中断的相关处理部分等内容。　　2 对于MSP430的中断处理　　2.1 函数调用和中断调用的操作　　MSP430最常使用的C编译器应该就是IAR Embedd-ed WorkBench。对于这一编译器来说，通过分析和研究，发现它有以下规律。　　(1)函数调用　　如果是函数级调用，编译器会在函数调用时先把当前函数PC压栈，然后调用函数，PC值改变。　　如果被调用的函数带有参数，那么，编译器按照以下的规则进行。　　最左边的两个参数如果不是struct（结构体）或者union（联合体），将被赋值到寄存器，否则将被压栈。函数剩下的参数都将被压栈。根据最左边的那两个参数的类型，分别赋值给R12（对于32位类型赋值给R12:R13）和R14(对于32位类型赋值给R14:R15)。　　(2)中断调用　　如果是在中断中调用中断服务子程序的话，编译器将把当前执行语句的PC压栈，同时再把SR压栈。接着，根据中断服务子程序的复杂程度，选择把R12~R15中的寄存器压栈。然后，执行中断服务子程序。中断处理结束后再把Rx寄存器出栈，SR出栈，PC出栈。把系统恢复到中断前的状态，使程序接着被中断的部分继续运行。　　图3 中断发生时的任务栈压栈操作　　2.2 任务级和中断级的任务切换步骤和原理　　(1)任务级的任务切换原理　　μC/OS-II是一个多任务的操作系统，在没有用户自己定义的中断情况下，任务间的切换步骤是这样的：任务间的切换一般会调用OSSched()函数。函数的结构如下：　　void OSSched(void)　　关中断　　如果（不是中断嵌套并且系统可以被调度）　　确定优先级最高的任务　　如果（最高级的任务不是当前的任务）　　调用OSCtxSw(); 　　} 　　} 　　开中断　　} 　　我们把这个函数称作任务调度的前导函数。它先判断要进行任务切换的条件，如果条件允许进行任务调度，则调用OSCtxSw()。这个函数是真正实现任务调度的函数。由于期间要对堆栈进行操作，所以OSCtxSw()一般用汇编语言写成。它将正在运行的任务的CPU的SR寄存器推入堆栈，然后把R4~R15压栈。接着把当前的SP保存在TCB->OSTCBStkPtr中，然后把最高优先级的TCB->OSTCBStkPtr的值赋值给SP。这时候，SP就已经指到最高优先级任务的任务堆栈了。然后进行出栈工作，把R15~R4出栈。接着使用RETI返回，这样就把SR和PC出栈了。简单地说，μC/OS-II切换到最高优先级的任务，只是恢复最高优先级任务所有的寄存器并运行中断返回指令（RETI），实际上，所作的只是人为地模仿了一次中断。　　(2)中断级的任务切换原理　　μC/OS-II的中断服务子程序和一般前后台的操作有少许不同，往往需要这样操作：　　保存全部CPU寄存器　　调用OSIntEnter()或OSIntNesting++ 　　开放中断　　执行用户代码　　关闭中断　　调用OSIntExit(); 　　恢复所有CPU寄存器　　RETI 　　OSIntEnter()就是将全局变量OSIntNesting加1。OSIntNesting是中断嵌套层数的变量。μC/OS-II通过它确保在中断嵌套的时候，不进行任务调度。执行完用户的代码后，μC/OS-II调用OSIntExit()，一个与OSSched()很像的函数。在这个函数中，系统首先把OSIntNesting减1，然后判断是否中断嵌套。如果不是的话，并且当前任务不是最高优先级的任务，那么找到优先级最高的任务，执行OSIntCtxSw()这一出中断任务切换函数。因为，在这之前已经做好了压栈工作；在这个函数中，要进行R15~R4的出栈工作。而且，由于在之前调用函数的时候，可能已经有一些寄存器被压入了堆栈。所以要进行堆栈指针的调整，使得能够从正确的位置出栈。　　3 使用μC/OS-II存在的问题和解决方法　　由于μC/OS-II在应用的时候会占用单片机上的一些资源，如系统时钟、RAM、Flash或者ROM，从而减少了用户程序对资源的利用。对于MSP430来说，RAM的占用是特别突出的问题。对于8、16位的单片机来说，片内的RAM容量都很小，MSP430也是如此（最大的片内RAM也只有2KB，例如MSP430F149）。如果使用扩展内存，会大大增加设计难度。　　通过对μC/OS-II的分析可以得知，μC/OS-II占用的RAM主要是用在每个任务的TCB、每个任务的堆栈等方面。通过进一步分析，发现任务堆栈大的原因是因为MSP430的硬件设计中没有把中断堆栈和任务堆栈分开。这样就造成了在应用μC/OS-II的时候，考虑每个任务的任务堆栈大小时，不单单需要计算任务中局部变量和函数嵌套层数，还需要考虑中断的最大嵌套层数。因为，对于μC/OS-II原始的中断处理的设计、中断处理过程中的中断嵌套中所需要压栈的寄存器大小和局部变量的内存大小，都需要算在每个任务的任务堆栈中，则对于每一个任务都需要预留这一部分内存，所以大量的RAM被浪费。从这里可以看出，解决这一问题的直接方法就是把中断堆栈和每个任务自己的堆栈分开。这样，在计算每个任务堆栈的时候，就不需要把中断处理中（包括中断嵌套过程中）的内存的占用计算到每个任务的任务堆栈中，只需要计算每个任务本身需要的内存大小，从而提高了RAM的利用率，可以缓解内存紧张的问题。　　在这种设计方案中，中断堆栈区也就是利用原有的MSP430中的系统堆栈区。在前后台的设计形式中，中断中的压栈和出栈的操作都是在系统的堆栈区完成的。基于μC/OS-II的任务切换的原理，我们对于任务堆栈的功能和系统堆栈的功能做了以下划分：任务在运行过程中产生中断和任务切换的时候，PC和SR以及寄存器Rx都保存在各个任务自己的任务堆栈中；而中断嵌套产生的压栈和出栈的操作都是放在系统堆栈中进行的。这种划分方式是基于尽量将中断任务与普通任务分开的思想设计的。　　从前面对于IAR EW的默认操作分析来看，堆栈的结构可以有两种。一种是把μC/OS-II的任务堆栈设计成图1所示的形式。这种方法是把编译器默认的压栈操作放在前面，然后再把剩下的寄存器进栈。但是，由于编译器在处理复杂程度不同的中断服务程序的时候，压入栈的寄存器的数量不定，所以会对以后其余寄存器的压栈和出栈操作增加复杂度。这里，我们采用了图2所示的方式生成堆栈。在这种堆栈中，PC和SR压栈后，通过调整SP指针，使得R4~R15寄存器覆盖编译器默认压栈的寄存器。这样，处理的难度会小一点。　　对于这样的设计方式，CPU必须能够：　　◆ 有相应的CPU寄存器能够模仿SP的一些功能，能使用相应的指令来完成类似SP的一些操作；　　◆ 作为SP使用的寄存器在编译过程中最好不被编译器默认使用。在IAR的编译器中，有一个选项可以避免在编译过程中使用到R4、R5。　　这两点MSP430都可以做到。　　下面对一个正在运行的优先级为6的任务中断后，会发生的几种情况进行分析。　　1）在中断的处理过程中没有更高优先级的中断产生，即不会产生中断嵌套。　　图3所示为中断发生后对于任务优先级为6的任务堆栈所进行的操作。中断发生后，PC和SR被系统压栈②，对于IAR C编译器来说，会按照复杂度不同的中断服务程序的要求，默认地进行一些寄存器的压栈操作③。因为我们要求的堆栈格式是如图2所示的，我们要把SP调整到SR后面④，然后进行R4~R15的压栈操作，形成我们所要求的堆栈格式⑤。　　进行任务堆栈的压栈工作以后，就可以调整SP的指针到系统堆栈了，如图4所示。压栈后的SP指向最后一个压栈内容①。我们把SP的值赋值给优先级6任务的TCB->OSTCBStkPtr，以便进行任务调度的时候出栈使用②。接着，就把SP调整到系统堆栈处③。在中断处理过程中，可能会出现压栈的操作，那么这种情况下SP的指针会随之移动。由于现在是中断堆栈中，所以不会破坏任务堆栈的格式。　　由于没有中断嵌套，在中断处理中没有别的中断发生，那么返回的步骤和上述的进栈操作正好相反。在中断处理完了以后，SP会自动回到图4中③的SP位置。接着，系统会查询到优先级最高的任务，然后把SP的指针移到优先级最高的任务的任务堆栈，进行R15~R4的出栈工作，最后用RETI中断返回指令返回到新的任务。因为我们把所有的任务堆栈都规定成相同的格式，所以它们之间不会产生问题。这里需要注意的是，因为系统在C编译器的中断处理中会对中断进入时默认压栈的寄存器出栈，所以在设计出栈的程序时，要先把这些内容压栈，这样才能正确出栈。　　2）在中断的处理过程中，有别的中断产生，产生中断嵌套。　　如图5所示，由于在处理中断的时候，SP已经被移到系统堆栈去了，只有当中断退出的时候才可能把SP移到别的任务的任务堆栈中。所以在中断的时候进行中断嵌套，那么对于中断的处理和第一次是一样的，所不同的是，这次保存在堆栈中的不是任务运行中的寄存器，而是中断处理中的寄存器，而且是保存在系统堆栈中而不是任务堆栈中。从这里就可以看出优化内存的效果。所有的中断嵌套中的寄存器压栈都压在系统堆栈中，这样对于任务堆栈内存大小的要求大大降低。　　因为μC/OS-II在进入中断中，会把全局变量OSIntNesting++；在退出中断的时候，又会把OSIntNesting--。在退出中断进行任务切换之前，μC/OS-II会先判断OSIntNesting是否为0，是0才会进行任务调度。当第二中断运行结束以后，退出中断嵌套的时候，OSIntNesting不为0，也就不会进行任务调度。因此，仍旧在系统堆栈出栈，那么系统会继续前面没有完成的中断服务程序。　　接着退出中断的顺序和非中断嵌套的顺序是一样的。在中断处理完以后，SP会自动回到图4中③的SP位置。接着，系统会查询到优先级最高的任务，然后把SP的指针移到优先级最高的任务的任务堆栈。进行R15~R4的出栈工作，最后用RETI中断返回指令返回到新的任务。　　中断的情况基本上就是上述两种。对于有些文献中提到的在中断中会调度到更高优先级的任务的情况，笔者觉得是不应该发生的。因为从上面的分析可以看出，默认的（μC/OS-II的设计思路）中断处理会同时对全局变量OSIntNesting进行增减处理，以给出是否需要任务调度的条件。那么即使在中断服务程序中把更高优先级的任务就绪，也会等到中断退出以后再进行调度，除非是在中断中直接调用更高优先级的任务函数。但这种方法应该是和μC/OS-II的原则相违背的，沿用的是以前前后台设计的思路。　　对于这样的设计方式，时钟节拍的处理方式必须和一般的中断处理方式是一样的。一般来说，MSP430使用WATCHDOG时钟中断作为时钟节拍的产生源。从本质上来说，时钟节拍本身也是中断处理过程，所以对于时钟节拍的处理应该和其它的中断处理过程相同。实际上，在时钟节拍的处理过程中也可能会存在中断嵌套的问题。　　中断堆栈和任务堆栈分离设计的程序流程如图6所示。　　4 几点建议　　① 编写中断程序的时候，有条件尽量使用汇编语言。因为这样可以避免一些编译器自己进行的操作，减少指针调整的次数。　　② 在用C编写中断服务的时候，因为有些功能必须调用汇编的函数才能实现。调用函数时，有些时候压栈的PC会破坏堆栈的结构。这个时候需要把堆栈进行适当的调整，保证堆栈格式的正确。　　③ 中断处理过程中调用OSIntExit()的时候，由于 μC/OS-II的原始设计中SP指针有时是不调整的，所以在OSIntExit()返回了以后，还要判断一下是否中断嵌套。因为有的时候是需要切换任务的。

7，ucosii实时操作系统的优缺点

源代码可以获得，实时性比较好，应用广泛，许可相比较还是比较便宜的。和风河的比实时性要差一点吧，开发的话可能有一定难度其他没有什么。

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时，必须对所开发的系统了解清楚，才能决定对于某种共享资源是否使用信号量。

8，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 ii在单片机使用中的一些特点1．在单片机系统中嵌入ucos ii将增强系统的可靠性，并使得调试程序变得简单。以往传统的单片机开发工作中经常遇到程序跑飞或是陷入死循环。可以用看门狗解决程序跑飞问题，而对于后一种情况，尤其是其中牵扯到复杂数学计算的话，只有设置断点，耗费大量时间来慢慢分析。如果在系统中嵌入 ucos ii的话，事情就简单多了。可以把整个程序分成许多任务，每个任务相对独立，然后在每个任务中设置超时函数，时间用完以后，任务必须交出 CPU的使用权。即使一个任务发生问题，也不会影响其他任务的运行。这样既提高了系统的可靠性，同时也使得调试程序变得容易。2．在单片机系统中嵌入ucos ii将增加系统的开销。现在所使用的51单片机，一般是指87C51或者89C51，其片内都带有一定的RAM和 ROM。对于一些简单的程序，如果采用传统的编程方法，已经不需要外扩存储器了。如果在其中嵌入ucos ii的话，在只需要使用任务调度、任务切换、信号量处理、延时或超时服务的情况下，也不需要外扩ROM了，但是外扩RAM是必须的。由于ucos ii是可裁减的操作系统，其所需要的RAM大小就取决于操作系统功能的多少。举例来说，μC/OS-II允许用户定义最大任务数。由于每建立一个任务，都要产生一个与之相对应的数据结构TCB，该数据结构要占用很大一部分内存空间。所以在定义最大任务数时，一定要考虑实际情况的需要。如果定得过大，势必会造成不必要的浪费。嵌入ucos ii以后，总的RAM需求可以由如下表达式得出：RAM总需求=应用程序的RAM需求+内核数据区的RAM需求+（任务栈需求+最大中断嵌套栈需求）·任务数所幸的是，μC/OS-II可以对每个任务分别定义堆栈空间的大小，开发人员可根据任务的实际需求来进行栈空间的分配。但在RAM容量有限的情况下，还是应该注意一下对大型数组、数据结构和函数的使用，别忘了，函数的形参也是要推入堆栈的。3．ucos ii的移植也是一件需要值得注意的工作。如果没有现成的移植实例的话，就必须自己来编写移植代码。虽然只需要改动两个文件，但仍需要对相应的微处理器比较熟悉才行，最好参照已有的移植实例。另外，即使有移植实例，在编程前最好也要阅读一下，因为里面牵扯到堆栈操作。在编写中断服务程序时，把寄存器推入堆栈的顺序必须与移植代码中的顺序相对应。

期待看到有用的回答！

9，关于嵌入式实时操作系统ucos ii的分析

嵌入式实时操作系统ucos ii的分析2010年01月06日星期三上午 01:15摘要：近年来，在单片机系统中嵌入操作系统已经成为人们越来越关心的一个话题。本文通过对一种源码公开的嵌入式实时操作系统ucos ii的分析，以51系列单片机为例，阐述了在单片机中使用该嵌入式操作系统的优缺点，以及在应用中应当注意的一些问题。关键词：实时操作系统；ucos ii；单片机引言早在20世纪60年代，就已经有人开始研究和开发嵌入式操作系统。但直到最近，它才在国内被越来越多的提及，在通信、电子、自动化等需要实时处理的领域所曰益显现的重要性吸引了人们越来越多的注意力。但是，人们所谈论的往往是一些著名的商业内核，诸如VxWorks、PSOS等。这些商业内核性能优越，但价格昂贵，主要用于16位和32位处理器中，针对国内大部分用户使用的51系列8位单片机，可以选择免费的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 ii在单片机使用中的一些特点 1．在单片机系统中嵌入ucos ii将增强系统的可靠性，并使得调试程序变得简单。以往传统的单片机开发工作中经常遇到程序跑飞或是陷入死循环。可以用看门狗解决程序跑飞问题，而对于后一种情况，尤其是其中牵扯到复杂数学计算的话，只有设置断点，耗费大量时间来慢慢分析。如果在系统中嵌入 ucos ii的话，事情就简单多了。可以把整个程序分成许多任务，每个任务相对独立，然后在每个任务中设置超时函数，时间用完以后，任务必须交出 CPU的使用权。即使一个任务发生问题，也不会影响其他任务的运行。这样既提高了系统的可靠性，同时也使得调试程序变得容易。 2．在单片机系统中嵌入ucos ii将增加系统的开销。现在所使用的51单片机，一般是指87C51或者89C51，其片内都带有一定的RAM和 ROM。对于一些简单的程序，如果采用传统的编程方法，已经不需要外扩存储器了。如果在其中嵌入ucos ii的话，在只需要使用任务调度、任务切换、信号量处理、延时或超时服务的情况下，也不需要外扩ROM了，但是外扩RAM是必须的。由于ucos ii是可裁减的操作系统，其所需要的RAM大小就取决于操作系统功能的多少。举例来说，μC/OS-II允许用户定义最大任务数。由于每建立一个任务，都要产生一个与之相对应的数据结构TCB，该数据结构要占用很大一部分内存空间。所以在定义最大任务数时，一定要考虑实际情况的需要。如果定得过大，势必会造成不必要的浪费。嵌入ucos ii以后，总的RAM需求可以由如下表达式得出： RAM总需求=应用程序的RAM需求+内核数据区的RAM需求+（任务栈需求+最大中断嵌套栈需求）·任务数所幸的是，μC/OS-II可以对每个任务分别定义堆栈空间的大小，开发人员可根据任务的实际需求来进行栈空间的分配。但在RAM容量有限的情况下，还是应该注意一下对大型数组、数据结构和函数的使用，别忘了，函数的形参也是要推入堆栈的。 3．ucos ii的移植也是一件需要值得注意的工作。如果没有现成的移植实例的话，就必须自己来编写移植代码。虽然只需要改动两个文件，但仍需要对相应的微处理器比较熟悉才行，最好参照已有的移植实例。另外，即使有移植实例，在编程前最好也要阅读一下，因为里面牵扯到堆栈操作。在编写中断服务程序时，把寄存器推入堆栈的顺序必须与移植代码中的顺序相对应。 4．和其他一些著名的嵌入式操作系统不同，ucos ii在单片机系统中的启动过程比较简单，不像有些操作系统那样，需要把内核编译成一个映像文件写入ROM中，上电复位后，再从ROM中把文件加载到RAM中去，然后再运行应用程序。ucos ii的内核是和应用程序放在一起编译成一个文件的，使用者只需要把这个文件转换成HEX格式，写入ROM中就可以了，上电后，会像普通的单片机程序一样运行。结语由以上介绍可以看出，ucos ii具有免费、使用简单、可靠性高、实时性好等优点，但也有移植困难、缺乏必要的技术支持等缺点，尤其不像商用嵌入式系统那样得到广泛使用和持续的研究更新。但开放性又使得开发人员可以自行裁减和添加所需的功能，在许多应用领域发挥着独特的作用。当然，是否在单片机系统中嵌入ucos ii应视所开发的项目而定，对于一些简单的、低成本的项目来说，就没必要使用嵌入式操作系统了。

10，ucosii源代码是用什么语言写的

是否μC/OS-II，是就看下面的内容，如果不是你想要的答案，本人也无能为力外行人粗略理解：从这篇文章可以看出μC/OS-II内核和应用程序放在一起编译成一个文件这种做法是特有的，应该也不能分开。单片机软件操作系统的利弊,UCOSII在单片机上的使用来源：今日电子摘要：近年来，在单片机系统中嵌入操作系统已经成为人们越来越关心的一个话题。本文通过对一种源码公开的嵌入式实时操作系统μC/OS-II的分析，以51系列单片机为例，阐述了在单片机中使用该嵌入式操作系统的优缺点，以及在应用中应当注意的一些问题。关键词：实时操作系统；μC/OS-II；单片机引言　　早在20世纪60年代，就已经有人开始研究和开发嵌入式操作系统。但直到最近，它才在国内被越来越多的提及，在通信、电子、自动化等需要实时处理的领域所日益显现的重要性吸引了人们越来越多的注意力。但是，人们所谈论的往往是一些著名的商业内核，诸如VxWorks、PSOS等。这些商业内核性能优越，但价格昂贵，主要用于16位和32位处理器中，针对国内大部分用户使用的51系列8位单片机，可以选择免费的μC/OS-II。μC/OS-II的特点　　1．μC/OS-II是由Labrosse先生编写的一个开放式内核，最主要的特点就是源码公开。这一点对于用户来说可谓利弊各半，好处在于，一方面它是免费的，另一方面用户可以根据自己的需要对它进行修改。缺点在于它缺乏必要的支持，没有功能强大的软件包，用户通常需要自己编写驱动程序，特别是如果用户使用的是不太常用的单片机，还必须自己编写移植程序。　　2．μC/OS-II是一个占先式的内核，即已经准备就绪的高优先级任务可以剥夺正在运行的低优先级任务的CPU使用权。这个特点使得它的实时性比非占先式的内核要好。通常我们都是在中断服务程序中使高优先级任务进入就绪态（例如发信号），这样退出中断服务程序后，将进行任务切换，高优先级任务将被执行。拿51单片机为例，比较一下就可以发现这样做的好处。假如需要用中断方式采集一批数据并进行处理，在传统的编程方法中不能在中断服务程序中进行复杂的数据处理，因为这会使得关中断时间过长。所以经常采用的方法是置一标志位，然后退出中断。由于主程序是循环执行的，所以它总有机会检测到这一标志并转到数据处理程序中去。但是因为无法确定发生中断时程序到底执行到了什么地方，也就无法判断要经过多长时间数据处理程序才会执行，中断响应时间无法确定，系统的实时性不强。如果使用μC/OS-II的话，只要把数据处理程序的优先级设定得高一些，并在中断服务程序中使它进入就绪态，中断结束后数据处理程序就会被立即执行。这样可以把中断响应时间限制在一定的范围内。对于一些对中断响应时间有严格要求的系统，这是必不可少的。但应该指出的是如果数据处理程序简单，这样做就未必合适。因为μC/OS-II要求在中断服务程序末尾使用OSINTEXIT函数以判断是否进行任务切换，这需要花费一定的时间。　　3．μC/OS-II和大家所熟知的Linux等分时操作系统不同，它不支持时间片轮转法。μC/OS-II是一个基于优先级的实时操作系统，每个任务的优先级必须不同，分析它的源码会发现，μC/OS-II把任务的优先级当做任务的标识来使用，如果优先级相同，任务将无法区分。进入就绪态的优先级最高的任务首先得到CPU的使用权，只有等它交出CPU的使用权后，其他任务才可以被执行。所以它只能说是多任务，不能说是多进程，至少不是我们所熟悉的那种多进程。显而易见，如果只考虑实时性，它当然比分时系统好，它可以保证重要任务总是优先占有CPU。但是在系统中，重要任务毕竟是有限的，这就使得划分其他任务的优先权变成了一个让人费神的问题。另外，有些任务交替执行反而对用户更有利。例如，用单片机控制两小块显示屏时，无论是编程者还是使用者肯定希望它们同时工作，而不是显示完一块显示屏的信息以后再显示另一块显示屏的信息。这时候，要是μC/OS-II即支持优先级法又支持时间片轮转法就更合适了。　　4．μC/OS-II对共享资源提供了保护机制。正如上文所提到的，μC/OS-II是一个支持多任务的操作系统。一个完整的程序可以划分成几个任务，不同的任务执行不同的功能。这样，一个任务就相当于模块化设计中的一个子模块。在任务中添加代码时，只要不是共享资源就不必担心互相之间有影响。而对于共享资源（比如串口），μC/OS-II也提供了很好的解决办法。一般情况下使用的是信号量的方法。简单地说，先创建一个信号量并对它进行初始化。当一个任务需要使用一个共享资源时，它必须先申请得到这个信号量，而一旦得到了此信号量，那就只有等使用完了该资源，信号量才会被释放。在这个过程中即使有优先权更高的任务进入了就绪态，因为无法得到此信号量，也不能使用该资源。这个特点的好处显而易见，例如当显示屏正在显示信息的时候，外部产生了一个中断，而在中断服务程序中需要显示屏显示其他信息。这样，退出中断服务程序后，原有的信息就可能被破坏了。而在μC/OS-II中采用信号量的方法时，只有显示屏把原有信息显示完毕后才可以显示新信息，从而可以避免这个现象。不过，采用这种方法是以牺牲系统的实时性为代价的。如果显示原有信息需要耗费大量时间，系统只好等待。从结果上看，等于延长了中断响应时间，这对于未显示信息是报警信息的情况，无疑是致命的。发生这种情况，在μC/OS-II中称为优先级反转，就是高优先级任务必须等待低优先级任务的完成。在上述情况下，在两个任务之间发生优先级反转是无法避免的。所以在使用μC/OS-II时，必须对所开发的系统了解清楚，才能决定对于某种共享资源是否使用信号量。μC/OS-II在单片机使用中的一些特点　　1．在单片机系统中嵌入μC/OS-II将增强系统的可靠性，并使得调试程序变得简单。以往传统的单片机开发工作中经常遇到程序跑飞或是陷入死循环。可以用看门狗解决程序跑飞问题，而对于后一种情况，尤其是其中牵扯到复杂数学计算的话，只有设置断点，耗费大量时间来慢慢分析。如果在系统中嵌入μC/OS-II的话，事情就简单多了。可以把整个程序分成许多任务，每个任务相对独立，然后在每个任务中设置超时函数，时间用完以后，任务必须交出CPU的使用权。即使一个任务发生问题，也不会影响其他任务的运行。这样既提高了系统的可靠性，同时也使得调试程序变得容易。　　2．在单片机系统中嵌入μC/OS-II将增加系统的开销。现在所使用的51单片机，一般是指87C51或者89C51，其片内都带有一定的RAM和ROM。对于一些简单的程序，如果采用传统的编程方法，已经不需要外扩存储器了。如果在其中嵌入μC/OS-II的话，在只需要使用任务调度、任务切换、信号量处理、延时或超时服务的情况下，也不需要外扩ROM了，但是外扩RAM是必须的。由于μC/OS-II是可裁减的操作系统，其所需要的RAM大小就取决于操作系统功能的多少。举例来说，μC/OS-II允许用户定义最大任务数。由于每建立一个任务，都要产生一个与之相对应的数据结构TCB，该数据结构要占用很大一部分内存空间。所以在定义最大任务数时，一定要考虑实际情况的需要。如果定得过大，势必会造成不必要的浪费。嵌入μC/OS-II以后，总的RAM需求可以由如下表达式得出：　　RAM总需求=应用程序的RAM需求+内核数据区的RAM需求+（任务栈需求+最大中断嵌套栈需求）·任务数　　所幸的是，μC/OS-II可以对每个任务分别定义堆栈空间的大小，开发人员可根据任务的实际需求来进行栈空间的分配。但在RAM容量有限的情况下，还是应该注意一下对大型数组、数据结构和函数的使用，别忘了，函数的形参也是要推入堆栈的。　　3．μC/OS-II的移植也是一件需要值得注意的工作。如果没有现成的移植实例的话，就必须自己来编写移植代码。虽然只需要改动两个文件，但仍需要对相应的微处理器比较熟悉才行，最好参照已有的移植实例。另外，即使有移植实例，在编程前最好也要阅读一下，因为里面牵扯到堆栈操作。在编写中断服务程序时，把寄存器推入堆栈的顺序必须与移植代码中的顺序相对应。　　4．和其他一些著名的嵌入式操作系统不同，μC/OS-II在单片机系统中的启动过程比较简单，不像有些操作系统那样，需要把内核编译成一个映像文件写入ROM中，上电复位后，再从ROM中把文件加载到RAM中去，然后再运行应用程序。μC/OS-II的内核是和应用程序放在一起编译成一个文件的，使用者只需要把这个文件转换成HEX格式，写入ROM中就可以了，上电后，会像普通的单片机程序一样运行。结语　　由以上介绍可以看出，μC/OS-II具有免费、使用简单、可靠性高、实时性好等优点，但也有移植困难、缺乏必要的技术支持等缺点，尤其不像商用嵌入式系统那样得到广泛使用和持续的研究更新。但开放性又使得开发人员可以自行裁减和添加所需的功能，在许多应用领域发挥着独特的作用。当然，是否在单片机系统中嵌入μC/OS-II应视所开发的项目而定，对于一些简单的、低成本的项目来说，就没必要使用嵌入式操作系统了。

文章TAG：ucosii支持多少个任务ucosii 支持多少