Loop Engineering：面向实时闭环系统的轻量级工程范式-开发者社区

1. 项目概述：Loop Engineering到底是什么，为什么突然火了

Loop Engineering这个词最近在技术社区、独立开发者论坛和硬件创意圈里频繁出现，但很多人点开标题后发现——没有统一定义，没有权威文档，甚至搜不到维基词条。我第一次听到它，是在某次嵌入式开发线下聚会里，一位做智能乐器的某开发者提到：“我们团队现在不叫‘固件开发’，改叫‘Loop Engineering’了。”当时桌上七八个人面面相觑，有人以为是新出的IDE插件，有人猜是某种RTOS调度模型，还有人直接掏出手机搜，结果首页全是零散的GitHub仓库名和Reddit讨论帖。

其实，“Loop Engineering”不是某个公司注册的新技术标准，也不是IEEE刚发布的协议规范。它是一种以“循环体（loop）”为第一设计单元的工程实践范式，核心思想非常朴素：把任何可重复执行、有输入输出、需稳定时序响应的系统行为，都抽象成一个独立、可配置、可观测、可组合的loop实例。这个loop可以小到一个ADC采样+滤波+阈值判断的10行C函数，也可以大到整个音频合成引擎的实时处理管线——关键不在于代码量，而在于你是否把它当作一个具备完整生命周期、状态边界和性能契约的“工程构件”来对待。

它之所以近期走热，并非因为技术本身有多新颖，而是因为现实需求倒逼出了这种表达方式。比如，现在做边缘AI设备的人越来越多，但大家很快发现：模型推理只是整个闭环里的一环，前面要接传感器数据流预处理，后面要联动执行器动作反馈，中间还得穿插自检、降频、日志上报等维护逻辑。如果还按传统“main函数+中断服务程序”的写法，代码很快变成一锅炖——哪个loop该跑多快？谁该优先抢占CPU？状态怎么跨loop同步？出问题时如何定位是A loop卡顿还是B loop丢帧？这些问题在单片机资源紧张、实时性要求苛刻的场景下，会直接决定产品能不能过量产测试。

所以Loop Engineering本质上是一套面向实时闭环系统的结构化组织方法论。它不绑定语言（C/C++/Rust/Python MicroPython都能用），不依赖特定芯片（ARM Cortex-M、ESP32、RISC-V、甚至FPGA软核都适用），也不强制框架（你可以手写调度器，也可以基于FreeRTOS任务封装，还可以用Zephyr的workqueue机制）。它的价值，体现在你写第5个类似功能模块时，不再需要从头查寄存器手册、重写延时逻辑、手动加临界区保护；而是打开你的loop模板库，选一个“带超时重试的I2C读取loop”，填入设备地址、寄存器偏移、期望值范围，再挂上失败回调——三分钟完成，且和之前写的SPI Flash擦写loop、PWM呼吸灯loop共享同一套状态机管理、统一的错误码体系和一致的调试接口。

提示：别被“Engineering”这个词吓住。它不是要你立刻去学控制理论或信号处理。Loop Engineering的入门门槛，其实比学会用Arduino IDE烧录blink程序还低——你只需要理解“while(1) { ... }”这个结构能做什么、不能做什么，以及当它开始承担真实业务逻辑时，哪些地方会悄悄失控。

适合谁看这篇？如果你正在做以下任一事情，这篇就是为你写的：

用STM32或GD32写电机驱动，但每次加个新传感器就怕主循环崩掉；
做树莓派Pico项目，发现MicroPython的time.sleep()在多任务下越来越不准；
给ESP32-C3写Wi-Fi配网流程，想让LED提示、按键扫描、AP热点管理、HTTP请求这四件事互不干扰又协同工作；
在Zephyr里配置多个k_work，但搞不清它们和k_timer、k_sem之间的调度优先级关系；
甚至只是用Python写个桌面自动化脚本，希望它能在后台持续监听剪贴板变化，同时每5秒检查一次本地文件更新，还不影响你正常操作电脑。

它解决的从来不是“能不能实现”的问题，而是“能不能长期稳定、便于修改、容易交接、快速排障”的问题。接下来，我会完全抛开概念空谈，带你从零开始，用一个真实可运行的项目——一个带物理旋钮调节、OLED实时显示、USB虚拟串口上报数据的环境温湿度监测节点——手把手拆解Loop Engineering的落地全过程。所有代码、接线图、调试技巧、踩过的坑，全部公开。你不需要提前准备任何特殊工具，一块常见的ESP32开发板（如DevKitC）、一个DHT22传感器、一个10K电位器、一块0.96寸I2C OLED屏，外加一根USB线，就能跟着做完。

2. 整体架构设计：为什么不用FreeRTOS任务，而选择自建Loop调度器

2.1 传统方案的隐性成本：任务 vs Loop的底层差异

很多初学者看到“Loop Engineering”，第一反应是：“这不就是FreeRTOS里的task吗？”表面上看确实相似：都是无限循环、都有优先级、都能挂起唤醒。但深入到内存模型、调度语义和调试支持三个层面，差异就非常显著了。

先说内存。FreeRTOS task每个实例默认分配独立栈空间（通常1KB~4KB），栈大小必须在创建时静态指定。这意味着：

如果你为DHT22读取loop分配2KB栈，但它实际只用300字节，剩下1.7KB纯属浪费；
而当你临时加一个需要解析JSON的loop（比如对接云平台），发现栈不够用，只能全局调大——结果所有其他loop的栈都跟着膨胀，RAM占用飙升；
更麻烦的是，栈溢出检测在嵌入式里极难触发：它不会报错，只会静默覆盖相邻变量，导致现象诡异（比如LED闪烁频率突变、OLED显示乱码），排查耗时数小时。

而Loop Engineering提倡的loop，本质是一个无栈协程（stackless coroutine）。它不申请独立栈，所有局部变量存放在loop结构体的heap分配内存中（或直接作为全局static变量），执行时复用主线程栈。这样带来的好处是：

内存占用精确可控：一个只做GPIO翻转的loop，结构体可能仅24字节；
动态伸缩友好：loop内部可安全调用malloc/free（只要保证不递归），无需担心栈爆；
调试信息丰富：每个loop的状态变量（如当前温度值、上次读取时间戳、重试计数）都作为结构体成员暴露，GDB或JTAG调试时可直接watch，不像task栈变量需层层展开。

再看调度语义。FreeRTOS task是抢占式调度，靠SysTick中断触发上下文切换。这带来两个硬伤：

确定性差：高优先级task一旦就绪，会立即打断当前task。对于需要严格周期执行的loop（比如10ms采样一次的ADC），你得把它的优先级设得极高，但这又可能导致低优先级task（如日志打印）长期饿死；
中断耦合深：task切换本身依赖中断，一旦关中断时间过长（比如在SPI传输中禁用所有中断），整个调度器就停摆。

Loop调度器则采用协作式轮询（cooperative polling）。所有loop注册到一个中央调度表，主循环按固定顺序依次调用每个loop的run()函数。每个loop必须在有限时间内返回（比如≤500μs），不得阻塞。这看似“原始”，实则换来三大优势：

绝对可预测：整个系统最大延迟 = 所有loop单次执行时间之和。你可以在编译时静态分析出最坏情况（Worst-Case Execution Time, WCET），这对工业控制、医疗设备至关重要；
中断解耦：loop内部可自由开关中断，不影响其他loop运行；
资源竞争简化：多个loop访问同一外设（如I2C总线）时，只需在loop结构体里加一个busy标志位，无需复杂信号量，代码行数减少一半以上。

最后是调试支持。FreeRTOS提供uxTaskGetSystemState()获取任务状态，但返回的是raw指针数组，需配合额外工具解析。而Loop Engineering天然支持“状态即数据”：每个loop结构体本身就是一份自描述的运行快照。比如下面这个温湿度loop的定义：

typedef struct { uint32_t last_read_ms; // 上次成功读取时间戳（ms） float temperature; // 当前温度（℃） float humidity; // 当前湿度（%RH） uint8_t retry_count; // 连续失败次数 bool is_valid; // 数据是否有效（防DHT22偶发乱码） } dht22_loop_t; dht22_loop_t g_dht22_loop = {0};

你在调试器里输入print g_dht22_loop，立刻看到全部关键状态，连注释都不用查。这种“所见即所得”的调试体验，在量产阶段能节省大量FA（Failure Analysis）时间。

2.2 本项目调度器设计：轻量、可配置、带健康监控

既然决定不用现成RTOS，那调度器自己写多少行合适？我的经验是：核心调度逻辑控制在100行以内，越简单越可靠。本项目采用三级结构：

基础层（core_loop.h/c）：定义loop抽象接口和调度器骨架
中间层（loop_scheduler.h/c）：实现带优先级队列、执行超时检测、健康心跳的增强调度器
应用层（app_loops.h/c）：具体业务loop的实现与注册

先看基础层最关键的loop_t结构体：

// core_loop.h typedef struct loop_s loop_t; // loop执行函数原型：返回true表示需继续调度，false表示暂停 typedef bool (*loop_run_fn)(loop_t *self); // loop销毁函数原型（用于释放动态内存） typedef void (*loop_destroy_fn)(loop_t *self); struct loop_s { const char *name; // loop名称，仅用于调试 loop_run_fn run; // 核心执行函数 loop_destroy_fn destroy; // 可选销毁函数 uint32_t period_ms; // 建议执行周期（ms），0表示不参与定时调度 uint32_t last_run_ms; // 上次执行时间戳（由调度器自动更新） uint32_t exec_time_us; // 上次执行耗时（微秒，由调度器自动统计） uint32_t max_exec_time_us; // 允许的最大执行时间（超时则告警） bool enabled; // 是否启用 void *priv; // 私有数据指针（指向具体loop结构体，如dht22_loop_t） };

这个设计刻意回避了“任务ID”“句柄”等抽象概念，所有操作基于指针。priv字段是关键——它让loop既能保持类型安全（编译期检查），又避免了C语言泛型缺失带来的void*滥用。比如DHT22 loop的初始化函数：

// dht22_loop.c loop_t* dht22_loop_create(gpio_num_t data_pin) { dht22_loop_t *inst = calloc(1, sizeof(dht22_loop_t)); if (!inst) return NULL; inst->data_pin = data_pin; // 初始化DHT22硬件... loop_t *loop = calloc(1, sizeof(loop_t)); if (!loop) { free(inst); return NULL; } loop->name = "dht22"; loop->run = dht22_loop_run; loop->destroy = dht22_loop_destroy; loop->period_ms = 2000; // 每2秒读一次 loop->max_exec_time_us = 15000; // 最多15ms，超时则记录 loop->priv = inst; // 关键：私有数据绑定 return loop; }

调度器主体逻辑（loop_scheduler_run()）只有78行，核心就三步：

遍历所有已注册loop，跳过enabled==false的；
对period_ms > 0的loop，检查millis() - last_run_ms >= period_ms，满足则执行；
执行前记录起始时间，执行后计算耗时，若超max_exec_time_us则通过串口打印告警（格式：[WARN] dht22 loop timeout: 18234us > 15000us）。

注意：这里用millis()而非SysTick，是因为ESP32的esp_timer_get_time()精度达1μs，且不依赖中断。很多教程教新手用vTaskDelay()，但那是为FreeRTOS设计的，脱离RTOS环境就失效。我们坚持“用最直白的API，解决最实际的问题”。

中间层增加了健康监控能力。每个loop可选配一个health_check_fn，由调度器每10秒统一调用一次，检查loop内部状态一致性。比如DHT22 loop的健康检查：

static bool dht22_health_check(loop_t *self) { dht22_loop_t *inst = (dht22_loop_t*)self->priv; // 规则1：连续失败超5次，强制重启DHT22 if (inst->retry_count > 5) { ESP_LOGW("DHT22", "Too many failures, resetting sensor"); dht22_reset_sensor(inst); inst->retry_count = 0; return true; // 已处理，无需告警 } // 规则2：温度值超出合理范围（-40~80℃），标记异常 if (inst->temperature < -40.0f || inst->temperature > 80.0f) { ESP_LOGE("DHT22", "Invalid temp: %.2f℃", inst->temperature); inst->is_valid = false; return false; // 未处理，触发上级告警 } return true; }

这种设计让故障恢复逻辑内聚在loop内部，而不是散落在main函数里一堆if-else判断中。当项目从3个loop扩展到12个loop时，这种内聚性带来的可维护性提升是指数级的。

3. 核心模块拆解：四个实战Loop的完整实现与交互逻辑

3.1 DHT22温湿度采集Loop：如何应对传感器的“不可靠性”

DHT22是入门级温湿度传感器，价格便宜、接线简单，但官方手册里藏着一句关键警告：“单次读取失败率约5%，建议实现重试机制”。很多教程直接忽略这点，导致成品在潮湿环境下数据断崖式丢失。Loop Engineering的解法是：把“重试”作为loop的固有属性，而非临时补丁。

我们的DHT22 loop结构体在2.2节已定义，现在看run()函数的核心逻辑：

bool dht22_loop_run(loop_t *self) { dht22_loop_t *inst = (dht22_loop_t*)self->priv; uint32_t now_ms = millis(); // 步骤1：检查是否到执行周期（2秒） if (now_ms - self->last_run_ms < self->period_ms) { return true; // 未到时间，跳过 } // 步骤2：尝试读取数据（底层调用ESP-IDF的driver/dhtxx.c） float temp, humi; esp_err_t err = dhtxx_read_data(inst->data_pin, &humi, &temp); if (err == ESP_OK) { // 成功：更新状态，重置重试计数 inst->temperature = temp; inst->humidity = humi; inst->retry_count = 0; inst->is_valid = true; inst->last_read_ms = now_ms; ESP_LOGD("DHT22", "T:%.1f℃ H:%.1f%%", temp, humi); } else { // 失败：增加重试计数，但不立即重试（避免总线冲突） inst->retry_count++; ESP_LOGW("DHT22", "Read failed (%d/%d)", inst->retry_count, DHT22_MAX_RETRY); // 若连续失败，触发健康检查（见2.2节） if (inst->retry_count >= DHT22_MAX_RETRY) { dht22_health_check(self); } } self->last_run_ms = now_ms; return true; }

这里有两个关键设计点：

不主动重试：很多代码在err != ESP_OK后立刻goto retry，这会导致I2C总线被反复拉低，反而加剧失败。我们采用“失败即记录，下次周期再试”的策略，让硬件有足够恢复时间；
重试计数与健康检查联动：DHT22_MAX_RETRY设为3，意味着连续3次失败（6秒）后，健康检查函数会被调度器调用，执行传感器复位。这种分层处理，让loop既轻量又鲁棒。

实操心得：DHT22对电源噪声极其敏感。我曾遇到一批板子在实验室稳定，到客户现场批量掉线。最终发现是客户电源适配器纹波过大（>200mVpp）。解决方案不是换传感器，而是在DHT22供电引脚并联一个10μF钽电容——成本增加0.03元，故障率从35%降至0.2%。这个细节不会写在任何SDK文档里，但它是Loop Engineering强调的“物理层认知”：loop的稳定性，永远建立在干净的电压、稳定的时钟、可靠的布线上。

3.2 旋钮调节Loop：用硬件中断+软件消抖实现毫秒级响应

项目要求用物理旋钮调节参数，常见做法是：

方案A：在主循环里用analogRead()每100ms读一次，然后映射到0~100范围；
方案B：用ADC DMA连续采样，再做滑动平均滤波。

两者都有硬伤：A响应迟钝（用户转一圈旋钮，屏幕才跳一次），B资源消耗大（DMA通道、内存缓冲区、中断服务程序）。Loop Engineering给出第三条路：中断触发+事件队列+状态机消抖。

硬件连接：旋钮中心抽头接ADC0（GPIO34），两端分别接3.3V和GND。这样旋钮转动时，ADC读数在0~4095间线性变化。

loop结构体新增字段：

typedef struct { // ...原有字段 uint16_t raw_value; // 上次ADC原始值 uint16_t smoothed_value; // 滑动平均后的值（10次采样） uint8_t debounce_counter; // 消抖计数器（0~9） uint32_t last_change_ms; // 上次有效变化时间戳 } knob_loop_t;

关键创新在run()函数的逻辑分支：

bool knob_loop_run(loop_t *self) { knob_loop_t *inst = (knob_loop_t*)self->priv; uint32_t now_ms = millis(); // 步骤1：检查是否有新ADC中断事件（由ISR放入全局队列） if (adc_event_queue_pop(&inst->event_queue, &inst->raw_value, 0)) { // 步骤2：软件消抖——连续3次读数变化<5才认为是有效旋转 int16_t diff = abs((int16_t)inst->raw_value - (int16_t)inst->smoothed_value); if (diff < 5) { inst->debounce_counter++; if (inst->debounce_counter >= 3) { // 确认有效变化，更新平滑值 inst->smoothed_value = (inst->smoothed_value * 9 + inst->raw_value) / 10; inst->last_change_ms = now_ms; inst->debounce_counter = 0; // 步骤3：通知其他loop（如OLED显示loop） knob_value_changed(inst->smoothed_value); } } else { inst->debounce_counter = 0; // 差异大，重置计数器 } } // 步骤4：超时保护——若1秒内无新事件，强制刷新显示（防死锁） if (now_ms - inst->last_change_ms > 1000) { knob_value_changed(inst->smoothed_value); inst->last_change_ms = now_ms; } return true; }

这里adc_event_queue_pop()是自定义的无锁环形队列，由ADC中断服务程序（ISR）在adc_isr_handler()里调用xQueueSendFromISR()填充。ISR里只做最轻量的事：读ADC值、存入队列、清除中断标志——整个过程<5μs，绝不在ISR里做浮点运算或调用printf。

注意：ESP32的ADC ISR默认在PRO CPU上运行，而我们的loop调度器在APP CPU上。跨核通信必须用FreeRTOS的xQueueSendFromISR()，不能用普通xQueueSend()。这是很多教程没讲清的坑，导致系统偶发死机。我们在CMakeLists.txt里显式指定CONFIG_ADC_ISR_IRAM=y，确保ISR代码常驻IRAM，避免cache miss引发的不可预测延迟。

3.3 OLED显示Loop：双缓冲机制避免画面撕裂

OLED屏用SSD1306驱动，I2C接口。常见bug是：当温湿度数据快速变化时，屏幕显示出现“半截数字”（比如温度显示“25.”，湿度显示“.6%”），这是典型的画面撕裂（tearing）——CPU正在往显存写新数据，而SSD1306的DMA控制器同时在读旧数据。

解决方案是双缓冲（double buffering）：维护两块显存（front buffer和back buffer），所有绘制操作都在back buffer进行，绘制完成后原子性地交换指针，再触发OLED刷新。

我们的OLED loop结构体：

typedef struct { uint8_t front_buffer[1024]; // SSD1306显存大小：128x64/8=1024字节 uint8_t back_buffer[1024]; uint8_t *current_buffer; // 指向当前front buffer bool buffer_dirty; // back buffer是否被修改 uint32_t last_refresh_ms; // 上次刷新时间戳 } oled_loop_t;

run()函数精简为：

bool oled_loop_run(loop_t *self) { oled_loop_t *inst = (oled_loop_t*)self->priv; uint32_t now_ms = millis(); // 步骤1：检查是否需刷新（最小间隔200ms，防频闪） if (now_ms - inst->last_refresh_ms < 200) { return true; } // 步骤2：若back buffer被修改，交换缓冲区并刷新 if (inst->buffer_dirty) { // 原子性交换指针（在单核MCU上，赋值是原子的） uint8_t *temp = inst->current_buffer; inst->current_buffer = (inst->current_buffer == inst->front_buffer) ? inst->back_buffer : inst->front_buffer; // 将current_buffer内容刷到OLED（调用ssd1306_write_buffer()） ssd1306_write_buffer(inst->current_buffer); inst->buffer_dirty = false; inst->last_refresh_ms = now_ms; } return true; }

关键点在于buffer_dirty标志位的设置时机——它由其他loop（如DHT22 loop、旋钮 loop）在更新数据后调用oled_update_temp(float t)等函数时置位。这些函数内部只操作back_buffer，绝不触碰current_buffer，彻底隔离读写。

实操心得：SSD1306的I2C写入速度是瓶颈。实测单次全屏刷新（1024字节）需约18ms。如果每帧都刷，帧率上限仅55fps，但人眼根本看不出区别。我们采用“脏矩形（dirty rectangle）”优化：只刷新变化区域。比如温度值从“25.3”变“25.4”，只需重绘最后3个像素列（12x8字体）。这将平均刷新时间从18ms降到2.3ms，帧率提升至400fps，且功耗降低60%。这个优化不改变loop接口，只在oled_update_temp()内部实现，体现了Loop Engineering的“关注点分离”哲学。

3.4 USB虚拟串口Loop：实现零拷贝日志上报

项目要求通过USB虚拟串口（CDC ACM）上报数据。常见做法是：

用printf()打日志，重定向到usb_serial_jtag；
或用uart_write_bytes()发送格式化字符串。

问题在于：printf()会分配临时栈空间，uart_write_bytes()需复制数据到UART FIFO。在高频上报场景（如每秒10次），内存碎片和CPU占用会飙升。

我们的解法是：零拷贝环形缓冲区 + 异步发送。USB CDC驱动提供usb_cdc_acm_write()函数，它接受一个const uint8_t*和长度，内部会将数据复制到USB端点缓冲区。我们要做的是：让这个const uint8_t*直接指向我们预先分配的内存块，避免二次复制。

loop结构体新增：

typedef struct { uint8_t tx_buffer[512]; // 发送缓冲区（环形队列） uint16_t tx_head; // 写入位置 uint16_t tx_tail; // 读取位置 bool tx_busy; // USB发送是否忙（避免重入） } usb_loop_t;

run()函数核心逻辑：

bool usb_loop_run(loop_t *self) { usb_loop_t *inst = (usb_loop_t*)self->priv; // 步骤1：检查USB是否就绪（CDC已枚举成功） if (!usb_cdc_acm_is_connected()) { return true; } // 步骤2：若发送缓冲区有数据且USB空闲，则发起发送 if (inst->tx_head != inst->tx_tail && !inst->tx_busy) { uint16_t len = (inst->tx_head >= inst->tx_tail) ? (inst->tx_head - inst->tx_tail) : (sizeof(inst->tx_buffer) - inst->tx_tail + inst->tx_head); // 计算本次可发送长度（不超过USB端点最大包长64字节） uint16_t send_len = MIN(len, 64); const uint8_t *src = (inst->tx_tail + send_len <= sizeof(inst->tx_buffer)) ? &inst->tx_buffer[inst->tx_tail] : &inst->tx_buffer[0]; // 异步发送（非阻塞） esp_err_t err = usb_cdc_acm_write(src, send_len, portMAX_DELAY); if (err == ESP_OK) { inst->tx_tail = (inst->tx_tail + send_len) % sizeof(inst->tx_buffer); inst->tx_busy = true; } } // 步骤3：USB发送完成中断会调用回调函数，置tx_busy=false return true; }

日志上报函数usb_log_printf()的实现：

int usb_log_printf(const char *fmt, ...) { va_list args; va_start(args, fmt); // 直接向tx_buffer写入（模拟snprintf，但不分配内存） int written = vsnprintf_ringbuf( &g_usb_loop.tx_buffer[0], sizeof(g_usb_loop.tx_buffer), &g_usb_loop.tx_head, fmt, args ); va_end(args); return written; }

vsnprintf_ringbuf()是我们封装的环形缓冲区版vsnprintf，它把格式化结果直接写入tx_buffer，并自动处理缓冲区绕回。整个过程无malloc、无栈分配、无数据复制，CPU占用率比标准printf低87%。

注意：USB CDC的usb_cdc_acm_write()是阻塞函数，但我们传入portMAX_DELAY让它等待USB端点空闲。为避免loop卡死，我们严格限制单次发送≤64字节（USB 2.0 full-speed端点最大包长），确保等待时间<1ms。这是“用确定性换简洁性”的典型Loop Engineering思维。

4. 系统集成与调试：Loop间通信、时序协调与故障注入测试

4.1 Loop间通信的三种模式：全局变量、事件总线、状态订阅

Loop之间必然需要交互。比如：旋钮调节后，OLED要刷新，USB要上报新参数。如何设计通信机制，直接影响系统可维护性。

模式1：全局变量（最简单，适合2~3个loop）
定义一个全局结构体：

typedef struct { float current_temp; float current_humi; uint16_t knob_value; } system_state_t; extern system_state_t g_system_state;

DHT22 loop更新g_system_state.current_temp，OLED loop读取它渲染。优点是零开销、易理解；缺点是耦合度高，新增loop需修改全局结构体，且无法做访问控制。

模式2：事件总线（推荐，适合4~10个loop）
实现一个轻量事件总线：

typedef enum { EVENT_KNOB_CHANGED, EVENT_TEMP_UPDATED, EVENT_OLED_REFRESHED, } event_type_t; typedef struct { event_type_t type; void *data; // 指向具体数据（如&knob_value） size_t len; // 数据长度 } event_t; // 注册事件处理器 void event_bus_register(event_type_t type, void (*handler)(const event_t*)); // 发布事件 void event_bus_post(const event_t *e);

各loop在初始化时注册自己关心的事件，DHT22 loop发布EVENT_TEMP_UPDATED，OLED和USB loop各自注册处理器。优点是松耦合、可扩展；缺点是需管理事件队列内存。

模式3：状态订阅（最灵活，适合>10个loop或复杂系统）
借鉴React的Context API，为每个状态创建订阅者列表：

typedef struct state_subscriber_s { void (*on_change)(void *state, void *user_data); void *user_data; struct state_subscriber_s *next; } state_subscriber_t; // 温度状态定义 typedef struct { float value; uint32_t timestamp; state_subscriber_t *subscribers; } temp_state_t; // 订阅温度变化 void temp_state_subscribe(temp_state_t *state, void (*on_change)(void*, void*), void *user_data);

DHT22 loop更新temp_state.value后，遍历subscribers链表调用所有回调。优点是粒度细、无事件丢失风险；缺点是内存占用稍高（每个订阅者需一个链表节点）。

本项目采用模式2（事件总线），因其在简洁性与灵活性间取得最佳平衡。事件总线实现仅43行代码，使用静态分配的环形队列（无malloc），支持16种事件类型，每个事件最大负载64字节，完全满足本项目需求。

4.2 时序协调：如何让OLED刷新不抢DHT22的I2C总线

I2C是共享总线，DHT22和OLED（SSD1306）都挂在同一组SCL/SDA上。如果DHT22 loop正在读取传感器（耗时约4ms），此时OLED loop恰好要刷新屏幕（耗时约18ms），就会发生总线冲突，导致两者都失败。

传统解法是加I2C mutex，但mutex本身有开销，且在单核MCU上可能引发优先级反转。Loop Engineering的思路是：让loop主动让出总线，而非被动等待。

我们在调度器中增加一个i2c_bus_lock标志位，由调度器统一管理：

// loop_scheduler.c static bool i2c_bus_locked = false; static loop_t *i2c_bus_owner = NULL; // loop注册时声明是否需要I2C void loop_register_i2c_dependent(loop_t *loop) { loop->requires_i2c = true; } // 调度器在run前检查 bool loop_scheduler_run() { for (int i = 0; i < loop_count; i++) { loop_t *l = loops[i]; // 若loop需要I2C，且总线被占用，则跳过本次执行 if (l->requires_i2c && i2c_bus_locked && l != i2c_bus_owner) { continue; // 主动让出，不执行 } // 若loop需要I2C且总线空闲，则锁定并执行 if (l->requires_i2c && !i2c_bus_locked) { i2c_bus_locked = true; i2c_bus_owner = l; } l->run(l); // 若loop释放了I2C（如DHT22读完），则解锁 if (l->requires_i2c && i2c_bus_owner == l) { i2c_bus_locked = false; i2c_bus_owner = NULL; } } return true; }

DHT22 loop和OLED loop都调用loop_register_i2c_dependent()注册。调度器保证：同一时刻，只有一个I2C-dependent loop在执行。由于DHT22执行快（4ms）、OLED执行慢（18ms），调度器会优先调度DHT22，等它完成后才轮到OLED，彻底避免冲突。