现代微控制器具有相当大的性能，这使许多程序员有机会大致考虑以下方面：-“如果性能的1-5％用于操作系统维护，这是可以的。 但是我的代码将易于调试和显示！” 大量用于存储操作系统代码的非易失性（Flash）存储器和用于为每个任务分配自己的堆栈的操作性（RAM / SRAM）存储器支持了这些想法。 但是，在大多数情况下，这种想法是错误的。 在本文中，我将告诉您原因。
关于我合作的项目
在我的实践中，我经常必须与“设计师”一起工作。 我在上一篇有关
在微控制器中使用C ++的文章中详细描述了这种方法。 然后我没有告诉最重要的事情。 该“构造函数”的大多数“块”都以某种方式与实时操作系统相关联。 大多数“块”都有自己的流程（任务，就使用的FreeRTOS实时操作系统而言）。 平均而言，该项目大约有10-15个任务。 有时该值达到35-40。
哪里那么多？
这是
每个项目中遇到的任务的简短列表：
- ADC维护（每个模块都有自己的流程进行维护）；
- wdt维护（如果操作系统崩溃，该任务将不会重置它，并且设备将重新启动）；
- 使用设置页面（一个单独的流控制使用闪存的工作）；
- 维护与外界交互的协议（接口的下游，例如uart）；
然后，每种设备已经有了特定的功能，例如用于维修热敏电阻的流（从ADC测量流中接收数据并将此数据转换为温度），轮询外围设备等等。
外观简洁
尽管项目中有许多任务，但每个任务都“隐藏”在相应类的对象内（请记住，构造函数是C ++，但这也可以使用“以面向对象的风格用C编程”在C中进行模仿。）
必要 ）。 由于此“构造函数”的对象是全局的，并且FreeRTOS 9用于项目中，因此支持在用户分配的缓冲区中创建其自己的实体，因此可以在链接时控制内存的使用。 因此，从监视内存泄漏的角度来看-一切或多或少是正常的。 但是有以下细微差别：
- 需要清楚地了解每个线程需要多少堆栈。 在这种情况下：
- 必须考虑紧急情况（例如，嵌套某种行为）；
- 如果使用了标准库中的函数，那么还应该知道它们的排列方式，或者至少知道它们将消耗多少堆栈；
除此之外，似乎使用操作系统只会改善代码的逻辑并使代码更清晰。
滥用操作系统功能
当您开始忘记专门为微控制器编写的内容时，主要问题就开始了。 操作系统将其成本强加于其自身的实体（例如信号量，互斥量，队列）上。 这是
用于实现终端功能的
UART类的示例。 在中断中，接收到一个字节，然后，如果该字节通过有效输入字符通过范围，则将其与相应的替换字符一起添加到队列中（例如，'\ n'更改为序列“ \ n \ r”）。 这样做是为了确保端口可以发送（因为该端口不仅可以用作终端，还可以通过它发送日志数据）。 一方面，这确保了将尽快发送响应，并且不会干扰发送更高优先级的数据（此外，发送更高优先级的数据时，它会累积在缓冲区中，从而允许使用DMA发送响应）。 但是，从这一刻开始，您将步履维艰。 与其在队列中写入一堆，不如在UART上当前不工作的非空缓冲区以及DMA结束时正确配置中断。 这种方法需要对外围设备如何工作有清晰的了解。 但是，它将成本降低到绝对最低，从而使这种解决方案的需求为零。
忽略微控制器的硬件功能
在我的实践中，我遇到了一个项目，该项目的18个操作系统软件计时器已调整为相同的频率。 同时，微控制器中大约有10个计时器，其中仅使用了系统计时器。 为操作系统的调度程序计时。 该决定是由于不希望微控制器“与硬件相通”而解释的。 同时，为软件定时器调用的功能分配了大约10 kb的堆栈空间。 实际上，使用了大约1 kb（短）。 这是由于“所调用的库内部正在发生的事情含糊不清”。
在这种情况下，可以安全地选择TIM6（在使用stm32f4的情况下），它将生成具有给定频率的中断，并且在内部可以简单地调用所需的函数。
使用无限循环代替状态机
在单独的专栏中，我将指出一些程序员无法编写紧凑的有限状态机，而是创建一个流，其中存在无限循环，该无限循环通过从队列中获取内容来开始其工作。 有趣的是，本文介绍了如何通过语言本身来创建紧凑的有限状态机。
忽略“硬件调度程序”
许多三十二位微控制器具有经过深思熟虑的中断控制器和可定制的优先级系统。 对于stm32f4，它的名称为NVIC，并且能够将中断优先级设置为16个级别（不考虑子级别）。
我必须处理的FreeRTOS下的大多数应用程序都可以编写为状态机，该状态机在具有正确配置的优先级的中断中调用。 如果处理器返回到“正常执行”，请进入“睡眠”状态。 在这种情况下，将不需要阻止对大多数资源（变量和其他资源）的访问。 应用程序将失去额外的抽象级别。 在这种情况下-远非免费。 但是，这种方法需要为每个项目进行周密的架构规划。 在项目中，“设计者”-所有中断都具有一个优先级，实际上，为了“过滤”数据而需要中断。 然后将残s剩饭放入队列中，相应类的对象流将在此处将它们拾起。
总结
在本文中，我讨论了在微控制器项目中使用操作系统时必须面对的基本问题，还探讨了在不损失代码可读性和逻辑性的情况下可以避免使用操作系统的常见情况。