STM32+RTOS环境下顺序作业管理的最优设计模式问询

针对电子机械系统中A→B→C→D这类顺序依赖的耗时作业，在STM32+RTOS环境下有几种比传统单线程状态机更易维护的方案，以下是具体实现和适用场景：

1. 单线程顺序任务模式 #

把整个作业流程封装到一个独立的RTOS任务中，利用信号量/事件标志组等待每个作业的完成信号，代码逻辑线性化，完全避免switch-case的碎片化问题。

代码示例（以FreeRTOS为例）： #

#include "FreeRTOS.h"
#include "semphr.h"

// 全局信号量（可根据实际情况改为静态创建）
SemaphoreHandle_t g_startFlowSem;
SemaphoreHandle_t g_jobADoneSem;
SemaphoreHandle_t g_jobBDoneSem;
SemaphoreHandle_t g_jobCDoneSem;
SemaphoreHandle_t g_jobDDoneSem;
SemaphoreHandle_t g_flowDoneSem;

void SequentialFlowTask(void *pvParameters) {
    for (;;) {
        // 等待流程启动触发（比如外部指令、传感器信号）
        xSemaphoreTake(g_startFlowSem, portMAX_DELAY);

        // 执行作业A，等待完成
        actionA();
        xSemaphoreTake(g_jobADoneSem, portMAX_DELAY); // 由中断/回调释放信号量

        // 执行作业B，等待完成
        actionB();
        xSemaphoreTake(g_jobBDoneSem, portMAX_DELAY);

        // 执行作业C，等待完成
        actionC();
        xSemaphoreTake(g_jobCDoneSem, portMAX_DELAY);

        // 执行作业D，等待完成
        actionD();
        xSemaphoreTake(g_jobDDoneSem, portMAX_DELAY);

        // 整个流程完成，发送完成通知
        xSemaphoreGive(g_flowDoneSem);
    }
}

// 初始化信号量
void InitSemaphores(void) {
    g_startFlowSem = xSemaphoreCreateBinary();
    g_jobADoneSem = xSemaphoreCreateBinary();
    g_jobBDoneSem = xSemaphoreCreateBinary();
    g_jobCDoneSem = xSemaphoreCreateBinary();
    g_jobDDoneSem = xSemaphoreCreateBinary();
    g_flowDoneSem = xSemaphoreCreateBinary();
}

优缺点： #

• 优势：代码逻辑直观，线性结构易读易维护；资源开销小，仅占用一个任务栈。
• 局限：整个流程串行执行，若某环节异常阻塞会影响后续作业；无法单独复用单个作业（如果不需要复用则无影响）。

2. 链式任务同步模式 #

将每个作业拆分为独立的RTOS任务，通过信号量实现任务间的触发联动，每个任务只负责自身的作业逻辑，完全解耦。

代码示例： #

// 触发信号量
SemaphoreHandle_t g_triggerJobA;
SemaphoreHandle_t g_triggerJobB;
SemaphoreHandle_t g_triggerJobC;
SemaphoreHandle_t g_triggerJobD;

// 作业A任务
void JobATask(void *pvParameters) {
    for (;;) {
        xSemaphoreTake(g_triggerJobA, portMAX_DELAY);
        actionA();
        xSemaphoreTake(g_jobADoneSem, portMAX_DELAY);
        xSemaphoreGive(g_triggerJobB); // 触发作业B
    }
}

// 作业B任务
void JobBTask(void *pvParameters) {
    for (;;) {
        xSemaphoreTake(g_triggerJobB, portMAX_DELAY);
        actionB();
        xSemaphoreTake(g_jobBDoneSem, portMAX_DELAY);
        xSemaphoreGive(g_triggerJobC); // 触发作业C
    }
}

// 作业C、D任务同理...

// 启动整个流程只需触发第一个任务
void StartSequentialFlow(void) {
    xSemaphoreGive(g_triggerJobA);
}

优缺点： #

• 优势：单个作业逻辑独立，便于调试和复用；若后续需要调整作业顺序，只需修改信号量的触发关系。
• 局限：任务数量增加会占用更多RTOS资源（栈空间、TCB），但STM32中一般资源足够；整体流程的状态监控需要协调多个任务。

3. 表驱动状态机任务模式 #

保留状态机的核心逻辑，但用状态表替代switch-case，避免代码碎片化，同时利用RTOS的同步机制处理等待逻辑，兼顾灵活性和可维护性。

代码示例： #

typedef struct {
    void (*execAction)(void);       // 当前状态的执行函数
    SemaphoreHandle_t waitSem;      // 等待完成的信号量
    uint8_t nextState;              // 下一个状态索引
} StateItem;

#define STATE_IDLE 0
#define STATE_A 1
#define STATE_B 2
#define STATE_C 3
#define STATE_D 4

// 状态表，添加/修改作业只需调整此表
StateItem stateTable[] = {
    {NULL, NULL, STATE_A},          // 空闲状态，等待启动后进入STATE_A
    {actionA, g_jobADoneSem, STATE_B},
    {actionB, g_jobBDoneSem, STATE_C},
    {actionC, g_jobCDoneSem, STATE_D},
    {actionD, g_jobDDoneSem, STATE_IDLE}
};

void StateMachineTask(void *pvParameters) {
    uint8_t currentState = STATE_IDLE;
    for (;;) {
        if (currentState == STATE_IDLE) {
            // 等待流程启动
            xSemaphoreTake(g_startFlowSem, portMAX_DELAY);
        }

        // 执行当前状态的动作
        if (stateTable[currentState].execAction != NULL) {
            stateTable[currentState].execAction();
        }

        // 等待动作完成
        if (stateTable[currentState].waitSem != NULL) {
            xSemaphoreTake(stateTable[currentState].waitSem, portMAX_DELAY);
        }

        // 切换到下一个状态
        currentState = stateTable[currentState].nextState;
    }
}

优缺点： #

• 优势：状态流转逻辑集中在状态表，添加新作业只需新增一行表项，代码不会碎片化；保留了状态机的灵活性，可处理分支流程（如果后续需要）。
• 局限：需要维护状态表结构，对新手有一定学习成本。

选型建议 #

• 如果作业流程固定、逻辑简单，优先选单线程顺序任务模式，实现成本最低。
• 如果需要单独复用单个作业或后续可能调整作业组合，选链式任务同步模式。
• 如果未来可能扩展分支流程（比如某些节点根据条件跳转），选表驱动状态机任务模式。

内容的提问来源于stack exchange，提问作者HYG