MC9S12DG128 的体系结构分析 μC/OS-II的移植过程

嵌入式技术

1372人已加入

描述

1 引言

在采用前后台系统软件设计模式的嵌入式系统中,主程序是一个无限循环,单任务顺序执行,通过设置一个或多个中断来处理异步事件。这种系统对于简单的应用是可以 的,但对于实时性要求比较高的、处理任务较多的应用,就会暴露出实时性差、系统可靠性低、稳定性差等缺点。μC/OS-II 是一个源代码公开、可移植、可裁剪的实时多任

务操作系统,具有低成本、稳定可靠、实时性好等优点,是专门针对微处理器和微控制器设计的实时内核,它的内核可以做到很小,很适合在单片机系统上移植。移植了μC/OS-II 的嵌入式系统可以使各个任务独立工作,互不干涉,很容易实现准时而且无误执行,使实时应用程序的设计和扩展变得容易,使应用程序的设计过程大为减化。本

文选用飞思卡尔(Freescale)公司的16 位单片机MC9S12DG128 作为硬件平台,针对MC9S12DG128 的存储器组织和体系结构,对μC/OS-II 源代码作了相应的改写,最终实

现了μC/OS-II 操作系统在MC9S12DG128 上的移植。通过μC/OS-II 在MC9S12DG128 上的移植,可以掌握移植和测试μC/OS-II 的实质内容,同时也很容易将其移植到其它的CPU 平台上。

2 MC9S12DG128 的体系结构(存储器的组织)

作者认为深刻理解MC9S12DG128 微控制器的体系结构和存储器组织是移植成功的一个关键步骤。MC9S12DG128 是16 位的高性能单片机,它具有极低的电源功耗和可高达

25MHz 的内部总线频率,片内资源包括1KB 的内部寄存器、8KB RAM、128KB FLASH、2KBEEPROM。MC9S12DG128 采用普林斯顿总线结构,程序存储器、数据存储器和I/O 端口为统一编址方式,总的寻址空间为64 KB,但DG128 内部有128KB Flash,显然存储空间超过了S12MCU 可寻址的64KB 空间,因此引入了页面访问机制,S12CPU 在内存的$8000~$BFFF 这一段开了一个窗口,这里有8 个16KB 的页面(其中$3E 和$3F 有固定地址),可以通过页面寄存器(PPAGE)选择其中的一页。对于64KB 以外的存储区,应用专用指令CALL 调用子程序,然后通过RTC 指令返回。

微控制器内部不同的存储器占用不同的存储空间,也就是说,不同的地址范围,它们均占据特定的地址空间,这些存储器和内部集成模块的地址分配并不是固定不变的,用户自己可以重新分配,但建不要轻易改动默认的映射空间,应直接采用默认地址映射空间。图1 是MC9S12DGl28 复位后的内存空间分配情况。其中,地址$0000~$03FF 为1KB 寄存器空间; $0000~$1FFF 为8KB RAM(可见7KB);$0000~$07FF 为2KBEEPROM(不可见)。

嵌入式

图1 MC9S12DGl28 复位后的内存空间分布情况

可以通过设置INITRG,INITRM,INIteE 寄存器来重新分配各存储器的位置。这些寄存器只能写一次,建议在初始化时分配存储器的位置。如果映射出现地址重叠时,S12CPU 内部的优先级控制逻辑会自动屏蔽级别较低的资源,保留级别最高的资源。寄存器具有最高优先级,与其重叠的RAM 和EEPROM 此时无效。存储器的优先级如下表所列。

3 μC/OS-II 在MC9S12DG128 上的移植

μC/OS-II 运行时要占用一部分ROM 和RAM 空间,但μC/OS-II 操作系统内核目标代码最小可以裁剪到小于2KB,MC9S12DG128 有8KB 的RAM 存储器和128KB 的Flash 存

储器,所以μC/OS-II 操作系统完全可以移植并运行在MC9S12DG128 上。

μC/OS-II 的95%代码是由ANSI C 写成的,具有很好的移植性。要实现μC/OS-II向S12 的移植,主要是做两方面的工作,一是重新定义内核的大小和功能;二是为内核编写与硬件相关的代码。μC/OS-II 的文件结构如图2 所示。

嵌入式

图2 μC/OS-II 的文件结构

可以看到,μC/OS-II 与CPU 类型无关的C 代码文件包括很多文件,它们是μC/OS-II的内核和很多功能函数,其中OS_CORE.C、OS_TIME.C 和OS_TASK.C 这三个文件是一定要用的,其他几个文件用于任务间通信,应用程序中可能只用到其中的几个,不用的可以不包含进去,以避免编译时生成没有代码。这部分代码与CPU 类型无关,在移植时,这些文件一个也不要动。

与CPU 类型有关的代码文件主要有:OS_CFG.H、OS_CPU.H、OS_CPU_A.ASM 和OS_CPUC.C。OS_CFG.H 是配置文件,需要根据应用配置,主要作用是确定用户应用程序使用μC/OS-II 提供的哪些系统功能函数,这个文件移植时要修改。OS_CPU.H 文件定义用于特定CPU 的数据类型、定义相关的宏。OS_CPU_A.ASM 是用汇编语言写的硬件有关的代码,OS_CPUC.C 文件是用C 语言写的与硬件有关的代码。如果移植使用的C 交叉编译工具在C 代码中可以插入汇编语句,那么在移植中,可以将OS_CPU_A.ASM 合到S_CPUC.C文件中。

3.1 重新定义内核的大小和功能

公共头文件INCLUDES.H,这个文件会被所有的C 源程序引用。在本例中此文件的代码如下。

#include

#include

#include

#include

#include

#include

#include

前四个头文件是C 函数库、预定义的类型等,和移植没有关系,是否一定要加取决于所用的编译器。后三个头文件必须被引用,用户可以添加自己的头文件,但一定要放

在最后面。

需要根据应用修改的文件是OS_CFG.H,这个文件用于配置内核的属性。用于设置与微控制器CPU 核心相关的属性,包括各种数据类型对应的存储长度等等。OS_CPU.H 包括了用#define 语句定义的、与处理器相关的常数、宏及类型等。因为不同的处理器有不同的字长,所以μC/OS-II 的移植包括的一系列数据类型定义,以确保其可移植性。μC/OS-II 代码不使用语言中的short,int,及long 等数据类型,因为它们是与编译器相关的,是不可移植的。采用定义的整形数据结构等既是可移植的,又很直观。

typedef unsigned char BOOLEAN; /* 布尔变量*/

typedef unsigned char INT8U; /* 无符号8 位整型变量*/

typedef signed char INT8S; /* 有符号8 位整型变量 */

typedef unsigned int INT16U; /* 无符号16 位整型变量*/

typedef signed int INT16S; /* 有符号16 位整型变量*/

……

用户还必须将任务堆栈的数据类型告诉给μC/OS-II。S12CPU 的是堆栈是16 位的,所以定义OS_STK 为INT16U。所有的任务堆栈都必须用OS_STK 来声明数据类型。

#define OS_STK INT16U /* 堆栈是16 位宽度*/

对于不同的处理器而言,数据入堆栈时堆栈指针的增长方向也是不一样的,MC9S12DG128 单片机的堆栈指针是由高地址向低地址增长的,所以,要预先设定堆栈的

增长方向:

#define OS_STK_GROWTH 1 /*堆栈指针由高地址向低地址增长*/

μC/OS-II 需要先禁止中断再访问代码的临界段,并且在访问完毕后重新允许中断。这就使得μC/OS-II 能够保护临界段代码免受多任务或中断服务例程的破坏。禁止和允许中断的宏是OS_ENTER_CRITICAL()和OS_EXIT_CRITICAL(),定义这两个宏的有三种方法,移植时采用的是方法1,进入临界代码前关中断,脱离临界代码后开中断[2]。方法1在OS_CPU.H 中是这样定义的:

#if OS_CRITICAL_METHOD == 1 //方法一

#define OS_ENTER_CRITICAL( ) asm SEI

#defien OS_EXIT_CRITICAL () asm CLI

#endif

3.2 编写与硬件相关的代码

接下来需要编写与硬件相关的代码。这部分代码可以用C 语言,也可以用汇编语言。移植中与硬件相关的文件中最主要的是OS_CPU_C.C 和汇编文件OS_CPU_A.ASM。由于移植使用的是Metrowerks 公司提供的CodeWarrior CW12 V4.6 版本的C 交叉编译工具,而CW12 V4.6 允许在C 代码中插入汇编语句,所以可以把OS_CPU_A.ASM 这个文件合并

到OS_CPU_C.C 文件中去。以下是具体的移植过程。

3.2.1 中断服务子程序OSTickISR()

中断服务子程序所使用的中断可以用实时时钟产生,也可以用单片机片内的定时器模块来产生。本次移植采用的是用模数计数器产生精确时钟节拍中断,用S12 的模数计数器可以实现任意时间的精确中断,这里的中断为每秒30 次。

时钟节拍中断发生时,CPU12 会自动CPU 把CPU 寄存器推入堆栈,然后是清中断标志。但是页面寄存器PPAGE 并没有被推入堆栈,如果CPU12 的寻址范围超过了64KB,则要把PPAGE 也推入堆栈,本文中没有用到PPAGE 寄存器。

时钟节拍中断服务子程序可能激活一个优先级高于当前被中断任务的优先级的任务。时钟节拍中断服务子程序要连续调用:OSIntEnter()、OSTimerTick()和OSIntExit()

这三个函数。OSIntEnter()通知μC/OS-II 进入中断服务子程序了。OSTimerTick()给要求延迟若干时钟节拍的任务延迟计数器减1,减1 后为0 则该任务进入就绪态。

OSIntExit()函数告诉μC/OS-II 时钟节拍中断服务子程序结束了,如果这时有更高优先级的任务进入了就绪态,OSIntExit()就会调用中断级的任务切换函数OSIntCtxSw()

做任务切换,以便让更高的优先级的任务运行。以下是函数代码:

void OSTickISR(void)

{

/*根据需要决定是否保存PPAGE 寄存器,此处没有保存*/

OSIntEnter();

MCFLG_MCZF=1; //清除模计数器中断标志位

OSTimeTick();

OSIntExit(); //退出中断并进行任务切换

}

3.2.2 任务堆栈初始化函数OSTaskStkInit()

这个C语言写的函数是与CPU硬件相关的。这个函数初始化任务的堆栈,由建立任务的函数OSTaskCreate()或扩展的建立任务函数OSTaskCreatExit()调用。建立任务的函数带有4个形式参数,扩展的建立任务的函数有8个参数。其中pdata用于向任务传递参数。利用了这个参数将页面寄存器PPAGE 参数传给建立的任务。在改写该函数的时候一定要深刻了解S12CPU在中断发生时各个CPU寄存器的入栈的顺序,否则,μC/OS-II是运行不起来的。中断发生时S12CPU各个寄存器入栈的顺序如图3所示。由于该函数是被建立任务的函数所调用的,所以各个CPU寄存器的初始值并不重要。但要CCR寄存器的内容需要注意:如果选择任务启动后允许中断发生,则所有的任务运行期间中断都允许;同样,如果选择任务启动后禁止中断,则所有的任务都禁止中断发生,而不能有所选择。本文选择在任务启动时开启中断。以下是函数代码:

void *OSTaskStkInit (void (*task)(void *pd), void *pdata, void *ptos, INT16U opt)

{

INT16U *stk;

pt = opt; // 'opt'未使用,此处可防止编译器的警告

stk = (INT16U *)ptos; //载入堆栈指针

*--stk = (INT16U)(pdata); //放置向函数传递的参数pdata

*--stk = (INT16U)(task); //函数返回地址PC

*--stk = (INT16U)(0x1122); //寄存器 Y

*--stk = (INT16U)(0x3344); //寄存器 X

((INT8U *)stk)--; // 寄存器A 仅需要1 个字节

*(INT8U *)stk = (INT8U)(0x55); //寄存器 A

((INT8U *)stk)--; // 寄存器B 仅需要1 个字节

*(INT8U *)stk = (INT8U)(0x66); //寄存器 B

((INT8U *)stk)--; // 寄存器CCR 仅需要1 个字节

*(INT8U *)stk = (INT8U)(0x00); //寄存器 CCR,开中断

return ((void *)stk);

}

3.2.3 让优先级最高的就绪态任务开始运行OSStartHightRdy()

OSStartHighRdy()是在多任务启动时被OSStart()调用的,μC/OS-II 做完所有的初始化工作之后,OSStart()就启动运行多任务,而OSStart()调用OSStartHighRdy()

函数运行多个就绪任务中优先级最高的任务。注意,堆栈指针总是储存在任务控制块的开头。

嵌入式

图3 中断发生时S12CPU寄存器入栈的顺序

OSStartHighRdy()将CPU 的堆栈指针SP 的值,改成优先级最高的就绪态任务的堆栈指针的值,然后将该任务的状态字由非运行态“FALSE”,改为运行态“TRUE”,然后

执行中断返回指令RTI 以开始运行这个任务。以下是详细代码:

void OSStartHighRdy(void)

{

OSTaskSwHook(); //调用钩子函数

asm{

ldx OSTCBCur // 加载OSTCBCur 的地址到 x

lds 0,x //把OSTCBStrPtr 载入堆栈指针 sp

ldaa OSRunning

inca // SRunning = TRUE

staa OSRunning

rti

}

}

3.2.4 任务级任务切换函数OSCtxSw()和中断级任务切换函数OSIntCtxSw()

任务级的切换是通过执行软中断指令来实现的。OSCtxSw()实际上就是软中断服务子程序,软中断服务子程序的向量地址指向OSCtxSw()。如果当前任务调用μC/OS-II

提供的功能函数,并使更高优先级任务进入了就绪状态,则μC/OS-II 就会借助上面提到的向量地址找到OSCtxSw()。在系统服务调用的最后,μC/OS-II 会调用任务调度函

数OSSched(),并由此推断出当前任务不再是需要运行的最重要的任务。

OSIntCtxSw()函数中的绝大多数代码同OS_TASK_SW()函数是一样的。而中断退出函数则是通过函数OSIntCtxSw()来从ISR 中执行切换功能,区别只是因为ISR 已经保存了

CPU 的寄存器,而不再需要在OSIntCtxSw()函数中保存CPU 的寄存器。以下只给出任务级任务切换函数OSCtxSw()的代码:

void OSCtxSw(void)

{

asm{

ldx OSTCBCur // 加载当前任务的堆栈指针

sts 0,x // 保存到当前任务的TCB 中

}

OSTaskSwHook(); //调用钩子函数

STCBCur = OSTCBHighRdy; // 改变任务的 OSTCBCur 和OSPrioCur

SPrioCur = OSPrioHighRdy;

asm{

ldx OSTCBCur // 得到新任务的堆栈指针

lds 0,x // 加载新任务的堆栈指针到 sp

rti

}

}

4 移植代码的测试

为了验证移植结果是否正确,对移植后μC/OS-II 代码进行了测试,这是移植中很重要的一个环节。首先对内核自身的运行情况进行了测试,待内核自身的运行正常工作

后,又创建三个任务:任务1 通过PORTA 口点亮LED 灯,该任务每秒运行一次;任务2和任务3 都通过串输出字符串,这两个任务都是每2 秒运行一次,并通过信号量来实现

互斥,以使得每个任务每次运行时均可完成所有字符的输出。实验测试证明在μC/OS-II管理与调度下,使得这三个任务都能正确、可靠地相继运行。

5 小结

通过μC/OS-II在MC9S12DG128上的移植,加深了对μC/OS-II内核工作原理和任务调度实现方法的理解,掌握了μC/OS-II移植的一般方法,测试结果表明移植代码可以稳定可靠的运行,实现了多任务的管理和调度。μC/OS-II实时操作系统的引入,不但可以提高系统的实时性、可靠性和稳定性,还提高了应用软件的可移植性,降低了开发人员的工作量。

打开APP阅读更多精彩内容
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉

全部0条评论

快来发表一下你的评论吧 !

×
20
完善资料,
赚取积分