嵌入式开发中外设管理框架规划-状态机模式

前言

开发中我们最头疼的就是造轮子，那么怎么避免造轮子成本，实现高效开发降低运维成本呢？
在面向对象设计中已经给了我们答案–状态机模式，这里给出一个架构演示介绍下其中的思想。
状态机的核心是

状态（state ）：当前处于哪种状态？
事件（event ）：状态转换的触发事件是什么？
动作（action）：触发之后需要做什么动作？

使用场景

1. 周期性读取外设数据
2. 执行过程中，外设有掉线、异常、关掉、重启等功能需求
3. 甚至有可能为了特殊任务需要将设备占用的资源释放
4. 这种需求的外设很多，想降开发成本

设计思想

1. 结构划分，设备必要的几个功能就是任务状态，使用状态机思想可以将所有设备任务进行管理
2. 每个状态独立设计
3. 设备从一种状态切换成另一个工作状态时，往往需要执行多个步骤，而具体执行细节不需要命令方操心
4. 供外界控制有专用接口
5. 同时为提高兼容适配，设计中不能涉及硬件平台相关
6. 往往一个设备上不止一个设备需要如此管理，当所有设备都需要相同功能逻辑时，就需要一个框架来低成本管理它

功能规划

1. 初始化(init)

   设备第一次上电需要的初始化任务，执行硬件初始化与软件控制初始化操作

2. 反初始化(deInit)

   设备运行异常等原因，需要重新初始化，甚至是需要重新上电使用执行的反初始化操作

3. 状态n(state_n)

   设备完成预期的初始化进程，进入一个默认状态，此状态接受有限的控制命令，解析成功后，执行响应动作完成

4. 事件控制命令(event)

   有新的事件到来并不代表设备能立刻执行，需要一定的响应时间，如有必要此处采取消费者模型管理到来的事件，下发命令不应该阻塞，除非需要给予回应

5. 周期性扫描(period)

   任务周期性消费事件(event)或执行特定的周期动作，在执行重要动作时可能时阻塞的

object接口

1. 对象初始化(隐藏在默认状态里)
2. 新增状态与动作接口
3. 事件收发接口
4. 状态读取接口
5. 数据访问接口

frame接口

1. 框架初始化
2. 框架刷新接口
3. 事件收发接口
4. 设备管理接口

设计

状态设计

typedef struct __STATE_OBJECT
{

}state_t,*state_ptr;

设备对象设计(device_object)

typedef struct __DEVICE_OBJECT
{

}device_objecet_t,device_objecet_ptr;

状态机框架设计(finite_state_machine)

typedef struct __finite_state_OBJECT

{

}device_objecet_t;

本文编写中。。。