在小型单片机项目开发初期，由于业务逻辑相对简单，我们往往较少关注程序架构层面的设计。
然而随着项目经验的积累，开发者会逐渐意识到模块间的耦合问题：当功能迭代时，一处修改可能引发连锁反应。
此时，构建松耦合的软件架构便成为提升系统扩展性的关键。
当前的代码框架采用了一种基于全局变量的解耦设计模式。各模块函数仅依赖底层驱动接口，无需跨模块调用其他功能函数，而是通过修改特定标志位传递状态信息。系统借助时间片轮询机制，在每个调度周期内由输出函数统一解析标志位状态，据此决定执行逻辑或输出动作。
这种设计有效隔离了模块间的直接依赖，使得代码维护与功能扩展更为灵活。
松耦合设计的核心特征
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); //关舵机}}
-
业务逻辑大致可以分为两个部分，但是其实没有很必要去根据这个再去分层，因为上述的逻辑框架已经很清晰
输入处理应该包含 ：- 硬件层面的输入获取
- 输入数据的预处理（如按键消抖）
- 核心业务逻辑处理
- 状态标志位的设置
- 输出处理应该包含 ：- 状态标志位的检查
- 简单的显示逻辑（如格式化）
- 硬件输出控制
