STM32 程序架构
程序是否使用裸机程序要看使用环境,有高安全、高实时需要,必须使用逻辑程序;如果是多外设同时处理,或者业务逻辑复杂,考虑用多任务。
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的实时性也不是一蹴而就的,需要合理拆解任务,确认周期任务的周期性,分配优先级(或者首先根据系统特性确定优先级策略:搜一下经典的任务调度策略),任务间资源竞争关系,中断与系统的调度关系。。