RTOS 任务划分

今天看到这篇文章《嵌入式软件任务的划分的原则》，引发我产品中的设计情况，正好也提出自己的观点，做一个总结。

嵌入式应用软件任务划分的原则_Frey_Liu的博客-CSDN博客

---

任务划分的原则是什么？如何才更加合理？有没有什么模型，原则？

什么是任务？为什么有任务？ 而大象无形

任务：做一些事情

why task：规则性的做事情，可被规则，监控，方便理解

那么任务如何设计，突出当前要做什么？比如功能模块划分，为了实时性控制提高执行效率

一、实时性要求

此种设计要求，满足实时性控制为主，要计算CPU性能和执行时间，需要预研最短周期和调度时间。

借助一个工具能个分析实时性才是最主要的，如何验证当前结果满足设计要求，再根据验证结果反复修正，达到设计要求。

因此此类系统为了能够达到实时性，往往业务是简单的，如果有复杂业务，若影响控制，尽可能剥离出去。

二、复杂业务要求

任务服务的满足业务逻辑清晰，这种侧重可维护性，业务扩展性。对实时性要去较弱，所以功能模块和逻辑性是设计的重点。

这种技术难点相对低些，需要团队多人参与开发，于是co-work在代码中提现，也就出现了功能模块的划分更加注重功能代码的重用和管理。好的设计会减少开发的投入。

目前遇到的几类设计模型，可以参考和深入思考

1.通讯/接口交互

2.显示/人机交互

3.数据采集

4.可配置维护

5.业务本身的处理步骤，可能是状态机+循环：比如数据处理

6.支撑模块：OTA、日志、存储、消息机制、系统监控

因此此类系统一般需要文档辅助理解逻辑，对外有使用限时，适用条件等约束

支撑模块是设计人员要重要维护部分，要能够提出系统好坏量化的依据，提出优化点，才能将任务放心拆解到团队后co-work，更新迭代。