ucos-ii 在skyeye上的移植分析

上传人:自*** 文档编号:80029461 上传时间:2019-02-18 格式:DOC 页数:8 大小:184.50KB
返回 下载 相关 举报
ucos-ii 在skyeye上的移植分析_第1页
第1页 / 共8页
ucos-ii 在skyeye上的移植分析_第2页
第2页 / 共8页
ucos-ii 在skyeye上的移植分析_第3页
第3页 / 共8页
ucos-ii 在skyeye上的移植分析_第4页
第4页 / 共8页
ucos-ii 在skyeye上的移植分析_第5页
第5页 / 共8页
点击查看更多>>
资源描述

《ucos-ii 在skyeye上的移植分析》由会员分享,可在线阅读,更多相关《ucos-ii 在skyeye上的移植分析(8页珍藏版)》请在金锄头文库上搜索。

1、SkyEye 技术报告uC/OS-II 在SkyEye 上的移植分析uC/OS-II 在SkyEye上的移植分析李明 SkyEye 仿真调试器是基于ARM7TDMI 核的,因此移植 uC/OS-II 到 SkyEye 上可以借鉴网上已有的例如 Sansung S3C3410X的移植代码,这在 uC/OS-II的主页上很容易找到。 当然自己动手做移植也是对 ARM 体系结构和汇编语言的进一步熟悉,同时对于 uC/OS-II 内核的调度机制会有更深的认识。整个移植工作可以分为两个方面,一部分是和 ARM 相关,一部分是和移植原理相关。在开始实际的移植工作前,需要对这两部分有一定的背景知识,尤其是和

2、侧重于和移植工作相关的概念和原理。下面分别做一些介绍:一、 ARM 的体系结构ARM(Advanced RISC Machines)是目前在嵌入式领域里应用最广泛的RISC微处理器结构,以其低成本、低功耗、高性能的特点占据了嵌入式系统应用领域的领先地位。ARM系列的处理器当前有ARM7、ARM9、ARM9E、ARM10等多个产品,此外ARM公司合作伙伴,例如Intel 也提供基于XScale微体系结构的相关处理器产品。所有的ARM处理器都共享ARM通用的基础体系结构,所以开发者在不同的ARM处理器上做操作系统移植时,可以将节省相当多的工作量,这无疑将大大降低软件开发成本。要详细完整的了解ARM

3、的体系结构,当然是去读 ARM Architectur Reference Manual ,这是一个13M 的pdf 文档,有800多页,可以从ARM的网站下载,也可以到阿卡嵌入式兴趣小组的FTP服务器( ftp:/159.226.40.150 )上找到。北航出的一本ARM 嵌入式处理器结构与应用基础基本上翻译了这个pdf中大部分重要的内容,可以作为入门的中文教材。这里我们仅仅对其中和移植工作密切相关的概念做简要介绍,1、 处理器模式: ( cpu mode ) ARM 的处理器可以工作在 7 种模式,如下图所示: 这里除 usr 模式以外的其他模式都叫做特权模式,除 usr 和 sys 外的

4、其他5种模式叫做异常模式。在 usr 模式下对系统资源的访问是受限制的,也无法主动地改变处理器模式。异常模式通常都是和硬件相关的,例如中断或者是试图执行未定义指令等。这里需要强调的是和移植相关的两种处理器模式:svc 态和 irq 态,分别指操作系统的保护模式和通用中断处理模式。这两种模式之间的转换可以通过硬件的方式,也可以通过软件的方式。uC/OS-II内核在执行过程中,大部分时间都是工作在 svc 态,当有硬件中断,例如时钟中断到来时,cpu 硬件上会自动完成从svc态进入 irq态,在中断处理程序的结束处,则需要通过编程的方法使得 cpu 从irq 态恢复到 svc 态,这个在移植代码中

5、可以找到。2、 程序状态寄存器: ( PSR:Program status register )在任何一种处理器模式中,都使用同一个寄存器来标识当前处理器的工作模式:这个寄存器叫做 CPSR ( Current Program Status Register ),它的 0-4 位用来表示cpu mode:每一种处理器异常模式,都有一个对应的SPSR ( Saved Program Status Register )寄存器,用来保存进入异常模式前的CPSR。SPSR的作用就是当从异常模式退出时,可以通过一条简单的汇编指令就能够恢复进入异常模式前的CPSR,而这个值都是保存在当前异常模式的SPSR

6、中的。例如:当从usr态进入中断irq 态时,原先的 CPSR_all 将被保存在当前的 SPSR_irq中,类似的异常模式下的 SPSR 还有 SPSR_fiq、SPSR_svc、SPSR_abt、SPSR_und。非异常模式的 usr和sys模式下没有 SPSR,只有 CPSR。不能显式的指定把 CPSR 保存到某个异常模式下的 SPSR,比如 SPSR_irq,而必须是变更到 irq 态之后cpu自动完成的,不能在其他态下硬性赋值,因为SPSR_irq是其他状态下不可见的。3、 ARM寄存器:( register )ARM处理器一共有37个寄存器,其中31个是通用寄存器,包括一个程序计数

7、器 PC。另外6个就是上面提到的程序状态寄存器。a) 通用寄存器:i. R0R7:与所有处理器模式无关的寄存器,可以用作任何用途。ii. R8R14:与处理器模式有关的寄存器,在不同的模式下,对应到不同的物理寄存器。其中 R13又叫做 sp,一般用于堆栈指针。R14又叫做lr,一般用于保存返回地址。这两个寄存器在每种异常模式下都对应到不同的物理寄存器上,例如lr_irq、lr_svc、lr_fiq 等。iii. R15:又叫做程序计数器,即pc,所有的模式下都使用同一个 pc。b) 状态寄存器:i. CPSR:当前程序状态寄存器,所有的模式下都使用同一个 CPSR。ii. SPSR:保存的程序

8、状态寄存器,每种异常模式下都有自己的SPSR,一共有5种SPSR,即 SPSR_irq、SPSR_fiq、SPSR_svc、SPSR_abt、SPSR_und。usr和sys 态下没有 SPSR 。所有的ARM寄存器的命名和含义,可以用下面的这张表来说明,其中相同命名的都是同一个物理寄存器,不同命名的寄存器都对应不同的物理寄存器。二、 uC/OS-II 移植工作介绍uC/OS-II 实际上可以简单地看作是一个多任务的调度器,在这个任务调度器之上完善并添加了和多任务操作系统相关的一些系统服务,如信号量、邮箱等。它的90%的代码都是用C语言写的,因此只要有相应的C语言编译器,基本上就可以直接移植到

9、特定处理器上,这也是uC/OS-II具有良好的可移植性的原因。移植工作的绝大部分都集中在多任务切换的实现上,因为这部分代码主要是用来保存和恢复处理器现场(即相关寄存器),因此不能用C语言,只能使用特定的处理器汇编语言完成。uC/OS-II的全部源代码量大约是60007000行,一共有15个文件。将 uC/OS-II 移植到ARM处理器上,需要完成的工作也非常简单,只需要修改三个和ARM体系结构相关的文件,代码量大约是500行。以下分别介绍这三个文件的移植工作:1、 OS_CPU.H 文件 数据类型定义这部分的修改是和所用的编译器相关的,不同的编译器会使用不同的字节长度来表示同一数据类型,比如i

10、nt,同样在x86平台上,如果用GNU的gcc 编译器,则编译为4 bytes,而使用MS VC则编译为2 bytes。我们这里使用的是 GNU 的 arm-elf-gcc,这是一个免费并且开放源码的编译器。相关的数据类型的定义如下: 堆栈单位因为处理器现场的寄存器在任务切换时都将会保存在当前运行任务的堆栈中,所以OS_STK 数据类型应该是和处理器的寄存器长度一致的。 堆栈增长方向堆栈由高地址向低地址增长,这个也是和编译器有关的,当进行函数调用时,入口参数和返回地址一般都会保存在当前任务的堆栈中,编译器的编译选项和由此生成的堆栈指令就会决定堆栈的增长方向。 宏定义包括开关中断的宏定义,以及进

11、行任务切换的宏定义。2、 OS_CPU_C.C 文件 任务堆栈初始化这里涉及到任务初始化时的一个堆栈设计,也就是在堆栈增长方向上如何定义每个需要保存的寄存器位置,在ARM体系结构下,任务堆栈空间由高至低依次将保存着pc、lr、r12、r11、r10、 r1、r0、CPSR、SPSR。低地址pclrR12R11.R1R0CPSRSPSR增长方向高地址 这里需要说明两点,一是当前任务堆栈初始化完成后,OSTaskStkInit 返回新的堆栈指针stk,在 OSTaskCreate()执行时将会调用 OSTaskStkInit 的初始化过程,然后通过OSTCBInit()函数调用将返回的sp指针保存

12、到该任务的TCB块中。二是初始状态的堆栈其实是模拟了一次中断发生后的堆栈结构,因为任务被创建后并不是直接就获得执行的,而是通过OSSched()函数进行调度分配,满足执行条件后才能获得执行的。为了使这个调度简单一致,就预先将该任务的pc指针和返回地址lr都指向函数入口,以便被调度时从堆栈中恢复刚开始运行时的处理器现场。 系统hook函数此外,在这个文件里面还需要实现几个操作系统规定的hook函数,如下:OSSTaskCreateHook( )OSTaskDelHook( )OSTaskSwHook( )OSTaskStatHook( )OSTimeTickHook( )如果没有特殊需求,则只需

13、要简单地将它们都实现为空函数就可以了。3、 OS_CPU_A.S 文件 OSStartHighRdy()此函数是在OSStart()多任务启动之后,负责从最高优先级任务的TCB控制块中获得该任务的堆栈指针sp,通过sp依次将cpu现场恢复,这时系统就将控制权交给用户创建的该任务进程,直到该任务被阻塞或者被其他更高优先级的任务抢占cpu。该函数仅仅在多任务启动时被执行一次,用来启动第一个,也就是最高优先级的任务执行,之后多任务的调度和切换就是由下面的函数来实现。 OSCtxSw()任务级的上下文切换,它是当任务因为被阻塞而主动请求cpu调度时被执行,由于此时的任务切换都是在非异常模式下进行的,因

14、此区别于中断级别的任务切换。它的工作是先将当前任务的cpu现场保存到该任务堆栈中,然后获得最高优先级任务的堆栈指针,从该堆栈中恢复此任务的cpu现场,使之继续执行。这样就完成了一次任务切换。 OSIntCtxSw()中断级的任务切换,它是在时钟中断ISR(中断服务例程)中发现有高优先级任务等待的时钟信号到来,则需要在中断退出后并不返回被中断任务,而是直接调度就绪的高优先级任务执行。这样做的目的主要是能够尽快地让高优先级的任务得到响应,保证系统的实时性能。它的原理基本上与任务级的切换相同,但是由于进入中断时已经保存过了被中断任务的cpu现场,因此这里就不用再进行类似的操作,只需要对堆栈指针做相应

15、的调整,原因是函数的嵌套。 OSTickISR()时钟中断处理函数,它的主要任务是负责处理时钟中断,调用系统实现的OSTimeTick函数,如果有等待时钟信号的高优先级任务,则需要在中断级别上调度其执行。其他相关的两个函数是OSIntEnter()和OSIntExit(),都需要在ISR中执行。 ARMEnableInt()& ARMDisableInt()分别是退出临界区和进入临界区的宏指令实现。主要用于在进入临界区之前关闭中断,在退出临界区的时候恢复原来的中断状态。它的实现比较简单,可以采用方法1直接开关中断来实现,也可以采用方法2通过保存关闭/恢复中断屏蔽位来实现。三、 我的移植体会移植 uC/OS-II 的绝大部分工作都集中在 os_cpu_a.S 文件的移植,这个文件的实现集中体现了所要移植到处理器的体系结构和uC/OS-II 的移植原理;在这个文件里,最困难的工作又集中体现在 OSIntCtxSw 和 OSTickISR 这两个函数的实现上。这是因为这两个函数的实现是和移植者的移植思路以及相关硬件定时器、中断寄存器的设置有关。在实际的移植工作中,这两个地方也是比较容易出错的地方。OSIntCtxS

展开阅读全文
相关资源
正为您匹配相似的精品文档
相关搜索

最新文档


当前位置:首页 > 办公文档 > 其它办公文档

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