单片机非耦合业务逻辑框架

在小型单片机项目开发初期，由于业务逻辑相对简单，我们往往较少关注程序架构层面的设计。

然而随着项目经验的积累，开发者会逐渐意识到模块间的耦合问题：当功能迭代时，一处修改可能引发连锁反应。

此时，构建松耦合的软件架构便成为提升系统扩展性的关键。

当前的代码框架采用了一种基于全局变量的解耦设计模式。各模块函数仅依赖底层驱动接口，无需跨模块调用其他功能函数，而是通过修改特定标志位传递状态信息。系统借助时间片轮询机制，在每个调度周期内由输出函数统一解析标志位状态，据此决定执行逻辑或输出动作。

这种设计有效隔离了模块间的直接依赖，使得代码维护与功能扩展更为灵活。

松耦合设计的核心特征

1. 全局变量驱动的通信机制

通过统一的状态标识实现模块间信息交互：

• 状态控制：lock_flag 作为门锁状态标志，被解锁模块、报警模块等共同读写；
• 模式切换：mode 变量定义系统工作模式（如待机、运行、调试），供电源管理、数据采集等模块动态调用；
• 异常追踪：password_error 记录密码错误次数，联动提示音模块、锁定计时模块触发对应逻辑。

2. 任务调度的隔离性

各核心任务（如 key_proc() 按键处理、lcd_proc() 屏幕刷新、as608_proc() 指纹识别）遵循 “独立执行” 原则：

• 无交叉调用：任务间仅通过调度器分配的时间片（如 10ms / 次）轮询激活，避免函数嵌套带来的耦合风险；
• 职责单一：每个任务专注处理专属功能，如 lcd_proc() 仅负责界面渲染，不涉及其他模块的业务逻辑。

3. 中断服务的原子性

• 串口中断：各串口（UART1/2/3）中断函数独立解析接收数据，更新对应缓冲区全局变量（如 uart1_rx_buf），不介入其他模块控制；
• 定时器中断：周期性刷新系统时钟、采样间隔等基础变量（如 tick_count），与业务逻辑解耦，确保时序稳定性。

架构设计的显著优势

1. 高度模块化开发

• 并行协作：开发团队可独立调试单个模块（如单独测试指纹识别算法），无需依赖完整系统环境；
• 敏捷扩展：新增功能（如蓝牙通信模块）仅需编写独立任务函数并注册至调度器，零侵入式集成。

2. 低风险维护特性

• 修改隔离：调整 lock_flag 的逻辑判断条件时，仅需验证门锁模块，不影响 LCD 显示或串口通信功能；
• 精准调试：通过监控全局变量（如 password_error 计数），可快速定位异常状态，降低调试复杂度。

3. 嵌入式场景适配性

• 资源优化：减少函数调用栈深度，避免因嵌套调用导致的内存溢出风险，适合 RAM/ROM 受限的 MCU（如 STM32F103）；
• 简化同步：通过全局变量与时间片轮询替代复杂的锁机制或信号量，降低多任务协作的开发成本

举个实际的例子：

在我定义的门锁控制函数中，整个项目上下仅仅只有定义，和在主函数中调用两个地方引用，在其他函数中却没有被调用。那么 门锁处理函数 是在什么时候知道他需要实现函数呢？

我们可以看到在函数内部，调用了自身驱动的底层函数，他的形参告诉了这个函数什么时候使用。

所以我们只需要在其他函数内部去修改形参这个全局变量就行。

如下图是全局标志位：可以看到在多个函数内容被修改读写。

类似的处理，我们可以稍加修改，在函数内部用判断的方式来决定什么时候开什么时候关。

同理lock_flag 作为全局变量 被其他任意函数读写和修改，而lock_proc() 只需要做好判断这个标志位并且执行对应操作就行。

那什么时候执行呢，当时是开始运行这个函数的时候，那问题又来了，什么时候运行呢。

这里我使用的是时间片轮询的方式进行任务调度。

void lock_proc()  //门锁处理函数
{if(lock_flag==1){lock(1);  //开舵机}else{lock(0);  //关舵机}}

-

业务逻辑大致可以分为两个部分，但是其实没有很必要去根据这个再去分层，因为上述的逻辑框架已经很清晰

输入处理应该包含 ：

- 硬件层面的输入获取
- 输入数据的预处理（如按键消抖）
- 核心业务逻辑处理
- 状态标志位的设置

- 输出处理应该包含 ：

- 状态标志位的检查
- 简单的显示逻辑（如格式化）
- 硬件输出控制