我的移植体会
移植 uC/OS-II 的绝大部分工作都集中在 os_cpu_a.S 文件的移植,这个文件的实现集中体现了所要移植到处理器的体系结构和uC/OS-II 的移植原理;在这个文件里,最困难的工作又集中体现在OSIntCtxSw 和 OSTickISR 这两个函数的实现上。这是因为这两个函数的实现是和移植者的移植思路以及相关硬件定时器、中断寄存器的设置有关。在实际的移植工作中,这两个地方也是比较容易出错的地方。
OSIntCtxSw 最重要的作用就是它完成了在中断ISR中直接进行任务切换,从而提高了实时响应的速度。它发生的时机是在 ISR 执行到 OSIntExit 时,如果发现有高优先级的任务因为等待的 time tick 到来获得了执行的条件,这样就可以马上被调度执行,而不用返回被中断的那个任务之后再进行任务切换,因为那样的话就不够实时了。
实现 OSIntCtxSw 的方法大致也有两种情况:一种是通过调整 sp 堆栈指针的方法,根据所用的编译器对于函数嵌套的处理,通过精确计算出所需要调整的 sp 位置来使得进入中断时所作的保存现场的工作可以被重用。这种方法的好处是直接在函数嵌套内部发生任务切换,使得高优先级的任务能够最快的被调度执行。但是这个办法需要和具体的编译器以及编译参数的设置相关,需要较多技巧。
另一种是设置需要切换标志位的方法,在 OSIntCtxSw 里面不发生切换,而是设置一个需要切换的标志, 等函数嵌套从进入 OSIntExit => OS_ENTER_CRITICAL() => OSIntCtxSw() =>OS_EXIT_CRITICAL() => OSIntExit退出后,再根据标志位来判断是否需要进行中断级的任务切换。这种方法的好处是不需要考虑编译器的因素,也不用做计算,但是从实时响应上不是最快,不过刚开始学习这种方法比较容易理解,实现起来也简单。SkyEye 目前的移植就是基于第二种方法的。
在中断态下进行任务切换,需要特别说明的一个问题是如何获得被中断任务的 lr_svc 。因为进入中断态后,lr 变成了lr_IRQ ,原来任务的 lr_svc 无法在中断态下获得,这样要得到 lr_svc ,就必须在中断ISR 里面进行一次 cpu mode 强制转换,即对 CPSR 赋值为0x000000d3 ,只有返回到 svc 态之后才能得到 原来任务的 lr ,这个对于任务切换很重要。还有一个需要留意的问题是在强制 CPSR 变成 svc 态之后,SPSR 也会相应地变成 SPSR_irq ,这样就需要在强制转变之前保存 SPSR ,也就是被中断任务中断前的 CPSR 。
全部移植代码在SkyEye仿真器上调试通过,在SkyEye的主页上可以下载获得。欢迎大家访问我们的主页 【 http://www.skyeye.org 】。 另外在 Linuxfans.org的论坛上 【 http://www.linuxfans.org/bbs/forum-58-1.html 】, 有关于 SkyEye 进展的最新讨论, 和另一个嵌入式开源项目【 www.lumit.org 】的大量资料下载, 【 http://www.linuxfans.org/bbs/forum-66-1.html 】。希望大家对我们的工作提出建议和批评,更希望有越来越多的人关注和参与进来。
总结
移植 uC/OS-II到 SkyEye 上,既是对 uC/OS-II 的学习和实验,同时也是对 SkyEye仿真器的验证和实践。uC/OS-II 作为一个优秀的实时操作系统已经被移植到各种体系结构的微处理器上,也是目前较为常用的公开源码的实时内核。从这里入手学习嵌入式系统开发的基本概念,以及在 SkyEye 里构造一个可以运行的RTOS,能够使我们更深入地了解嵌入式开发的流程,在没有硬件的条件下也能对ARM的体系结构有个初步的认识。
在移植 uC/OS-II 到 SkyEye 之后,我得到了一块 Samsung 的ARM 评估板,在调通了板子上一些相关硬件(例如串口输出和定时器)的驱动后,仅仅花了不到一天时间就将SkyEye 下的 uC/OS-II 移植到了真实的开发板上,这也说明在 SkyEye 上所做的移植工作是非常有意义和帮助的,完全可以作为嵌入式开发的入门捷径。
如果大家移植过程中遇到什么问题,欢迎发email和我讨论。
本文关键字:暂无联系方式嵌入式系统-技术,单片机-工控设备 - 嵌入式系统-技术