0429

OS_CPU.H

1. OS_CPU.H包括了用#defines定义的与处理器相关的常量，宏和类型定义。OS_CPU.H的大体结构如程序清单 L8.1所示。  
2. 程序清单 L 8.1  OS_CPU.H.  
3. #ifdef  OS_CPU_GLOBALS  
4. #define OS_CPU_EXT  
5. #else  
6. #define OS_CPU_EXT  extern  
7. #endif  
8.   
9. /* 
10. ************************************************************************ 
11. *                                数据类型 
12. *                            (与编译器相关) 
13. ************************************************************************ 
14. */  
15.   
16. typedef unsigned char  BOOLEAN;  
17. typedef unsigned char  INT8U;      /* 无符号8位整数    */    (1)  
18. typedef signed   char  INT8S;       /* 有符号8位整数    */  
19. typedef unsigned int   INT16U;     /* 无符号16位整数   */  
20. typedef signed   int   INT16S;      /* 有符号16位整数   */  
21. typedef unsigned long  INT32U;     /* 无符号32位整数   */  
22. typedef signed   long  INT32S;      /* 有符号32位整数   */  
23. typedef float          FP32;         /* 单精度浮点数      */  (2)  
24. typedef double         FP64;         /* 双精度浮点数     */  
25.   
26. typedef unsigned int   OS_STK;      /* 堆栈入口宽度为16位 */  
27.   
28. /* 
29. ************************************************************************* 
30. *                             与处理器相关的代码 
31. ************************************************************************* 
32. */  
33.   
34. #define  OS_ENTER_CRITICAL()  ???  /* 禁止中断              */  (3)  
35. #define  OS_EXIT_CRITICAL()   ???  /* 允许中断              */  
36.   
37. #define  OS_STK_GROWTH        1    /* 定义堆栈的增长方向： 1=向下, 0=向上 */  (4)  
38.   
39. #define  OS_TASK_SW()         ???   (5)  
40.   
41. 01与编译器相关的数据类型  
42.     因为不同的微处理器有不同的字长，所以µC/OS-Ⅱ的移植包括了一系列的类型定义以确保其可移植性。尤其是，µC/OS-Ⅱ代码从不使用C的short,int和long等数据类型，因为它们是与编译器相关的，不可移植。相反的，我定义的整型数据结构既是可移植的又是直观的[L8.1(2)]。为了方便，虽然µC/OS-Ⅱ不使用浮点数据，但我还是定义了浮点数据类型[L8.1(2)]。  
43.     例如，INT16U数据类型总是代表16位的无符号整数。现在，µC/OS-Ⅱ和用户的应用程序就可以估计出声明为该数据类型的变量的数值范围是0－65535。将µC/OS-Ⅱ移植到32位的处理器上也就意味着INT16U实际被声明为无符号短整型数据结构而不是无符号整型数据结构。但是，µC/OS-Ⅱ所处理的仍然是INT16U。  
44.     用户必须将任务堆栈的数据类型告诉给µC/OS-Ⅱ。这个过程是通过为OS_STK声明正确的C数据类型来完成的。如果用户的处理器上的堆栈成员是32位的，并且用户的编译文件指定整型为32位数，那么就应该将OS_STK声明位无符号整型数据类型。所有的任务堆栈都必须用OS_STK来声明数据类型。  
45.     用户所必须要做的就是查看编译器手册，并找到对应于µC/OS-Ⅱ的标准C数据类型。  
46.   
47. .02 OS_ENTER_CRITICAL()和OS_EXIT_CRITICAL()  
48.     与所有的实时内核一样，µC/OS-Ⅱ需要先禁止中断再访问代码的临界段，并且在访问完毕后重新允许中断。这就使得µC/OS-Ⅱ能够保护临界段代码免受多任务或中断服务例程(ISRs)的破坏。中断禁止时间是商业实时内核公司提供的重要指标之一，因为它将影响到用户的系统对实时事件的响应能力。虽然µC/OS-Ⅱ尽量使中断禁止时间达到最短，但是µC/OS-Ⅱ的中断禁止时间还主要依赖于处理器结构和编译器产生的代码的质量。通常每个处理器都会提供一定的指令来禁止/允许中断，因此用户的C编译器必须要有一定的机制来直接从C中执行这些操作。有些编译器能够允许用户在C源代码中插入汇编语言声明。这样就使得插入处理器指令来允许和禁止中断变得很容易了。其它一些编译器实际上包括了语言扩展功能，可以直接从C中允许和禁止中断。为了隐藏编译器厂商提供的具体实现方法，µC/OS-Ⅱ定义了两个宏来禁止和允许中断：OS_ENTER_CRITICAL()和OS_EXIT_CRITICAL()[L8.1(3)]。  
49.   
50. {  
51.     OS_ENTER_CRITICAL();  
52.     /* ｵµC/OS-II 临界代码段 */  
53.     OS_EXIT_CRITICAL();  
54. }  
55.   
56. 方法1  
57.     执行这两个宏的第一个也是最简单的方法是在OS_ENTER_CRITICAL()中调用处理器指令来禁止中断，以及在OS_EXIT_CRITICAL()中调用允许中断指令。但是，在这个过程中还存在着小小的问题。如果用户在禁止中断的情况下调用µC/OS-Ⅱ函数，在从µC/OS-Ⅱ返回的时候，中断可能会变成是允许的了！如果用户禁止中断就表明用户想在从µC/OS-Ⅱ函数返回的时候中断还是禁止的。在这种情况下，光靠这种执行方法可能是不够的。  
58. 方法2  
59.     执行OS_ENTER_CRITICAL()的第二个方法是先将中断禁止状态保存到堆栈中，然后禁止中断。而执行OS_EXIT_CRITICAL()的时候只是从堆栈中恢复中断状态。如果用这个方法的话，不管用户是在中断禁止还是允许的情况下调用µC/OS-Ⅱ服务，在整个调用过程中都不会改变中断状态。如果用户在中断禁止的时候调用µC/OS-Ⅱ服务，其实用户是在延长应用程序的中断响应时间。用户的应用程序还可以用OS_ENTER_CRITICAL()和OS_EXIT_CRITICAL()来保护代码的临界段。但是，用户在使用这种方法的时候还得十分小心，因为如果用户在调用象OSTimeDly()之类的服务之前就禁止中断，很有可能用户的应用程序会崩溃。发生这种情况的原因是任务被挂起直到时间期满，而中断是禁止的，因而用户不可能获得节拍中断！很明显，所有的PEND调用都会涉及到这个问题，用户得十分小心。一个通用的办法是用户应该在中断允许的情况下调用µC/OS-Ⅱ的系统服务！  
60.     问题是：哪种方法更好一点？这就得看用户想牺牲些什么。如果用户并不关心在调用µC/OS-Ⅱ服务后用户的应用程序中中断是否是允许的，那么用户应该选择第一种方法执行。如果用户想在调用µC/OS-Ⅱ服务过程中保持中断禁止状态，那么很明显用户应该选择第二种方法。  
61.     给用户举个例子吧，通过执行STI命令在Intel 80186上禁止中断，并用CLI命令来允许中断。用户可以用下面的方法来执行这两个宏：  
62.   
63. #define OS_ENTER_CRITICAL()  asm CLI  
64. #define OS_EXIT_CRITICAL()   asm STI  
65.   
66.     CLI和SCI指令都会在两个时钟周期内被马上执行(总共为四个周期)。为了保持中断状态，用户需要用下面的方法来执行宏：  
67.   
68. #define OS_ENTER_CRITICAL()  asm PUSHF; CLI  
69. #define OS_EXIT_CRITICAL()   asm POPF  
70.   
71.     在这种情况下，OS_ENTER_CRITICAL()需要12个时钟周期，而OS_EXIT_CRITICAL()需要另外的8个时钟周期(总共有20个周期)。这样，保持中断禁止状态要比简单的禁止/允许中断多花16个时钟周期的时间(至少在80186上是这样的)。当然，如果用户有一个速度比较快的处理器(如Intel Pentium Ⅱ),那么这两种方法的时间差别会很小。  
72. 03  OS_STK_GROWTH  
73.     绝大多数的微处理器和微控制器的堆栈是从上往下长的。但是某些处理器是用另外一种方式工作的。µC/OS-Ⅱ被设计成两种情况都可以处理，只要在结构常量OS_STK_GROWTH [L8.1(4)]中指定堆栈的生长方式(如下所示)就可以了。  
74.     置OS_STK_GROWTH为0表示堆栈从下往上长。  
75.     置OS_STK_GROWTH为1表示堆栈从上往下长。  
76. 04  OS_TASK_SW()  
77.     OS_TASK_SW()[L8.1(5)]是一个宏，它是在µC/OS-Ⅱ从低优先级任务切换到最高优先级任务时被调用的。OS_TASK_SW()总是在任务级代码中被调用的。另一个函数OSIntExit()被用来在ISR使得更高优先级任务处于就绪状态时，执行任务切换功能。任务切换只是简单的将处理器寄存器保存到将被挂起的任务的堆栈中，并且将更高优先级的任务从堆栈中恢复出来。  
78.     在µC/OS-Ⅱ中，处于就绪状态的任务的堆栈结构看起来就像刚发生过中断并将所有的寄存器保存到堆栈中的情形一样。换句话说，µC/OS-Ⅱ要运行处于就绪状态的任务必须要做的事就是将所有处理器寄存器从任务堆栈中恢复出来，并且执行中断的返回。为了切换任务可以通过执行OS_TASK_SW()来产生中断。大部分的处理器会提供软中断或是陷阱（TRAP）指令来完成这个功能。ISR或是陷阱处理函数(也叫做异常处理函数)的向量地址必须指向汇编语言函数OSCtxSw()(参看8.04.02)。  
79.     例如，在Intel或者AMD 80x86处理器上可以使用INT指令。但是中断处理向量需要指向OSCtxSw()。Motorola 68HC11处理器使用的是SWI指令，同样，SWI的向量地址仍是OSCtxSw()。还有，Motorola 680x0/CPU32可能会使用16个陷阱指令中的一个。当然，选中的陷阱向量地址还是OSCtxSw()。  
80.     一些处理器如Zilog Z80并不提供软中断机制。在这种情况下，用户需要尽自己的所能将堆栈结构设置成与中断堆栈结构一样。OS_TASK_SW()只会简单的调用OSCtxSw()而不是将某个向量指向OSCtxSw()。µC/OS已经被移植到了Z80处理器上，µC/OS-Ⅱ也同样可以。