A. 为什么说操作系统ucos是实时的ucos是多任务的
白话一点解释一下，希望纳大能帮助你：
实时：指OS能够满足用户根据需求所设计的切换时机和切换延时的要求。任意时刻，你希望你的系统里嫌茄模，哪一个事务最应该被优先处理？如果ucOS能满足你的要求（通过你对任务的合理设计），那么就可以说他是实时的OS。
使用ucOS构建系统时，你的所有用户事务（需要做的事情）可以被划分到多个任务里，ucOS可以根据你的实际设计，按优先级调度他们（协调该先执行哪一个任务，并立即执行），芹缓这就可以说，ucOS是多任务了。
B. 介绍几种主流嵌入式操作系统的特点，并分析比较 哥们，我现在纠结这个问题，可以给点指点吗
如果你是学习阶段的话，那linux和UCOS-II是比较合适的
uc/os和uclinux操作系统是两种性能优良源码公开且被广泛应用的的免费嵌入式操作系统，可以作为研究实时操作系统和非实时操作系统的典范。本文通过对 uc/os和uclinux的对比，分析和总结了嵌入式操作系统应用中的若干重要问题，归纳了嵌入式系统开发中操作系统的选型依据。
两种开源嵌入式操作系统介绍
uc/os和uclinux操作系统，是当前得到广泛应用的两种免费且公开源码的嵌入式操作系统。uc/os适合小型控制系统，具有执行效率高、占用空间小、实时性能优良和可扩展性强等特点，最小内核可编译至2k。uclinux则是继承标准linux 的优良特性，针对嵌入式处理器的特点设计的一种操作系统，具有内嵌网络协议、支持多种文件系统，开发者可利用标准linux先验知识等优势。其编译后目标文件可控制在几百k量级。
uc/os是一种免费公开源代码、结构小巧、具有可剥夺实时内核的实时操作系统。其内核提供任务调度与管理、时间管理、任务间同步与通信、内存管理和中断服务等功能。
uclinux是一种优秀的嵌入式linux版本。uclinux是micro-conrol-linux的缩写。同标准linux相比，它集成了标准linux操作系统的稳定性、强大网络功能和出色的文件系统等主要优点。但是由于没有mmu(内存管理单元)，其多任务的实现需要一定技巧。
两种嵌入式操作系统主要性能比较
嵌入式操作系统是嵌入式系统软硬件资源的控制中心，它以尽量合理的有效方法组织多个用户共享嵌入式系统的各种资源。其中用户指的是系统程序之上的所有软件。所谓合理有效的方法，指的就是操作系统如何协调并充分利用硬件资源来实现多任务。复杂的操作系统都支持文件系统，方便组织文件并易于对其规范化操作。
嵌入式操作系统还有一个特点就是针对不同的平台，系统不是直接可用的，一般需要经过针对专门平台的移植操作系统才能正常工作。进程调度、文件系统支持和系统移植是在嵌入式操作系统实际应用中最常见的问题，下文就从这几个角度入手对uc/os和uclinux进行分析比较。
进程调度
任务调度主要是协调任务对计算机系统内资源(如内存、i/o设备、cpu)的争夺使用。进程调度又称为cpu调度，其根本任务是按照某种原则为处于就绪状态的进程分配cpu。由于嵌入式系统中内存和i/o设备一般都和cpu同时归属于某进程，所以任务调度和进程调度概念相近，很多场合不加区分，下文中提到的任务其实就是进程的概念。
进程调度可分为"剥夺型调度"和"非剥夺型调度"两种基本方式。所谓"非剥夺型调度"是指：一旦某个进程被调度执行，则该进程一直执行下去直至该进程结束，或由于某种原因自行放弃cpu进入等待状态，才将cpu重新分配给其他进程。所谓"剥夺型调度"是指：一旦就绪状态中出现优先权更高的进程，或者运行的进程已用满了规定的时间片时，便立即剥夺当前进程的运行(将其放回就绪状态)，把cpu分配给其他进程
作为实时操作系统，uc/os是采用的可剥夺型实时多任务内核。可剥夺型的实时内核在任何时候都运行就绪了的最高优先级的任务。uc/os中最多可以支持64 个任务，分别对应优先级0~63，
其中0为最高优先级。调度工作的内容可以分为两部分：最高优先级任务的寻找和任务切换。
其最高优先级任务的寻找是通过建立就绪任务表来实现的。uc/os中的每一个任务都有独立的堆栈空间，并有一个称为任务控制块tcb(task control block)数据结构，其中第一个成员变量就是保存的任务堆栈指针。任务调度模块首先用变量 ostcbhighrdy记录当前最高级就绪任务的tcb地址，然后调用os_task_sw() 函数来进行任务切换。
uclinux的进程调度沿用了linux的传统，系统每隔一定时间挂起进程，同时系统产生快速和周期性的时钟计时中断，并通过调度函数(定时器处理函数)决定进程什么时候拥有它的时间片。然后进行相关进程切换，这是通过父进程调用fork 函数生成子进程来实现的。
uclinux系统fork调用完成后，要么子进程代替父进程执行(此时父进程已经 sleep)，直到子进程调用exit退出；要么调用exec执行一个新的进程，这个时候产生可执行文件的加载，即使这个进程只是父进程的拷贝，这个过程也不可避免。当子进程执行exit或exec后，子进程使用wakeup把父进程唤醒，使父进程继续往下执行。
uclinux由于没有mmu管理存储器，其对内存的访问是直接的，所有程序中访问的地址都是实际的物理地址。操作系统队内存空间没有保护，各个进程实际上共享一个运行空间。这就需要实现多进程时进行数据保护，也导致了用户程序使用的空间可能占用到系统内核空间，这些问题在编程时都需要多加注意，否则容易导致系统崩溃。
由上述分析可以得知，uc/os内核是针对实时系统的要求设计实现的，相对简单，可以满足较高的实时性要求。而uclinux则在结构上继承了标准linux的多任务实现方式，仅针对嵌入式处理器特点进行改良。其要实现实时性效果则需要使系统在实时内核的控制下运行，rt-linux就是可以实现这一个功能的一种实时内核。
文件系统
所谓文件系统是指负责存取和管理文件信息的机构，也可以说是负责文件的建立、撤销、组织、读写、修改、复制及对文件管理所需要的资源(如目录表、存储介质等)实施管理的软件部分。
uc/os是面向中小型嵌入式系统的，如果包含全部功能(信号量、消息邮箱、消息队列及相关函数)，编译后的uc/os内核仅有6~10kb，所以系统本身并没有对文件系统的支持。但是uc/os具有良好的扩展性能，如果需要的话也可自行加入文件系统的内容。
uclinux则是继承了linux完善的文件系统性能。其采用的是romfs文件系统，这种文件系统相对于一般的ext2文件系统要求更少的空间。空间的节约来自于两个方面，首先内核支持romfs文件系统比支持ext2文件系统需要更少的代码，其次romfs文件系统相对简单，在建立文件系统超级块(superblock)需要更少的存储空间。romfs文件系统不支持动态擦写保存，对于系统需要动态保存的数据采用虚拟ram盘的方法进行处理(ram盘将采用ext2文件系统)。
uclinux还继承了linux网络操作系统的优势，可以很方便的支持网络文件系统且内嵌tcp/ip协议，这为uclinux开发网络接入设备提供了便利。
由两种操作系统对文件系统的支持可知，在复杂的需要较多文件处理的嵌入式系统中uclinux是一个不错的选择。而uc/os则主要适合一些控制系统。
操作系统的移植
嵌入式操作系统移植的目的是指使操作系统能在某个微处理器或微控制器上运行。uc/os和uclinux都是源码公开的操作系统，且其结构化设计便于把与处理器相关的部分分离出来，所以被移植到新的处理器上是可能的。
以下对两种系统的移植分别予以说明。
(1)uc/os的移植
要移植uc/os，目标处理器必须满足以下要求；
·处理器的c编译器能产生可重入代码，且用c语言就可以打开和关闭中断；
·处理器支持中断，并能产生定时中断；
·处理器支持足够的ram(几k字节)，作为多任务环境下的任务堆栈；
·处理器有将堆栈指针和其他cpu寄存器读出和存储到堆栈或内存中的指令。
在理解了处理器和c编译器的技术细节后，uc/os的移植只需要修改与处理器相关的代码就可以了。
具体有如下内容：
·os_cpu.h中需要设置一个常量来标识堆栈增长方向；
·os_cpu.h中需要声明几个用于开关中断和任务切换的宏；
·os_cpu.h中需要针对具体处理器的字长重新定义一系列数据类型；
·os_cpu_a.asm需要改写4个汇编语言的函数；
·os_cpu_c.c需要用c语言编写6个简单函数；
·修改主头文件include.h，将上面的三个文件和其他自己的头文件加入。
(2)uclinux的移植
由于uclinux其实是linux针对嵌入式系统的一种改良，其结构比较复杂，相对 uc/os，uclinux的移植也复杂得多。一般而言要移植uclinux，目标处理器除了应满足上述uc/os应满足的条件外，还需要具有足够容量(几百k字节以上)外部rom和ram。
uclinux的移植大致可以分为3个层次：
·结构层次的移植，如果待移植处理器的结构不同于任何已经支持的处理器结构，则需要修改linux/arch目录下相关处理器结构的文件。虽然uclinux内核代码的大部分是独立于处理器和其体系结构的，但是其最低级的代码也是特定于各个系统的。这主要表现在它们的中断处理上下文、内存映射的维护、任务上下文和初始化过程都是独特的。这些例行程序位于linux/arch/目录下。由于linux所支持体系结构的种类繁多，所以对一个新型的体系，其低级例程可以模仿与其相似的体系例程编写。
·平台层次的移植，如果待移植处理器是某种uclinux已支持体系的分支处理器，则需要在相关体系结构目录下建立相应目录并编写相应代码。如mc68ez328就是基于无mmu的m68k内核的。此时的移植需要创建 linux/arch/m68knommu/platform/ mc68ez328目录并在其下编写跟踪程序(实现用户程序到内核函数的接口等功能)、中断控制调度程序和向量初始化程序等。
·板级移植，如果你所用处理器已被uclinux支持的话，就只需要板级移植了。板级移植需要在linux/arch/?platform/中建立一个相应板的目录，再在其中建立相应的启动代码crt0_rom.s或crt0_ram.s和链接描述文档rom.ld或ram.ld就可以了。板级移植还包括驱动程序的编写和环境变量设置等内容。
结语
通过对uc/os和uclinux的比较，可以看出这两种操作系统在应用方面各有优劣。 uc/os占用空间少，执行效率高，实时性能优良，且针对新处理器的移植相对简单。uclinux则占用空间相对较大，实时性能一般，针对新处理器的移植相对复杂。但是，uclinux具有对多种文件系统的支持能力、内嵌了tcp/ip协议，可以借鉴linux丰富的资源，对一些复杂的应用，uclinux具有相当优势。例如cisco 公司的 2500/3000/4000 路由器就是基于uclinux操作系统开发的。总之，操作系统的选择是由嵌入式系统的需求决定的。简单的说就是，小型控制系统可充分利用uc/os小巧且实时性强的优势，如果开发pda和互联网连接终端等较为复杂的系统则uclinux是不错的选择。
还有就是如果从开发的工具方便好用，易用的角度来看，那些收费的系统用起来更爽一些
C. 嵌入式高手进 考试题解答
推荐一：OS_CPU.H
1、定义与编译器无光的数据类型
只是按照不同的编译器编写对应的数据类型的typedef 对应于ARM7的数据类型的编写如下
typedef unsigned char BOOLEAN;/* 布尔变量*/
typedef unsigned char INT8U; /* 无符号8位整型变量*/
typedef signed char INT8S; /* 有符号8位整型变量*/
typedef unsigned short INT16U; /* 无符号16位整型变量*/
typedef signed short INT16S; /裤返举* 有符号16位整型变量*/
typedef unsigned int INT32U; /* 无符号32位整型变量*/
typedef signed int INT32S; /* 有符号32位整型变量*/
typedef float FP32; /*单精度浮点数(32Bit)*/
typedef double FP64; /*双精度浮点数(64Bit)*/
/*在上面定义的数据类型中按照ARM7的堆栈宽度选择INT32U*/
typedef INT32U OS_STK; /* 堆栈是32位宽度*/
接下来一部分是为了兼容低版本UCOS的数据类型所编写的代码，在UCOS-II中暂不考虑
2 与处理器相关的代码
先定义中断的实现方式，预先设定的中断方式有三种，在ARM7中设置为方式 2
#define OS_CRITICAL_METHOD 2/*选择开,关中断的方式 */
接下来的一段是我暂时还没有完全搞懂的一部分,只知道是设定了12个软件中断的函数,当调用这
些函数之前都会执行对应中断号的事情。具体的看到后面应该能完全搞懂软件中断的实现方式，
该段代码在后面的文件中会有具体的解释，这里暂时不看
定义堆世塌栈的生长方式，ARM7内核支持两种生长方式，但是ADS的C语言编译器只支持从上往下的生
长方式，因此：
#define OS_STK_GROWTH 1 /* 堆栈是从上往下长的，0－从下往上的生长方式 */
最后几行分别定义了用户模式01和系统模式1f以及IRQ中断禁止的指令80三个立即数，方便调用.
还有两个预定义往胡碧后看应该知道作用，暂不考虑，不是很重要.
软中断：
中断不返回形式：
void _swi(swi_num) swi_name(arguments);
返回一个结果到R0中
int _swi(swi_num) swi_name(arguments);
最多可以返回四个结果R0-R3到一个结构struct type{ int a,b,c,d}中
type(返回类型) _value_in_regs(返回多个结果的修饰符) _swi(swi_num) swi_name(arguments);
在ARM中实现软中断的方法我在blog里面搜了很多文章也没有看到讲的通俗一点的，还是自己看
ARM的移植代码吧首先定义了一堆软中断的中断号，其中0和1的中断服务子程序是用汇编编写的，
其他的都是在c语言编写的中断服务子程序SWI_Exception中。
__swi(0x00) void OS_TASK_SW(void);
/* 任务级任务切换函数 */
__swi(0x01) void _OSStartHighRdy(void);
/* 运行优先级最高的任务 */
__swi(0x02) void OS_ENTER_CRITICAL(void);
/* 关中断 */
__swi(0x03) void OS_EXIT_CRITICAL(void);
/* 开中断 */
__swi(0x40) void *GetOSAddr(int Index);
/* 获取系统服务函数入口 */
__swi(0x41) void *GetUsrAddr(int Index);
/* 获取自定义服务函数入口 */
__swi(0x42) void OSISRBegin(void);
/* 中断开始处理 */
__swi(0x43) int OSISRNeedSwap(void);
/* 判断中断是否需要切换 */
__swi(0x80) void ChangeToSYSMode(void);
/* 任务切换到系统模式 */
__swi(0x81) void ChangeToUSRMode(void);
/* 任务切换到用户模式 */
__swi(0x82) void TaskIsARM(INT8U prio);
/* 任务代码是ARM代码 */
__swi(0x83) void TaskIsTHUMB(INT8U prio);
/* 任务代码是THUMB */
比如在程序运行到调用OS_TASK_SW(void)函数时,就产生软件中断,然后就进入中断服务子程序，
按照什么指令走呢？恩，就按照下面这个代码，这个代码是将软件中断异常处理程序挂接到内核
的作用的，是在启动代码中实现的：
LDR PC，SWI_Addr
SWI_Addr DCD SoftwareInterrupt
因此当产生软中断之后PC就跳到了SoftwareInterrupt,这时就算真正进入了软件异常中断处理部
分了，然后就是执行下面的汇编代码SoftwareInterrupt
LDR SP, StackSvc
/*重新设置堆栈指针*/
STMFD SP!, {R0-R3, R12, LR}
/*保存 R0,R1,R2,R3,R12,LR(R14),注意为什么只保存这几个
寄存器呢，因为R4-R11存储局部变量,编译器自动保护他们*/
MOV R1, SP /* R1指向参数存储位置 */
MRS R3, SPSR /*保存管理模式的状态寄存器*/
TST R3, #T_bit /* 中断前是否是Thumb状态 */
LDRNEH R0, [LR,#-2] /* 若是,取得Thumb状态SWI号*/
BICNE R0, R0, #0xff00 /*THUMB指令SWI功能号为8位 */
LDREQ R0, [LR,#-4] /* 为零即ARM指令取得SWI号 */
BICEQ R0, R0, #0xFF000000
/*在ARM指令集中SWI功能号为24位所以高8位清零r0=SWI号*/
CMP R0, #1 /*
LDRLO PC, =OSIntCtxSw /* 疑惑ing */
/* 功能号为0到OSIntCtxSw执行中断任务切换函数 */
LDREQ PC, =__OSStartHighRdy/*SWI为1第一次任务切换*/
BL SWI_Exception /*否则进入c编写的中断函数 */
LDMFD SP!, {R0-R3, R12, PC}/*R0-R3，R12，LR出栈 */
StackSvc
DCD (SvcStackSpace + SVC_STACK_LEGTH * 4 - 4)
怎么进入c编写的中断服务子程序SWI_Exception呢？通过下面的申明
IMPORT SWI_Exception ;软中断异常处理程序
表示将c程序中的该函数挂接到此段汇编代码中,同样的道理
EXPORT __OSStartHighRdy
EXPORT OSIntCtxSw ;中断退出时的入口
参见startup.s中的IRQ_Handler
EXPORT SoftwareInterrupt ;软中断入口上面的申明是将该段汇编代码挂接到外面，
因此在外部可以直接调用函数名
继续看OS_CPU_A.S的其他部分代码，就是两个软件异常中断处理函数OSIntCtxSw和OSStarHighRdyOSIntCtxSw代码是中断服务子程序使得更高优先级的任务进入就绪状态后，中断返回后需要切换到该任务时调用的，这是被切换的任务的CPU寄存器的值已经在响应中断后存入了堆栈中，因此，这里不需要重复保存了直接切换任务即可，具体过程看代码OSIntCtxSw
;下面为保存任务环境 ;当响应软件异常中断后进入了系统模式，在上面的代码中我们可以看到，进入系统模式时保存的堆栈结构从顶到底依次是：R0,R1,R2,R3,R12,LR，而在用户模式中任务的堆栈结构应该是：OsEnterSum,CPSR,RO-12,LR,PC，所以在进行软件中断任务切换之前先要保存原来任务的堆栈结构。
LDR R2, [SP, #20] ;获取PC
LDR R12, [SP, #16] ;获取R12
MRS R0, CPSR MSR CPSR_c, #(NoInt | SYS32Mode)
MOV R1, LR
STMFD SP!, {R1-R2} ;保存LR,PC
STMFD SP!, {R4-R12} ;保存R4-R12 MSR CPSR_c, R0
LDMFD SP!, {R4-R7} ;获取R0-R3
ADD SP, SP, #8 ;出栈R12,PC
MSR CPSR_c, #(NoInt | SYS32Mode)
STMFD SP!, {R4-R7} ;保存R0-R3
LDR R1, =OsEnterSum ;获取OsEnterSum
LDR R2, [R1]
STMFD SP!, {R2, R3} ;保存CPSR,OsEnterSum ;保存当前任务堆栈指针到当前任务的TCB
LDR R1, =OSTCBCur
LDR R1, [R1]
STR SP, [R1] BL OSTaskSwHook ;调用钩子函数
;OSPrioCur <= OSPrioHighRdy
LDR R4, =OSPrioCur
LDR R5, =OSPrioHighRdy
LDRB R6, [R5]
STRB R6, [R4]
;OSTCBCur <= OSTCBHighRdy
LDR R6, =OSTCBHighRdy
LDR R6, [R6]
LDR R4, =OSTCBCur
STR R6, [R4]
OSIntCtxSw_1
;获取新任务堆栈指针
LDR R4, [R6]
ADD SP, R4, #68 ;17寄存器CPSR,OsEnterSum,R0-R12,LR,SP
LDR LR, [SP, #-8]
MSR CPSR_c, #(NoInt | SVC32Mode) ;进入管理模式
MOV SP, R4 ;设置堆栈指针 LDMFD SP!, {R4, R5} ;CPSR,OsEnterSum
;恢复新任务的OsEnterSum
LDR R3, =OsEnterSum
STR R4, [R3]
MSR SPSR_cxsf, R5 ;恢复CPSR
LDMFD SP!, {R0-R12, LR, PC }^ ;运行新任务
__OSStartHighRdy
MSR CPSR_c, #(NoInt | SYS32Mode) ;调整到管理模式
;告诉uC/OS-II自身已经运行
LDR R4, =OSRunning
MOV R5, #1
STRB R5, [R4] ;标记多任务运行标记为真 BL OSTaskSwHook ;调用钩子函数，可以运行用户自定义的函数 LDR R6, =OSTCBHighRdy ;R6存有最高优先级的就绪任务的控制块地址
LDR R6, [R6]
B OSIntCtxSw_1 ;转到前面编写的中断返回函数块的任务跳转部分的代码，因为这两个函数都要用到这部分代码，进入这段代码之前高优先级的就绪任务的任务控制快地址存在R6中。 AREA SWIStacks, DATA, NOINIT,ALIGN=2
SvcStackSpace SPACE SVC_STACK_LEGTH * 4 ;管理模式堆栈空间 OSIntCtxSw_1的代码：OSIntCtxSw_1
;获取新任务堆栈指针
LDR R4, [R6] ;任务控制块的堆栈指针放在R6中，现在放在R4中
ADD SP, R4, #68 ;17寄存器CPSR,OsEnterSum,R0-R12,LR,SP
LDR LR, [SP, #-8]
MSR CPSR_c, #(NoInt | SVC32Mode) ;进入管理模式
MOV SP, R4 ;设置堆栈指针，R4存有没有改动过的堆栈指针 LDMFD SP!, {R4, R5} ;CPSR,OsEnterSum
;恢复新任务的OsEnterSum
LDR R3, =OsEnterSum
STR R4, [R3]
MSR SPSR_cxsf, R5 ;恢复CPSR
LDMFD SP!, {R0-R12, LR, PC }^ ;运行新任务，恢复现场，异常处理返回；中断返回指令的寄存器列表其中必须包括PC后的^符号，表示这是一条特殊形式的指令。这条指令在从存储器中装载PC的同时，CPSR也得到恢复。这里使用的堆栈指针SP是属于异常模式的寄存器，每个异常模式有自己的堆栈指针。SoftwareInterrupt
LDR SP, StackSvc ; 重新设置堆栈指针
STMFD SP!, {R0-R3, R12, LR} ;保存寄存器
MOV R1, SP ; R1指向参数存储位置 MRS R3, SPSR
TST R3, #T_bit ; 中断前是否是Thumb状态
LDRNEH R0, [LR,#-2] ; 是: 取得Thumb状态SWI号
BICNE R0, R0, #0xff00
LDREQ R0, [LR,#-4] ; 否: 取得arm状态SWI号
BICEQ R0, R0, #0xFF000000
; r0 = SWI号，R1指向参数存储位置
CMP R0, #1
LDRLO PC, =OSIntCtxSw
LDREQ PC, =__OSStartHighRdy ; SWI 0x01为第一次任务切换 BL SWI_Exception
LDMFD SP!, {R0-R3, R12, PC}^
StackSvc DCD (SvcStackSpace + SVC_STACK_LEGTH * 4 - 4)OSIntCtxSw
;下面为保存任务环境
LDR R2, [SP, #20] ;获取PC（LR）
LDR R12, [SP, #16] ;获取R12
MRS R0, CPSR MSR CPSR_c, #(NoInt | SYS32Mode)
MOV R1, LR
STMFD SP!, {R1-R2} ;保存LR,PC
STMFD SP!, {R4-R12} ;保存R4-R12 MSR CPSR_c, R0
LDMFD SP!, {R4-R7} ;获取R0-R3
ADD SP, SP, #8 ;出栈R12,PC
MSR CPSR_c, #(NoInt | SYS32Mode)
STMFD SP!, {R4-R7} ;保存R0-R3
LDR R1, =OsEnterSum ;获取OsEnterSum
LDR R2, [R1]
STMFD SP!, {R2, R3} ;保存CPSR,OsEnterSum ;保存当前任务堆栈指针到当前任务的TCB
LDR R1, =OSTCBCur
LDR R1, [R1]
STR SP, [R1] BL OSTaskSwHook ;调用钩子函数
;OSPrioCur <= OSPrioHighRdy
LDR R4, =OSPrioCur
LDR R5, =OSPrioHighRdy
LDRB R6, [R5]
STRB R6, [R4] ;把OSPrioHighRdy最高优先级的就绪任务传给OSPrioCur
;OSTCBCur <= OSTCBHighRdy
LDR R6, =OSTCBHighRdy
LDR R6, [R6]
LDR R4, =OSTCBCur
STR R6, [R4] ;将最高优先级的任务控制块指针传给当前任务控制块指针
关于中断和时钟节拍，UCOS-II对于ARM7通用的中断服务程序的汇编与c函数接口如下：MACRO和MEND伪指令用于宏定义，MACRO标识宏定义的开始，MEND标识宏定义的结束。定义之后在程序中就可以通过宏指令多次调用该段代码MACRO
$IRQ_Label HANDLER $IRQ_Exception_ EXPORT $IRQ_Label ; 输出的标号
IMPORT $IRQ_Exception_ ; 引用的外部标号$IRQ_Label
SUB LR, LR, #4 ; 计算返回地址
STMFD SP!, {R0-R3, R12, LR} ; 保存任务环境
MRS R3, SPSR ; 保存状态
STMFD SP, {R3, SP, LR}^ ; 保存用户状态的R3,SP,LR,注意不能回写
; 如果回写的是用户的SP，所以后面要调整SP
LDR R2, =OSIntNesting ; OSIntNesting++
LDRB R1, [R2]
ADD R1, R1, #1
STRB R1, [R2] SUB SP, SP, #4*3
MSR CPSR_c, #(NoInt | SYS32Mode) ; 切换到系统模式
CMP R1, #1
LDREQ SP, =StackUsr
BL $IRQ_Exception_ ; 调用c语言的中断处理程序 MSR CPSR_c, #(NoInt | SYS32Mode) ; 切换到系统模式
LDR R2, =OsEnterSum ; OsEnterSum,使OSIntExit退出时中断关闭
MOV R1, #1
STR R1, [R2] BL OSIntExit LDR R2, =OsEnterSum ; 因为中断服务程序要退出，所以OsEnterSum=0
MOV R1, #0
STR R1, [R2] MSR CPSR_c, #(NoInt | IRQ32Mode) ; 切换回irq模式
LDMFD SP, {R3, SP, LR}^ ; 恢复用户状态的R3,SP,LR,注意不能回写
; 如果回写的是用户的SP，所以后面要调整SP
LDR R0, =OSTCBHighRdy
LDR R0, [R0]
LDR R1, =OSTCBCur
LDR R1, [R1]
CMP R0, R1 ADD SP, SP, #4*3 ;
MSR SPSR_cxsf, R3
LDMEQFD SP!, {R0-R3, R12, PC}^ ; 不进行任务切换
LDR PC, =OSIntCtxSw ; 进行任务切换
MEND二：OS_CPU_C.C 个文件中要求用户编写10个简单的C函数，但是只有1个函数是必要的，其余的函数必须声明，但不一定要包含任何代码，大致看了一下作用好像是用来调试之类的。唯一要编写的是OSTaskStkInit（） OSTaskStkInit（）函数的功能是初始化任务的栈结构，任务的堆栈结构与CPU的体系结构、编译器有密切的关联。从ARM的结构可以写出如下的栈结构：程序计数器PC，程序链接器LR，R12－R1，R0用于传递第一个参数pdata，CPSR/SPSR，关中断计数器（用于计算关中断的次数，这样就实现了中断的嵌套），返回的地址指针是指向的最后一个存入的数据，而不是一个空地址。软件中断异常SWI服务程序C语言部分 void SWI_Exception(int SWI_Num, int *Regs)：参数SWI_Num对应前面文件中定义的功能号，其中0、1号的功能在后面的文件中定义，这里只定义了其他10个功能。 2、3分别对应关中断和开中断 关中断：MRS R0, SPSR //在软件中断的时候直接对程序状态保存寄存器SPSR操作也就是对CPSR的操作
ORR R0, R0, #NoInt //在汇编语言中对寄存器的对应位置位用ORR，清零用BIC
MSR SPSR_c, R0 //SPSR_c表示的是只改变SPSR的控制段的8位代码，其他三段_f，_s，_x中标志位在_f段，其他为保留位 开中断：MRS R0, SPSR //在开中断中基本与上面相同，只是ORR改成BIC清零
BIC R0, R0, #NoInt
MSR SPSR_c, R 由于需要实现中断嵌套，所以只有当关中断的计数器减为0的时候才能够开中断，而且每次关中断的时候该计数器都应该加1。另外，插入汇编语言时用_asm指令。 80、81、82、83分别对应系统模式、用户模式、ARM指令集、THUMB指令集 系统模式：MRS R0, SPSR
BIC R0, R0, #0x1f //先将控制模式的低5位清零
ORR R0, R0, #SYS32Mode //设置成系统模式的1F
MSR SPSR_c, R0 用户模式：MRS R0, SPSR
BIC R0, R0, #0x1f
ORR R0, R0, #USR32Mode //设置成用户模式的10
MSR SPSR_c, R0 ARM指令集与THUMB指令集的代码如下： ptcb = OSTCBPrioTbl[Regs[0]];
if (ptcb != NULL)
{
ptcb -> OSTCBStkPtr[1] &= ~(1 << 5);
} ptcb = OSTCBPrioTbl[Regs[0]];
if (ptcb != NULL)
{
ptcb -> OSTCBStkPtr[1] |= (1 << 5);
} 昨天就是看到这里，出现了一个意识到是不能忽悠的地方就是UCOS里面的任务控制块OS_TCB的概念，因此今天的任务就是把这部分看看。。。 大概回忆了一下昨天晚上的工作，开始今天的工作吧
一点一点来，什么不会就学什么，都不会就都学。。。没有问题只要你肯努力。。。。。。__OSStartHighRdy
MSR CPSR_c, #(NoInt | SYS32Mode) ;MSR：在ARM中只有MSR能够直接设置状态寄存器CPSR或SPSR，可以是立即数或者源寄存器，NoInt是禁止中断，SYS32Mode是系统模式
;告诉uC/OS-II自身已经运行
LDR R4, =OSRunning ;OSRunning正在运行多任务的标志，＝OSRunning是把OSRunning的地址加载到R4，R4里存的是一个地址。。。
MOV R5, #1
STRB R5, [R4] ;将R5存储到R4存的地址的变量即OSRunning中，也就是将OSRunning置1 BL OSTaskSwHook ;调用钩子函数，OSTaskSwHook 是用于扩展的，在任务切换的时候执行用户自己定义的功能。 LDR R6, =OSTCBHighRdy ;OSTCBHighRdy指向最高优先级任务的控制块TCB的指针！！！将放指针的地址放到R6中。
LDR R6, [R6] ;将R6地址处的数据读出即OSTCBHighRdy的地址放到R6中
B OSIntCtxSw_1 ;跳转到OSIntCtxSw_1 AREA SWIStacks, DATA, NOINIT,ALIGN=2
SvcStackSpace SPACE SVC_STACK_LEGTH * 4 ;管理模式堆栈空间继续昨天没有看完的代码OSIntCtxSw
;下面为保存任务环境
LDR R2, [SP, #20] ;获取PC，放入R2
LDR R12, [SP, #16] ;获取R12，//R12存的什么东西啊？？？
MRS R0, CPSR MSR CPSR_c, #(NoInt | SYS32Mode) ;进入系统模式并禁止中断
MOV R1, LR ;R1放LR值
STMFD SP!, {R1-R2} ;保存LR,PC，将R1，R2存入SP
STMFD SP!, {R4-R12} ;保存R4-R12，将R4-12存入SP MSR CPSR_c, R0 ;再回到之前的模式
LDMFD SP!, {R4-R7} ;获取R0-R3
ADD SP, SP, #8 ;出栈R12,PC
MSR CPSR_c, #(NoInt | SYS32Mode)
STMFD SP!, {R4-R7} ;保存R0-R3
LDR R1, =OsEnterSum ;获取OsEnterSum
LDR R2, [R1]
STMFD SP!, {R2, R3} ;保存CPSR,OsEnterSum ;保存当前任务堆栈指针到当前任务的TCB
LDR R1, =OSTCBCur
LDR R1, [R1]
STR SP, [R1] BL OSTaskSwHook ;调用钩子函数
;OSPrioCur <= OSPrioHighRdy
LDR R4, =OSPrioCur
LDR R5, =OSPrioHighRdy
LDRB R6, [R5]
STRB R6, [R4]
;OSTCBCur <= OSTCBHighRdy
LDR R6, =OSTCBHighRdy
LDR R6, [R6]
LDR R4, =OSTCBCur
STR R6, [R4]
OSIntCtxSw_1
;获取新任务堆栈指针
LDR R4, [R6] ;把OSTCBHighRdy指向最高优先级任务的控制块TCB的指针给R4
ADD SP, R4, #68 ;17寄存器：CPSR,OsEnterSum,R0-R12,LR,SP
LDR LR, [SP, #-8] ;取出LR放到LR
MSR CPSR_c, #(NoInt | SVC32Mode) ;进入管理模式并且保持禁止中断
MOV SP, R4 ;设置堆栈指针 LDMFD SP!, {R4, R5} ;CPSR,OsEnterSum。LDMFD数据出栈，放入R4，R5
;恢复新任务的OsEnterSum
LDR R3, =OsEnterSum ;OsEnterSum的地址存入R3
STR R4, [R3] ;把R4的值赋给OsEnterSum
MSR SPSR_cxsf, R5 ;恢复CPSR；在管理模式里是修改SPSR
LDMFD SP!, {R0-R12, LR, PC }^ ;运行新任务 ，恢复现场，异常处理返回
D. 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应视所开发的项目而定，对于一些简单的、低成本的项目来说，就没必要使用嵌入式操作系统了。
E. AIX是一个什么样的系统麻烦给点详细的资料
AIX 全名为（Advanced Interactive Executive），它是IBM 公司的Unix操作系统，
整个系统的设计从网络、主机硬件系统，到操作系统完全遵守开放系统的原则。
下面对AIX 作以介绍。
RS/6000 采用IBM 的UNIX操作系统-AIX作为其操作系统。这是一
个目前操作系统界最成功，应用领域最广，最开放的第二代的UNIX系
统。它特别适合于做关键数据处理（CRITICAL）。
AIX 包含了许多IBM 大型机传统受欢迎的特征，如系统完整性，系统可管理
性和系统可用性。
在 AIX 操作系统上，有许多的数据库和开发工具，用户除了选用已有的应用
软件外，还可以根据各自的需要进行开发。
此外，在AIX 之上，有一组功能强，使用方便的系统管理工具。对于异种平台
互存，互操作有很成熟的解决方案。
由于该 UNIX 的先进的内核技术和最好的开放性，因此，虽然RS/6000
从宣布到今天只有短短的5 年多的时间携慧陪，它已在各行各业有了广泛的运用，
并在1993和1994年连续二年在MIDRANGE商用 UNIX 领域处于第一位。
RISC SYSTEM/6000的操作系统是AIX ，它是性能卓越的、开放的
UNIX，汇集了多年来计算机界在UNIX上的研究成果，以IBM 在计算机
体系结构、操作系统方面40多年极其丰富的经验。最大限度的使用RISC
技术，安装了象AIX 这样的具备工业界实力的UNIX操作系统。
它既可连接SAA 体系结构，又能与非IBM 系统的网络相连，因此，可以
和多数专业银行现有的系统实现互连，这对今后业务系统拓展将带来极大的
灵活性，并降低投资。
AIX 遵循一系列的国际标准：
* IEEE POSIX1004.1－碧碰1990
* X/OPEN 移植指南ISSUE3的基本级（XPG3）
* AES/OS REVISION A （OSF/1 LEVEL 2 资格）
* FIPS 151－1
* AIX的编译器： XLC、C++(可选)、FORTRAN(可选)、PASCAL(可选)、COBOL(可选)
* ADA 的编译器已达到XPG3“成员”级的认可。
* AIX 支持多用户、多任务。
AIX有一些其它特性包括：
AIX 提供了3 种SHELL ：SYSTEM V的KORN、BOURNE SHELL和4.3BSDC
SHELL作为可选择的UNIX系统界面；
安全设施满足TCB （Trusted Computing Base）的C2级；
实时处理能力，这对于“面向交易”的应用至关重要（如零售业
和银行等），它使RS/6000 获得极高的响应和吞吐量；
虚拟存储管理，当需要时，可将一些不常用的模块转送至外存，
提高内存的可利用性。
先进的文件系统，使得系统管理更加有效，并提高了数据可靠性
以及完整性。
能兼容Dos 应用程序和数据。
InfoExplorer，快速信息超文本索引系统- 不仅包括文字，而且
对包含声音、图像的索引辩蠢系统，这是个联机的文件接口。包括全部的
超文本的索引和查找，以及面向任务和坐标的多重导引和索引系统。
这个文字及图形索引系统以一个灵活的、基于任务的方式去使用详细
资料及培训资料。
高级系统管理工具（SMIT，System Management Interface Tool）。
提供一级菜单驱动程序，诸如完成软件的安装与设置、设备的设置及
管理、问题的测定、存贮管理等。可以自动地进行I/O 设备设置，
ASCII 终端也可充当系统控制台。在LAN 上可以进行远程系统的安装。
系统工作负载
系统工作负载的完整准确的定义对于预测或理解它的性能是很关键的。在衡量系统性能时，工作负载的不同可能会比 CPU 时钟速度或随机访问存储器（RAM）大小不同带来更多的变化。工作负载的定义不仅必须包含向系统发送的请求的类型和速率，还要包含将要执行的确切软件包和内部应用程序。
包括系统将在后台处理的工作也很重要。例如，如果一个系统包含通过 NFS 加载且由其它系统频繁访问的文件系统，那么处理那些访问很可能是总体工作负载中非常重要的一部分，即使该系统不是正式的服务器也是如此。
已进行标准化从而允许在不同系统之间进行比较的工作负载称为基准程序。但是，很少有实际的工作负载能完全符合基准程序的精确算法和环境。即使是那些最初从实际的应用程序发展而来的行业标准基准程序也已经过简化和均匀化，从而使它们可移植到大量的硬件平台上。使用行业标准基准程序唯一有效的方法是减小将接受严肃评估的候选系统的范围。因此，在尝试理解系统的工作负载和性能时不应该只依赖基准测试结果。
可以将工作负载分为以下类别：
多用户
由多个用户通过各自的终端提交的工作组成的工作负载。通常，这种工作负载的性能目标有两种可能，即在保留指定的最坏情况响应时间条件下最大化系统吞吐量，或者对于固定不变的工作负载获得尽可能快的响应时间。
服务器
由来源于其它系统的请求组成的工作负载。例如，文件服务器的工作负载主要是磁盘读写请求。它是多用户工作负载（加上 NFS 或其它 I/O 活动）的磁盘 I/O 部分，所以适用同样的目标，即在给定的相应时间限制下最大化吞吐量。其它的服务器工作负载由诸如数学计算密集的程序、数据库事务、打印机作业之类的项组成。
工作站
由单独的用户通过键盘提交工作和在该系统的显示器上接收结果组成的工作负载。通常这种工作负载的最高优先级性能目标是使用户请求的响应时间最短。
性能目标
在定义了系统必须处理的工作负载后，可以选择性能标准并根据这些标准设定性能目标。计算机系统的总体性能标准是响应时间和吞吐量。
响应时间是提交请求和返回该请求的响应之间使用的时间。示例包括：
数据库查询花费的时间
将字符回显到终端上花费的时间
访问 Web 页面花费的时间
吞吐量是对单位时间内完成的工作量的量度。示例包括：
每分钟的数据库事务
每秒传送的文件千字节数
每秒读或写的文件千字节数
每分钟的 Web 服务器命中数
这些度量之间的关系很复杂。有时可能以响应时间为代价而得到较高的吞吐量，而有时候又要以吞吐量为代价得到较好的响应时间。在其它情况下，一个单独的更改可能对两者都有提高。可接受的性能基于合理的吞吐量与合理的响应时间相结合。
在规划或调谐任何系统中，当处理特定的工作负载时一定要保证对响应时间和吞吐量都有明确的目标。否则，有可能存在一种风险，那就是您花费了分析时间和物力改善的仅仅是系统性能中一个次要的方面。
程序执行模型
为了清楚地检查工作负载的性能特征，需要有一个动态而非静态的程序执行模型，如下图所示。
图 1. 程序执行层次结构. 该图形以一个三角形为基础。左边代表和右边适当的操作系统实体匹配的硬件实体。程序必须从存储在磁盘上的最低级别开始，到最高级别的处理器运行程序指令。例如，从底部到顶部，磁盘硬件实体容纳可执行程序；实内存容纳等待的操作系统线程和中断处理程序；转换后备缓冲区容纳可分派的结程；高速缓存中包含当前分派的线程和处理器流水线；而寄存器中包含当前的指令。
程序为了运行必须沿着硬件和操作系统层次结构并行向上前进。硬件层次结构中的每个元素都比它下面的元素稀少和昂贵。不仅程序不得不为了每个资源和其它程序竞争，而且从一个级别过渡到下一级别也要花时间。为了理解程序执行动态，需要对层次结构中每一级别有个基本的了解。
硬件层次结构
通常，从一个硬件级别移动到另一级别所需要的时间主要由较低级别的等待时间（从发出请求到接受到第一批数据的时间）组成。
固定磁盘
对于一个在单机系统中运行的程序而言，最慢的操作是从磁盘上取得代码或数据，这是因为有下列原因：
必须引导磁盘控制器直接访问指定的块（排队延迟）。
磁盘臂必须寻道以找到正确的柱面（寻道等待时间）。
读／写磁头必须等候直到正确的块旋转到它们下面（旋转等待时间）。
数据必须传送到控制器（传送时间）然后传递到应用程序中（中断处理时间）。
除了程序中显式的读或写请求以外，还有许多原因导致磁盘操作缓慢。频繁的系统调谐活动证明是不必要地跟踪了磁盘 I/O。
实内存
实内存通常称为随机存取存储器或 RAM，它比磁盘速度快，但每个字节的开销非常昂贵。操作系统尽量只把当前使用的代码和数据保存在 RAM 中，而把任何额外的内容存储在磁盘上，或者决不首先把它们带入 RAM 中。
然而，RAM 的速度不一定比处理器快。通常在硬件意识到 RAM 访问需求与处理器可使用数据或指令的时间之间，会出现许多处理器周期的 RAM 等待时间。
如果要访问存储到磁盘上（或者尚未调进）的某一虚拟内存页，则会产生一个缺页故障，并且程序的执行暂挂直到该页从磁盘读取。
转换后备缓冲区（TLB）
使程序员不会受限于系统的物理局限性的方法是实现虚拟内存。程序员在设计和编写程序时认为内存非常大，系统将负责将程序中指令和数据的虚拟地址转换成需要用来从 RAM 取得的指令和数据的实际地址。因为这个地址转换过程可能很费时，系统将最近访问过的虚拟内存页的实际地址保存在一个叫转换后备缓冲区（TLB）的高速缓存中。
只要运行中的程序继续访问程序和数据页中的一小部分，则完整的从虚拟到实际页地址的转换过程就不需要在每次 RAM 访问的时候都重做一次。当程序试图访问的虚拟内存页没有 TLB 入口（即 TLB 未命中）时，则需要大量的处理器周期（即 TLB 未命中等待时间）来进行地址转换。
高速缓存
为了将程序必须经历的 RAM 等待时间减到最小，系统为指令和数据组织了高速缓存。如果所需的指令和数据已在高速缓存中，则产生高速缓存命中，处理器就可在下一个周期立刻使用该指令或数据。否则产生高速缓存未命中，伴随有 RAM 等待时间。
在某些系统中，有两到三级高速缓存，通常称它们为 L1、L2 和 L3。如果一个特殊的存储器引用导致 L1 未命中，则检查 L2。如果 L2 产生未命中，则引用转至下一个级别，要么是 L3（如果存在），要么是 RAM。
高速缓存的大小和结构根据型号的不同而有不同，但是有效使用它们的原理是相同的。
流水线和寄存器
流水线型超标量体系结构使得在某些情况下可以同时处理多个指令。大批的通用寄存器和浮点寄存器使得可以将相当多的程序数据保存在寄存器中，而不需要频繁存储和重新装入。
可以设计优化编译器最大限度地利用这些能力。当生成产品程序时，无论程序有多小编译器的优化函数都应该能使用。Optimization and Tuning Guide for XL Fortran, XL C and XL C++ 中描述了如何将程序调谐到最大性能。
软件层次结构
程序为了运行还必须逐步执行软件层次结构中的一系列步骤。
可执行程序
当请求运行某个程序时，操作系统执行一些操作以将磁盘上的可执行程序转换成运行中的程序。首先，必须扫描当前 PATH 环境变量中的目录以查找程序的正确副本。然后，系统装入程序（不要和 ld 命令混淆，该命令是个绑定程序）必须解析出从程序到共享库的任何外部引用。
为了表示用户的请求，操作系统将创建一个进程或一组资源（例如专用虚拟地址段），任何运行中的程序都需要该进程或资源。
操作系统也会在该进程中自动创建一个单独的线程。线程是一个单独程序实例的当前执行状态。在 AIX 中，对处理器和其它资源的访问是根据线程来分配而不是根据进程分配的。应用程序可在一个进程中创建多个线程。这些线程共享由运行它们的进程所拥有的资源。
最后，系统转移到程序的入口点。如果包含入口点的程序页还不在内存中（可能因为程序最近才编译、执行和复制），则由它引起的缺页故障中断将该页从它的后备存储器中读取出来。
中断处理程序
通知操作系统发生了外部事件的机制是中断当前运行线程并将控制转移到中断处理程序。在中断处理程序可以运行之前，必须保存足够的硬件状态以保证在中断处理完成后系统能恢复线程的上下文。新调用的中断处理程序将经历在硬件层次结构中上移带来的所有延迟（除了页面故障）。如果该中断处理程序最近没有运行过（或者中间程序很节约时间），那么它的任何代码或数据不太可能保留在 TLB 或高速缓存中。
当再次调度已中断的线程时，它的执行上下文（如寄存器内容）逻辑上将得到恢复，以便它可以正确运行。然而，TLB 和高速缓存的内容必须根据程序的后继请求重新构造。因此，作为中断的结果，中断处理程序和被中断的线程都可能遇到大量的高速缓存未命中和 TLB 未命中延迟。
等待线程
无论何时只要执行的程序发出不能立刻满足的请求，例如同步 I/O 操作（显式的或缺页故障的结果），该线程就会处于等待状态，直到请求完成为止。除了请求本身所需的时间以外，通常这还会导致另外一些 TLB 和高速缓存的延迟时间。
可分派线程
当某个线程可分派但不在运行时，它不能完成任何有用的事情。更糟的是，正运行的其它线程可能导致重新使用该线程的高速缓存线路并将实内存页收回，从而引起最终分派时出现更多的延迟。
当前已分派的线程
调度程序选择对使用处理器有强烈要求的线程。在‘CPU 调度程序性能概述’中讨论了影响该项选择需要考虑的事项。当分派线程后，处理器的逻辑状态恢复成线程中断时有效的状态。
当前的机器指令
如果未出现 TLB 或高速缓存未命中的情况，绝大多数机器指令都能在单个处理器周期内执行。相比之下，如果程序迅速转换到该程序的不同区域且访问大量不同区域中的数据，就会产生较高的 TLB 和高速缓存未命中率，执行每条指令使用的平均处理器周期数（CPI）可能大于 1。这种程序被认为有较差的局域性引用能力。它也许在使用必需的最少指令数来做这个工作，但是要消耗大量不必要的周期数。部分是因为指令数和周期数之间相关性较弱，检查程序列表来计算路径长度不会再直接产生一个时间值。由于较短的路径通常比较长的路径快，所以速率根据路径长度率的不同而明显不同。
编译器用完善的方法重新安排代码从而将程序执行所需的周期数降到最小。追求最佳性能的程序员必须首先致力于确保编译器具有有效优化代码所需的全部信息，而不是试图事后批评编译器的优化技术（请参阅‘预处理器和编译器的有效使用’）。优化有效性的实际衡量标准是可信工作负载的性能。
系统调谐
在有效实现应用程序后，系统总体性能的进一步提高就成了系统调谐考虑的一个问题。系统级调谐包含的主要组件有：
通信 I/O
取决于工作负载的类型与通信链路的类型，可能需要调谐以下的一个或多个通信设备驱动程序：TCP/IP 或 NFS。
固定磁盘
逻辑卷管理器（LVM）控制文件系统的位置和磁盘上调页空间，这可能会极大地影响系统经历的寻道等待时间。磁盘设备驱动程序控制执行 I/O 请求所遵从的顺序。
实内存
虚拟内存管理器（VMM）控制空闲实内存帧的池，并决定何时从何处取用帧来补充该池。
运行线程
调度程序确定接下来由哪个可调度实体接收控制权。在 AIX 中，可调度实体是线程。请参阅‘线程支持’。
性能调谐过程介绍
性能调谐主要是资源管理问题和正确的系统参数设置。调谐工作负载和系统以有效利用资源由下列步骤组成：
识别系统中的工作负载
设置目标：
确定如何评测结果
量化目标和区分目标的优先级
识别限制系统性能的关键资源
最小化工作负载的关键资源要求：
如果可选择的话，使用最适当的资源
减少个别程序或系统函数对关键资源的要求
结构化资源的并行使用
修改资源的分配以反映优先级
更改个别程序的优先级或资源限制
更改系统资源管理参数的设置
重复步骤 3 到步骤 5 直到满足目标（或者资源饱和）
如果必要的话，使用其它资源
在系统性能管理的每个阶段都有相应的工具（参阅附录 A ‘监视和调谐命令和子例程’）。这些工具有些可从 IBM 得到；另一些是第三方产品。下图说明在一个简单的 LAN 环境中性能管理的各阶段。
图 2. 性能阶段. 该图用五个加权的圆圈说明对系统性能调谐的各步骤：规划、安装、监视、调谐和扩展。每个圆圈代表系统处于不同的性能状态：空闲、不均衡、均衡和过载。实质上就是扩展一个过载的系统、调谐系统直到它是均衡的、监视不均衡的系统并且在需要扩展时安装更多的资源。
识别工作负载
系统执行的所有工作都必须能够识别。特别是在 LAN 连接的系统中，通过系统的用户之间仅有的非正式协议，可以轻松地开发出一组复杂的交叉安装的文件系统。这些文件系统必须被识别出来并作为任何调谐活动的一部分进行考虑。
对于多用户工作负载，分析员必须量化一般情况和高峰期的请求率。确定用户实际与终端交互时间的实际比例也是很重要的。
该识别阶段中的一个要素是决定必须对生产系统进行评估和调谐活动，还是在另一系统上（或“切换”）用实际工作负载的模拟型式来完成评估和调谐活动。分析员必须针对非生产环境的灵活性权衡来自于生产环境结果的较大可靠性，分析员可在非生产环境中进行试验，当然试验所冒的风险是性能下降或更糟。
设置目标的重要性
虽然可以根据可测数量设置目标，但实际希望的结果往往带有主观性，比如令人满意的响应时间。进一步讲，分析员必须抵挡住调谐可测量的东西而不是对他而言是重要东西的诱惑。如果没有系统提供的评估能符合所要求的改进，那么就必须对该评估进行设计。
量化目标最有价值的方面不是选择达到的数字，而是对（通常）多个目标的相对重要性进行公开判定。如果这些优先级没有事先设定且不是每个相关的人都理解的话，分析员在没有进行频繁咨询之前不能作出任何折衷的决定。分析员还容易对用户的反应或管理性能中一些已经被忽略的方面而感到吃惊。如果系统的支持和使用跨过了组织的边界，您可能需要供应商和用户之间的书面服务级协议，可确保对性能目标和优先级有一个清楚而共同的理解。
识别关键资源
通常，给定工作负载的性能可由一两种关键系统资源的可用性和速度决定。分析员必须正确识别出那些资源，否则会冒险陷入无休止的尝试出错操作。
系统具有物理资源和逻辑资源。关键的物理资源通常比较容易识别，因为较多的系统性能工具可用来评估物理资源的利用率。通常最影响性能的物理资源如下：
CPU 周期
内存
I/O 总线
不同的适配器
磁盘臂
磁盘空间
网络访问
逻辑资源不太容易识别。逻辑资源通常是对物理资源进行分区的编程抽象。进行分区的目的是共享和管理物理资源。
构建于其上的物理资源和逻辑资源的一些示例如下：
CPU
处理器时间片
内存
页面帧
堆栈
缓冲区
队列
表
锁和信号量
磁盘空间
逻辑卷
文件系统
文件
分区
网络访问
会话
信息包
通道
了解逻辑资源和物理资源是很重要的。因为缺少逻辑资源线程可能阻塞，就像因为缺少物理资源而阻塞一样，扩展下层物理资源未必能保证创建附加的逻辑资源。例如，考虑使用 NFS 块 I/O 守护程序 biod。客户机上的一个 biod 守护程序要求处理每个暂挂的 NFS 远程 I/O 请求。因此，biod 守护程序的数量限制了能同时运行的 NFS I/O 操作的数量。当缺少 biod 守护程序时，系统检测会指示 CPU 和通信链路只使用了很少一部分。您可能有系统未充分利用（并且很慢）的假象，事实上这时是因为缺少 biod 守护程序从而限制了其余的资源。biod 守护程序使用处理器周期和内存，但您不能简单地通过添加实内存或将它转移到一个更快的 CPU 上来修正这个问题。解决方案是创建更多的逻辑资源（biod 守护程序）。
在应用程序开发过程中可能不经意间创建逻辑资源和瓶颈。传递数据或控制设备的方法可以有效地创建一个逻辑资源。当偶然创建这样的资源时，通常没有工具可监视它们的使用，也没有接口控制它们的分配。它们的存在可能不会引起重视，直到某个特定性能问题出现时就会突出它们的重要性。
最小化关键资源要示
下面讨论在三个级别上考虑最小化工作负载的关键资源要求。
使用适当的资源
决定在一个资源上使用另一个资源时应该理智地考虑并且头脑中要有明确的目标。在应用程序开发过程中有一个选择资源的示例，即通过增加内存消耗来减少 CPU 的消耗来达到一个平衡。用于演示资源选择的公共的系统配置决策为：是将文件放置在单独的本地工作站上，还是放置在远程服务器上。
减少关键资源的要求
对于本地开发的应用程序，可用多种方法检查程序以便其更有效地执行相同的功能或除去不需要的功能。在系统管理级别上，争用关键资源的低优先级工作负载可以移动到其它系统中、在其它时间运行或由“工作负载管理器”控制。
结构化资源的并行使用
因为工作负载需要运行多个系统资源，从而可以利用这样的事实，即资源是独立的且可以并行使用。例如，操作系统预读算法检测到程序在顺序访问文件的事实，因此它调度并行执行的其它顺序读取操作，同时应用程序还处理先前的数据。并行也用于系统管理。例如，如果某个应用程序同时访问两个或多个文件且如果同时访问的这些文件存放在不同的驱动器上，那么添加一个额外的磁盘驱动器可能会提高磁盘 I/O 的速率。
资源分配优先级
操作系统提供了一些方法来区分活动的优先级。有些在系统级别上设置，比如磁盘调步。其它的例如进程优先级可由单个用户设置以反映连接到特定任务上的重要性。
重复调谐步骤
性能分析的一个公认的真理是接下来总有瓶颈出现。减少某个资源的使用意味着另一资源限制了吞吐量或响应时间。例如，假设我们的系统中有下列的利用率级别：
CPU：90% 磁盘：70% 内存：60%
这个工作负载是 CPU 受限的。如果成功的调谐工作负载使得 CPU 负载从 90% 降到 45%，则可望在性能上有两倍的改善。不幸的是现在的工作负载是 I/O 受限的，它有下列的近似利用率：
CPU：45% 磁盘：90% 内存：60%
改善后的 CPU 利用率允许程序立刻提交磁盘请求，但接下来我们会受到由磁盘驱动器的容量施加的限制。性能改善也许是 30% 而不是预期的 100%。
总是存在一个新的关键资源。重要的问题是使用手边的资源是否已经满足性能目标。
注意: 用 vmtune、schedtune 和其它调谐命令产生的不正当系统调谐可能导致意外的系统行为，例如降低系统或应用程序的性能或系统暂停。更改仅应在性能分析识别出瓶颈时才适用。
注:
对于性能相关的调谐设置，不存在什么一般建议。
应用额外的资源
在前述所有的方法都用尽后如果系统性能仍不能满足它的目标，则必须增强或扩展关键资源。如果关键资源是逻辑资源且下层物理资源足够，则无需额外代价就可以扩展逻辑资源。如果关键资源是物理资源，分析员必须研究一些额外的问题：
必须增强或扩展关键资源到什么程度才可以终止瓶颈？
系统性能会满足它的目标吗？或另外的资源会首先饱和吗？
如果有一串关键资源的话，增强或扩展所有这些资源或与另一系统划分当前工作负载是否更节省成本呢？
性能基准
当试图比较不同环境中给定软件的性能时，常会遇到许多可能的错误，一些是技术上的，一些是概念上的。本节包含主要的提示信息。本书其它各节讨论评测过去和特定处理时间的不同方法。
评测处理系统调用需要花费的时间（挂钟）时，需要获取一个由下列内容组成的数字：
执行正运行服务的指令所需要的确切时间
处理器等待内存中的指令或数据时延迟的不同时间（也就是说，高速缓存和 TLB 不命中的代价）
在调用开头和结束访问时钟所需要的时间
由周期性事件如系统定时器中断所消耗的时间
由或多或少的随机事件消耗的时间，如 I/O
为了避免报告一个不精确的数字，常常要求多次评测工作负载。因为所有的外部的因素都会增加处理时间，典型的评估集有一个曲线的形式
F. UCOS新手，下面这个可重入函数有什么作用为什么要定义OS_TCB *ptcb这个变量
TCB — （Task Control Blank ）OS_TCB *ptcb 是任务控制块结构体指针，用于传递任务控制块地址，在uCOS内所用任务公用一个TCB，每个任务进行操作都会通过地址进行访问才会生效！该拍逗函数是删除任务钩子函数，用于在删除任务时进行相应用户操作，比如释放临界变量啊，控制其他任务同步等等。
ptcb = ptcb; //预防编译出错
因为有些编译器在预编译时发现入口参数未使用会出现警告，通过这句埋埋就表示已弯贺蚂经使用，相应就不会报错了！
希望你满意！
G. UC/OS与Linux操作系统的区别
uc/os比较简单一点，开始学的uc/os，感觉没意思了就开始学linux,感觉ucos只是在单片机上跑跑，像arm9的一般是跑linux。其实先学哪个都差不多，因为学习方法大不相同，差别太大了，ucos太简单，就一些信号量，邮箱什么的，懂了也就会了，linux有点难，涉及知识太多，光是涉及内核以外的编程就需要大把大把的经典书籍去看。兴趣很重要，都靠兴趣过来的。
H. 什么是UCOS操作系统
u C / O S 是一种免费公开源代码、结构小巧、具有可剥夺实时内核的实时操作系统。x0dx0ax0dx0aμC/OS-II 的前身是μC/OS，最早出自于1992 年美国嵌入式系统专家Jean J.Labrosse 在《嵌入式系统编程》杂志的5 月和6 月刊上刊登的文章连载，并把μC/OS 的源码发布在该杂志的B B S 上。x0dx0ax0dx0aμC/OS 和μC/OS-II 是专门为计算机的嵌入式应用设计的，绝大部分代码是用C语言编写的。CPU 硬件相关部分是用汇编语言编写的、总量约200行的汇编语言部分被压缩到最低限度，为的是便于移植到任何一种其它的CPU 上。用户只要有标准的ANSI 的C交叉编译器，有汇编器、连接器等软件工具，就可以将μC/OS-II嵌人到开发的产品中。μC/OS-II 具有执行效率高、占用空间小、实时性能优良和可扩展性强等特点， 最小内核可编译至 2KB 。μC/OS-II 已经移植到了几乎所有知名的CPU 上。x0dx0ax0dx0a严格地说uC/OS-II只是一个实时操作系统内核，它仅仅包含了任务调度，任务管理，时间管理，内存管理和任务间的通信和同步等基本功能。没有提供输入输出管理，文件系统，网络等额外的服务。但由于uC/OS-II良好的可扩展性和源码开放，这些非必须的功能完全可以由用户自己根据需要分别实现。x0dx0ax0dx0auC/OS-II目标是实现一个基于优先级调度的抢占式的实时内核，并在这个内核之上提供最基本的系统服务，如信号量，邮箱，消息队列，内存管理，中断管理等。x0dx0ax0dx0a任务管理x0dx0ax0dx0auC/OS-II 中最多可以支持64 个任务，分别对应优先级0～63，其中0 为最高优先级。63为最低级，系统保留了4个最高优先级的任务和4个最低优先级的任务，所有用户可以培神使用的任务数有56个。x0dx0ax0dx0auC/OS-II提供了任务管理的各种函数调用，包括创建任务，删除任务，改变任务的优先级，任务挂起和恢复等。x0dx0ax0dx0a系统初始化时会自动产生两个任务：一个是空闲任务，它的优先级最低，改任务仅给一个整形变量做累加运算；另一个是系统任务，它的优先级为次低，改任务负责统计当前cpu的利用率。x0dx0ax0dx0a时间管理x0dx0ax0dx0auC/OS-II的时间管理是通过定时中断来实现的，该定芦薯时中断一般为10毫秒或100毫秒发生一次，时间频率取决于用户对硬件系统的定时器编程来实现。中断发生的时间间隔是固定不变的，该中断也成为一个时钟节拍。x0dx0ax0dx0auC/OS-II要求用户在定时中断的服务程序中，调用系统提供的与时钟节拍相关的系统函数，例如中断级的任务切换陪中者函数，系统时间函数。x0dx0ax0dx0a内存管理x0dx0ax0dx0a在ANSI C中是使用malloc和free两个函数来动态分配和释放内存。但在嵌入式实时系统中，多次这样的错作会导致内存碎片，且由于内存管理算法的原因，malloc和free的执行时间也是不确定。x0dx0ax0dx0auC/OS-II中把连续的大快内存按分区管理。每个分区中包含整数个大小相同的内存块，但不同分区之间的内存快大小可以不同。用户需要动态分配内存时，系统选择一个适当的分区，按块来分配内存。释放内存时将该块放回它以前所属的分区，这样能有效解决碎片问题，同时执行时间也是固定的。x0dx0ax0dx0a任务间通信与同步x0dx0ax0dx0a对一个多任务的操作系统来说，任务间的通信和同步是必不可少的。uC/OS-II中提供了4中同步对象，分别是信号量，邮箱，消息队列和事件。所有这些同步对象都有创建，等待，发送，查询的接口用于实现进程间的通信和同步。x0dx0ax0dx0a任务调度x0dx0ax0dx0auC/OS-II 采用的是可剥夺型实时多任务内核。可剥夺型的实时内核在任何时候都运行就绪了的最高优先级的任务。x0dx0ax0dx0auC/os-II的任务调度是完全基于任务优先级的抢占式调度，也就是最高优先级的任务一旦处于就绪状态，则立即抢占正在运行的低优先级任务的处理器资源。为了简化系统设计，uC/OS-II规定所有任务的优先级不同，因为任务的优先级也同时唯一标志了该任务本身。x0dx0ax0dx0a任务调度将在以下情况下发生：x0dx0ax0dx0a1） 高优先级的任务因为需要某种临界资源，主动请求挂起，让出处理器，此时将调度就绪状态的低优先级任务获得执行，这种调度也称为任务级的上下文切换。x0dx0ax0dx0a2） 高优先级的任务因为时钟节拍到来，在时钟中断的处理程序中，内核发现高优先级任务获得了执行条件(如休眠的时钟到时)，则在中断态直接切换到高优先级任务执行。这种调度也称为中断级的上下文切换。x0dx0ax0dx0a这两种调度方式在uC/OS-II的执行过程中非常普遍，一般来说前者发生在系统服务中，后者发生在时钟中断的服务程序中。x0dx0ax0dx0a调度工作的内容可以分为两部分：最高优先级任务的寻找和任务切换。其最高优先级任务的寻找是通过建立就绪任务表来实现的。u C / O S 中的每一个任务都有独立的堆栈空间，并有一个称为任务控制块TCB(Task Control Block)的数据结构，其中第一个成员变量就是保存的任务堆栈指针。任务调度模块首先用变量OSTCBHighRdy 记录当前最高级就绪任务的TCB 地址，然后调用OS_TASK_SW()函数来进行任务切换。x0dx0ax0dx0aμC/OS-II的组成部分x0dx0ax0dx0aμC/OS-II可以大致分成核心、任务处理、时间处理、任务同步与通信，CPU的移植等5个部分。x0dx0ax0dx0a1) 核心部分(OSCore.c)x0dx0ax0dx0a是操作系统的处理核心，包括操作系统初始化、操作系统运行、中断进出的前导、时钟节拍、任务调度、事件处理等多部分。能够维持系统基本工作的部分都在这里。x0dx0ax0dx0a2) 任务处理部分(OSTask.c)x0dx0ax0dx0a任务处理部分中的内容都是与任务的操作密切相关的。包括任务的建立、删除、挂起、恢复等等。因为μC/OS-II是以任务为基本单位调度的，所以这部分内容也相当重要。x0dx0ax0dx0a3) 时钟部分(OSTime.c)x0dx0ax0dx0aμC/OS-II中的最小时钟单位是timetick（时钟节拍）。任务延时等操作是在这里完成的。x0dx0ax0dx0a4) 任务同步和通信部分x0dx0ax0dx0a为事件处理部分，包括信号量、邮箱、邮箱队列、事件标志等部分；主要用于任务间的互相联系和对临界资源的访问。x0dx0ax0dx0a5) 与CPU的接口部分x0dx0ax0dx0a是指μC/OS-II针对所使用的CPU的移植部分。由于μC/OS-II是一个通用性的操作系统，所以对于关键问题上的实现，还是需要根据具体CPU的具体内容和要求作相应的移植。这部分内容由于牵涉到SP等系统指针，所以通常用汇编语言编写。主要包括中断级任务切换的底层实现、任务级任务切换的底层实现、时钟节拍的产生和处理、中断的相关处理部分等内容。
I. 如何学习 nucleus os
内容：
一、nucleus plus特点：
1.内核采用微内核的设计，方便移植，资料写着更reliable，但是我不这么认为，与linux相比，以ARM平台为例，NU只用到了SVC mode，内核与用户任务都运行在同一个状态下，消掘也就是说所有的task都拥有访问任何资源的权限，这样很reliable么？
2.real-time OS，NU是一个软实时操作系统（VxWorks是硬实时），thread control component支持多任务以及任务的抢占，对于中断的处理定义了两种服务方式，LISR和HISR，这个与linux中的上、下半部机制类似，linux中的下半部是通过软中断来实现的，NU的HISR只是作为一种优先级总是高于task的任务出现。
3.NU是以library的方式应用的，通过写自己的app task与裁剪后的NU内核及组键歼件链接起来，NU并没有CLI
二、组件
1.IN component
初始化组件由三个部分组成，硬件在reset后首先进入INT_initialize()，进行板级的相关初始化，首先设置SVC mode，关中断，然后将内核从rom中拷贝至ram中，建立bss段，依次建立sys stack, irq stack和fiq stack，最后初始化timer，建立timer HISR的栈空间，看了一下2410平台的代码，一个tick大概是15.8ms，完成板级的初始化后就进入了INC_initialize，初始化各个组件，其中包括Application initialize，create task和HISR，最后将控制权交给schele，主要看了一下RAM中地址空间的安排
|timer HISR stack = 1024|
|FIQ stack = 512|
|IRQ stack = 1024|
|SVC stack = 1024|
|.bss|
|.data|
|.text|
其中SVC stack的大小与中断源的个数相关，nested irq发生时，irq_context保存在SVC stack中，IRQ的stack只是做了临时栈的作用。
2.thread control component
TC组件是NU内核的最重要组成部分，主要涵盖了调度、中断、任务的相关操作、锁、时钟几个方面，下面分别介绍。
调度（schele）
NU中的线程类型（在同一个地址空间内）有两种，HISR和task，HISR可以理解为一种优先级较高的task，但又不是task，HISR优先级高于task的实现方式就是schle时，先去查看当前是否有active的HISR，再去查看task。task有suspend、ready、finished和terminated四种状态，而HISR只有executing和no-active这两种状态。
每一个task都拿亮核有一个线程控制的数据结构（TCB thread control block）,其中包括了task的优先级、状态、时间片、task栈、protect信息、signal操作的标志位和signal_handler等，task在创建时初始化这些信息，将task挂到一个create_list上，初始设定task为pure_suspend，如果设定auto start，调用resume_task（）唤醒task，这里有个细节，如果在application initialize中create_task()，则task不会自动运行，因为初始化还未完成，控制权还没有交给schele，无法调度task。task被唤醒后状态改变为ready，并挂在一个TCD_Priority_List[256]上，数组的每个元素是一个指向TCB环形双向链表的指针，根据task的tc_priority找到对应优先级的TCB head pointer。
每一个HISR都有一个HISR控制的数据结构（HCB HISR control block）,其中只有优先级，HISR栈和HISR entry信息，因此HISR是不可以suspend，同时也没有time slice以及signal的相关操作，一般情况下当发生了中断后，HISR被activate，schele就会调度HISR运行，期间如果不发生中断，HISR的执行是不会被打断的，HISR的优先级只有0、1、2，timer的HISR优先级为2，也就是说由外部中断激活的HISR很难被抢占的，只有更高优先级的中断HISR才可以。与task不同，被激活的HISR使用head_list和tail_list将HCB挂在一个单项的链表上，因为相同优先级的HISR不会抢占对方，因此不需要双向链表，使用两个指针目的是加快HISR执行的速度。
一个实时操作系统的核心就是对于任务的调度，NU的调度策略是time slice和round robin的算法，
调度的部分主要有三个函数control_to_system()用于保存上下文，建立solicited stack，关中断，关system time slice，并重置task的time slice为预设值，将sp更新为system_stack_pointer，调用schele()，调度的过程是非常简单的查询，就是查看两个全局的变量，TCD_Execute_HISR和TCD_Execute_Task，schele部分的关键是打开了中断，不然如果当前没有ready的task或是被激活的HISR，则shele死循环下去，查询到下一个应该执行的线程后跳转至control_to_thread(),在这里重新开启system time slice，然后将线程的tc_stack_ptr加入到sp中，切换至线程的栈中，依次pop出来，即完成了任务调度。
任务的切换主要是上下文的切换，也就是task栈的切换，函数的调用会保存部分regs和返回地址，这些动作都是编译器来完成的，而OS中的任务切换是运行时（runtime）的一种状态变化，因此编译器也无能为力，所以对于上下文的保存需要代码来实现。
任务的抢占是异步的因此必须要通过中断来实现，一般每次timer的中断决定当前的task的slice time是否expired，然后设置TCT_Set_Execute_Task为相同优先级的其他task或更高优先级的task；高优先级的task抢占低优先级的task，一般是外部中断触发，在HISR中resume_task()唤醒高优先级的task，然后schele到高优先级的task中，因为timer的HISR是在系统初始化就已经注册的，只是执行timeout和time slice超时后的操作，并没有执行resume_task的动作。
NU中的stack有两种solicited stack和interrupt stack，solicited stack是一种minmum stack，而interrupt stack是对当前所有寄存器全部保存，TCB中的minimum stack size = 申请得到stack size - solicited stack（在arm mode下占44字节，thumb mode下占48字节），thumb标志用来记录上下文保存时的ARM的工作模式，c代码编译为thumb模式，这样可以减小code size，提高代码密度，assembly代码编译为arm模式提升代码的效率，NU中内核的代码不多，主要是assembly代码。stack的类型与其中PC指向的shell无关，interrupt stack保存的是task或是HISR在执行的过程中被中断时的现场，solicited stack建立的地方包括 control_to_system()、schele_protect()和send_signals()发送给占有protect资源的task的情况，HISR_Shell()执行完后会建立solicited stack，再跳转至schele。
(Lower Address) Stack Top -> 1 (Interrupt stack type)
CPSR Saved CPSR
r0 Saved r0
r1 Saved r1
r2 Saved r2
r3 Saved r3
r4 Saved r4
r5 Saved r5
r6 Saved r6
r7 Saved r7
r8 Saved r8
r9 Saved r9
r10 Saved r10
r11 Saved r11
r12 Saved r12
sp Saved sp
lr Saved lr
(Higher Address) Stack Bottom-> pc Saved pc
(Lower Address) Stack Top -> 0 (Solicited stack type)
!!FOR THUMB ONLY!! 0/0x20 Saved state mask
r4 Saved r4
r5 Saved r5
r6 Saved r6
r7 Saved r7
r8 Saved r8
r9 Saved r9
r10 Saved r10
r11 Saved r11
r12 Saved r12
(Higher Address) Stack Bottom-> pc Saved pc
一个简单的例子说明stack的情况，首先是一个task在ready(executing)的状态下，而且time slice超时了，timer中断发生后，保存task上下文interrupt_contex_save()，在task的tc_stack_ptr指向的地方建立中断栈
taskA |interrupt stack|___tc_stack_ptr 栈顶端是pc=lr-4
ARM对于中断的判定发生在当前指令完成execute时，同时pipeline的原因pc=pc+8，入栈时就把lr-4首先放在stack的最高端（high）。
timer的LISR完成后激活了HISR，执行TCC_Time_slice()将当前task移到相同优先级的尾端，并且设置下一个要执行的task，HISR在栈顶端保存的是这个HISR_shell的入口地址，因为task的执行完就finished，HISR是可重入的
HISR |solicited stack| 栈顶端是HISR_shell_entry
中断（interrupt）
前面已经提及了中断的基本操作，这里就写一些代码路径的细节，中断的执行主要是两个部分LISR和HISR，分成两个部分的目的就是将关中断的时间最小化，并且在LISR中开中断允许中断的嵌套，以及建立中断优先级，都可以减少中断的延迟，保证OS的实时性。
NU的中断模式是可重入的中断处理方式，也就是基于中断优先级和嵌套的模式，中断的嵌套在处理的过程中应对lr_irq_mode寄存器进行保存，因为高优先级的中断发生时会覆盖掉低优先级中断的r14和spsr，因此要利用系统的栈来保存中断栈。
NU对于中断上下文的保存具体操作如下：
（1）在中断发生后执行的入口函数INT_IRQ()中，将r0-r4保存至irq的栈中
（2）查找到对应的interrupt_shell()，clear中断源，更新全局的中断计数器，然后进行interrupt_contex_save
（3）首先利用r1,r2,r3保存irq模式下的sp,lr,spsr，这里sp是用来切换至系统栈后拷贝lr和spsr的,这里保存lr和spsr是目的是task被抢占后，当再次schele时可以返回task之前的状态。
（4）切换至SVC模式，如果是非嵌套的中断则保存上下文至task stack中，将irq模式下的lr作为顶端PC的返回值入栈，将SVC模式下的r6-r14入栈，将irq模式下的sp保存至r4中入栈，最后将保存在irq_stack中的r0-r4入栈
（5）如果是嵌套中断，中断的嵌套发生在LISR中，在执行LISR时已经切换至system stack，因此嵌套中断要将中断的上下文保存至system stack中，与task stack中interrupt stack相比只是少了栈顶用来标记嵌套的标志（1 not nested）
（6）有一个分支判断，就是如果当前线程是空，即TCD_Current_Thread == NULL，表明当前是schele中，因为初始化线程是关中断的，这样就不为schele线程建立栈帧，因为schele不需要保存上下文，在restore中断上下文时直接跳转至schele。
中断上下文的恢复
全局的中断计数器INT_Count是否为0来判定当前出栈的信息，如果是嵌套则返回LISR中，否则切换至system stack执行schele
timer
timer与中断紧密相关，其实timer也是中断的一种，只是发生中断的频率较高，且作用重大，一个实时操作系统，时间是非常重要的一部分，NU中的timer主要有四个作用：
（1）维护系统时钟 TMD_system_clock
（2）task的time slice
（3）task的suspend timeout timer
（4）application timer
其中（3）（4）共用一种机制，一个全局的时间轴TMD_timer，timeout timer和app timer都建立在一个TM_TCB的数据结构上，通过tm_remaining_time来表征当前timer的剩余时间，例如当前有timer_list上有三个TM_TCB，依次是Ta = 5，Tb = 7, Tc = 20,那么建立的链表上剩余时间依次是5，2，8，如果现在要加入一个新的timer根据timer值插入至合适的位置，如果插入的timer为13，则安排在Tb后面，剩余时间为1，后面的8改为7，当发生了timer expired，则触发timer_HISR，如果是app timer则执行timer callback，如果是task timeout timer，则执行TCC_Task_Timeout唤醒task。
（2）的实现也是依赖于全局的time slice时间轴，每一个task在执行时都会将自己的时间片信息更新至全局的时间轴上，当一个task的time slice执行完在timer HISR中调用TCC_task_Timeout将当前的task放在相同优先级list的最尾端，并设置下一个最高优先级的任务。task在执行的过程中只有被中断后time slice会保存下来，其他让出处理器的情况都会将time slice更新为预设值。
protect
protect与linux的锁机制类似，互斥访问，利用开关中断来实现，并且拥有protect的task是不可以suspend的，必须要将protect释放后才可以挂起，当一个优先级较低的task占有protect资源，如果被抢占，一个高优先级的task或HISR在请求protect资源时会执行TCC_schele_protect()让出处理器给低优先级的task执行，直到低优先级的task执行unprotect()为止，此时task或HISR建立的是solicited stack，同时在control_to_thread前开关中断一次，这样可以减少一次上下文的切换。NU中常用到的是system_protect，它就是一把大锁，保护内核中所有全局数据结构的顺序访问，粒度很大。
LISR中不可以请求protect资源，因为LISR是中断task后执行，如果task占有protect资源，这时LISR又去请求protect资源，会发生死锁，因为LISR让出处理器后，schele没办法再次调度到LISR执行，则发生死锁错误，因此在LISR中除了activate_HISR（）以外不可以使用system call，例如resume_task等等，这写系统调用都会请求protect资源。
对于protect的请求按照一定的顺序可以防止死锁，NU的源码中一般将system_protect资源的请求放在后面，其他如DM_protect先请求。
J. ucos-ii是怎样移植到Keil C上的
在移植的时候 尽量保证得到的源代码改动最少
并且调试方便 而且目录结构分类清晰
网上的各明滚个项目都有如下特点：
1：一来就吭哧吭哧修改头文件，每个文件都#include "includes.h"
2: ucos和其他文件 或者放在一个文件夹 或者在项目里面不管3721都加上
跳来跳去头都是大的 而且调试的时候出些莫名其妙的问题：比如贺扮
设不了断点 或者调试无法进入c文件等等
我的设想：前提 得到ucos2.84
1： 改动尽量少 即不按常规修改里面的#include "includes.h"等
ucos说放哪里我们就放哪里
2: 项目结构和文件存放结构合理，该有的有 不该有的就没有
3: 调试时编译器不会出现怪问题
4： 文档尽量清楚 每处和每步小小的修改都要说明
建议最开始看完 杨屹 大虾的文章
[里面的os_cfg_r.h->改成os_cfg.h] 至此，是ucos里面的[第一处修改]
1: 建立项目文件 拷贝原始文件 整理文件夹
目录如下：
FirstVersion: 根目录 project.uv就放下面
-ucos : 拷贝ucos2.83源代码和os_cpu_a.a51 等凡是ucos相关的到下面 去掉只读和存档属性 自己加一个app_cfg.h(ucos2.83增
加的) 里面内容是#include <reg51.h>嘿嘿
-output:
项目设置:
-SourceGroup
->STARTUP.A51 main.c
--ucos
->os_task.c os_core.c
2: 设置
1： Target1 -> options->output和Listing里面点"Select Folder for Objects" 改为\output
2: Target1->options -> C51和A51里面的 Include Paths->加入ucos
4: Target1 -> options->Target的MemoryModel和CodeRomSize都用Large
编译： 有四个警告 'OSIntCtxSw': missing function-prototype
'OSStartHighRdy': missing function-prototype
'OSCtxSw': missing function-prototype
UCOS\OS_CORE.C(1356): warning C275: expression with possibly no effect
第四个警告是由于OS_TaskIdle()里面
(void)p_arg; /* Prevent compiler warning for not using 'parg' */
没有起到作用 改成p_arg = p_arg;即可。 至此，是在ucos里面的[第二处修改]
3：加入 OS_CPU_C.C 不要问这个文件哪里来的 地球人都知道
在不管它通不通前 还有修改
1： 最前面保持跟其他.c文件一致 加入
#ifndef OS_MASTER_FILE
#include <ucos_ii.h>
#endif
2：加入若干个激拍余函数的函数体 大体都是带"hook"的， 这些个函数只在ucos_ii.h有个声明，但由于只有头文件有定义没有函数体 ，keil会
把它编译成LJMP STARTUP1的语句。知道有什么后果了吧
注意#if的条件头文件和c文件要一致
在这里感觉ucos是不是搞了点”技术处理“？反正n个函数头文件和c文件的#if条件不一致
一不小心会造成LJMP STARTUP1! 注意把os_core.c ucos_ii.h和os_cpu_c里面都要改完
至此，是在ucos里面的[第三处修改] 要改的地方还不少
//in ucos_ii.h
#if OS_CPU_HOOKS_EN
void OSInitHookBegin (void);
void OSInitHookEnd (void);
void OSTCBInitHook (OS_TCB *ptcb);
void OSTaskCreateHook (OS_TCB *ptcb);
void OSTaskDelHook (OS_TCB *ptcb);
void OSTaskStatHook (void);
void OSTaskIdleHook (void);
#endif
#if OS_TASK_SW_HOOK_EN
void OSTaskSwHook (void);
#endif
#if OS_TIME_TICK_HOOK_EN
void OSTimeTickHook (void);
#endif
4： 现在开始改OS_CPU_C.C里面的函数
将OSTaskStkInit()改成跟ucos_ii.h里面一样。具体就是原来里面yy大虾的函数是
void *OSTaskStkInit (void (*task)(void *pd), void *ppdata, void *ptos, INT16U opt)
总之网上各个版本都是ppdata..呵呵 。ucos2.83里面用的是p_arg.我们把它修改成
OS_STK *OSTaskStkInit (void (*task)(void *p_arg) ,
void *p_arg,
OS_STK *ptos,
INT16U opt)
编译能通过 先不管运行起来对不对
5： 在ucos组里面加入os_cpu_a.a51 不要问这个文件哪里来的 地球人都知道
编译 会出现错误： *** ERROR L102: EXTERNAL ATTRIBUTE MISMATCH
这是因为os_cpu_a.a51里面
EXTRN IDATA (OSTCBHighRdy)
EXTRN IDATA (OSRunning)
EXTRN IDATA (OSPrioCur)
EXTRN IDATA (OSPrioHighRdy)
对引用的外部变量作了idata的定义，而ucos_ii.h里面没有
在这里 os_cpu.h里面 先增加一个#define DATATYPE_1 idata
在ucos_ii.h找到这四个变量 增加idata定义 至此，是在ucos里面的[第三处修改]
编译能通过
6：在ucos_ii.h里面
#if 0
void OSStartHighRdy (void);
void OSIntCtxSw (void);
void OSCtxSw (void);
#endif
这就是造成上面的其中三个编译警告的原因 既然ucos2.83里面有说
* IMPORTANT: These prototypes MUST be placed in OS_CPU.H
那么我们就把它们placed in OS_CPU.H
不改动原来的代码 只
void OSStartHighRdy (void);
void OSIntCtxSw (void);
void OSCtxSw (void);
到os_cpu.h里面 再编译 现在就只有
*** WARNING L16: UNCALLED SEGMENT, IGNORED FOR OVERLAY PROCESS的警告了
Program Size: data=84.0 xdata=2348 code=8721 //keil 8.06
至此 整个框架就搭起来了 下面就来慢慢对付OSTaskStkInit()这个函数
gogogo!!!!!!!!!!!!!!!!!!
1: os_cfg.h里面先 disable掉
OS_DEBUG_EN OS_FLAG_EN OS_MBOX_EN OS_MEM_EN OS_MUTEX_EN OS_Q_EN OS_SEM_EN
等等等等
题外话： 做一个Configuration Wizard的OS_CFG.H 这下方便多了 。这可是个体力活！ 嘿嘿
也不违背了不改动原始文件的初衷
开始go了。建立最简单的一个东西
#include <ucos_ii.h>
void main(void)
{
OSInit();
OSStart();
}
发现走到os_cpu_a.a51里面的
OSStartHighRdy:
USING 0 ;上电后51自动关中断，此处不必用CLR EA指令，因为到此处还未开中断，本程序退出后，开中断。
LCALL _?OSTaskSwHook --》一call就call复位了 我靠
捣鼓了下建一个os_cpu_a.c 加入工程 且右键的options->Generate Assembleer SRC File打勾
内容为
#ifndef OS_MASTER_FILE
#include <ucos_ii.h>
#endif
void OSStartHighRdy(void) {
OSTaskSwHook();
} 看了看 生成的东西是这样的
?PR?OSStartHighRdy?OS_CPU_A SEGMENT CODE
EXTRN CODE (OSTaskSwHook)
PUBLIC OSStartHighRdy
RSEG ?PR?OSStartHighRdy?OS_CPU_A
OSStartHighRdy:
USING 0
LJMP OSTaskSwHook
END
简直莫名其妙 于是 将os_cpu_a.a51改成
;EXTRN CODE (_?OSTaskSwHook)
EXTRN CODE (OSTaskSwHook) ;keil8.06 <-----改这里
;子程序
;-------------------------------------------------------------------------
RSEG ?PR?OSStartHighRdy?OS_CPU_A
OSStartHighRdy:
USING 0 ;上电后51自动关中断，此处不必用CLR EA指令，因为到此处还未开中断，本程序退出后，开中断。
;LCALL _?OSTaskSwHook
LCALL OSTaskSwHook <-----改这里
再测试 ok 能进入OSIdleStask 并在里面循环 看来是c和汇编连接的一些问题 先把它放一边以后解决 [待解决的问题2]继续测试
这里又想到个问题 万一#define OS_TASK_SW_HOOK_EN 0 那么OSTaskSwHook()就不被编译。
在汇编里面调用会不会又复位？keil这点太……[不知道哪里可以设置 待解决的问题2]，
测试了下 果然复位 我靠！作个说明“如果用keil，那么OS_TASK_SW_HOOK_EN 一定要为1
好了 就算第一步测试搞定 现在来做个”笨活路“ 给所有的函数加上reentrant! 内部的static就不用了。
现在开始调试serial 将yy大虾的serial.c搞过来 加入工程
1： 看到汇编和c混合头都是大的 把
#pragma asm
push IE
EA = 0;
之类的东东全部改成 _push_(IE); EA = 0;嘿嘿 当然不要忘记在app_cfg.h加#include <intrins.h>
现在有:
#include <ucos_ii.h>
void Task1(void *p_arg) keilReentrant;
void Task2(void *p_arg) keilReentrant;
void Task3(void *p_arg) keilReentrant;
OS_STK Task1Stack[MaxStkSize];//注意：我在ASM文件中设置?STACK空间为40H即64。
OS_STK Task2Stack[MaxStkSize];
OS_STK Task3Stack[MaxStkSize];
void main(void)
{
unsigned char ucReturn;
OSInit();
OSInitTimer0(); //也就是原来的InitTimer0();
InitSerial();
InitSerialBuffer();
ucReturn = OSTaskCreate(Task1, (void *)0, &Task1Stack[0] ,2);
ucReturn = OSTaskCreate(Task2, (void *)0, &Task2Stack[0] ,3);
ucReturn = OSTaskCreate(Task3, (void *)0, &Task3Stack[0] ,4);
OSStart();
}
void Task1(void *p_arg) keilReentrant
{
p_arg = p_arg;
ET0=1;
for(;;){
//PrintStr("Task 1 is active. \n");
OSTimeDly(3*OS_TICKS_PER_SEC);
}
}
void Task2(void *p_arg) keilReentrant
{
p_arg = p_arg;
for(;;){
PrintStr("Task 2 is active. \n");
OSTimeDly(2*OS_TICKS_PER_SEC);
}
}
void Task3(void *p_arg) keilReentrant
{
p_arg = p_arg;
for(;;){
PrintStr("Task 3 is active. \n");
OSTimeDly(3*OS_TICKS_PER_SEC);
}
}
运行 我靠 怎么就显示"Task 1 is active" 任务不切换 ？为啥。
原来os_time.c还没有加到项目里面去(因为这个项目没有把
ucos_ii.c加入项目);OSTimeDly()哪里会工作
加进去，运行->OK
OS_timr 把OS_Timr.c加入 并打开en的开关编译的时候会出现err。原因是回调函数参数太多的问题
解决方法见 http://www.keil.com/support/docs/2066.htm
在ucos-ii.h里面
/* add keilReentrant to to solve the Error 212: Indirect call: Parameters do not fit within registers */
typedef void (*OS_TMR_CALLBACK)(void *ptmr, void *parg) reentrant ;
附加一点就是项目里面直接加如.a文件 不用在include c51L.lib
然后加入一个lcd的驱动 呵呵很简单1602的。前提就是尽量不修改ucos的变量 函数名称和调用方式等
详细见工程。调试通过 不过是在proteus里面。在这里感谢jjj www.proteus.com.cn
记得因为lcd.c里面用到了sempost函数 所以如果要用就必须把OS_MAX_EVENTS 算进去,在你原来的设定值加一
到此 新鲜的ucos2.84出炉了。奉献此身体给大家。想来想去 唯一的卖点就是写了点细节，二是改了个os_cfg.h...呵呵
打包文件在下 ！ 只有文档的兄台也不用发mail给我 自己网上找去 应该有下
熊伟 于大年初一 深圳 [email protected] jdsu光电
version2:
不知道怎么回事，一到 LCALL OSTaskSwHook --》一call就call复位了 我靠
又改回来 LCALL _?OSTaskSwHook 又好了
想了想 是不是我又加了.a文件的原因？
因为后来我又加了一个INT0Function.c 和INT0Function_a.a51
void Int0Function() keilReentrant
{ //中断在汇编中实现，去掉interrupt {//INT0中断服务子程序
}
#include <include_a.h>
NAME INT0FUNCTION_A ;模块名
?PR?_?INTOFunction?INT0FUNCTION_A SEGMENT CODE
EXTRN CODE (_?INTOFunction)
;-------------------------------------------------------------------------
CSEG AT 0013H ;INT0中断
LJMP INT0ISR ;工作于系统态，无任务切换。
RSEG ?PR?_?INTOFunction?INT0FUNCTION_A
INT0ISR:
USING 0
CLR EA ;先关中断，以防中断嵌套。
PUSHALL
LCALL _?INTOFunction
POPALL
SETB EA
RETI
;-------------------------------------------------------------------------
END
;-------------------------------------------------------------------------