从屎山代码到RTOS,老工程师的架构进化史

很多老铁和我反馈，说很喜欢看我写的内容，不管是朋友圈还是文章，能在字里行间，受益匪浅。

想想也很久没时间没写长文了，既然大家喜欢看，我尽量抽时间多写。

长文预警，全文5800多字，写了16个小时，如果你想真正深入了解哪些项目需要上RTOS？RTOS有哪些优势？具体能解决产品哪些痛点？请花十分钟，耐心看完，这篇文章比你看一套教程更一针见血，如果你赶时间，建议先点赞+收藏防止找不到。。

前段时间，本来想录新项目的教程，因为从去年研发出来，教程就一直烂尾了，没想到还要继续烂尾...

后面我们评估了一下，想着把我们项目6跑个RTOS，给支持我们的老铁，再安排一波彩蛋，会不会投产比更高一点？

答案是一定的，从几个维度分析吧

1.如果学完我们项目现有的架构，比如任务管理、队列、链表。再去学RTOS，简直就是so esay! 很多思维，代码和RTOS都是类似的，老铁们需要花费的时间不多，但简历又能添金不少。

2.项目6这种级别的，上个RTOS，站在产品的角度，也合情合理，合理意味着更有说服力。

评估下来，大家都不用投入太多，但是产出高，说干就干，于是我们花了2个月左右，先是把freertos移植到项目6，然后又录了教程。

但今天不是来吹我们教程的，而是来解决很多小伙伴的一个疑问，就是RTOS能做什么项目？或者什么项目要上RTOS？

一、为什么要用RTOS？

想解决这个问题，就要追溯到RTOS能给项目带来的好处，或者便利，大白话讲就是RTOS有哪些功能优势？能具体解决产品哪些痛点？

1.解决项目架构问题

RTOS是"Real-time Operating System"单词的缩写，对应的中文称为"实时操作系统"，目前市面的RTOS系统种类比较多，我们这里以FreeRTOS为例。

虽然我们推出了FreeRTOS的教程，但不意味着这是求职者的刚需技能，我和徐工都在一线干研发有10年以上，碰到上RTOS的项目，可以说不多。

一般复杂点的项目，用我们自己写的那个架构就能胜任，而且移植起来没那么繁琐，代码也没那么臃肿，该有的功能也有，比如任务管理，定时器矩阵，队列。

这个架构，下到51，上到STM32的项目，都能用，不过51单片机资源匮乏的，就别用了，省着点吧。

而且这个架构经过了很多批量产品的验证，扩展性、移植性都稳的一批。

可以说，如果你自己能写出这种架构，企业对你的认可度，比你只会用RTOS高多了，因为这背后意味着你的编程功底很扎实。

也非常荣幸受到了很多老铁认可，随机截了几张图。

这个架构教程也是开放的，可以找我安排，也可以自己去看。

哈哈，不吹水了，这不是一篇GG文！！！！

回到RTOS，我个人认为，RTOS本质上，就是一个高实时性的程序架构，解决你项目程序"地基"的痛点，很多工程师没能力自己设计稳定的架构，就用这种现成的。

但是有能力的，都是习惯用自己写的架构，简单轻便，而且程序100%可控，像实时性这个问题，写程序时规避好，实时性基本和RTOS没啥区别，至少产品功能没影响，毕竟RTOS用不熟，也会埋雷的。

架构稳了，你在此基础上"搭积木"，才不会造成系统性的程序崩塌风险，这对于复杂的项目特别重要，可以说没好的架构，项目基本上很难做稳定，哪怕能做稳定，后期维护成本也巨高，比如改个功能，移植到更便宜的芯片啥的，砸键盘的心都有。

2.项目代码的模块化管理

一个成熟的架构，除了支持不同的内核和开发平台，像模块化这些，都是基本操作，我们根据不同的应用和功能创建不同的任务，这样就相当于你的项目增加了一个老板，可以很轻松地指挥哪个任务执行，什么时候执行，什么频率执行等等....

在单片机程序开发时，大多数工程师都是从while(1)死循环开始，将一堆功能代码都对接到while循环里面运行，包括我自己也是这样过来的。

以下是我10年前的代码截图，这种方式的缺点是不好控制每个任务的执行/不执行，以什么频率执行。

用专业术语来说，这种就是屎山代码。

后面随着开发经验丰富起来，不断优化架构以后，现在做项目，变成了如下代码：

咋一看，是不是以为加了RTOS系统？

其实没有，只是借鉴了系统的编程思路，把传统的while(1)结构进行了代码封装，本质还是轮询的机制。

轮询机制的弊端是，无法做到任务抢占式，就是任务插队，这样的话，对于没有经验的工程师，可能会因为某些任务代码时间过长，而影响整个系统的实时性。

如果有丰富经验，能规避掉延时高的代码，说出来你可能不信，这个架构比RTOS好用不是亿点点...

以下是我们无际单片机项目6增加了FreeRTOS后的代码：

下面以这个项目为例，给大家一一讲解下FreeRTOS功能的实际应用场景。

比如任务的抢占式调度，消息队列，内存动态分配，软件定时器....等功能。

这些功能，几乎每个都能解决某些特定应用场景的痛点，而且这些功能，我们只需要通过调用现成的API函数，就可以实现，极大减轻了工程师的负担。

二、RTOS提供的功能以及应用场景

1.任务的抢占式调度

FreeRtos的任务调度支持抢占式调度，这也是它的优势之一。

FreeRtos系统创建的每个任务都有优先级参数的配置，抢占式调度就是基于优先级来实现的，如下图，以项目6创建的4个任务为例，其中硬件处理层任务的优先级最高（优先级为5），数字越大优先级越高。 

在项目6中，对实时性要求比较高的功能代码，基本都在硬件数据采集这块，例如Lora数据收发，如果有lora门磁探测器触发了，要第一时间收集数据，然后触发主机报警，这是比较紧急的任务，因为我们项目的核心功能就是防盗报警。

硬件层还有其它，比如串口数据接收，这个是连接wifi和4G，优先级也需要高一些，当主机报警后能第一时间把数据上传到我们云平台，以及给用户拨打警示电话。

剩下的就是PWM输入定时器捕获，PWM输出等等了...

所以，这个优先级怎么去规划，一般是按照项目的功能来的，需要紧急处理的功能逻辑，往往优先级设置最高。

2.消息队列

消息队列是什么？有什么用？

消息队列主要是用来处理单片机大数据采集和处理的，比较经典的使用场景就是串口数据接收和解析。

FreeRTOS队列和我们自己架构的队列，原理都是大同小异的。

这里我们以项目6的Lora模块无线数据的接收为例，来介绍FreeRTOS消息队列的应用。

Lora模块我们接的是单片机串口。

如下截图，红色标注的是用来接收Lora接收数据消息队列的创建。

首先要按照消息队列的格式来定义消息队列的名称和大小，然后在Lora初始化程序中通过API函数创建消息队列。

创建完成后，消息队列的返回值要赋值给消息队列的句柄（句柄也就是我们定义的消息队列的名称），数据的入列和出列就是通过句柄来操作的。

消息队列创建完成之后，就是消息队列的使用，包括消息队列的入列和出列。

如下图，对应的就是Lora接收数据消息队列的入列和出列的过程。

把Lora接收到的数据入列处理截图:

Lora接收到的数据出列处理代码截图:

如果是我们无际单片机项目特训营的老铁，可能会好奇，为什么入列，出列函数的名字，和我们自己架构是一样的？

答案是为了兼容，API函数名称做了重定义，因为我们是在我们架构的基础上，改的RTOS，方便大家学完我们架构无缝过渡RTOS。

上面的截图只是说明了消息队列的过程，关于Lora数据处理的过程远比这个要复杂，文章篇幅有限，这里就不介绍了

除了Lora，还有我们OTA升级的功能，这种大数据流的，用队列也能事半功倍。

队列的本质，就是可以先把数据存起来(比如存在数组里)，等用到了再取，理解这个本质，就好抛砖引玉了。

不过要想实现这个功能，就要把数据进行一系列的算法处理，才能实现，比如说存数据和取数据，可能每次位置都不一样。

这种应用场景很多，比如任务之间的数据传递，是不是也可以？既然需求多，是不是可以写成一套模版程序呢？下次就不用重复造轮子了，所以有了入列、出列这类函数。

3.内存动态分配，提升单片机RAM的使用率

在产品开发中，我们经常会碰到一个问题，如果没有动态内存分配，那么定义的全局变量/数组只能用于有一个特定的功能，这样会导致RAM资源的浪费。

举例来说，在我们项目6网关的探测器列表界面下，要显示这个网关所有配对好的探测器，探测器数量一般是动态的，可能用户A配对了5个探测器，用户B配对了10个，用户C配对了20个.....

在具体的代码中，我们程序定义了两个静态结构体数组用来实现探测器列表的功能。

这两个静态的结构体数组占用了比较大的RAM空间，假如客户突然发神经，要求这台主机要支持配对100个探测器，这个结构体数组大小就是100，这得多吓人，光这个结构数组就把单片机的RAM用得差不多了。

我们不妨计算以下：

这里以StuDTCtemp结构体数组为例，结构体数组的元素类型Stu_DTC，通过 sizeof(Stu_DTC)计算，占用52个字节，假设最多支持20个探测器，再乘以数组元素的个数20，共1040个字节；

这1040个字节RAM空间被显示探测器列表界面长期占用，造成了ARM空间的浪费。

这里我们只计算了其中一个结构体数组，如果上图两个结构体数组占用的空间加起来更大。

而FreeRTOS提供的内存动态分配就可以很好的解决这个问题，动态内存分配是指在程序运行时，根据需要动态地分配和释放内存。这种方式可以更大限度的利用RAM空间。

应用内存动态分配，优化后的代码如下；

这样就可以实现在需要显示探测器列表的时候，申请已配对探测器需要用到的内存大小，退出当前界面的时候，释放内存。

内存动态分配可以提高RAM的使用率，但会如上图，内存动态分配需要和结构体指针配合使用，这样就会增加代码的复杂度,如果使用不当，会造成内存的泄漏、碎片化等问题。因此内存动态分配，我们主要使用在占用RAM空间比较大的变量中。

如果没有RTOS的话，就要自己手撸内存管理代码，我们就手撸过，相当痛苦，调了3天3夜。

下图是我们原来写的内存管理代码，解决了碎片化的问题，本来想在项目中加入，但是考虑到复杂程度过高，怕无际单片机项目特训营老铁学得嗷嗷叫，就放弃了。

内存分配：

内存释放：

这个源码，是有放到项目3资料包里的，特训营需要的老铁可以自己去研究。

4.时间管理和Delay延时处理

在嵌入式开发过程中，我们经常会碰到一些丧心病狂的延时需求，举个例子，LED灯每5秒快闪3次，按键消抖，单口通讯的时序控制等等....

用死循环延时函数这种方式肯定是不行的，会长时间占用CPU资源，导致无法及时响应其它任务。

为了解决这个问题，我们采取了很多方法，如使用定时器或状态机等。

尽管这些方法都能解决延时问题，但它们在可扩展性和移植性，以及规范性方面都存在很多不足，就是换一个项目不通用。

所以，FreeRTOS提供的阻塞式延时函数vTaskDelay(); vTaskDelay()就解决了这些痛点。

函数是以系统滴答（SysTick）为单位实现延时的，通常是1ms，例如vTaskDelay(1000)，就表示1000ms的延时。

什么是阻塞延时？

阻塞延时就是在延时计时过程中，单片机的CPU可以处理其他任务或代码，当计时时间到了之后，FreeRtos会自动返回任务并执行下一条指令，这种方式既节省了CPU资源，又提高了系统的响应性。

可以看以下示例，在FreeRtosTask1函数代码中，使用vTaskDelay(1000)实现LED1间隔1秒翻转，在FreeRtos实现1秒的延时过程中，CPU能够处理其他任务。

5.软件定时器功能

除了FreeRTOS提供的延时函数外，FreeRTOS也提供了软件定时器功能，通过软件定时器也可以实现上面的功能，这个跟我们自己架构的定时器矩阵功能原理差不多。

FreeRTOS软件定时器是一种纯软件实现的定时器，它利用系统的时基(通常是系统滴答中断)，来模拟定时器的功能，而不需要占用额外的硬件资源。

我们以项目6中通过软件定时器实现LED7间隔500ms翻转，来简单的了解FreeRTOS的软件定时器功能。

当然，软件定时器虽然不占用硬件定时器资源，但也有一些缺点，由于它是基于系统时基实现的，定时精度受限于系统时基的频率，无法达到硬件定时器那样的高精度。

还有软件定时器的执行需要消耗一定的CPU时间，如果定时器数量过多或者定时频率过高，可能会对系统的实时性产生影响。

以上知识列举了FreeRTOS的一些经典功能，除了以上还有信号量，任务通知，事件标志组等功能，由于篇幅有限，这就就给大家不一一列举了。

三、有哪些项目要用RTOS？

虽然RTOS功能非常强大，但并不是所有的单片机项目都适合，尤其是资源比较匮乏的51内核单片机。

FreeRTOS系统内核代码大概需要占用7-10K的Flash空间，如果单片机的Flash空闲小于64K，就不推荐使用。

其次就是RAM空间的消耗，如果要用到消息队列，内存分配，建议RAM空间在20K以上, RAM空间太小，无法发挥FreeRTOS系统的优势。

上面是从单片机硬件资源上的建议，站在项目的角度，FreeRTOS比较适合中大型项目，例如我们项目6这种，项目功能比较复杂，涉及的模块比较多，这样就可以充分的体现它的优势，包括不同模块任务的管理，任务之间消息的传递，内存的动态分配等。

在老工程师眼里，一般流传一句话："能不用RTOS，就不用"，特别是跑量的产品，代码越好理解，越简单越好。

一方面是在使用FreeRTOS系统的时候，需要有比较扎实的编程基础，包括回调函数，函数指针，结构体数组，钩子函数，临界保护等。

如果没有扎实的编程基础的话，很难游刃有余地驾驭该系统，如果开发中出现了奇怪的问题，就无法快速锁定并解决问题。