RTOS 任务划分
今天看到这篇文章《嵌入式软件任务的划分的原则》,引发我产品中的设计情况,正好也提出自己的观点,做一个总结。
嵌入式应用软件任务划分的原则_Frey_Liu的博客-CSDN博客
任务划分的原则是什么?如何才更加合理?有没有什么模型,原则?
什么是任务?为什么有任务? 而大象无形
任务:做一些事情
why task:规则性的做事情,可被规则,监控,方便理解
那么任务如何设计,突出当前要做什么?比如功能模块划分,为了实时性控制提高执行效率
一、实时性要求
此种设计要求,满足实时性控制为主,要计算CPU性能和执行时间,需要预研最短周期和调度时间。
借助一个工具能个分析实时性才是最主要的,如何验证当前结果满足设计要求,再根据验证结果反复修正,达到设计要求。
因此此类系统为了能够达到实时性,往往业务是简单的,如果有复杂业务,若影响控制,尽可能剥离出去。
二、复杂业务要求
任务服务的满足业务逻辑清晰,这种侧重可维护性,业务扩展性。对实时性要去较弱,所以功能模块和逻辑性是设计的重点。
这种技术难点相对低些,需要团队多人参与开发,于是co-work在代码中提现,也就出现了功能模块的划分更加注重功能代码的重用和管理。好的设计会减少开发的投入。
目前遇到的几类设计模型,可以参考和深入思考
1.通讯/接口交互
2.显示/人机交互
3.数据采集
4.可配置维护
5.业务本身的处理步骤,可能是状态机+循环:比如数据处理
6.支撑模块:OTA、日志、存储、消息机制、系统监控
因此此类系统一般需要文档辅助理解逻辑,对外有使用限时,适用条件等约束
支撑模块是设计人员要重要维护部分,要能够提出系统好坏量化的依据,提出优化点,才能将任务放心拆解到团队后co-work,更新迭代。