51单片机上移植ucosIIWord格式.docx
《51单片机上移植ucosIIWord格式.docx》由会员分享，可在线阅读，更多相关《51单片机上移植ucosIIWord格式.docx（13页珍藏版）》请在冰豆网上搜索。
绝大部分的C编译器都是为嵌入式系统设计的，它包括汇编器、连接器和定位器。
连接器用来将不同的模块（编译过和汇编过的文件）连接成目标文件。
定位器则允许用户将代码和数据放置在目标处理器的指定内存映射空间中。
所用的C编译器还必须提供一个机制来从C中打开和关闭中断。
一些编译器允许用户在C源代码中插入汇编语言。
这就使得插入合适的处理器指令来允许和禁止中断变得非常容易了。
还有一些编译器实际上包括了语言扩展功能，可以直接从C中允许和禁止中断。
3.目录和文件
本书所付的磁盘中提供了µ
C/OS-Ⅱ的安装程序，可在硬盘上安装µ
C/OS-Ⅱ和移植实例代码（Intel80x86实模式，大模式编译）。
我设计了一个连续的目录结构，使得用户更容易找到目标处理器的文件。
如果想增加一个其它处理器的移植实例，您可以考虑采取同样的方法（包括目录的建立和文件的命名等等）。
所有的移植实例都应放在用户硬盘的\SOFTWARE\µ
COS-Ⅱ目录下。
各个微处理器或微控制器的移植源代码必须在以下两个或三个文件中找到：
OS_CPU.H，OS_CPU_C.C，OS_CPU_A.ASM。
汇编语言文件OS_CPU_A.ASM是可选择的，因为某些C编译器允许用户在C语言中插入汇编语言，所以用户可以将所需的汇编语言代码直接放到OS_CPU_C.C中。
放置移植实例的目录决定于用户所用的处理器，例如在下面的表中所示的放置不同移植实例的目录结构。
注意，各个目录虽然针对完全不同的目标处理器，但都包括了相同的文件名。
Intel/AMD80186
\SOFTWARE\uCOS-II\Ix86S
\OS_CPU.H
\OS_CPU_A.ASM
\OS_CPU_C.C
\SOFTWARE\uCOS-II\Ix86L
Motorola68HC11
\SOFTWARE\uCOS-II\68HC11
INCLUDES.H
在第一章中曾提到过，INCLUDES.H是一个头文件，它在所有.C文件的第一行被包含。
#include"
includes.h"
INCLUDES.H使得用户项目中的每个.C文件不用分别去考虑它实际上需要哪些头文件。
使用INCLUDES.H的唯一缺点是它可能会包含一些实际不相关的头文件。
这意味着每个文件的编译时间可能会增加。
但由于它增强了代码的可移植性，所以我们还是决定使用这一方法。
用户可以通过编辑INCLUDES.H来增加自己的头文件，但是用户的头文件必须添加在头文件列表的最后。
OS_CPU.H
OS_CPU.H包括了用#defines定义的与处理器相关的常量，宏和类型定义。
OS_CPU.H的大体结构如程序清单L8.1所示。
程序清单L8.1OS_CPU.H.
#ifdefOS_CPU_GLOBALS
#defineOS_CPU_EXT
#else
#defineOS_CPU_EXTextern
#endif
/*
************************************************************************
*数据类型
*（与编译器相关）
*/
typedefunsignedcharBOOLEAN;
typedefunsignedcharINT8U;
/*无符号8位整数*/
（1）
typedefsignedcharINT8S;
/*有符号8位整数*/
typedefunsignedintINT16U;
/*无符号16位整数*/
typedefsignedintINT16S;
/*有符号16位整数*/
typedefunsignedlongINT32U;
/*无符号32位整数*/
typedefsignedlongINT32S;
/*有符号32位整数*/
typedeffloatFP32;
/*单精度浮点数*/
（2）
typedefdoubleFP64;
/*双精度浮点数*/
typedefunsignedintOS_STK;
/*堆栈入口宽度为16位*/
*************************************************************************
*与处理器相关的代码
#defineOS_ENTER_CRITICAL（）?
?
/*禁止中断*/（3）
#defineOS_EXIT_CRITICAL（）?
/*允许中断*/
#defineOS_STK_GROWTH1/*定义堆栈的增长方向：
1=向下,0=向上*/（4）
#defineOS_TASK_SW（）?
（5）
与编译器相关的数据类型
因为不同的微处理器有不同的字长，所以µ
C/OS-Ⅱ的移植包括了一系列的类型定义以确保其可移植性。
尤其是，µ
C/OS-Ⅱ代码从不使用C的short,int和long等数据类型，因为它们是与编译器相关的，不可移植。
相反的，我定义的整型数据结构既是可移植的又是直观的[L8.1
（2）]。
为了方便，虽然µ
C/OS-Ⅱ不使用浮点数据，但我还是定义了浮点数据类型[L8.1
（2）]。
例如，INT16U数据类型总是代表16位的无符号整数。
现在，µ
C/OS-Ⅱ和用户的应用程序就可以估计出声明为该数据类型的变量的数值范围是0－65535。
将µ
C/OS-Ⅱ移植到32位的处理器上也就意味着INT16U实际被声明为无符号短整型数据结构而不是无符号整型数据结构。
但是，µ
C/OS-Ⅱ所处理的仍然是INT16U。
用户必须将任务堆栈的数据类型告诉给µ
C/OS-Ⅱ。
这个过程是通过为OS_STK声明正确的C数据类型来完成的。
如果用户的处理器上的堆栈成员是32位的，并且用户的编译文件指定整型为32位数，那么就应该将OS_STK声明位无符号整型数据类型。
所有的任务堆栈都必须用OS_STK来声明数据类型。
用户所必须要做的就是查看编译器手册，并找到对应于µ
C/OS-Ⅱ的标准C数据类型。
OS_ENTER_CRITICAL（）和OS_EXIT_CRITICAL（）
与所有的实时内核一样，µ
C/OS-Ⅱ需要先禁止中断再访问代码的临界段，并且在访问完毕后重新允许中断。
这就使得µ
C/OS-Ⅱ能够保护临界段代码免受多任务或中断服务例程（ISRs）的破坏。
中断禁止时间是商业实时内核公司提供的重要指标之一，因为它将影响到用户的系统对实时事件的响应能力。
虽然µ
C/OS-Ⅱ尽量使中断禁止时间达到最短，但是µ
C/OS-Ⅱ的中断禁止时间还主要依赖于处理器结构和编译器产生的代码的质量。
通常每个处理器都会提供一定的指令来禁止/允许中断，因此用户的C编译器必须要有一定的机制来直接从C中执行这些操作。
有些编译器能够允许用户在C源代码中插入汇编语言声明。
这样就使得插入处理器指令来允许和禁止中断变得很容易了。
其它一些编译器实际上包括了语言扩展功能，可以直接从C中允许和禁止中断。
为了隐藏编译器厂商提供的具体实现方法，µ
C/OS-Ⅱ定义了两个宏来禁止和允许中断：
OS_ENTER_CRITICAL（）和OS_EXIT_CRITICAL（）[L8.1（3）]。
{
OS_ENTER_CRITICAL（）;
/*ｵµ
C/OS-II临界代码段*/
OS_EXIT_CRITICAL（）;
}
方法1
执行这两个宏的第一个也是最简单的方法是在OS_ENTER_CRITICAL（）中调用处理器指令来禁止中断，以及在OS_EXIT_CRITICAL（）中调用允许中断指令。
但是，在这个过程中还存在着小小的问题。
如果用户在禁止中断的情况下调用µ
C/OS-Ⅱ函数，在从µ
C/OS-Ⅱ返回的时候，中断可能会变成是允许的了！
如果用户禁止中断就表明用户想在从µ
C/OS-Ⅱ函数返回的时候中断还是禁止的。
在这种情况下，光靠这种执行方法可能是不够的。
方法2
执行OS_ENTER_CRITICAL（）的第二个方法是先将中断禁止状态保存到堆栈中，然后禁止中断。
而执行OS_EXIT_CRITICAL（）的时候只是从堆栈中恢复中断状态。
如果用这个方法的话，不管用户是在中断禁止还是允许的情况下调用µ
C/OS-Ⅱ服务，在整个调用过程中都不会改变中断状态。
如果用户在中断禁止的时候调用µ
C/OS-Ⅱ服务，其实用户是在延长应用程序的中断响应时间。
用户的应用程序还可以用OS_ENTER_CRITICAL（）和OS_EXIT_CRITICAL（）来保护代码的临界段。
但是，用户在使用这种方法的时候还得十分小心，因为如果用户在调用象OSTimeDly（）之类的服务之前就禁止中断，很有可能用户的应用程序会崩溃。
发生这种情况的原因是任务被挂起直到时间期满，而中断是禁止的，因而用户不可能获得节拍中断！
很明显，所有的PEND调用都会涉及到这个问题，用户得十分小心。
一个通用的办法是用户应该在中断允许的情况下调用µ
C/OS-Ⅱ的系统服务！
问题是：
哪种方法更好一点？
这就得看用户想牺牲些什么。
如果用户并不关心在调用µ
C/OS-Ⅱ服务后用户的应用程序中中断是否是允许的，那么用户应该选择第一种方法执行。
如果用户想在调用µ
C/OS-Ⅱ服务过程中保持中断禁止状态，那么很明显用户应该选择第二种方法。
给用户举个例子吧，通过执行STI命令在Intel80186上禁止中断，并用CLI命令来允许中断。
用户可以用下面的方法来执行这两个宏：
#defineOS_ENTER_CRITICAL（）asmCLI
#defineOS_EXIT_CRITICAL（）asmSTI
CLI和SCI指令都会在两个时钟周期内被马上执行（总共为四个周期）。
为了保持中断状态，用户需要用下面的方法来执行宏：
#defineOS_ENTER_CRITICAL（）asmPUSHF;
CLI
#defineOS_EXIT_CRITICAL（）asmPOPF
在这种情况下，OS_ENTER_CRITICAL（）需要12个时钟周期，而OS_EXIT_CRITICAL（）需要另外的8个时钟周期（总共有20个周期）。
这样，保持中断禁止状态要比简单的禁止/允许中断多花16个时钟周期的时间（至少在80186上是这样的）。
当然，如果用户有一个速度比较快的处理器（如IntelPentiumⅡ）,那么这两种方法的时间差别会很小。
OS_STK_GROWTH
绝大多数的微处理器和微控制器的堆栈是从上往下长的。
但是某些处理器是用另外一种方式工作的。
µ
C/OS-Ⅱ被设计成两种情况都可以处理，只要在结构常量OS_STK_GROWTH[L8.1（4）]中指定堆栈的生长方式（如下所示）就可以了。
置OS_STK_GROWTH为0表示堆栈从下往上长。
置OS_STK_GROWTH为1表示堆栈从上往下长。
OS_TASK_SW（）
OS_TASK_SW（）[L8.1（5）]是一个宏，它是在µ
C/OS-Ⅱ从低优先级任务切换到最高优先级任务时被调用的。
OS_TASK_SW（）总是在任务级代码中被调用的。
另一个函数OSIntExit（）被用来在ISR使得更高优先级任务处于就绪状态时，执行任务切换功能。
任务切换只是简单的将处理器寄存器保存到将被挂起的任务的堆栈中，并且将更高优先级的任务从堆栈中恢复出来。
在µ
C/OS-Ⅱ中，处于就绪状态的任务的堆栈结构看起来就像刚发生过中断并将所有的寄存器保存到堆栈中的情形一样。
换句话说，µ
C/OS-Ⅱ要运行处于就绪状态的任务必须要做的事就是将所有处理器寄存器从任务堆栈中恢复出来，并且执行中断的返回。
为了切换任务可以通过执行OS_TASK_SW（）来产生中断。
大部分的处理器会提供软中断或是陷阱（TRAP）指令来完成这个功能。
ISR或是陷阱处理函数（也叫做异常处理函数）的向量地址必须指向汇编语言函数OSCtxSw（）（参看8.04.02）。
例如，在Intel或者AMD80x86处理器上可以使用INT指令。
但是中断处理向量需要指向OSCtxSw（）。
Motorola68HC11处理器使用的是SWI指令，同样，SWI的向量地址仍是OSCtxSw（）。
还有，Motorola680x0/CPU32可能会使用16个陷阱指令中的一个。
当然，选中的陷阱向量地址还是OSCtxSw（）。
一些处理器如ZilogZ80并不提供软中断机制。
在这种情况下，用户需要尽自己的所能将堆栈结构设置成与中断堆栈结构一样。
OS_TASK_SW（）只会简单的调用OSCtxSw（）而不是将某个向量指向OSCtxSw（）。
C/OS已经被移植到了Z80处理器上，µ
C/OS-Ⅱ也同样可以。
OS_CPU_A.ASM
µ
C/OS-Ⅱ的移植实例要求用户编写四个简单的汇编语言函数：
OSStartHighRdy（）
OSCtxSw（）
OSIntCtxSw（）
OSTickISR（）
如果用户的编译器支持插入汇编语言代码的话，用户就可以将所有与处理器相关的代码放到OS_CPU_C.C文件中，而不必再拥有一些分散的汇编语言文件。
四．实验步骤
1.安装实验环境keiluV4
●安装KeilC51V9.00版本，即uV4
●打开uVision4，点击File---LicenseManagement...，打开LicenseManagement窗口，复制右上角的CID
●打开注册机，在CID窗口里填上刚刚复制的CID，其它设置不变
●点击Generate生成许可号，复制许可号
●将许可号复制到LicenseManagement窗口下部的NewLicenseIDCode，点击右侧的AddLIC
●若上方的Product显示的是PK51Prof.DevelopersKit即注册成功，SupportPeriod为有效期，一般可以到30年左右，若有效期较短，可多次生成许可号重新注册。
。
2.打开实验例程
1）打开51ucosii软件包，查看所含文件信息，在keiluV4下新建工程并将51ucosii下所包含的文件都添加到工程里,选择好相关工程配置项，编译生成调试文件及hex文件，利用keiluV4仿真器观察运行结果（使用串口1）；
2）分析整个实验文件目录结构及实验参考程序。
3）按照实验内容要求编写程序并编译运行
3.利用proteus进行仿真
五．实验现象与结果分析
1.建立并熟悉编译及仿真调试环境（keil+proteus）
2.下载已移植好的软件包，在开发环境下建立工程编译并运行观察运行结果，使用Keil自带的仿真调试工具观察程序运行情况（内存的分配、变量及CPU寄存器的动态变化、任务的切换运行状态等）；
比较移植前和移植后的相关文件，析移植过程中做了哪些改动工作。
1）.Keil调试窗口和结果：
2）.移植到proteus开发环境中，利用proteus的硬件仿真。
参考源代码：
#include<
includes.h>
sbitled=P1^7;
unsignedcharcodetable[]={
0x3f,0x06,0x5b,0x4f,
0x66,0x6d,0x7d,0x07,
0x7f,0x6f,0x77,0x7c,
0x39,0x5e,0x79,0x71};
unsignedinti=0;
voidTaskStartyya（void*yydata）reentrant;
voidTaskStartyyb（void*yydata）reentrant;
voidTaskStartyyc（void*yydata）reentrant;
OS_STKTaskStartStkyya[MaxStkSize];
//注意：
我在ASM文件中设置?
STACK空间为40H即64。
OS_STKTaskStartStkyyb[MaxStkSize];
OS_STKTaskStartStkyyc[MaxStkSize];
voidmain（void）
OSInit（）;
InitTimer0（）;
InitSerial（）;
InitSerialBuffer（）;
OSTaskCreate（TaskStartyya,（void*）0,&
TaskStartStkyya[0],6）;
OSTaskCreate（TaskStartyyb,（void*）0,&
TaskStartStkyyb[0],3）;
//OSTaskCreate（TaskStartyyc,（void*）0,&
TaskStartStkyyc[0],4）;
OSStart（）;
voidTaskStartyya（void*yydata）reentrant
yydata=yydata;
clrscr（）;
PrintStr（"
\n\t\t*******************************\n"
）;
\t\t*Hello!
Thenewworld.*\n"
\t\t*******************************\n\n\n"
led=1;
for（;
;
）{
if（i==16）
i=0;
led=~led;
OSTimeDlyHMSM（0,0,1,0）;
}
voidTaskStartyyb（void*yydata）reentrant
//P1=0x00;
P1=table[i];
i++;
OSTimeDlyHMSM（0,0,1,0）;
voidTaskStartyyc（void*yydata）reentrant
）{
升级会员 