从硬编码到状态机：构建可维护的OLED菜单系统实战指南

在嵌入式开发中，菜单系统是用户交互的核心组件。随着项目复杂度提升，传统的if-else或switch-case实现方式很快会变得难以维护。本文将展示如何利用u8g2图形库和状态机设计模式，在FreeRTOS环境下构建一个可扩展的多级菜单系统。

1. 传统菜单系统的痛点与解决方案

大多数开发者最初实现的菜单系统都遵循相似的路径：通过一堆条件判断语句处理用户输入和界面跳转。这种实现方式在菜单项较少时勉强可用，但当菜单层级超过三级或功能增加时，代码会迅速膨胀为难以维护的"面条代码"。

典型问题包括：

• 菜单逻辑与显示逻辑高度耦合
• 新增菜单项需要修改多处条件判断
• 状态管理混乱，容易产生bug
• 缺乏统一的架构，不同开发者实现方式各异

状态机(FSM)为解决这些问题提供了优雅的方案。通过将菜单系统抽象为状态集合和状态转换规则，我们可以实现：

• 清晰的关注点分离
• 可预测的行为
• 易于扩展的结构
• 更好的代码可维护性

2. 状态机基础与菜单建模

有限状态机由三个核心要素组成：

1. 状态(States)：系统可能处于的离散情况
2. 事件(Events)：触发状态转换的输入
3. 转换(Transitions)：状态对事件的响应规则

对于OLED菜单系统，我们可以这样建模：

状态：每个菜单界面都是一个独立状态，包括：

• 主菜单
• 各级子菜单
• 设置界面
• 对话框等特殊界面

事件：用户输入事件，通常包括：

• 确认(OK)
• 左移(LEFT)
• 右移(RIGHT)
• 返回(BACK)

转换：定义事件如何改变当前状态，例如：

• 在主菜单按下OK进入选中子菜单
• 在子菜单按下BACK返回上级菜单

c复制typedef enum {
    STATE_MAIN_MENU,
    STATE_SUB_MENU_1,
    STATE_SUB_MENU_2,
    STATE_SETTINGS,
    // 更多状态...
} MenuState;

typedef enum {
    EVENT_OK,
    EVENT_LEFT,
    EVENT_RIGHT,
    EVENT_BACK
} MenuEvent;

3. 系统架构设计与实现

3.1 核心数据结构设计

良好的数据结构设计是菜单系统的基石。我们采用以下结构体表示菜单项和状态：

c复制typedef struct {
    uint8_t currentIndex;  // 当前选中项索引
    uint8_t leftIndex;     // 左键跳转索引
    uint8_t rightIndex;    // 右键跳转索引 
    uint8_t okIndex;       // 确认键跳转索引
    void (*displayFunc)(void); // 显示函数指针