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

·Word资料FreeRTOS移植到STM32F103步骤与注意事项2017年05月29日11:16:361496原文地址：.openedv./thread-77593-1-1.html前言：由于之前听过太多人抱怨移植FreeRTOS到STM32有各种各样的问题，小灯经过一年多对FreeRTOS的研究并在公司产品中应用，多少有些心得，接下来就由小灯以最新版的FreeRTOS为例一步一步移植到STM32F103上，并提醒大家某些需要注意的事项。本文档为非正式技术文档，故排版会有些凌乱，希望大家能提供宝贵意见以供小灯参考改进。下面先以IAR移植为例，说明移植过程中的诸多注意事项，最后再以MDK移植时不再重复说明，所以还是建议大家先花些时间看IAR的移植过程，哪怕你不使用IAR，最好也注意下那一大堆注意事项！一、从官网下载最新版的FreeRTOS源码下面的网址是官方最新源码的下载地址：=files目前官方提供的最新版本是v9.0.0，FreeRTOS源码在解压目录下的路径为FreeRTOS_V9.0.0rc2\FreeRTOS\SourceFreeRTOS组织为了抢用户也是拼了命的，不信你打开Demo文件夹看看，里面提供了FreeRTOS在各种单片机上已经移植好的工程，如果建工程时遇到什么问题，可以参考下这些Demo。不过小灯现在着重于自己动手移植FreeRTOS，考虑到原子哥正点原子的用户比较多，绝大多数习惯了使用MDK来开发STM32，因此小灯分别以IAR和MDK两种使用比较广泛的开发环境来移植FreeRTOS。说到IAR和MDK，不得不提的是小灯自从用了IAR之后就果断放弃了MDK，相信很多人有这个经历，哈哈！在开始移植FreeRTOS之前，先介绍下FreeRTOS的源码：·Word资料FreeRTOS的源码比较少，源文件也远没有UCOS多，不过麻雀虽小五脏俱全，FreeRTOS的短小精悍也是最令小灯着迷的，虽然缺少了很多组成部分，例如GUI、网络协议栈、文件系统等，不过这些统统都不是问题，因为完全可以移植第三方的组件！一不小心牛逼又吹大了，哈哈！回归正题，FreeRTOS的源码核心部分是tasks.c和list.c，其余的几个文件功能都是可选的，例如软件定时器、队列、协程等等，小灯就不介绍了，有兴趣的话可以到官网上看介绍。include文件夹里面的文件是操作系统相关的头文件，而portable这个文件夹有些奇葩，先看看里面有啥：这里的文件几乎都是与平台相关的，如果你要删掉这里的文件时就必须小心了，因为不是所有文件都能删除的。注意文件夹MemMang，里面存放的是FreeRTOS自带的存管理方案的源文件：·Word资料关于存管理方案的选择，小灯以后再跟大家讨论，现在只需要知道这些文件不能删就好。接下来看看IAR文件夹的容，里面都是跟单片机底层相关的，由于我们以STM32F103为例，因此只需要保留ARM_CM3文件夹即可，其余可选择性删除。ARM_CM3文件夹里只有几个文件，这几个文件是操作系统最最底层的部分：接下来再看看Keil文件夹的容，里面只有一个文件，文件提示See-also-the-RVDS-directory，意思是让我们参照RVDS目录下的文件。其实我们以MDK建工程时，就是拿RVDS目录下的文件来替代的，因此我们应该把RVDS目录下的文件拷贝到Keil目录下，跟上面IAR文件夹一样我们只拷贝ARM_CM3文件夹即可：到这里我们可以把其他无用的文件统统删掉了，portable目录下只保留下面几个文件夹的文件即可：现在已经把源码整理好了，接下来就开始移植工作吧！二、IAR下移植FreeRTOS事先说明下，小灯使用的IAR版本是·Word资料关于IAR下如何创建STM32基础工程，小灯就偷下懒不介绍了，这入门级的知识还是交给卖开发板的人来传播吧，小灯就以自己平常用的简单工程为例：工程当中只有一个LED.c是小灯额外添加的，小灯一直停留在跑灯的水平，习惯用LED来观察现象，希望各位大神莫怪。工程源码结构如下：其中FreeRTOS文件夹下就是FreeRTOS的源码：·Word资料接下来在工程里面添加FreeRTOS文件：文件清单如下：FreeRTOS\tasks.cFreeRTOS\list.cFreeRTOS\portable\IAR\ARM_CM3\port.cFreeRTOS\portable\IAR\ARM_CM3\portasm.sFreeRTOS\portable\MemMang\heap_4.c这时有人可要问为何没有把FreeRTOS的所有文件都添加进去，原因我上面提过了，FreeRTOS的核心部分是tasks.c和list.c，其余的几个文件是可选部分，在此小灯就先不添加这些可选部分以简化我们的工程。小灯建议大家使用存管理的方案四heap_4.c，因为该方案具有存块碎片合并功能，比heap_2.c的最优存块分配方案要稳定很多，这是小灯经过很长时间测试对比出来的，公司的产品也是一直使用heap_4.c，稳定性无懈可击！接下来非常重要的一步就是添加头文件路径：·Word资料头文件路径如下：$PROJ_DIR$\..\Source\FreeRTOS\include$PROJ_DIR$\..\Source\FreeRTOS\portable\IAR\ARM_CM3好了这时我们可以尝试编译下整个工程了，编译结果提示缺少了个头文件：FreeRTOS组织也真是奇葩，居然连这么重要的文件都不提供在源码里面！！！前面提醒过大家，新建工程时碰到问题一定要参考官方提供的Demo，既然Demo是一堆成品的工程，那么里面绝对有我们所需的这个FreeRTOSConfig.h我们就选择打开Demo\CORTEX_STM32F103_IAR下的这个工程吧，果不其然里面真的有我们需要的这个头文件：·Word资料把这文件放哪里好呢，这是一直纠结小灯的问题，官方直接把这文件放在工程目录下，但这么重要的配置文件这么随便放似乎不太好吧。在小灯看来，这个文件的重要性和打开的概率绝不比FreeRTOS核文件低，所以还是把它放在源码里面比较合理：在C/C++Compiler下添加头文件路径：$PROJ_DIR$\..\Source\FreeRTOS还有一个地方一定要十分注意，因为操作系统的最最底层的几个文件也需要用到FreeRTOSConfig.h头文件，而底层文件是用汇编来写的，因此必须在Assembler下添加FreeRTOSConfig.h头文件路径：·Word资料好了再编译一次：0个错误0个警告，程序员最欢喜的莫过于看见这个结果了，哈哈！在编写系统任务前，有必要对配置文件FreeRTOSConfig.h进行检查。FreeRTOSConfig.h里面几乎都是一些宏定义，关于这些宏定义的具体用法，可以在官网上查阅：.freertos.org/a00110.html小灯只以其中几个比较重要的参数作特别说明，下面以小灯修改过的FreeRTOSConfig.h为例作为说明：（1）定义系统底层相关的函数·Word资料其中SVC中断时操作系统启动时进入的中断，而PendSV中断手动切换任务时进入的中断，SysTick中断不用我多说了，正点原子的基础例程几乎都使用这个定时器定时，在这里SysTick是作为操作系统的心脏。由于FreeRTOS对这几个中断的名称做了自己的定义，因此必须要重定义这几个函数才能正常进入中断，但这么做又会跟ST提供的stm32f10x_it.c文件当中定义的中断相冲突，因此必须将stm32f10x_it.c下对应的几个中断服务函数屏蔽掉，否则编译会提示函数重定义：（2）修改系统可屏蔽的中断优先级阈值FreeRTOS提供的可屏蔽中断优先级阈值是191，对应的十六进制数是0xBF：#defineconfigMAX_SYSCALL_INTERRUPT_PRIORITY191由于STM32F103的优先级分组只有4个位，而CM3的优先级是以MSB对齐的，也就是说STM32F103的优先级寄存器只有最高4位有效，低四位是无效的。当操作系统进入临界区时，会把上面的可屏蔽中断优先级阈值写入BASEPRI寄存器以屏蔽部分中断：因此当进入临界区时，优先级对应0xB~0xF的中断均被屏蔽，而优先级处于0xB前面的中断不受影响。这个跟CM0有区别，也是最值得注意的地方。上述的基础知识不是小灯要重点提的，对CM3的优先级不熟悉的朋友建议查阅《Cortex-M3权威指南》，接下来才是小灯要重点提的。由于使用正点原子的开发板的用户比较多，很多人直接把FreeRTOS移植到原子哥的工程下，然后出现了各种各样的诡异问题，一直无解。其中一个非常严重的问题就是小灯上面提及到的中断屏蔽的问题，下面小灯就这个问题进行一个简单的分析，先贴上正点原子的部分代码：·Word资料这是原子哥最常用的中断优先级分组方式，采用分组方式2，2位抢占优先级2位亚优先级。但是在移植FreeRTOS时必须要修改成优先级分组方式4：把STM32的优先级分组的4个位均设成抢占优先级，也就是说完全放弃亚优先级。为何要这么设置？其实这得怪FreeRTOS机构里面被驴踢过的逗逼，这些逗逼为了自己省事，直接默认不使用亚优先级，下面让大家见识下这群逗逼的解释：不过站在他们的角度来思考，其实我们也应该给他们那么一丁点儿理解，毕竟他们采取了一个比较简单的方法来获取不同厂商的单片机的有效优先级位数，算法是通过对优先级寄存器组的某一个寄存器写入0xFF，然后再读出来看实际上有多少位写入成功，然后根据实际的有效位数来重设优先级分组寄存器的分组方式（上面提到的分组方式4）。有兴趣的可以研究下他们的算法，代码截图在下面：·Word资料不知不觉越扯越远了，回归正题，到底为何要重设可屏蔽的中断优先级阈值，我们重新把思路理一下。根据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的作用后，下面小灯提供一个参考值：·Word资料由于优先级寄存器是高四位有效，因此上述的屏蔽阈值实际上是0x1，也就是说优先级在1~15之间的中断均可被操作系统屏蔽，而优先级0归由用户自己控制。值得注意的是configMAX_SYSCALL_INTERRUPT_PRIORITY的高四位绝对不能设为0，下面小灯给出0x0F的仿真结果：当configMAX_SYSCALL_INTERRUPT_PRIORITY设为0x0F时系统在进入临界区时BASEPRI寄存器的值一直为0，没有更新。下面给出0x1F时的仿真结果：当c