在做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映射。
推荐阅读
RT-Thread隐藏的宝藏之completion
【20210305期AI简报】基于TensorRT完成NanoDet模型部署
【20210219期AI简报】嵌入式机器学习（TinyML）实战教程、谷歌开源计算框架JAX...
原文链接:嵌入式IoT
作者:bigmagic
