1、《****ARM7--LPC2200》的P25：可以通过“MSR写状态寄存器”指令来修改T位实现（ARM状态和Thumb状态）状态切换，但是因为它不会清空流水线，所以这种方法是不安全的，因此强烈推荐使用BX指令进行安全的状态切换。

 

2、《****ARM7--LPC2200》的P31：当通过程序直接改写CPSR来切换模式时，CPSR不会被保存到SPSR，因此只有发生异常或者中断时，才需要将CPSR备份到SPSR。

 

3、《****ARM7--LPC2200》的P31：根据ATPCS规定（规定了子程序间调用的基本规则），子程序中的局部变量使用内部寄存器R4-R11来保存（Thumb状态为R4-R7，如果寄存器不够用则存放在内存中）。因为这些寄存器都是32位的，所以程序处理32位长度的变量时效率最高。如果我们把局部变量定义为8位或16位，它们也独占着一个32位的寄存器，非但没有减少寄存器的使用量，还会导致编译器使用额外的指令来限定变量的内容（比如使用“与”指令来屏蔽32位寄存器中的高位）。所以在定义局部变量时请尽量定义为32位长度的（比如用于循环计数的变量）。

 

4、《****ARM7--LPC2200》的P41：LPC2000系列ARM是基于ARM7TDMI内核的，不具有MMU，所以不应该发生中止异常。初学者时常遇到的中止异常是因为指针操作不当引起的，比如通过一个没有赋值的指针（被称为“野指针”）来读写数据，如果该指针指向的区域没有存储器可供访问，那么将引起中止异常。

       在调试阶段如果进入了中止异常模式，可以通过中止模式下的R14找到进入异常前的程序位置（原理见“进入异常”部分内容）。

 

5、《****ARM7--LPC2200》的P57：“^”后缀不允许在用户模式或系统模式下使用，若在LDM指令且寄存器列表中包含有PC时使用，那么除了正常的多寄存器传送外，还会把SPSR也拷贝到CPSR中，这可用于异常处理返回。

       使用“^”后缀进行数据传送且寄存器列表不包含PC时，则加载/存储的是用户模式的寄存器，而不是当前模式的寄存器。

       当Rn在寄存器列表中且使用后缀“！”时，对于STM指令，若Rn为寄存器列表中的最低数字的寄存器，则会将Rn的初值保存；其它情况下Rn的加载值和存储值不可预知。

 

6、《****ARM7--LPC2200》的P110：PLL在芯片复位和进入掉电模式时会被关闭并从时钟系统中切换出去。芯片从掉电模式被唤醒后，PLL并不会自动使能和连接，只能通过软件使能。程序必须在配置并激活PLL后等待其锁定，然后再连接PLL。

 

7、《****ARM7--LPC2200》的P113：进行PLL馈送时两个写操作的时序必须正确，而且必须是连续的VPB总线周期，也就是在写完第一个字节0xAA后不能去操作别的外设，而应该紧接着写第二个字节0x55，所以通常在执行PLL馈送操作时必须禁止中断。不管是写入的值不正确还是没有满足前两个条件，对PLLCON或PLLCFG寄存器的更改都不会生效。

 

8、《****ARM7--LPC2200》的P118：VPB总线在系统复位以默认的速度运行，其速度是处理器时钟（cclk）的1/4。

 

9、《****ARM7--LPC2200》的P133-P136：在LPC2200微处理器中，为了适应外部存储器组的宽度和类型，EMC提供了一组字节定位选择信号（BLS0~BLS3）。这样，即使外部存储器组是16位或32位格式时，利用WE、OE与BLSn信号仍然可以实现字节操作。要实现这些功能，需要对相应存储器组配置寄存器中的RBLE位进行设定。

       对外部存储器组进行写访问时，RBLE位决定WE信号是否有效（为0时WE无效）；

       对外部存储器组进行读访问时，RBLE位决定BLSn信号是否有效（为0时BLSn无效）。

       （详见P134的表格和波形）

 

10、《****ARM7--LPC2200》的P136：由于16位存储器件的结构是16位半字地址空间，一个地址空间对应两个字节的数据，所以将这两个字节数据又分为“高字节”和“低字节”。“高字节”和“低字节”实际上是从LPC2200角度看到的，当LPC2200外部地址总线的地址位A0=0时，访问的是“低字节”，反之，A0=1时，访问的便是“高字节”。

 

11、BLS3~BLS0在总线读写操作时是自动产生，还是需要通过寄存器手工设置？

       自答：应该为自动产生。见《****ARM7--LPC2200》的P138-P141的波形图。

 

12、用C语言如何实现对外部存储器高低字节的访问？

       自答：可以定义一个字节型指针来指向外部16位或32位存储器空间。

写操作时：（有字节操作时RBLE应为1），字节方式写访问16位存储器时，访问高字节时应设地址线的A0为1。

       字节方式写访问32位存储器时，访问字节0时，地址线的A1A0=00b，

                                 访问字节1时，地址线的A1A0=01b，

                                 访问字节2时，地址线的A1A0=10b，

                                 访问字节3时，地址线的A1A0=11b，

      半字方式操作32位存储器时，应定义一个半字型指针来指向外部32位存储器空间，其它类似（只要令A1为1或0，就可访问高半字或低半字）。

读操作时：当RBLE=1时，对存储器进行读操作，BLSn-BLS0都有效，不过根据指针的不同来访问不同的字节、半字或字。

具体程序代码和相关波形见《****ARM7--LPC2200》的P138-P143。

 

2008-9-10  读《****ARM7--LPC2200》笔记

13、《****ARM7--LPC2200》的P161：ARM7硬件不支持中断嵌套。

 

14、《****ARM7--LPC2200》的P165：PLL中断和WDT中断的中断标志都不能被软件清除，因而中断处理完毕后，而且必须只能通过VICIntEncClear来将这两个中断禁止，实现中断返回。

 

15、《****ARM7--LPC2200》的P176：“__irq”是ADS编译器的关键字。在ADS编译器中，“__irq”专门用来声明中断服务程序，如果用“__irq”来声明一个函数，那么该函数表示一个IRQ中断服务程序，编译器便会自动生成处理器模式切换代码和现场保护、恢复代码，代码示例见P176、P178。

 

16、《****ARM7--LPC2200》的P184：外部中断输入引脚和串口输入引脚的高效利用见P184。

 

17、《****ARM7--LPC2200》的P187：把相应引脚设置为外部中断功能时，引脚为输入模式，由于没有内部上拉电阻，用户需要外接一个上拉电阻，确保引脚不会悬空。

 

2008-9-10 读“μCOS-II程序设计基础.ppt”笔记：

18、“μCOS-II程序设计基础.ppt”的P14：OSTimeDlyHMSM（）可能需要多个OSTimeDlyResume（）才能恢复。具体原因见函数OSTimeDlyHMSM（）。

 

19、“μCOS-II程序设计基础.ppt”的P14-P15：中断服务程序不能调用可能会导致任务调度的函数，它们主要是一些等待事件的函数***Pend（） <主要为OSFlagPend()、OSMboxPend()、OSMutexPend()、OSQPend()、OSSemPend()>，这些函数需要用***Accept（）替代函数代替。另外，函数OSTaskCreate()、OSTaskCreateExt()、OSTaskDel()、OSTaskResume()、OSTaskChangePrio()、OSTaskSuspend()、OSTimeDly()、OSTimeDlyHMSM() 、OSTimeResume()都属于在中断服务程序中禁止调用的函数。

       一些函数虽然没有明确地规定不能被中断服务程序调用，但因为中断服务程序的特性，一般不会使用：（1）创建事件和删除事件的函数。（2）.与任务相关的函数OSTaskChangePrio() 、 OSTaskDelReq() 、OSTaskStkChk() 和OSTaskQuery() 。至于函数OSSchedLock()和OSSchedUnlock()，在中断服务程序中使用没有任何意义。

 

20、“μCOS-II程序设计基础.ppt”的P18：使能任务统计功能OSStatInit()复位一次只能调用一次，并且必须在任务中调用，在调用时其它用户任务不能处于就绪状态。

 

21、“μCOS-II程序设计基础.ppt”的P18：μC/OS-II的初始化函数有2个：OSInit()和OSStart()，它们不能在任何任务和中断服务程序中使用，仅在main()函数中按照一定的规范被调用，其中OSInit()函数初始化μC/OS-II内部变量，OSStart()函数启动多任务环境。

 

22、“μCOS-II程序设计基础.ppt”的P20（《基于嵌入式实时操作系统的程序设计技术》的P134）：延时函数OSTimeDly()是以系统节拍数为参数，而延时函数OSTimeDlyHMSM()是以实际时间值为参数，但在执行过程中仍然转换为系统节拍数。如果实际时间不是系统节拍的整数倍，将进行四舍五入处理。设系统节拍为50毫秒，调用OSTimeDly(20)的效果是延时1秒钟，调用OSTimeDlyHMSM(0,1,27,620)的实际时间是延时1分27秒600毫秒。

 

23、“μCOS-II程序设计基础.ppt”的P22：状态查询过程是一个无限循环过程，只有当希望的状态出现以后才能退出这个无限循环，这种情况在实时操作系统管理下是不允许的，它将剥夺低优先级任务的运行机会。解决这个问题的办法是“用定时查询代替连续查询” 。

       查询条件成立，运行后续代码；

       不成立，延时再查询，同时让出cpu占有权，供低优先级任务使用。

 

24、“μCOS-II程序设计基础.ppt”的P26：为什么“消息油箱”和“消息队列”在数据通讯时不需要遵守“资源同步”规则 ？

       自答：例如OSMboxPost（Str_Box, s）向消息油箱Str_Box发送一个字符串指针消息，

请求消息油箱程序ss = OSMboxPend(Str_Box,10,&err)一旦得到了消息就已经把消息指针取出并且放到指针ss中，对原来的消息进行更改不会影响到ss的值。（程序例码见《嵌入式实时操作系统uC/OS-II 原理及应用》的P138）

 

25、“μCOS-II程序设计基础.ppt”的P38：无论时钟节拍何时发生，µC/OS-Ⅱ都会将一个32位的计数器加1，这个计数器在用户调用OSStart()初始化多任务和4,294,967,295个节拍执行完一遍的时候从0开始计数。

 

26、“μCOS-II程序设计基础.ppt”的P57：中断服务程序一般不会调用建立和删除事件函数，否则要么没有起到事件的作用，要么程序很复杂；

中断服务程序不能调用等待事件的函数，否则可能造成程序崩溃，可以调用无等待获得事件函数获得信号，但事实上，在中断中调用无等待获得事件的情况都很少。

 

27、“μCOS-II程序设计基础.ppt”的P59、P62：互斥信号量也称为mutex，专用于资源同步。互斥信号量具有一些特性：占用一个空闲优先级，以便解决优先级反转问题。

       在嵌入式系统中，经常使用互斥信号量访问共享资源来实现资源同步。而用来实现资源同步的互斥信号量在创建时初始化，这是由OSMutexCreate ()函数来实现的。

       OSMutexPost ()发送互斥信号量函数与OSMutexPend ()等待互斥信号量函数必须成对出现在同一个任务调用的函数中，因此我们需要编写一个公共的库函数，因为有多个任务可能调用这个函数。

 

28、“μCOS-II程序设计基础.ppt”的P82：在嵌入式系统中，经常使用信号量访问共享资源来实现资源同步。在使用时，注意发送信号量函数OSSemPost()与等待信号量函数OSSemPend()必须成对出现在同一个任务调用的函数中，才能实现资源同步。

       用来实现资源同步的信号量在创建时初始值为相同资源的数目，不过嵌入式系统中极少出现完全等同的资源，所以一般初始化为1。

 

29、“μCOS-II程序设计基础.ppt”的P97、P100：消息是任务之间的一种通信手段，当同步过程需要传输具体内容时就不能使用信号量，此时可以选择消息邮箱，即通过内核服务可以给任务发送带具体内容的消息。

       消息邮箱与信号量最大的区别：消息邮箱可以存放一条完整的内容信息，而用信号量进行行为同步时，只能提供同步时刻的信息，不能提供内容信息。

 

30、“μCOS-II程序设计基础.ppt”的P132：ANSI C中，可以使用malloc()和free()两个函数来动态分配内存，在嵌入式系统中，它们一般也是可用的，但并不适合。因为：1）产生碎片，造成连续内存不够大，导致有内存也不能分配，程序执行失败；2）分配和释放的内存块大小不同，所以执行时间不确定；3）内存一般是不可重入的。

       为了避免上面的3个问题，μC/OS-II自己设计了一套动态内存分配系统。μC/OS-II的动态内存分配是以块为单位分配的，一次只能分配一个块，块的大小可以由用户来定义。

 

31、“μCOS-II程序设计基础.ppt”的P133：系统可以管理多个堆（用于动态内存管理的空间），各个堆中的块的大小可以定义得不一样，但同一个堆中的块大小是相同的。

       μC/OS-II的动态内存管理是数据队列的绝佳伴侣，配合使用异常方便 。

 

2008-9-10 读“μCOS-II微小内核分析.ppt”笔记：

32、“μCOS-II微小内核分析.ppt” 的P9：在任务级不能调用OSIntExit()函数。即使中断服务程序使用直接递增OSIntNesting的方法（没有调用OSIntEnter()），也必须调用OSIntExit()函数。

 

33、“μCOS-II微小内核分析.ppt” 的P14：在μC/OS-Ⅱ中，当任务一旦建立，这个任务就进入就绪态准备运行。如果多任务环境已经启动，则进行任务调度。

 

34、“μCOS-II微小内核分析.ppt” 的P52-P55：关于任务级任务切换函数OS_TASK_SW()及中断级任务切换函数OSIntCtxSw()汇编代码的详细解释。以及关于OSIntCtxSw()返回时的各寄存器设置等。详见《嵌入式实时操作系统uC/OS-II 原理及应用》的P217-P219。

“μCOS-II微小内核分析.ppt” 的P53：在管理模式下LDMFD指令仅用于恢复现场、中断异常返回并执行新任务，即通过出栈操作将PC、LR（R14_svc）和状态字的值装回CPU的寄存器中。这是因为此时任务可能处于系统模式，也可能处于用户模式；可能使用ARM指令集，也可能使用Thumb指令集，所以只能用管理模式的SPSR保存任务的CPSR，然后执行该指令返回任务，只有这样处理才能保证正确地切换CPU的模式和状态。 

详细图例演示见“μCOS-II微小内核分析.ppt” 的P95。

 

36、“μCOS-II微小内核分析.ppt” 的P74：可重入的代码指的是一段代码可以被多个任务同时调用，而不必担心数据被破坏。即就是说，可重入型函数在任何时候都可以被中断，一段时间以后又可以继续运行，而相应数据却不会丢失。

可重入型函数或者只使用局部变量，即变量保存在CPU寄存器或堆栈中；或者使用全局变量。当使用全局变量时，则要对全局变量予以保护。

 

2008-9-11 读“μCOS-II微小内核分析.ppt”笔记：

37、“μCOS-II微小内核分析.ppt” 的P110：信号量初始化时一定要给信号量赋初值，并将等待信号量任务列表清空。

 

38、“μCOS-II微小内核分析.ppt” 的P114-P115：

1)、将任务加入等待任务列表：

              pevent->OSEventGrp                |= OSMapTbl[prio >> 3];

pevent->OSEventTbl[prio >> 3] |= OSMapTbl[prio & 0x07];

2）、从等待任务列表中删除任务

              if ((pevent->OSEventTbl[prio >> 3] &= ~OSMapTbl[prio & 0x07]) == 0) {

           pevent->OSEventGrp &= ~OSMapTbl[prio >> 3];

}

       3）、从等待任务列表中查找优先级最高的任务也很简单：

y     = OSUnMapTbl[pevent->OSEventGrp];

x     = OSUnMapTbl[pevent->OSEventTbl[y]];

prio = (y << 3) + x;

 

39、“μCOS-II微小内核分析.ppt” 的P128：有了事件支持之后，删除任务时就要特别小心了。当一个任务在等待事件时可能被别的任务删除，此时尽管任务已经删除，但任务还保存在事件的等待任务列表中。当对应的事件到来之时，会将这个已经不存在(或者说睡眠态)的任务设置为就绪态，这显然是不可能的。如果在事件来临之前又建立了另一个优先级相同任务，则程序执行的结果显然是错误的。

因此，删除任务时必须将任务从它等待事件的等待任务列表中删除。

 

2008-9-11 读“常见问题解答.pdf”笔记：

40、若LPC2000 芯片已加密(工程选用RelInFLASH 或RelInChip 目标时，将会对LPC2000

芯片进行加密，LPC2106/2105/2104 和LPC2210/2290 除外)，则JTAG 口无法连接调试，需

要使用ISP 软件将芯片全片擦除后才能JTAG 连接调试。

 

2008-9-18读《基于嵌入式实时操作系统的程序设计技术》笔记：

41、《基于嵌入式实时操作系统的程序设计技术》的P10：OS_MAX_EVENTS:在应用中最大事件控制块的个数，包括信号量（htwang注：计数信号量和互斥信号量）、邮箱和消息队列的总和。

<htwang注：应该还包括事件标志组。不包括事件标志组（信号量集），原因见《基于嵌入式实时操作系统uC/OS-II》的P130和P151的图例比对。>

 

42、《基于嵌入式实时操作系统的程序设计技术》的P10：OS_MAX_TASKS: 定义用户程序中可以使用的最多任务数。该值不能大于62。该项值的设定应该比实际应用的任务数大一些，这样在增加新的任务时就不需要修改这一项的值。但不能比实际任务数大太多，这样会浪费宝贵的内存空间。

<2008-9-18 htwang注：OS_MAX_TASKS 不包括统计任务和空闲任务。>

<2008-9-22 htwang注：在“os_cfg.h”中定义的OS_MAX_TASKS只是用户实际使用的任务，不包括系统任务（空闲任务和统计任务）OS_N_SYS_TASKS（在“ucos_ii.h”中定义）。原因可以见“《μCOS-II微小内核分析与程序设计—基于LPC2000》的P19”和“《基于嵌入式实时操作系统的程序设计技术》的P10”。>

 

43、《基于嵌入式实时操作系统的程序设计技术》的P10-P11：OS_LOWEST_PRIO: 设定系统中要使用的最低任务的优先级。设定该值可以节省操作系统使用RAM的空间（htwang注：如何节省？），任务的最低优先级和最大任务数没有直接关系（htwang注：最好两者要一致，如分配OS_MAX_TASKS 为11<加上统计任务和空闲任务总任务数为13>，则分配OS_LOWEST_PRIO为12<有效值为0～12共13个优先级别>）。

<任务数可以大于、等于或小于优先级数，例如5个任务可以设置10个优先级空间供选用。（赵永科）>

 

<htwang注：任务数OS_MAX_TASKS与总的任务控制块有关（见“μCOS-II微小内核分析.ppt” 的P25），需要消耗RAM，如系统文件ucos_ii.h中有：

OS_EXT  OS_TCB  OSTCBTbl[OS_MAX_TASKS + OS_N_SYS_TASKS]; /* Table of TCBs*/

而OS_LOWEST_PRIO与任务等待事件表、任务就绪表以及优先级数组有关，如系统文件ucos_ii.h中有：

#define  OS_EVENT_TBL_SIZE  ((OS_LOWEST_PRIO) / 8 + 1)   /* Size of event table*/

#define  OS_RDY_TBL_SIZE   ((OS_LOWEST_PRIO) / 8 + 1)   /* Size of ready table*/

OS_EXT  OS_TCB  *OSTCBPrioTbl[OS_LOWEST_PRIO + 1];/* Table of pointers to created TCBs */

其中：任务等待事件表：见“μCOS-II微小内核分析.ppt” 的P113-P115、也可见本笔记的第38条，与OS_LOWEST_PRIO相关的表格消耗RAM很少，只是确定位（字节）数组的大小。

任务就绪表：见“μCOS-II微小内核分析.ppt” 的P35、P33，只是在任务就绪表初始化时用到，不消耗RAM。

优先级数组：见“μCOS-II微小内核分析.ppt” 的P25，消耗RAM较少，数组放的只是指向具体任务的指针。

结论：1）、OS_LOWEST_PRIO的减小对RAM的节省微乎其微。

         2）、总的任务数（包括系统任务）不能大于最低优先级（OS_LOWEST_PRIO＋1），即必须有最低优先级 >＝ 最大任务数。否则有些任务会分配到相同的优先级，而这是uCOS操作系统所不允许的。

         3）、任务的最低优先级和最大任务数两者不一定要一致，最好是最低优先级 > 最大任务数，这样可以给操作系统升级和互斥信号量的优先级反转预留优先级空间。（htwang注：主要是为互斥信号量的优先级反转预留优先级空间，这样既可减少RAM的消耗，又可以在软件程序增加互斥信号量时不用更改每个任务的优先级。）

> 

操作系统留了两个任务优先级OS_LOWEST_PRIO和OS_LOWEST_PRIO-1给空闲任务和统计任务，所以用户可以用的实际任务优先级的值是在0～OS_LOWEST_PRIO-2之间。

       如在程序中OS_LOWEST_PRIO设定为20，实际可用的优先级为0～18，其中优先级0～3（htwang注：还应加上OS_LOWEST_PRIO-3与OS_LOWEST_PRIO-2）为操作系统作者建议保留的级别，以备升级之用（htwang注：也可用于互斥信号量的优先级反转）。如果为了产品与新版本的操作系统兼容，则可以利用的优先级为4～18，也许刚开始的实际应用中仅有7个任务，这样设置的目的是：在各个任务优先级之间彼此可以间隔，在插入新任务或者使用互斥信号量时就不用调整其他任务的优先级了。

      

44、《基于嵌入式实时操作系统的程序设计技术》的P35：uC/OS-II实时操作系统还保留对最高的4个优先级（0、1、2、3）和OS_LOWEST_PRIO-3与OS_LOWEST_PRIO-2的使用权，以备将来操作系统升级时使用。

 

45、《基于嵌入式实时操作系统的程序设计技术》的P115：互斥信号量的优先级继承权必须高于所有需要访问这个共享资源的任务的优先级。

2008-9-18 htwang注：互斥信号量应反转的优先级只要比使用互斥信号量的所有系统任务的优先级都高就可以，不一定要在最高的优先级（比如0～3）之中选。例如：有4个任务，其中任务1的优先级为4，任务2的优先级为7，这两者都没有使用互斥信号量；任务3和任务4的优先级分别为6和8，且使用了同一个互斥信号量，那么该互斥信号量所需使用的反转优先级可以为5（当然也可以为0～3）。

 

46、《基于嵌入式实时操作系统的程序设计技术》的P11：OS_TICKS_PER_SEC的如果设置得太大，则系统的实时性会受到影响；如果设置得太小，则CPU会忙于时钟处理而增大开销。

 

47、《基于嵌入式实时操作系统的程序设计技术》的P14：在普通的应用中，用户是通过调用TargetInit()函数初始化目标板。但是千万不要在启动多任务以前调用TargetInit()函数，因为该函数打开了时钟节拍中断。

 

48、《基于嵌入式实时操作系统的程序设计技术》的P14：如果用户需要用FIQ中断，就应该定义FIQ中断堆栈的大小。

<htwang注：在启动代码文件Startup.s文件的最开始处有各个异常的堆栈大小定义。>

 

49、《基于嵌入式实时操作系统的程序设计技术》的P25：任务划分小结：

       1）、首先，以CPU为中心，将与各种输入/输出设备（或端口）相关的功能分别划分为独立的任务；

       2）、发现“关键”功能，将其最“关键”部分“剥离”出来，用一个独立任务（或ISR）完成，剩余部分用另外一个任务实现，两者之间通过通信机制沟通；

       3）、发现“紧迫”功能，将其最“紧迫”部分“剥离”出来，用一个独立的高优先级任务（或ISR）完成，剩余部分用另外一个任务实现，两者之间通过通信机制沟通；

       4）、对于既“关键”又“紧迫”的功能，按“紧迫”功能处理；

       5）、将消耗机时较多的数据处理功能划分出来，封装为较低优先级任务；

       6）、将关系密切的若干功能组合成为一个任务，达到功能聚合的效果；

       7）、将由相同事件触发的若干功能组合成为一个任务，从而免除事件分发机制；

       8）、将运行周期相同的功能组合成为一个任务，从而免除时间事件分发机制；

       9）、将若干按固定顺序执行的功能组合成为一个任务，从而免除同步接力通信的麻烦。

 

50、2008-9-19补 《基于嵌入式实时操作系统的程序设计技术》的P36：任务的优先级安排原则如下：

       1）、中断关联性：与中断服务程序（ISR）有关联的任务应该安排尽可能高的优先级，以便及时处理异步事件，提高系统的实时性。如果优先级安排得比较低，则CPU有可能被优先级比较高的任务长期占用，以致于在第二次中断发生时连第一次中断还没有处理，从而产生信号丢失现象；

       2）、紧迫性：因为紧迫任务对响应时间有严格要求，在所有紧迫任务中，按响应时间要求排序，越紧迫的任务安排的优先级越高。紧迫性为最高原则。紧迫任务通常与ISR关联。

       3）、关键性：任务越关键安排的优先级越高，以保障其执行机会。

       4）、频繁性：对于周期性任务，执行越频繁，则周期越短，允许耽误的时间也越短，故应该安排的优先级也越高，以保障及时得到执行。

       5）、快捷性：在前面各项条件相近时，越快捷（耗时短）的任务安排的优先级越高，以使其他就绪任务的延时缩短。

       6）、传递性：信息传递的上游任务的优先级高于下游任务的优先级，如信号采集任务的优先级高于数据处理任务的优先级。

<htwang 注：注意任务同时满足几个原则的情况。如一个任务既紧迫又关键，就不能按照关键任务处理，应该按照（关键的）紧迫任务处理。>

 

51、2008-9-18 《基于嵌入式实时操作系统的程序设计技术》的P25：任务运行必须满足RMA测试公式，任务才能正常运行调度。详见《基于嵌入式实时操作系统的程序设计技术》的P25-P26。

RMA的测试公式为：   

式中：*博客内容为网友个人发布，仅代表博主个人观点，如有侵权请联系工作人员删除。