(转)FreeRTOS移植到STM32F103步骤与注意事项

1万 · 2018-6-28 15:56

下面先以IAR移植为例，说明移植过程中的诸多注意事项，最后再以MDK移植时不再重复说明，所以还是建议大家先花些时间看IAR的移植过程，哪怕你不使用IAR，最好也注意下那一大堆注意事项！

一、从官网下载最新版的FreeRTOS源码

FreeRTOS组织为了抢用户也是拼了命的，不信你打开Demo文件夹看看，里面提供了FreeRTOS在各种单片机上已经移植好的工程，如果建工程时遇到什么问题，可以参考下这些Demo。

不过小灯现在着重于自己动手移植FreeRTOS，考虑到原子哥@正点原子的用户比较多，绝大多数习惯了使用MDK来开发STM32，因此小灯分别以IAR和MDK两种使用比较广泛的开发环境来移植FreeRTOS。说到IAR和MDK，不得不提的是小灯自从用了IAR之后就果断放弃了MDK，相信很多人有这个经历，哈哈！

在开始移植FreeRTOS之前，先介绍下FreeRTOS的源码：

FreeRTOS的源码比较少，源文件也远没有UCOS多，不过麻雀虽小五脏俱全，FreeRTOS的短小精悍也是最令小灯着迷的，虽然缺少了很多组成部分，例如GUI、网络协议栈、文件系统等，不过这些统统都不是问题，因为完全可以移植第三方的组件！

一不小心牛X又吹大了，哈哈！回归正题，FreeRTOS的源码核心部分是tasks.c和list.c，其余的几个文件功能都是可选的，例如软件定时器、队列、协程等等，小灯就不介绍了，有兴趣的话可以到官网上看介绍。include文件夹里面的文件是操作系统相关的头文件，而portable这个文件夹有些奇葩，先看看里面有啥：

这里的文件几乎都是与平台相关的，如果你要删掉这里的文件时就必须小心了，因为不是所有文件都能删除的。

注意文件夹MemMang，里面存放的是FreeRTOS自带的内存管理方案的源文件：

关于内存管理方案的选择，小灯以后再跟大家讨论，现在只需要知道这些文件不能删就好。

接下来看看IAR文件夹的内容，里面都是跟单片机底层相关的，由于我们以STM32F103为例，因此只需要保留ARM_CM3文件夹即可，其余可选择性删除。ARM_CM3文件夹里只有几个文件，这几个文件是操作系统最最底层的部分：

接下来再看看Keil文件夹的内容，里面只有一个文件，文件提示See-also-the-RVDS-directory，意思是让我们参照RVDS目录下的文件。其实我们以MDK建工程时，就是拿RVDS目录下的文件来替代的，因此我们应该把RVDS目录下的文件拷贝到Keil目录下，跟上面IAR文件夹一样我们只拷贝ARM_CM3文件夹即可：

到这里我们可以把其他无用的文件统统删掉了，portable目录下只保留下面几个文件夹的文件即可：

现在已经把源码整理好了，接下来就开始移植工作吧！

1万 · 2018-6-28 15:57

二、IAR下移植FreeRTOS
事先说明下，小灯使用的IAR版本是

关于IAR下如何创建STM32基础工程，小灯就偷下懒不介绍了，这入门级的知识还是交给卖开发板的人来传播吧，小灯就以自己平常用的简单工程为例：

工程当中只有一个LED.c是小灯额外添加的，小灯一直停留在跑灯的水平，习惯用LED来观察现象，希望各位大神莫怪。工程源码结构如下：

其中FreeRTOS文件夹下就是FreeRTOS的源码：

接下来在工程里面添加FreeRTOS文件：

文件清单如下：
FreeRTOS\tasks.c
FreeRTOS\list.c
FreeRTOS\portable\IAR\ARM_CM3\port.c
FreeRTOS\portable\IAR\ARM_CM3\portasm.s
FreeRTOS\portable\MemMang\heap_4.c

这时有人可要问为何没有把FreeRTOS的所有文件都添加进去，原因我上面提过了，FreeRTOS的核心部分是tasks.c和list.c，其余的几个文件是可选部分，在此小灯就先不添加这些可选部分以简化我们的工程。
小灯建议大家使用内存管理的方案四heap_4.c，因为该方案具有内存块碎片合并功能，比heap_2.c的最优内存块分配方案要稳定很多，这是小灯经过很长时间测试对比出来的，公司的产品也是一直使用heap_4.c，稳定性无懈可击！

接下来非常重要的一步就是添加头文件路径：

头文件路径如下：
$PROJ_DIR$\..\Source\FreeRTOS\include
$PROJ_DIR$\..\Source\FreeRTOS\portable\IAR\ARM_CM3
好了这时我们可以尝试编译下整个工程了，编译结果提示缺少了个头文件：

FreeRTOS组织也真是奇葩，居然连这么重要的文件都不提供在源码里面！！！前面提醒过大家，新建工程时碰到问题一定要参考官方提供的Demo，既然Demo是一堆成品的工程，那么里面绝对有我们所需的这个FreeRTOSConfig.h
我们就选择打开Demo\CORTEX_STM32F103_IAR下的这个工程吧，果不其然里面真的有我们需要的这个头文件：
把这文件放哪里好呢，这是一直纠结小灯的问题，官方直接把这文件放在工程目录下，但这么重要的配置文件这么随便放似乎不太好吧。在小灯看来，这个文件的重要性和打开的概率绝不比FreeRTOS内核文件低，所以还是把它放在源码里面比较合理：在C/C++ Compiler下添加头文件路径：
$PROJ_DIR$\..\Source\FreeRTOS
还有一个地方一定要十分注意，因为操作系统的最最底层的几个文件也需要用到FreeRTOSConfig.h头文件，而底层文件是用汇编来写的，因此必须在Assembler下添加FreeRTOSConfig.h头文件路径：

好了再编译一次：

0个错误0个警告，程序员最欢喜的莫过于看见这个结果了，哈哈！

1万 · 2018-6-28 15:58

在编写系统任务前，有必要对配置文件FreeRTOSConfig.h进行检查。FreeRTOSConfig.h里面几乎都是一些宏定义，关于这些宏定义的具体用法，可以在官网上查阅：http://www.freertos.org/a00110.html
小灯只以其中几个比较重要的参数作特别说明，下面以小灯修改过的FreeRTOSConfig.h为例作为说明：

（1）定义系统底层相关的函数

其中SVC中断时操作系统启动时进入的中断，而PendSV中断手动切换任务时进入的中断，SysTick中断不用我多说了，@正点原子的基础例程几乎都使用这个定时器定时，在这里SysTick是作为操作系统的心脏。由于FreeRTOS对这几个中断的名称做了自己的定义，因此必须要重定义这几个函数才能正常进入中断，但这么做又会跟ST提供的stm32f10x_it.c文件当中定义的中断相冲突，因此必须将stm32f10x_it.c下对应的几个中断服务函数屏蔽掉，否则编译会提示函数重定义：
（2）修改系统可屏蔽的中断优先级阈值
FreeRTOS提供的可屏蔽中断优先级阈值是191，对应的十六进制数是0xBF：
#defineconfigMAX_SYSCALL_INTERRUPT_PRIORITY 191
由于STM32F103的优先级分组只有4个位，而CM3的优先级是以MSB对齐的，也就是说STM32F103的优先级寄存器只有最高4位有效，低四位是无效的。当操作系统进入临界区时，会把上面的可屏蔽中断优先级阈值写入BASEPRI寄存器以屏蔽部分中断：

因此当进入临界区时，优先级对应0xB~0xF的中断均被屏蔽，而优先级处于0xB前面的中断不受影响。这个跟CM0有区别，也是最值得注意的地方。
上述的基础知识不是小灯要重点提的，对CM3的优先级不熟悉的朋友建议查阅《Cortex-M3权威指南》，接下来才是小灯要重点提的。由于使用@正点原子的开发板的用户比较多，很多人直接把FreeRTOS移植到原子哥的工程下，然后出现了各种各样的诡异问题，一直无解。其中一个非常严重的问题就是小灯上面提及到的中断屏蔽的问题，下面小灯就这个问题进行一个简单的分析，先贴上@正点原子的部分代码：
这是原子哥最常用的中断优先级分组方式，采用分组方式2，2位抢占优先级2位亚优先级。但是在移植FreeRTOS时必须要修改成优先级分组方式4：

把STM32的优先级分组的4个位均设成抢占优先级，也就是说完全放弃亚优先级。为何要这么设置？其实这得怪FreeRTOS机构里面被驴踢过的逗逼，这些逗逼为了自己省事，直接默认不使用亚优先级，下面让大家见识下这群逗逼的解释：
不过站在他们的角度来思考，其实我们也应该给他们那么一丁点儿理解，毕竟他们采取了一个比较简单的方法来获取不同厂商的单片机的有效优先级位数，算法是通过对优先级寄存器组的某一个寄存器写入0xFF，然后再读出来看实际上有多少位写入成功，然后根据实际的有效位数来重设优先级分组寄存器的分组方式（上面提到的分组方式4）。有兴趣的可以研究下他们的算法，代码截图在下面：

不知不觉越扯越远了，回归正题，到底为何要重设可屏蔽的中断优先级阈值，我们重新把思路理一下。根据STM32的中断优先级的设计，只有高4位有效，还有FreeRTOS默认将4个优先级位均划分为抢占优先级。由于FreeRTOS官方提供的中断优先级阈值是191（对应实际的0xB），也就是11~15的优先级均可被操作系统屏蔽。但我们实际使用时设置的中断优先级一般不会使用到11打后的，例如@正点原子的基础例程里面使用最多的1~3，所以我们必须要修改这个值，否则我们要重新修改所有底层驱动的优先级。
那么怎么修改比较合理？这个就得看实际应用需要了，其实使用宏configMAX_SYSCALL_INTERRUPT_PRIORITY来屏蔽部分中断是比较合理的，相对于CM3，CM0没有中断优先级阈值寄存器，只能简单粗暴的开启全局中断和关闭全局中断。操作系统在执行十分重要的工作时一般不能打断这个工作，尤其是这时在中断里面调用了操作系统的API函数，这都会严重影响系统的稳定性。小灯对configMAX_SYSCALL_INTERRUPT_PRIORITY的理解是，这个数值打后的所有中断均划入操作系统管理，而这个数值打前的中断则归由用户自己管理，但用户必须十分小心地处理这些中断，用户可以使用这些中断来处理一些跟操作系统无关的工作。这纯属个人理解，如有错误之处还请大家指出，小灯会尽快修改！
分析完configMAX_SYSCALL_INTERRUPT_PRIORITY的作用后，下面小灯提供一个参考值：

由于优先级寄存器是高四位有效，因此上述的屏蔽阈值实际上是0x1，也就是说优先级在1~15之间的中断均可被操作系统屏蔽，而优先级0归由用户自己控制。值得注意的是configMAX_SYSCALL_INTERRUPT_PRIORITY的高四位绝对不能设为0，下面小灯给出0x0F的仿真结果：

当configMAX_SYSCALL_INTERRUPT_PRIORITY设为0x0F时系统在进入临界区时BASEPRI寄存器的值一直为0，没有更新。下面给出0x1F时的仿真结果：

当configMAX_SYSCALL_INTERRUPT_PRIORITY设为0x1F时系统在进入临界区时BASEPRI寄存器的值更新为0x10，中断优先级阈值寄存器起作用了！原因在上面也解释过了，因为STM32F103的优先级寄存器是高四位有效的，对应的BASEPRI也是高四位能够写入而低四位无法写入，而BASEPRI有一个特点——对它写0会取消屏蔽所有中断（相当于禁用了该寄存器），因此BASEPRI的高四位一定不能设为0，否则不会屏蔽任何中断，这点注意下就好了。
（3）添加参数检测功能

该参数检测功能是官方提供的一个参考，很多人为了省事不使用参数检测，但小灯劝诫各位千万不能干这蠢事！说了半天想必大家也累了，那么接下来就开始我们跑灯之旅吧！

下面就以LED创建两个闪烁任务：

至于LED底层驱动代码在工程里面提供了，在这不详细解释，读者可自行修改。在main函数里首先设置中断优先级分组方式4，然后创建2个LED任务，堆栈深度40个字（160字节）即可，然后启动任务调度器，整个操作系统就能够跑起来了。
重新编译下工程，这时会提示有错误：

接下来我们需要屏蔽这些编译错误：

在C/C++ Compiler的Diagostics里面添加Pa082,Pe191,Pe167
重新编译一次：

编译通过，下载到板子上后就能够看到2个LED按照一定的频率闪烁了！

1万 · 2018-6-28 15:59

三、MDK下移植FreeRTOS
由于在上面IAR移植过程中已经把需要注意的事项详细，再次就不累述了，只给出移植过程。小灯使用的MDK版本是：

至于MDK工程的新建，请参照@正点原子的教程资料，小灯就不抢原子哥风头了，哈哈！
工程沿袭了小灯一贯的简约作风：

（1）添加FreeRTOS源文件：

源文件清单路径如下：
FreeRTOS\tasks.c
FreeRTOS\list.c
FreeRTOS\portable\Keil\ARM_CM3\port.c
FreeRTOS\portable\MemMang\heap_4.c
注意这里的FreeRTOSConfig.h的来源小灯在上面IAR移植里面已经详细说明了，而且对FreeRTOSConfig.h里面的内容做了大篇幅的分析，读者请自行翻查，在此不再累述。

（2）添加头文件路径：

（3）修改stm32f10x_it.c文件：

至于为了要修改该文件，小灯在上面IAR移植里面已经详细说明了，读者请自行翻查，在此不再累述。

（4）创建两个LED闪烁任务：

代码的解释在IAR移植里面已经详细说明了，读者请自行翻查，在此不再累述。

（5）编译工程：

在MDK移植FreeRTOS相对来说顺利很多，因为不会出现一大堆警告和错误。接下来下载到板子，效果跟IAR移植后一样，2个LED按照预定的频率闪烁！
总结：
FreeRTOS的移植难度并不大，只是有些地方需要注意，否则出问题了也完全找不出问题出在哪里。由于小灯习惯了使用IAR，习惯使用MDK的用户如果看IAR的移植步骤可能会很不习惯，但两者移植过程相仿，读者只需要注意对应的事项就好。鉴于小灯水平有限，文档难免会有出错的地方，小灯也很希望各位能指出错误之处或提供宝贵意见，小灯会及时修改，不胜感激！