第13章 移植ucosII.docx

第13章 移植ucosII.docx

《第13章 移植ucosII.docx》由会员分享，可在线阅读，更多相关《第13章 移植ucosII.docx（23页珍藏版）》请在冰豆网上搜索。

第13章移植ucosII

第13章移植µC/OS-Ⅱ

这一章介绍如何将µC/OS-Ⅱ移植到不同的处理器上。

所谓移植，就是使一个实时内核能在某个微处理器或微控制器上运行。

为了方便移植，大部分的µC/OS-Ⅱ代码是用C语言写的；但仍需要用C和汇编语言写一些与处理器相关的代码，这是因为µC/OS-Ⅱ在读写处理器寄存器时只能通过汇编语言来实现。

由于µC/OS-Ⅱ在设计时就已经充分考虑了可移植性，所以µC/OS-Ⅱ的移植相对来说是比较容易的。

如果已经有人在您使用的处理器上成功地移植了µC/OS-Ⅱ，您也得到了相关代码，就不必看本章了。

当然，本章介绍的内容将有助于用户了解µC/OS-Ⅱ中与处理器相关的代码。

要使µC/OS-Ⅱ正常运行，处理器必须满足以下要求：

1.处理器的C编译器能产生可重入代码。

2.用C语言就可以打开和关闭中断。

3.处理器支持中断，并且能产生定时中断（通常在10至100Hz之间）。

4.处理器支持能够容纳一定量数据（可能是几千字节）的硬件堆栈。

5.处理器有将堆栈指针和其它CPU寄存器读出和存储到堆栈或内存中的指令。

像Motorola6805系列的处理器不能满足上面的第4条和第5条要求，所以µC/OS-Ⅱ不能在这类处理器上运行。

图13.1说明了µC/OS-Ⅱ的结构以及它与硬件的关系。

由于µC/OS-Ⅱ为自由软件，当用户用到µC/OS-Ⅱ时，有责任公开应用软件和µC/OS-Ⅱ的配置代码。

这本书和磁盘包含了所有与处理器无关的代码和Intel80x86实模式下的与处理器相关的代码（C编译器大模式下编译）。

如果用户打算在其它处理器上使用µC/OS-Ⅱ，最好能找到一个现成的移植实例，如果没有只好自己编写了。

用户可以在正式的µC/OS-Ⅱ网站www.µCOS-Ⅱ.com中查找一些移植实例。

图13.1µC/OS-II硬件和软件体系结构

如果用户理解了处理器和C编译器的技术细节，移植µC/OS-Ⅱ的工作实际上是非常简单的。

前提是您的处理器和编译器满足了µC/OS-Ⅱ的要求，并且已经有了必要工具。

移植工作包括以下几个内容：

●用#define设置1个常量的值（OS_CPU.H）

●声明11个数据类型（OS_CPU.H）

●用#define声明4个宏（OS_CPU.H）

●用C语言编写10个简单的函数（OS_CPU_C.C）

●编写四个汇编语言函数（OS_CPU_A.ASM）

根据处理器的不同，一个移植实例可能需要编写或改写50至300行的代码，需要的时间从几个小时到一星期不等。

一旦代码移植结束，下一步工作就是测试。

测试一个象µC/OS-Ⅱ一样的多任务实时内核并不复杂。

甚至可以在没有应用程序的情况下测试。

换句话说，就是让内核自己测试自己。

这样做有两个好处：

第一，避免使本来就复杂的事情更加复杂；第二，如果出现问题，可以知道问题出在内核代码上而不是应用程序。

刚开始的时候可以运行一些简单的任务和时钟节拍中断服务例程。

一旦多任务调度成功地运行了，再添加应用程序的任务就是非常简单的工作了。

13.00开发工具

如前所述，移植µC/OS-Ⅱ需要一个C编译器，并且是针对用户用的CPU的。

因为µC/OS-Ⅱ是一个可剥夺型内核，用户只有通过C编译器来产生可重入代码；C编译器还要支持汇编语言程序。

绝大部分的C编译器都是为嵌入式系统设计的，它包括汇编器、连接器和定位器。

连接器用来将不同的模块（编译过和汇编过的文件）连接成目标文件。

定位器则允许用户将代码和数据放置在目标处理器的指定内存映射空间中。

所用的C编译器还必须提供一个机制来从C中打开和关闭中断。

一些编译器允许用户在C源代码中插入汇编语言。

这就使得插入合适的处理器指令来允许和禁止中断变得非常容易了。

还有一些编译器实际上包括了语言扩展功能，可以直接从C中允许和禁止中断。

13.01目录和文件

本书所付的磁盘中提供了µ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

\OS_CPU.H

\OS_CPU_A.ASM

\OS_CPU_C.C

Motorola68HC11

\SOFTWARE\uCOS-II\68HC11

\OS_CPU.H

\OS_CPU_A.ASM

\OS_CPU_C.C

13.02INCLUDES.H

在第一章中曾提到过，INCLUDES.H是一个头文件，它在所有.C文件的第一行被包含。

#include"includes.h"

INCLUDES.H使得用户项目中的每个.C文件不用分别去考虑它实际上需要哪些头文件。

使用INCLUDES.H的唯一缺点是它可能会包含一些实际不相关的头文件。

这意味着每个文件的编译时间可能会增加。

但由于它增强了代码的可移植性，所以我们还是决定使用这一方法。

用户可以通过编辑INCLUDES.H来增加自己的头文件，但是用户的头文件必须添加在头文件列表的最后。

13.03OS_CPU.H

OS_CPU.H包括了用#defines定义的与处理器相关的常量，宏和类型定义。

OS_CPU.H的大体结构如程序清单L13.1所示。

程序清单L13.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）

13.03.01与编译器相关的数据类型

因为不同的微处理器有不同的字长，所以µC/OS-Ⅱ的移植包括了一系列的类型定义以确保其可移植性。

尤其是，µC/OS-Ⅱ代码从不使用C的short,int和long等数据类型，因为它们是与编译器相关的，不可移植。

相反的，我定义的整型数据结构既是可移植的又是直观的[L13.1

（2）]。

为了方便，虽然µC/OS-Ⅱ不使用浮点数据，但我还是定义了浮点数据类型[L13.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数据类型。

13.03.02OS_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（）[L13.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Ⅱ）,那么这两种方法的时间差别会很小。

13.03.03OS_STK_GROWTH

绝大多数的微处理器和微控制器的堆栈是从上往下长的。

但是某些处理器是用另外一种方式工作的。

µC/OS-Ⅱ被设计成两种情况都可以处理，只要在结构常量OS_STK_GROWTH[L13.1（4）]中指定堆栈的生长方式（如下所示）就可以了。

置OS_STK_GROWTH为0表示堆栈从下往上长。

置OS_STK_GROWTH为1表示堆栈从上往下长。

13.03.04OS_TASK_SW（）

OS_TASK_SW（）[L13.1（5）]是一个宏，它是在µC/OS-Ⅱ从低优先级任务切换到最高优先级任务时被调用的。

OS_TASK_SW（）总是在任务级代码中被调用的。

另一个函数OSIntExit（）被用来在ISR使得更高优先级任务处于就绪状态时，执行任务切换功能。

任务切换只是简单的将处理器寄存器保存到将被挂起的任务的堆栈中，并且将更高优先级的任务从堆栈中恢复出来。

在µC/OS-Ⅱ中，处于就绪状态的任务的堆栈结构看起来就像刚发生过中断并将所有的寄存器保存到堆栈中的情形一样。

换句话说，µC/OS-Ⅱ要运行处于就绪状态的任务必须要做的事就是将所有处理器寄存器从任务堆栈中恢复出来，并且执行中断的返回。

为了切换任务可以通过执行OS_TASK_SW（）来产生中断。

大部分的处理器会提供软中断或是陷阱（TRAP）指令来完成这个功能。

ISR或是陷阱处理函数（也叫做异常处理函数）的向量地址必须指向汇编语言函数OSCtxSw（）（参看13.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-Ⅱ也同样可以。

13.04OS_CPU_A.ASM

µC/OS-Ⅱ的移植实例要求用户编写四个简单的汇编语言函数：

OSStartHighRdy（）

OSCtxSw（）

OSIntCtxSw（）

OSTickISR（）

如果用户的编译器支持插入汇编语言代码的话，用户就可以将所有与处理器相关的代码放到OS_CPU_C.C文件中，而不必再拥有一些分散的汇编语言文件。

13.04.01OSStartHighRdy（）

使就绪状态的任务开始运行的函数叫做OSStart（），如下所示。

在用户调用OSStart（）之前，用户必须至少已经建立了自己的一个任务（参看OSTaskCreate（）和OSTaskCteateExt（））。

OSStartHighRdy（）假设OSTCBHighRdy指向的是优先级最高的任务的任务控制块。

前面曾提到过，在µC/OS-Ⅱ中处于就绪状态的任务的堆栈结构看起来就像刚发生过中断并将所有的寄存器保存到堆栈中的情形一样。

要想运行最高优先级任务，用户所要做的是将所有处理器寄存器按顺序从任务堆栈中恢复出来，并且执行中断的返回。

为了简单一点，堆栈指针总是储存在任务控制块（即它的OS_TCB）的开头。

换句话说，也就是要想恢复的任务堆栈指针总是储存在OS_TCB的0偏址内存单元中。

voidOSStartHighRdy（void）

{

CalluserdefinableOSTaskSwHook（）;

Getthestackpointerofthetasktoresume:

Stackpointer=OSTCBHighRdy->OSTCBStkPtr;

OSRunning=TRUE;

Restoreallprocessorregistersfromthenewtask'sstack;

Executeareturnfrominterruptinstruction;

}

注意，OSStartHighRdy（）必须调用OSTaskSwHook（），因为用户正在进行任务切换的部分工作——用户在恢复最高优先级任务的寄存器。

而OSTaskSwHook（）可以通过检查OSRunning来知道是OSStartHighRdy（）在调用它（OSRunning为FALSE）还是正常的任务切换在调用它（OSRunning为TRUE）.

OSStartHighRdy（）还必须在最高优先级任务恢复之前和调用OSTaskSwHook（）之后设置OSRunning为TRUE。

13.04.02OSCtxSw（）

如前面所述，任务级的切换问题是通过发软中断命令或依靠处理器执行陷阱指令来完成的。

中断服务例程，陷阱或异常处理例程的向量地址必须指向OSCtxSw（）。

如果当前任务调用µC/OS-Ⅱ提供的系统服务，并使得更高优先级任务处于就绪状态，µC/OS-Ⅱ就会借助上面提到的向量地址找到OSCtxSw（）。

在系统服务调用的最后，µC/OS-Ⅱ会调用OSSched（），并由此来推断当前任务不再是要运行的最重要的任务了。

OSSched（）先将最高优先级任务的地址装载到OSTCBHighRdy中，再通过调用OS_TASK_SW（）来执行软中断或陷阱指令。

注意，变量OSTCBCur早就包含了指向当前任务的任务控制块（OS_TCB）的指针。

软中断（或陷阱）指令会强制一些处理器寄存器（比如返回地址和处理器状态字）到当前任务的堆栈中，并使处理器执行OSCtxSw（）。

OSCtxSw（）的原型如程序清单L13.2所示。

这些代码必须写在汇编语言中，因为用户不能直接从C中访问CPU寄存器。

注意在OSCtxSw（）和用户定义的函数OSTaskSwHook（）的执行过程中，中断是禁止的。

程序清单L13.2OSCtxSw（）的原型

voidOSCtxSw（void）

{

保存处理器寄存器;

将当前任务的堆栈指针保存到当前任务的OS_TCB中:

OSTCBCur->OSTCBStkPtr=Stackpointer;

调用用户定义的OSTaskSwHook（）;

OSTCBCur=OSTCBHighRdy;

OSPrioCur=OSPrioHighRdy;

得到需要恢复的任务的堆栈指针:

Stackpointer=OSTCBHighRdy->OSTCBStkPtr;

将所有处理器寄存器从新任务的堆栈中恢复出来;

执行中断返回指令;

}

13.04.03OSIntCtxSw（）

OSIntExit（）通过调用OSIntCtxSw（）来从ISR中执行切换功能。

因为OSIntCtxSw（）是在ISR中被调用的，所以可以断定所有的处理器寄存器都被正确地保存到了被中断的任务的堆栈之中。

实际上除了我们需要的东西外，堆栈结构中还有其它的一些东西。

OSIntCtxSw（）必须要清理堆栈，这样被中断的任务的堆栈结构内容才能满足我们的需要。

要想了解OSIntCtxSw（），用户可以看看µC/OS-Ⅱ调用该函数的过程。

用户可以参看图13.2来帮助理解下面的描述。

假定中断不能嵌套（即ISR不会被中断），中断是允许的，并且处理器正在执行任务级的代码。

当中断来临的时候，处理器会结束当前的指令，识别中断并且初始化中断处理过程，包括将处理器的状态寄存器和返回被中断的任务的地址保存到堆栈中[F13.2

（1）]。

至于究竟哪些寄存器保存到了堆栈上，以及保存的顺序是怎样的，并不重要。

图13.2在ISR执行过程中的堆栈内容.

接着，CPU会调用正确的ISR。

µC/OS-Ⅱ要求用户的ISR在开始时要保存剩下的处理器寄存器[F13.2

（2）]。

一旦寄存器保存好了，µC/OS-Ⅱ就要求用户或者调用OSIntEnter（），或者将变量OSIntNesting加1。

在这个时候，被中断任务的堆栈中只包含了被中断任务的寄存器内容。

现在，ISR可以执行中断服务了。

并且如果ISR发消息给任务（通过调用OSMboxPost（）或OSQPost（）），恢复任务（通过调用OSTaskResume（）），或者调用OSTimeTick（）或OSTimeDlyResume（）的话，有可能使更高优先级的任务处于就绪状态。

假设有一个更高优先级的任务处于就绪状态。

µC/OS-Ⅱ要求用户的ISR在完成中断服务的时候调用OSIntExit（）。

OSIntExit（）会告诉µC/OS-Ⅱ到了返回任务级代码的时间了。

调用OSIntExit（）会导致调用者的返回地址被保存到被中断的任务的堆栈中[F13.2（3）]。

OSIntExit（）刚开始时会禁止中断，因为它需要执行临界段的代码。

根据OS_ENTER_CRITICAL（）的