FreeRTOS+CubeMX系列第一篇——初识FreeRTOS

冬瓜~

已于 2022-09-14 15:11:58 修改

阅读量1.8w

点赞数 68

分类专栏： # FreeRTOS+CubeMX 文章标签：操作系统嵌入式 c++ FreeRTOS

于 2020-08-14 22:08:06 首次发布

本文链接：https://blog.csdn.net/weixin_44793491/article/details/107577711

版权

FreeRTOS+CubeMX 专栏收录该内容

2 篇文章 31 订阅

订阅专栏

文章目录

一.关于FreeRTOS

1.什么是FreeRTOS?

FreeRTOS是一个迷你的实时操作系统内核。是一个轻量级的操作系统，功能包括：任务管理、时间管理、信号量、消息队列、内存管理、记录功能、软件定时器、协程等，可基本满足较小系统的需要。

在嵌入式领域，FreeRTOS是不多的同时具有实时性，开源性，可靠性，易用性，多平台支持等特点的嵌入式操作系统。目前，FreeRTOS已经发展到支持包含X86，Xilinx，Altera等多达30种的硬件平台，其广阔的应用前景已经越来越受到业内人士的瞩目。

2.为什么选择FreeRTOS?

具备安全性。
具备稳定性。 大量开发者使用，并保持高速增长趋势。更多的人使用可以促进发现BUG，增强了稳定性。
内容简单。 作为一个轻量级的实时操作系统，FreeRTOS本身文件非常少，其内容全部围绕着任务调度，占用的硬件资源比较少，可以应用在对成本要求严格的场合。
文档齐全。 在FreeRTOS官方网站上，可以找到所有你需要的资料。
免费、开放源码。 要知道开源不等于免费，像uC/OS，Linux都是开源的，但是一旦用于商业用途都是需要支付一定费用。FreeRTOS不旦开源，而且完全可以免费用于商业产品，这也是为什么FreeRTOS的使用者如此多，据市场调查报告显示，近10年FreeRTOS的使用量在RTOS使用榜上一直稳居前5。

在此，致敬FreeRTOS创始者Richard Barry，感谢他无私的开源精神。

插入一个采访：
问：什么精神鼓励你开发了FreeRTOS？

Richard Barry（FreeRTOS的创始人）:
开发FreeRTOS的想法来自大约10多年前我经历的一个服务的项目，我的一个任务是选择一个合适的RTOS。当时可以选择的一个RTOS已经使用在该公司的商业产品里面了，但是版税极为昂贵。而且，我们的应用仅仅需要一个很小的RTOS解决方案，一个大的、商业的RTOS在我们这个项目中一点也没有价值。我转而寻找一个适合的开源的RTOS，然而令我失望的是，因为没有好的文档，开源软件的学习周期太长了，还没有技术支持，软件的质量也难以让人满意。最终我只好推荐了一个商业的、没有产品版税的RTOS。

当项目结束的时候，我开始思考，有多数人会经历同样的寻找过程呢？我想只是应该有数千人计吧。因为我是一个极客，我开始自己开发一个解决方案，从中我也找到了乐趣。最初的FreeRTOS 版本发表了之后，很明显我的预计是正确的，的确有数千计的工程师寻找这种解决方案。

之后，我就更正式的安排和计划这个工作。首先我把使用开源的免费软件的风险列了出来，比如质量、知识产权侵权和技术支持问题，接着制定了一个可以减少以上风险的FreeRTOS开发和发行的模式。举三个例子吧，FreeRTOS遵守MISRA规范，进而保证产品的质量，使用FreeRTOS没有知识产权侵权的风险，而且通过社区和专业公司提供技术支持。可以这样说，FreeRTOS基本上就是一个商业RTOS，但是完全免费，这也就是今天人们看到FreeRTOS如此受到欢迎的原因。

———— 对话FreeRTOS创始人

二.FreeRTOS的特点

实时性： FreeRTOS可以配置成为一个硬实时操作系统内核，也可以配置为非实时型内核，甚至于部分任务是实时性的，部分不是。这一点比uC/OS-II 要灵活。
任务数量： FreeRTOS对任务数没有限制，同一优先级也可以有多个任务。这点上比uC/OS-II好。
抢占式或协作式调度算法： 任务调度既可以为抢占式也可以为协作式。采用协作式调度算法后，一个处于运行态任务除非主动要求任务切换，否则是不会被调度出运行态的。
任务调度的时间点： 调度器会在每次定时中断到来时决定任务调度，同时外部异步事件也会引起调度器任务调度。
调度算法： 任务调度算法首先满足高优先级任务最先执行，当多于1个任务具有相同的高优先级时，采用round robin算法调度。
优先级翻转： FreeRTOS没有提供优先级继承机制或其他的避免优先级翻转的方法。
任务间通信： FreeRTOS 支持队列和几种基本的任务同步机制。
（一）消息队列： 任务间传递信息可以采用队列方式，FreeRTOS实现的队列机制传递信息是采用传值方式，因此对于传递大量数据效率有些低。但可以通过传递指针的方式提高效率。中断处理函数中读写队列都是非阻塞型的。任务中读写队列可以为阻塞型也可以配置非阻塞型。当配置为阻塞型时可以指定一个阻塞的最大时间限（Timeout）。
（二）任务间同步： FreeRTOS 支持基本的信号量功能。FreeRTOS 采用队列来实现信号量的功能，可以认为一个值为n的信号量就是一个长度为n的队列，队列中每个元素的大小为0。这样的队列并不会浪费宝贵的内存空间。
（三）对于死锁（Deadlock）的处理： FreeRTOS 并没有实现一种可以完全避免死锁的机制。只是通过指定一个阻塞的最大时间限（Timeout）来减少死锁现象的发生。或者说是给出了当死锁现象发生时解锁的可能。当然能不能真的解锁要依赖于使用者的处理代码是否合适。
（四）临界区： FreeRTOS 采用开关中断的方式实现临界区保护。任务代码中临界区可以嵌套，FreeRTOS 会自动记录每个任务中临界区嵌套的层数。
（五）暂停调度： 与进入临界区类似，FreeRTOS 可以通过暂时关闭任务调度来保证任务代码不被更高优先级的其他任务打断，与临界区不同，关闭任务调度并不会关闭中断，这样中断处理函数仍会照常的执行。
（六）内存分配： FreeRTOS 提供了多种内存动态分配的方法，具体程序中需要选择其中一种。最简单的内存分配方式提供了一种非常简单的固定内存分配算法，这种方式下只支持内存的分配，不支持分配内存的回收。因此，任务建立后就不能被删除。其他几种内存分配算法支持分配内存的回收，有的方法支持邻接内存块的合并，有些不支持。对我个人来说，我还是比较欣赏uC/OS-II中内存分配的方法，既保证了实时性，也具有一定的灵活性。FreeRTOS 中提供的几种方式，实时性好的功能上有缺陷，功能上完善的实时性却不好。我通常采用的方式是采用最简单的内存固定分配算法，当需要动态释放时将uC/OS-II中内存分配的代码拿来用。

———此处内容来自博客(https://blog.csdn.net/liyuanbhu/article/details/7911163)

三.如何在CubeMX上配置FreeRTOS

开发环境：CubeMX Vesion 5.4.0
Keil Vesion 5.28

（一）首先，像往常一样需要先设置RCC、SYS以及时钟树，这里不做详细介绍。

需要提醒一点的是：裸机的时钟源默认是SysTick，但是开启FreeRTOS后，FreeRTOS会占用SysTick，所以需要需要为其他总线提供另外的时钟源。具体步骤如下图（以TIM7例）

（二）开启FreeRTOS（选择CMSIS_V1，V2我没用过），进行相关配置。详情如下：

在FreeRTOS的配置列表中有七种不同属性的配置，为其标上序号，其对应的内容为：

Task and Quenes： 任务与队列的创建。
Timers and Semaphores： 定时器和信号量的创建。
Mutexes： 互斥量的创建。
FreeRTOS Heap Usage： 用于查看堆使用情况。
config parameters： 内核参数设置，用户根据自己的实际应用来裁剪定制FreeRTOS内核。
Include parameters： FreeRTOS部分函数的使能。
User Constants： 相关宏的定义，可以自建一些常量在工程中使用。

详情如下：

1. Task and Quenes 任务与队列：
关于任务和队列的创建，这里不做详细介绍，因为后面还会继续更新博客专门讲任务和队列创建以及对应的API函数。这里主要提醒一点：任务与队列不一定需要在CubeMX中创建，也可以在其生成的工程中调用FreeRTOS源码手动创建任务与队列。在CubeMX中创建任务本质上和在工程内创建没有什么不同，都是都调用FreeRTOS源码，只不过CubeMX会对FreeRTOS源码进行二次封装。

2. Timers and Semaphores 定时器与信号量：
用于定时器和信号量的创建

3. Mutexes 互斥量：
用于互斥量的创建

4. FreeRTOS Heap Usage 堆使用情况：

FreeRTOS Heap Usage 用于查看FreeRTOS堆的使用情况（关于堆与栈的区别）。就像电脑下载软件会占用电脑内存一样，FreeRTOS内创建任务也会占用单片机内存。除了任务，还有队列、信号量等等都会占用内存，从FreeRTOS Heap Usage 栏就能看出各部分的内存占用情况（以Bytes为单位）。

5. config parameters 系统内核配置：