第13章移植ucosII.doc

上传人:工**** 文档编号:562695118 上传时间:2022-11-17 格式:DOC 页数:20 大小:297.51KB
返回 下载 相关 举报
第13章移植ucosII.doc_第1页
第1页 / 共20页
第13章移植ucosII.doc_第2页
第2页 / 共20页
第13章移植ucosII.doc_第3页
第3页 / 共20页
第13章移植ucosII.doc_第4页
第4页 / 共20页
第13章移植ucosII.doc_第5页
第5页 / 共20页
点击查看更多>>
资源描述

《第13章移植ucosII.doc》由会员分享,可在线阅读,更多相关《第13章移植ucosII.doc(20页珍藏版)》请在金锄头文库上搜索。

1、第13章移植C/OS-这一章介绍如何将C/OS-移植到不同的处理器上。所谓移植,就是使一个实时内核能在某个微处理器或微控制器上运行。为了方便移植,大部分的C/OS-代码是用C语言写的;但仍需要用C和汇编语言写一些与处理器相关的代码,这是因为C/OS-在读写处理器寄存器时只能通过汇编语言来实现。由于C/OS-在设计时就已经充分考虑了可移植性,所以C/OS-的移植相对来说是比较容易的。如果已经有人在您使用的处理器上成功地移植了C/OS-,您也得到了相关代码,就不必看本章了。当然,本章介绍的内容将有助于用户了解C/OS-中与处理器相关的代码。要使C/OS-正常运行,处理器必须满足以下要求:1.处理器

2、的C编译器能产生可重入代码。2. 用C语言就可以打开和关闭中断。3. 处理器支持中断,并且能产生定时中断(通常在10至100Hz之间)。4. 处理器支持能够容纳一定量数据(可能是几千字节)的硬件堆栈。5. 处理器有将堆栈指针和其它CPU寄存器读出和存储到堆栈或内存中的指令。像Motorola 6805系列的处理器不能满足上面的第4条和第5条要求,所以C/OS-不能在这类处理器上运行。图13.1说明了C/OS-的结构以及它与硬件的关系。由于C/OS-为自由软件,当用户用到C/OS-时,有责任公开应用软件和C/OS-的配置代码。这本书和磁盘包含了所有与处理器无关的代码和Intel 80x86实模式

3、下的与处理器相关的代码(C编译器大模式下编译)。如果用户打算在其它处理器上使用C/OS-,最好能找到一个现成的移植实例,如果没有只好自己编写了。用户可以在正式的C/OS-网站www. COS-.com中查找一些移植实例。图 13.1C/OS-II 硬件和软件体系结构如果用户理解了处理器和C编译器的技术细节,移植C/OS-的工作实际上是非常简单的。前提是您的处理器和编译器满足了C/OS-的要求,并且已经有了必要工具。移植工作包括以下几个内容:l 用#define设置1个常量的值(OS_CPU.H)l 声明11个数据类型(OS_CPU.H)l 用#define声明4个宏(OS_CPU.H)l 用C

4、语言编写10个简单的函数(OS_CPU_C.C)l 编写四个汇编语言函数(OS_CPU_A.ASM)根据处理器的不同,一个移植实例可能需要编写或改写50至300行的代码,需要的时间从几个小时到一星期不等。一旦代码移植结束,下一步工作就是测试。测试一个象C/OS-一样的多任务实时内核并不复杂。甚至可以在没有应用程序的情况下测试。换句话说,就是让内核自己测试自己。这样做有两个好处:第一,避免使本来就复杂的事情更加复杂;第二,如果出现问题,可以知道问题出在内核代码上而不是应用程序。刚开始的时候可以运行一些简单的任务和时钟节拍中断服务例程。一旦多任务调度成功地运行了,再添加应用程序的任务就是非常简单的

5、工作了。13.00开发工具如前所述,移植C/OS-需要一个C编译器,并且是针对用户用的CPU的。因为C/OS-是一个可剥夺型内核,用户只有通过C编译器来产生可重入代码;C编译器还要支持汇编语言程序。绝大部分的C编译器都是为嵌入式系统设计的,它包括汇编器、连接器和定位器。连接器用来将不同的模块(编译过和汇编过的文件)连接成目标文件。定位器则允许用户将代码和数据放置在目标处理器的指定内存映射空间中。所用的C编译器还必须提供一个机制来从C中打开和关闭中断。一些编译器允许用户在C源代码中插入汇编语言。这就使得插入合适的处理器指令来允许和禁止中断变得非常容易了。还有一些编译器实际上包括了语言扩展功能,可

6、以直接从C中允许和禁止中断。13.01目录和文件本书所付的磁盘中提供了C/OS-的安装程序,可在硬盘上安装C/OS-和移植实例代码(Intel 80x86实模式,大模式编译)。我设计了一个连续的目录结构,使得用户更容易找到目标处理器的文件。如果想增加一个其它处理器的移植实例,您可以考虑采取同样的方法(包括目录的建立和文件的命名等等)。所有的移植实例都应放在用户硬盘的SOFTWARECOS-目录下。各个微处理器或微控制器的移植源代码必须在以下两个或三个文件中找到:OS_CPU.H,OS_CPU_C.C,OS_CPU_A.ASM。汇编语言文件OS_CPU_A.ASM是可选择的,因为某些C编译器允许

7、用户在C语言中插入汇编语言,所以用户可以将所需的汇编语言代码直接放到OS_CPU_C.C中。放置移植实例的目录决定于用户所用的处理器,例如在下面的表中所示的放置不同移植实例的目录结构。注意,各个目录虽然针对完全不同的目标处理器,但都包括了相同的文件名。Intel/AMD 80186SOFTWAREuCOS-IIIx86SOS_CPU.HOS_CPU_A.ASMOS_CPU_C.CSOFTWAREuCOS-IIIx86LOS_CPU.HOS_CPU_A.ASMOS_CPU_C.CMotorola 68HC11SOFTWAREuCOS-II68HC11 OS_CPU.HOS_CPU_A.ASMOS

8、_CPU_C.C13.02INCLUDES.H在第一章中曾提到过,INCLUDES.H是一个头文件,它在所有.C文件的第一行被包含。#include includes.hINCLUDES.H使得用户项目中的每个.C文件不用分别去考虑它实际上需要哪些头文件。使用INCLUDES.H的唯一缺点是它可能会包含一些实际不相关的头文件。这意味着每个文件的编译时间可能会增加。但由于它增强了代码的可移植性,所以我们还是决定使用这一方法。用户可以通过编辑INCLUDES.H来增加自己的头文件,但是用户的头文件必须添加在头文件列表的最后。13.03OS_CPU.HOS_CPU.H包括了用#defines定义的与

9、处理器相关的常量,宏和类型定义。OS_CPU.H的大体结构如程序清单 L13.1所示。程序清单 L 13.1OS_CPU.H.#ifdef OS_CPU_GLOBALS#define OS_CPU_EXT#else#define OS_CPU_EXT extern#endif/* 数据类型* (与编译器相关)*/typedef unsigned char BOOLEAN;typedef unsigned char INT8U; /* 无符号8位整数 */ (1)typedef signed char INT8S; /* 有符号8位整数 */typedef unsigned int INT16U

10、; /* 无符号16位整数 */typedef signed int INT16S; /* 有符号16位整数 */typedef unsigned long INT32U; /* 无符号32位整数 */typedef signed long INT32S; /* 有符号32位整数 */typedef float FP32; /* 单精度浮点数 */(2)typedef double FP64; /* 双精度浮点数 */typedef unsigned int OS_STK; /* 堆栈入口宽度为16位 */* 与处理器相关的代码*/#define OS_ENTER_CRITICAL() ? /

11、* 禁止中断 */(3)#define OS_EXIT_CRITICAL() ? /* 允许中断 */#define OS_STK_GROWTH 1 /* 定义堆栈的增长方向: 1=向下, 0=向上 */(4)#define OS_TASK_SW() ?(5)13.03.01与编译器相关的数据类型因为不同的微处理器有不同的字长,所以C/OS-的移植包括了一系列的类型定义以确保其可移植性。尤其是,C/OS-代码从不使用C的short,int和long等数据类型,因为它们是与编译器相关的,不可移植。相反的,我定义的整型数据结构既是可移植的又是直观的L13.1(2)。为了方便,虽然C/OS-不使用浮

12、点数据,但我还是定义了浮点数据类型L13.1(2)。例如,INT16U数据类型总是代表16位的无符号整数。现在,C/OS-和用户的应用程序就可以估计出声明为该数据类型的变量的数值范围是065535。将C/OS-移植到32位的处理器上也就意味着INT16U实际被声明为无符号短整型数据结构而不是无符号整型数据结构。但是,C/OS-所处理的仍然是INT16U。用户必须将任务堆栈的数据类型告诉给C/OS-。这个过程是通过为OS_STK声明正确的C数据类型来完成的。如果用户的处理器上的堆栈成员是32位的,并且用户的编译文件指定整型为32位数,那么就应该将OS_STK声明位无符号整型数据类型。所有的任务堆

13、栈都必须用OS_STK来声明数据类型。用户所必须要做的就是查看编译器手册,并找到对应于C/OS-的标准C数据类型。13.03.02OS_ENTER_CRITICAL()和OS_EXIT_CRITICAL()与所有的实时内核一样,C/OS-需要先禁止中断再访问代码的临界段,并且在访问完毕后重新允许中断。这就使得C/OS-能够保护临界段代码免受多任务或中断服务例程(ISRs)的破坏。中断禁止时间是商业实时内核公司提供的重要指标之一,因为它将影响到用户的系统对实时事件的响应能力。虽然C/OS-尽量使中断禁止时间达到最短,但是C/OS-的中断禁止时间还主要依赖于处理器结构和编译器产生的代码的质量。通常每个处理器都会提供一定的指令来禁止/允许中断,因此用户的C编译器必须要有一定的机制来直接从C中执行这些操作。有些编译器能够允许用户在C源代码中插入汇编语言声明。这样就使得插入处理器指令来允许和禁止中断变得很容易了。其它一些编译器实际上包括了语言扩展功能,可以直接从C中允许和禁止中断。为了隐藏编译器厂商提供的具体实现方法,C/OS-定义了两个宏来禁止和允许中断:

展开阅读全文
相关资源
相关搜索

当前位置:首页 > 生活休闲 > 社会民生

电脑版 |金锄头文库版权所有
经营许可证:蜀ICP备13022795号 | 川公网安备 51140202000112号