Hello China操作系统STM32移植指南(一)

Hello China操作系统移植指南

首先说明一下,为了适应更多的文化背景,对Hello China操作系统的名字做了修改,修改为“Hello X”,或者连接在一起,写为“HelloX“。其中X是不固定的,可以根据具体应用的国家,甚至城市,进行定制化。比如在中国,我仍然会叫做”Hello China“,但是如果有人在美国使用了,则可以叫做”Hello USA“,在香港使用了,可以叫做”Hello Hongkong“,等等。但这些都是HelloX的分支,必须明确说明。这样做,主要目的是为了Hello China操作系统的全球化推广,后续将作为开源项目托管到github上,届时任何国家和地区的人都可以参与开发。

经过一段时间的尝试,现在已经成功把Hello China V1.76版的内核代码,移植到STM32芯片上。本文就对这个移植过程进行详细说明。在正式介绍移植步骤之前,先说明一下移植原理。

STM32移植原理

STM32芯片是ST公司开发的基于Cortex-M3 CPU(ARM系列)的SoC,在各行各业中得到了广泛的应用。往STM32上移植,本质上就是向Cortex-M3 CPU上的移植,移植后的内核,可以很容易的再移植到其它基于Cortex-M3 CPU的芯片上。关于STM32更多的背景及特性等,这里就不多说了。为了更好的理解下面的内容,建议读者先了解一下Cortex-M3 CPU的一些基础机制,这样阅读起来更加容易。

如果您一直在x86系列CPU上做开发,那么当接触到ARM系列CPU的时候,您会发现非常容易。ARM CPU非常简洁,逻辑比x86简单得多。根据我个人的经验,x86CPU的保护模式编程,比实模式编程要简单,而ARM CPU的编程,则比x86的保护模式更简单。虽然模型简单了,但由于指令系统不同,对中断/异常的处理机制也不一样,导致移植过程并不是很容易。主要集中在下列几个方面:

中断机制的移植

首先是中断处理机制的移植,这是任何操作系统向不同CPU上的移植,都需要涉及到的问题。x86 CPU采用中断描述表的方式,每个中断占用一个表项,表里面记录了处理中断的中断向量(函数)。一旦中断发生,CPU会调用对应中断号的中断向量。Cortex-M3CPU的中断机制与此基本类似,但是其中断向量表却简单得多,不像x86一样,内嵌了很多的控制信息。而且Cortex-M3的中断向量表的位置是固定的,就是在物理内存的起始处。Hello China在设计的时候,为了兼容多种CPU,其中断机制采用了“统一入口”的形式。即针对CPU的所有中断向量表,都填写一个唯一的入口-GeneralIntHandler,这个入口由Hello China操作系统实现。然后GeneralIntHandler再根据实际的中断向量号,调用具体的中断处理程序。这样的机制,可以适应大多数CPU的需求。因为有的CPU只有一个中断向量表,不像x86那样,每个中断都有向量表对应。因此在把中断处理机制移植到Cortex-M3的时候,必须要把每个中断向量跟GeneralIntHandler链接起来。下面是Cortex-M3的典型中断向量表结构:

__Vectors

DCD     __initial_sp               ; Top of Stack

DCD     Reset_Handler              ; Reset Handler

DCD     NMI_Handler                ; NMI Handler

DCD     HardFault_Handler          ; Hard Fault Handler

DCD     MemManage_Handler          ; MPU Fault Handler

DCD     BusFault_Handler           ; Bus Fault Handler

DCD     UsageFault_Handler         ; Usage Fault Handler

DCD     0                          ; Reserved

DCD     0                          ; Reserved

DCD     0                          ; Reserved

DCD     0                          ; Reserved

DCD     SVC_Handler                ; SVCall Handler

DCD     DebugMon_Handler           ; Debug Monitor Handler

DCD     0                          ; Reserved

DCD     PendSV_Handler             ; PendSV Handler

DCD     SysTick_Handler            ; SysTick Handler

; ExternalInterrupts

DCD     WWDG_IRQHandler            ; Window Watchdog

DCD     PVD_IRQHandler             ; PVD through EXTI Line detect

DCD     TAMPER_IRQHandler          ; Tamper

DCD     RTC_IRQHandler             ; RTC

DCD     FLASH_IRQHandler           ; Flash

………

向量表的第一个表项,是CPU的初始堆栈指针(即MSP寄存器的值),后续每个表项,都对应特定异常或中断的处理程序。最简单的修改方式,就是把上述每个中断向量(除初始堆栈指针外),替换为GeneralIntHandler函数。但这样做有一个问题,那就是无法确定中断向量号。因为GeneralIntHandlr是用C语言实现的,接受中断向量作为参数。因此又用汇编语言实现了一个Int_Entry_Wrapper的函数,作为中间的一层封装。这个函数代码如下:

Int_Entry_Wrapper    PROC

EXPORT  Int_Entry_Wrapper

IMPORT GeneralIntHandler   ;Implementedin C file.

MRS R0,IPSR

AND R0,R0,#0xFF

MRS R1,MSP

LDR R2,=GeneralIntHandler

BX  R2

ENDP

函数的逻辑很简单,首先读取IPSR寄存器,从中得到中断向量号,然后再以中断向量号和堆栈指针为参数,调用GeneralIntHandler。使用Int_Entry_Wrapper替换Cortex-M3的中断向量表中的所有项,即可实现中断的连接。

用户如果要编写设备驱动程序,需要在中断向量表中增加中断向量的时候,就无需修改启动文件(比如MDK生成的是startup_stm32f10x_xx.S文件)了,直接调用Hello China提供的中断接口函数-ConnectInterrupt和DisconnectInterrupt即可,屏蔽了底层的中断实现。

用户在实现中断函数的时候,也无需在进入中断和离开中断时调用操作系统的“夹层函数”(诸如InterruptEnter/InterruptLeave等函数),因为夹层功能都已经在GeneralIntHandler中实现了。这种编程模型,符合操作系统对硬件的抽象理念,同时扩展性也非常强。

需要说明的是,在基于MDK开发环境的STM32移植中,我们并没有直接使用上述方法,而是做了适当变通,使得这个过程更加简单。因为直接用Int_Entry_Wrapper替换中断向量表,毕竟有很多的编辑工作,需要一条一条的修改,容易出错。在MDK生成的启动文件中,对所有的中断处理函数都做了一个缺省实现,如下:

………

USART1_IRQHandler

USART2_IRQHandler

USART3_IRQHandler

EXTI15_10_IRQHandler

RTCAlarm_IRQHandler

USBWakeUp_IRQHandler

B .

ENDP

这是一个死循环,因此,只要用下面的代码,替换这个死循环实现即可:

………

RTCAlarm_IRQHandler

USBWakeUp_IRQHandler

IMPORTInt_Entry_Wrapper

LDRR0,=Int_Entry_Wrapper

BX R0

ENDP

在具体移植过程中,只要找到startup_stm32f10x_XX.S文件,用上述代码替换缺省实现的死循环,即可完成中断链接。需要说明的是,Int_Entry_Wrapper是在另外一个汇编文件-osadapt.S中实现的。Osadapt.S是Hello China为了向STM32移植而增加的一个文件,里面还实现了其它底层功能,后面会详细讲解。

任务切换机制的移植

任务切换是操作系统移植的最重要的地方,毕竟不同的CPU,其底层机制是不同的。操作系统的任何功能模块都可以用C语言编写,但任务切换确是例外,目前尚未看到能够用C语言直接实现任务切换的CPU。

Hello China在实现的时候,任务切换机制做了优化,所需的汇编代码非常少。但是为了迎合不同的任务切换场景,分成了两种任务切换时机:

1.         中断内的任务切换,这种情形下,CPU的硬件中断处理机制已经帮助操作系统把任务(或者线程)的堆栈框架搭建好,操作系统无需自行建立堆栈框架,只需选择合适的线程,恢复堆栈框架即可;

2.         非中断内的任务切换(也叫做进程内的任务切换),这种情况下,一般是由系统调用引发。用户程序调用系统功能,比如调用CreateKernelThread创建一个核心线程,操作系统内核会在线程创建完成之后,重新检查系统中的所有内核线程,看是否有比当前核心线程优先级更高的线程。如果有,则内核会保存当前线程的堆栈框架,然后选择优先级最高的处于就绪状态的线程,恢复其堆栈框架,让其运行。与中断过程不同,这里需要操作系统内核自己建立待切换出线程的堆栈框架,工作要稍微多一些。

对应上述两种情况,Hello China操作系统实现了两个函数:ShceduleFromInt和ScheduleFromProc,分别用以实现。这两个函数分别调用更加底层的用汇编语言实现的两个函数:__SwitchTo和__SaveAndSwitch,来实现核心线程的切换。这种切换机制,因为不用引发额外的系统中断,所以我们称为inline schedule,对应config.h文件中的__CFG_SYS_IS。大多数CPU都是采用这种切换方式,高效简洁,易于理解。

但到了Cortex-M3的CPU,由于其底层机制的制约,无法使用上述inlineschedule机制。Cortex-M3的推荐做法是,专门预留了一个系统中断(异常),叫做PendSV,用于线程切换。任何希望切换线程的代码,需要引发这个异常,所有具体的切换工作,在这个异常处理程序中进行。这样就不分中断切换和进程切换了,所有切换统一进行。为了区分上面的inline schedule方式,我们把这种情形称为uniform schedule(简称unischedule,统一切换)。Unischedule的好处是不分切换所处的状态,相对简洁,但是不好之处在于,兼容性比较差,很少有CPU只支持这种方式,因此其通用性欠佳。

Hello China支持上述两种方式。在移植的时候,如果在config.h文件中定义了宏__CFG_SYS_IS(Inline Schedule),则采用第一种方式切换,如果把这个宏定义注释掉,则采用第二种方式切换。在Cortex-M3上,我们注释掉该宏定义,采用第二种方式切换。要引发任务切换,操作系统内核代码必须引发一个PendSV中断,下面是引发该中断的汇编代码:

ScheduleFromInt

ScheduleFromProc

PROC

EXPORTScheduleFromInt

EXPORTScheduleFromProc

PUSH {R4,R5}

LDRR4,=NVIC_INT_CTRL

LDRR5,=NVIC_PENDSVSET

STR R5,[R4]

POP {R4,R5}

BX LR

NOP

ENDP

要切换线程的时候,只要调用ScheduleFromInt或者ScheduleFromProc两个函数即可,这两个函数的实现是一样的,就是引发一个PendSV异常。

异常引发之后,在所有系统中断都处理完毕后,PendSV异常处理程序会被调用。由于我们在系统初始化的时候,设置PendSV异常的优先级是最低的,因此如果有任何中断处理程序在运行,PendSV异常处理程序就不会被调用。下面是PendSV处理程序的代码:

PendSV_Handler PROC

EXPORT PendSV_Handler

IMPORT UniSchedule    ;UniSchedule is implemented in C file.

PUSH {R4-R11}    ;Save un-saved registers.

MOV R4,LR

MRS R0,MSP

MRSR1,MSP

LDR R2,=UniSchedule

BLX R2           ;Now R0 contains the new thread toswitch to.

MOV LR,R4

MSR MSP,R0

POP {R4-R11}

BX LR

ENDP

这个程序也非常简单,先保存R4到R11寄存器(其它的寄存器,在进入异常处理程序的时候,已经由CPU保存),然后以当前堆栈指针为参数,调用UniSchedule函数。这个函数返回一个优先级最高的可调度线程的堆栈指针,然后PendSV直接恢复返回的线程的堆栈,即可切换到目标线程继续运行。

UniSchedule是用C语言实现的一个函数,位于ktmgr.c文件中。这个函数从系统中选择一个优先级最高的,且状态是ready的线程,返回其上下文指针(即堆栈指针)。需要注意的是,如果系统中没有比当前核心线程优先级更高的线程,则该函数直接返回当前核心线程的上下文,这样的结果就是,当前核心线程继续执行。

驱动程序的移植

个人认为,驱动程序移植是操作系统移植过程中工作量最大,也是最难的工作。毕竟不同的CPU,其外设管理方式不同,访问方式也不同。比如x86 CPU,是通过读写端口(in/out指令)来实现外设访问的。但是ARM系列CPU,则是通过内存映射方式,直接读写外设控制寄存器的。在实现驱动程序的时候,一般是针对某种CPU写的,在程序中内嵌了很多访问外设的代码。在移植的时候,这些代码都要一行一行的变换。如果说操作系统内核的移植是“黑盒移植”,无需审视每一行代码,只要移植几个接口函数即可,那么驱动程序的移植,则必须是“白盒移植”,需要认真检查每一行代码,确保每一行代码都能够在目标设备上工作。

在Hello China V1.76的移植中,只移植了一个USART设备的驱动程序。在基于x86的PC上,这就是串口驱动程序。移植的时候,所花的时间,比内核部分的移植还要大。从代码量上统计,也跟内核部分差不多,可见驱动程序移植只繁琐。虽然工作量大,但其难度却不是很大,不像内核一样,存在很多陷阱。

在移植过程中,还有其它一些注意的地方,在此就不做更多说明了。如有需要,在本文后面会提到。

上一篇:JS 和 Java 中URL特殊字符编码方式


下一篇:Java的基本数据类型与转换