程序是否使用裸机程序要看使用环境，有高安全、高实时需要，必须使用裸机程序；如果是多外设同时处理，或者业务逻辑复杂，考虑用多任务。

os用在单片机上那个只能叫调度，逻辑你还是得写吧，单片机的程序更重要的是逻辑框架的设计，不要和我提os，os只是一种任务调度的方式，不同的产品逻辑框架是不一样的。rtthread命名就比rtos实在。

裸机架构现在比较成熟的有两个：

  • Event-driven finite-state machine，事件驱动的有限状态机。
  • 基于定时器的调度器。

FSM(有限状态机)：把每个任务拆解成n个小步骤，每个小步骤保证快进快出，确保不阻塞其他任务；main loop里就是调用每个任务的状态机。 配合中断和状态机搞前后台。中断函数必须保证快进快出。绝对不能进行io (简单的操作gpio不算)或者耗时操作 。

STM32 根本不适合上系统。单核芯片，所谓多任务，只是用协程和轮询搞的障眼法，根本不是真的并行运算。

同一时间只能执行一个Task，还要忙着来回切任务，归根结底还是只有一个核心干活儿，既管算，又管切，负担不仅没少，反而更重了。

上系统用ESP32，双核的。一个管算，一个管切。

看门狗定时器的作用：在不违反“功能安全的前提下”，使用复位强行修正程序运行bug，效果立竿见影但适用范围较小。（有bug最好还是需要通过调试和测试，从根源上解决问题）

用rtos主要不是因为业务复杂，是因为提供了丰富的功能，减少代码开发成本。特别是对于菜鸟来说，用官方移植好的rtos工程来开发，可以省很多事。rtos都经过了大量的测试，bug基本就是出在业务逻辑中。

对于一个需求明确的项目，如果你使用裸机实现比较困难的话，那么往往使用各种框架或RTOS来实现，也是依然困难的。无论是裸机还是现成框架或者RTOS，哪种方法来实现你的项目，你都要对项目进行1.功能划分；2.各个功能之间如果有联动，就会有信号传递；3.各种耦合的解耦；4.资源的占用和释放（比如串口收发）；

5.输入输出的合理采集、控制；

6.各个功能模块之间的“调度”（借用RTOS的概念来总结。也就是意味着哪怕是裸机也会有简单的调度）

仓促这么总结，一般项目大体如是，有遗漏也有可能，可以留言提醒。

当这些事情做好，你会发现，无论是裸机还是RTOS，都要遵循你的这些顶层设计。

其中裸机就需要自己来做调度，自己做资源管理，自己做信号量的收发控制，特点是灵活完全可控，代价是容易自己搞出各种坑；

而RTOS提供给性能优秀的调度、资源管理、信号收发机制，代价就是你必须按照RTOS的规范来使用他们，如果使用方式不合理，也会出各种坑。

死机不一定是OS造成的，原因千差万别，可能是软件逻辑BUG，可能是资源使用不当，可能是硬件瞬态造成的。你们有检查到死机的时候，是什么原因造成的吗？ 先定位什么原因造成的死机，才好针对性做出整改。我总结死机主要分成下面4大类：程序跑到未定义区域，可以通过PC指针查看出来；程序卡死在某个死循环；卡在中断/陷阱，无限进中断/陷阱；供电不正常，程序无法自测，通过测量供电、Reset等判断；对操作系统，还有MCU，硬件环境的理解和使用，都涉及到系统的稳定性。如果说稳定的系统，简单的比较稳定，比如汽车电子产品里面，经常用到的最简单、最基本的定时任务查询系统，不过如果你们业务比较复杂的话，就需要精心设计才行。至于第三方OS，不是一股脑使用或者不使用，而是需要根据具体公式团队情况、项目情况、开发人员情况，来决定的。如果做的项目功能，特别是人机交互这块不是很复杂，追求简单、稳定，几个人就可以胜任情况下，完全可以裸机开发。如果人机交互较多，业务系统复杂，团队人员不稳定，还是用系统会比较合适些，因为新人进来不了解你们现有的系统，会有很大的学习成本。

首先，概括的说一句：现在基于mcu的这些rtos

其实和我们说的裸机并无差别，无差别意思是它们都是对硬件cpu时间片的有效利用，以满足系统任务的（或功能函数）执行调度需求。而说差别只不过是形态上的差别，rtos系统使用异常中断，堆栈，队列等硬的、软的机制、资源，以增加复杂度为代价实现了cpu时间片的分配，任务的分割与同步。

但是rtos再完美，他还是有掣肘的，限制它的就是脱离不了同为前后台硬件架构的这种硬件执行模式，好多系统出现bug原因包括但不限于以下两种：一是系统复杂度引入冲突，二是丢掉裸机前后台思维理念，损害了cpu执行层面要求。相反，裸机的好处在这里就显现出来了——赤裸裸享用硬件的前后台模式，思想开放切完全匹配cpu前后台的执行机制：前台中断做周期的状态刷新，实时的事件捕获，关键的硬实时的异步执行；后台superloop根据标志和状态（包括周期性或逻辑性符合）按需执行。

其实，实时系统的实时性是我们编程的强约束要求，所以一般好钢用在刀刃上，前后台裸系统用好的前提就是分析系统性能的实时性要求，因为他不能抢占（唯一的异步抢占就是中断了，但又不能太费，中断原则就是快进快出），所以更要把功能模块分类分级，周期性的任务分赛道。不是所有任务都要很快执行，也不是都要排队一个不差的轮调公平执行，而是按需求执行：数码管动态刷新50hz就很ok了，无刷电机pid调整率需要20k级别，大型锅炉温度按照最快变化曲线和精确度确定（大几秒就可以啦）。确认了模块执行频率，第二步评估执行时间，然后可以得出各模块cpu占用清单：频率，时间，此时算得cpu占用率，而各个模块总的占用率低于69%以下为好。（有文献可查）

最后，rtos的实时性也不是一蹴而就的，需要合理拆解任务，确认周期任务的周期性，分配优先级（或者首先根据系统特性确定优先级策略：搜一下经典的任务调度策略），任务间资源竞争关系，中断与系统的调度关系。。