前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >rt-thread 针对不同架构芯片移植的方法

rt-thread 针对不同架构芯片移植的方法

作者头像
bigmagic
发布2021-03-09 15:24:59
9670
发布2021-03-09 15:24:59
举报
文章被收录于专栏:嵌入式iot嵌入式iot

在做rt-thread系统移植的这段时间里,积累一些快速移植的经验,不论是现有架构的不同型号的芯片,还是一个全新架构的移植,只需要按照一定的步骤进行,一般大的方向不会出错。剩下的事情就是解决为什么没有达到预期效果的问题。

移植的里程碑有如下的几个:

1.芯片工作在正常的模式,可以正常的执行c代码逻辑

2.至少有一个串口驱动

3.上下文切换逻辑

4.定时器可以正常的使用

5.串口输入有正常的中断产生并能够读到数据

针对以上的顺序详细描述问题以及解决办法。

芯片的工作模式

​​不同架构的芯片一定会有对应的模式适合操作系统的运行,这是芯片设计时就考虑到的问题,所以移植也要遵循这种规则。另外也涉及到寄存器的访问权限问题。

比如armv7,其操作系统存在的模式为system模式,可以方便的切换到其他模式。还有比较典型的armv8架构的el1特权级别。当然把芯片模式切换到其他的模式,也可以,比如rt-thread整个系统运行在el3特权模式,在el3特权级别最高,但是并不是越高越好,往往el3会有更加合适的用法。其切换到逻辑一般在芯片启动后,执行的最初一段的汇编代码逻辑里面,一般芯片在上电后,都会进入最高特权权限的模式里,切换到操作系统特定的特权级别模式即可。

可以正常执行c代码

完成这一步也是汇编的代码的实现,这一步的通用关键操作是bss段清零,以及设置栈指针地址。

对于bss段清零的必要性是因为c语言的语法规则,以前的存储程序的存储器是很贵的,所以程序在生成的时候,把未初始化的全局变量和静态变量,这些存储空间不存入存储器空间,然后在程序加载的时候,将这段空间指向的区域清零。而函数中的非静态的变量则存储在栈中,地址不确定。

如果不进行bss的清零,可能导致的问题是全局变量和静态变量的值不确定,导致程序编程时遇到异常的现象。

清空bss段的步骤也很简单,就是将bss这一段内存空间设置为0即可。

而设置栈地址也就是sp的地址,仅仅是为了在操作系统线程还未启动调度时,最开始的栈空间。根据c语言的函数调用规则,c语言进行函数调用时,都需要压栈和出栈,这段栈空间是用户自行分配的。

所以需要注意点是rt-thread启动调度前也是有一个栈空间的,调度启动后该栈空间不被使用,每个线程栈空间才生效。

至少有一个串口驱动

要完成这个工作,需要注意的问题是事先已经完成了串口驱动的验证工作。也就是可以正常的接收和发送数据。完成rt-thread串口驱动对接,只需实现串口初始化,串口接收,串口发送,中断注册即可。

由于前期没有中断,实现串口发送功能就可以接着进行下面工作了。

正常情况下,可以看到串口可以输出rt-thread的logo了。

​上下文切换逻辑

对于程序的上下文,可以理解为程序当前运行的现场。其现场里面主要包含的内容有,当前所有的寄存器状态,当前sp的值,有些处理器还有pc值等等。

对于第一个调度起来的线程,其上下文的内容是人工手动赋值的。因为并不能保证调度器执行的第一个线程是哪个具体的线程,所以每个线程都会存储一个人工填充的上下文。

需要注意的地方主要有三点,第一个线程调度启动后,会打开全局中断,具体是在上下文恢复时,由汇编代码实现。第二个是线程退出后,会启动下一次调度,线程回收工作由空闲线程完成。第三点一定要确保压栈的顺序和出栈的顺序一致性。

该功能实现正常的标志是可以正常进入main函数以及msh控制台。但不能输入控制,因为没有实现串口输入中断,如果已经实现串口中断,那可以msh输入。

​定时器可以正常使用

定时器可以正常使用的前提中断可以正常的产生,然后周期性的产生定时器中断。

定时器是系统tick的关键,没有定时器,系统将无法在任务中通过delay释放CPU资源,但是可以通过主动切换任务的方式进行调度。

关于rt-thread的tick的时间片多少合适的问题,这里解释为,一般合适的10ms,对于主频很高的芯片可以是1ms。曾经在30mhz的主频的FPGA上验证系统,发现并不能正常运行起来。分析因为系统定时器中断产生的太频繁,主频太低,程序来不及处理完成又发生了中断。

​串口可正常输入

该步骤可作为移植的成功的验证工作,这一步的工作并非技术难点,但是往往前面步骤没有成功,可能会导致这里出现不了想要的现象。

比如曾经协助一个客户完成移植工作时,发现串口中断打开后,只能输入一个字符串后无反应,后来才查到中断处理标志没有清空。

一般可以正常的输入输出,该系统移植就基本成功了。

​移植的工作难点

对于上面的步骤中,最难的就是栈帧的规划,上下文切换和中断处理。

结合实际移植经验,往往容易出问题的地方就是入栈和出栈的顺序对不上,或者有些寄存器没有存到栈中。在这个工作的时候,要检查一下寄存器是32位还是64位,可能因为这个小细节,导致栈帧的偏移。

另外要注意的是,线程压栈的时候,一定要压线程退出后的回收函数,曾经也因为没有注意这个细节导致main函数退出后,系统运行异常。

中断里面复杂设计在于中断的嵌套,往往在中断里执行调度,并不会立马执行到切换线程的上下文,这样就破坏了现场,而是待到所有中断执行完成后,再切换上下文。这一点在cortex-m上很好理解,中断控制器在处理pendsv异常时,总是等待其他高优先级中断处理完成后,再去处理优先级最低的pendsv。而对于sparc这种设计,切换任务是通过trap异常实现的,trap异常高于中断,也就是切换线程优先级高于中断,这是系统设计里面不合理的,在软件设计时,往往通过设置中断嵌套标志位,等到所有中断执行完成后,再切换上下文,一定不能够在中断执行时,把上下文切换走。

​移植经验分享

rt-thread的移植是有一些关键点的,找到这些关键点,可以非常顺利的规划清楚方向和目标,对于每个关键点进行技术攻克,这样是最快也是最高效的做事方式。

要想移植不同芯片架构,需要非常清楚这个芯片的架构,也需要非常熟悉rt-thread系统最关键点底层代码。一般熟悉rt-thread的底层代码并不是很难,从头读一遍aarch64的rt-thread最小系统实现两三天就能差不多理解,而芯片手册的阅读要结合实际的工作经验,弄清楚芯片特权模式、看懂寄存器,看懂汇编基本就可以了。当然有些处理器是需要实现mmu才能正常执行的,比如aarch64,必须实现mmu的功能,即使是1:1映射。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2021-02-16,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 嵌入式IoT 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档