ESP32 WiFi连接状态通知STM32指示灯

ESP32与STM32双核协同系统的深度实践：从状态感知到智能反馈

你有没有遇到过这样的场景？一个物联网设备明明已经上电，Wi-Fi也在尝试连接，但用户却只能对着黑乎乎的面板干等——不知道是没连上、密码错了，还是干脆死机了。这背后其实暴露了一个普遍问题： 网络通信和人机交互之间的断层 。

在今天的嵌入式系统中，我们越来越依赖像ESP32这样强大的Wi-Fi/BLE芯片来实现联网功能，但它真的适合直接驱动LED、蜂鸣器或者LCD屏幕吗？反过来，那些擅长实时控制的MCU（比如STM32），又是否应该被复杂的TCP/IP协议栈拖慢节奏？

答案显然是否定的。于是，“分工协作”成了最优解：让ESP32专注联网，STM32负责外设控制。听起来简单，但怎么连？怎么传？怎么确保不出错？这才是真正的挑战所在 🧩

本文将带你完整走一遍这个“双MCU协同”的工程闭环——不是停留在理论层面，而是从第一行代码、第一个电阻、每一次信号抖动开始，深入每一个细节。你会发现， 看似简单的状态指示灯背后，藏着一整套精密设计的软硬件协同机制 。

准备好了吗？咱们出发！🚀

为什么需要两个MCU？ESP32 + STM32 的黄金组合

先别急着画电路图，我们得先搞清楚：为什么要用两个处理器？

单片机的“能力边界”正在被重新定义

过去，一片MCU搞定所有事情的时代已经过去了。现在的物联网终端不仅要连Wi-Fi、处理TLS加密、跑OTA升级，还得响应按键、驱动RGB灯、读取传感器……这些任务对资源的需求完全不同：

• ESP32 强在哪里？
  它内置了完整的Wi-Fi协议栈和蓝牙模块，支持FreeRTOS，拥有丰富的SDK（如ESP-IDF），开发网络应用非常高效。更重要的是，它能自动处理AP扫描、重连、DHCP获取IP等一系列复杂流程。

• STM32 又强在哪？
  实时性强！中断响应快、外设丰富、GPIO控制精准。尤其是在工业控制或低功耗场景下，它的表现远超大多数Wi-Fi SoC。而且很多型号支持多种低功耗模式（Stop/Standby），非常适合电池供电设备。

所以你看，两者各有千秋：

✅ ESP32 = 网络专家
✅ STM32 = 控制大师

把它们组合起来，就像是给系统装上了“双大脑”🧠：一个管对外沟通，一个管内部调度。

但这引出了新问题——这两个“大脑”之间该怎么对话？

选哪种通信方式？UART vs I²C vs SPI vs CAN 全面对比

要让两个MCU协同工作，第一步就是建立可靠的通信链路。常见的选择有四种：UART、I²C、SPI 和 CAN。每种都有自己的脾气，不能随便乱用。

那么回到我们的需求：ESP32只需要告诉STM32一句话：“我现在是什么Wi-Fi状态？” 数据量极小（通常就1个字节），频率也不高（几秒一次），而且只有两个固定节点。

这种情况下， UART 是最合适的方案 。理由如下：

1. 够用就好 ：不需要高速传输，也不需要挂多个设备；
2. 开发成本低 ：ESP-IDF 和 STM32 HAL 库都原生支持，配置几行代码就能跑通；
3. 调试直观 ：可以用串口助手直接看数据，排查问题效率极高；
4. 易于扩展 ：未来如果想让STM32反向发命令给ESP32（比如重启Wi-Fi），也能轻松实现半双工通信。

当然，如果你做的是车载网关或者工厂PLC，那CAN才是王道；如果是传感器采集板，I²C更省引脚。但在我们这个“状态通知+指示灯反馈”的轻量级应用里，UART 就是那个刚刚好的选择 ⚖️

硬件怎么接？别小看一根线的设计学问

你以为UART就是TX接RX、RX接TX、再加个GND完事了吗？Too young too simple 😏

实际工程中，哪怕是一根导线，都可能成为系统不稳定的根本原因。下面我们来拆解几个关键点。

电平匹配：3.3V和5V能直接连吗？

ESP32的工作电压是3.3V，IO耐压一般不超过3.6V。而部分STM32系列（比如经典的F103）虽然标称“5V容忍”，但这指的是输入高电平时可以承受5V，不代表输出也要拉到5V！

重点来了 👇
- ✅ ESP32 TX → STM32 RX：没问题！3.3V输出能被STM32识别为高电平（VIH通常≥2.0V）
- ❌ STM32 TX → ESP32 RX：危险！如果STM32输出5V，会烧毁ESP32！

所以稳妥的做法是：
- 如果STM32也工作在3.3V，则可以直接连接；
- 如果STM32是5V系统，建议通过电平转换芯片（如TXB0108）或限流电阻+钳位二极管保护ESP32。

不过在本项目中，我们只让ESP32发送状态码，STM32只接收，因此只需单向连接即可避免风险。

物理连接推荐方案（含抗干扰设计）

+-------------+          +--------------------+
|   ESP32     |          |     STM32F407      |
|             |          |                    |
| GPIO17 (TX) |---[R=1k]---> PA3 (USART2_RX)  |
|             |          |                    |
| GND         |----------|-- GND              |
| 3.3V        |----------|-- VDD              |
+-------------+          +--------------------+

几点说明：

• 串联1kΩ电阻 ：不是为了限流，而是抑制信号反射。当两块板子距离较远或使用排线时，阻抗突变会导致边沿振铃，加个小电阻相当于“阻尼器”。
• 共地必须可靠 ：至少在一个点牢固连接，否则参考电平不一致，数据全乱套。
• 电源去耦不可少 ：每个MCU的VDD-GND之间并联一个0.1μF陶瓷电容，滤除高频噪声。
• 走线尽量短 ：尤其是数字信号线，远离DC-DC、电机等干扰源。

💡 小贴士：如果你是在面包板上做原型验证，记得用双绞线连接TX和GND，模拟差分走线效果，抗干扰能力大幅提升！

波特率设置玄学？误差计算让你心里有底

UART通信靠的是双方约定相同的波特率。但你知道吗？即使是115200这么常见的速率，不同MCU的实际输出也可能存在偏差。

以ESP32为例，它使用80MHz APB时钟来生成波特率：

$$
Divider = \frac{80\,MHz}{16 × BaudRate} = \frac{80000000}{16 × 115200} ≈ 43.40
$$

取整后divider=43，则实际波特率为：

$$
Actual\ Rate = \frac{80000000}{16 × 43} ≈ 116279\,bps
$$

相对误差为：

$$
Error = \left|\frac{116279 - 115200}{115200}\right| ≈ 0.94\%
$$

而UART通常允许±5%的误差范围（采样窗口在比特中间±半个周期内有效），所以完全OK！

再看STM32这边，假设PCLK1=72MHz：

huart2.Init.BaudRate = 115200;
HAL_UART_Init(&huart2); // HAL库自动计算BRR寄存器值

内部计算：
$$
USARTDIV = \frac{72000000}{115200} ≈ 625 → BRR = 0x271
$$

误差仅约0.15%，几乎可以忽略。

✅ 结论：只要两边都用晶振而不是RC振荡器，115200bps完全可以稳定通信。

协议怎么定？别让裸数据变成“薛定谔的包”

现在硬件通了，接下来就是软件层面的大考：如何保证数据传得准、收得稳？

直接发一个 0x01 过去行不行？理论上可以，但现实中会有各种意外：电源波动、电磁干扰、程序卡顿……导致收到的数据可能是错的、断的、甚至根本不是你要的那个。

所以我们需要一套轻量级但可靠的通信协议。

自定义帧结构设计（适用于状态通知类场景）

我们采用如下格式：

[Header][Length][Data][Checksum][Tail]

举个例子：发送“已连接”状态（0x02）

AA 01 02 A9 BB

其中 A9 = 0xAA ^ 0x01 ^ 0x02

STM32端收到后，先检查首尾是否匹配，再做XOR校验，全部通过才认为是有效帧。

这样的设计带来了三大好处：
1. 自同步能力强 ：即使一开始丢了几个字节，也能通过0xAA和0xBB重新定位帧边界；
2. 防粘包/断包 ：Tail标志明确结束位置；
3. 基础纠错能力 ：单字节错误可通过Checksum发现。

当然，如果你追求更高可靠性，也可以加上CRC8或序列号重传机制，但对于状态通知这种低频次应用，XOR已经足够健壮 ✅

ESP32端：如何监听Wi-Fi事件并发送状态码？

终于进入代码环节啦！🎉

ESP32运行在ESP-IDF环境下，其事件驱动模型是实现非阻塞状态监测的核心。

注册Wi-Fi事件回调函数（基于ESP-IDF v4.x+）

#include "esp_event.h"
#include "esp_wifi.h"
#include "esp_log.h"

static const char *TAG = "WIFI_MONITOR";

// 事件处理函数
static void wifi_event_handler(void* arg, esp_event_base_t event_base,
                               int32_t event_id, void* event_data)
{
    if (event_base == WIFI_EVENT) {
        switch(event_id) {
            case WIFI_EVENT_STA_START:
                ESP_LOGI(TAG, "WiFi station started");
                break;
            case WIFI_EVENT_STA_DISCONNECTED: {
                uint8_t reason = ((wifi_event_sta_disconnected_t*)event_data)->reason;
                ESP_LOGW(TAG, "WiFi disconnected, reason: %d", reason);
                send_wifi_status_to_stm32(0x00); // 断开
                break;
            }
        }
    } else if (event_base == IP_EVENT && event_id == IP_EVENT_STA_GOT_IP) {
        ip_event_got_ip_t* event = (ip_event_got_ip_t*) event_data;
        ESP_LOGI(TAG, "Got IP: " IPSTR, IP2STR(&event->ip_info.ip));
        send_wifi_status_to_stm32(0x01); // 已连接
    }
}

// 初始化Wi-Fi
void init_wifi_station() {
    ESP_ERROR_CHECK(esp_netif_init());
    ESP_ERROR_CHECK(esp_event_loop_create_default());
    esp_netif_create_default_wifi_sta();

    wifi_init_config_t cfg = WIFI_INIT_CONFIG_DEFAULT();
    ESP_ERROR_CHECK(esp_wifi_init(&cfg));

    // 注册事件处理器
    ESP_ERROR_CHECK(esp_event_handler_register(WIFI_EVENT, ESP_EVENT_ANY_ID, &wifi_event_handler, NULL));
    ESP_ERROR_CHECK(esp_event_handler_register(IP_EVENT, IP_EVENT_STA_GOT_IP, &wifi_event_handler, NULL));

    // 配置SSID和密码
    wifi_config_t wifi_config = {
        .sta = {
            .ssid = "Your_SSID",
            .password = "Your_Password",
        },
    };

    ESP_ERROR_CHECK(esp_wifi_set_mode(WIFI_MODE_STA));
    ESP_ERROR_CHECK(esp_wifi_set_config(WIFI_IF_STA, &wifi_config));
    ESP_ERROR_CHECK(esp_wifi_start());

    ESP_LOGI(TAG, "WiFi initialization complete, connecting...");
}

🔍 关键点解析：

• esp_event_handler_register() 是核心API，允许你在不轮询的情况下捕获Wi-Fi事件；
• WIFI_EVENT_STA_DISCONNECTED 触发时机很频繁，比如信号弱、密码错、路由器重启都会触发；
• IP_EVENT_STA_GOT_IP 才真正代表“可以上网了”，比单纯的物理连接更有意义；
• event_data 是一个 void* 指针，必须根据事件类型强制转换才能访问具体字段。

如何防止“抖动”误报？加入去抖机制太重要了！

想象一下：你的设备放在窗边，Wi-Fi信号忽强忽弱，ESP32每隔几秒就上报一次“断开→重连”。STM32那边的LED疯狂闪烁红绿交替，用户体验直接崩盘 💥

这就是典型的“事件抖动”问题。解决办法很简单：加个时间窗口过滤。

#define DEBOUNCE_DELAY_MS 2000  // 2秒去抖

static int64_t last_disconnect_time = 0;

static void wifi_event_handler(void* arg, esp_event_base_t event_base,
                               int32_t event_id, void* event_data)
{
    int64_t current_time = esp_timer_get_time() / 1000; // 当前毫秒

    if (event_base == WIFI_EVENT && event_id == WIFI_EVENT_STA_DISCONNECTED) {
        int64_t time_diff = current_time - last_disconnect_time;

        if (time_diff > DEBOUNCE_DELAY_MS) {
            ESP_LOGW(TAG, "Significant disconnection detected");
            send_wifi_status_to_stm32(0x00);
            last_disconnect_time = current_time;
        }
    }

    if (event_base == IP_EVENT && event_id == IP_EVENT_STA_GOT_IP) {
        last_disconnect_time = 0;  // 成功连上，清零计时器
        send_wifi_status_to_stm32(0x01);
    }
}

这样一来，只有间隔超过2秒的断开事件才会被上报，避免了因短暂信号波动引发的误动作。

此外，还可以优化Wi-Fi配置减少无效断开：

.wifi_config.sta.listen_interval = 3;
.wifi_config.sta.sort_method = WIFI_CONNECT_AP_BY_SIGNAL;
.wifi_config.sta.threshold.rssi = -80;

设置最小RSSI阈值，优先连接信号强的AP，进一步提升稳定性。

发送逻辑怎么做？FreeRTOS任务队列解耦更稳健

别忘了，Wi-Fi事件发生在中断上下文中，不能在里面执行耗时操作（比如UART发送）。否则会影响整个系统的实时性。

最佳实践是： 事件回调只负责“通知”，发送任务交给独立线程处理 。

QueueHandle_t wifi_status_queue;

void uart_send_task(void *pvParameters) {
    uint8_t status_code;
    while (1) {
        if (xQueueReceive(wifi_status_queue, &status_code, portMAX_DELAY) == pdTRUE) {
            uart_write_bytes(UART_NUM_2, (const char*)&status_code, 1);
            vTaskDelay(pdMS_TO_TICKS(10)); // 防止连续冲击
        }
    }
}

void send_wifi_status_to_stm32(uint8_t code) {
    xQueueSendFromISR(wifi_status_queue, &code, NULL);
}

这套“生产者-消费者”模型有几个优势：

• 解耦事件检测与通信发送；
• 支持消息排队，防止丢失；
• 可扩展性强，后续还能加入日志记录、远程上报等功能。

初始化时记得创建队列和任务：

wifi_status_queue = xQueueCreate(10, sizeof(uint8_t));
xTaskCreate(uart_send_task, "uart_tx", 1024, NULL, 10, NULL);

STM32端接收：DMA + 空闲中断 = 零拷贝高效接收

STM32这边也不能落后。如果用轮询或普通中断接收UART数据，CPU占用率会很高，尤其在长时间运行时容易出问题。

高端玩法是： DMA双缓冲 + 空闲中断（IDLE Interrupt）

// 初始化代码
huart3.Instance = USART3;
huart3.Init.BaudRate = 115200;
huart3.Init.WordLength = UART_WORDLENGTH_8B;
huart3.Init.StopBits = UART_STOPBITS_1;
huart3.Init.Parity = UART_PARITY_NONE;
huart3.AdvancedInit.AdvFeatureInit = UART_ADVFEATURE_NO_INIT;

__HAL_RCC_USART3_CLK_ENABLE();
__HAL_RCC_DMA1_CLK_ENABLE();

hdma_usart3_rx.Instance = DMA1_Stream1;
hdma_usart3_rx.Init.Request = DMA_REQUEST_USART3_RX;
hdma_usart3_rx.Init.Direction = DMA_PERIPH_TO_MEMORY;
hdma_usart3_rx.Init.PeriphInc = DMA_PINC_DISABLE;
hdma_usart3_rx.Init.MemInc = DMA_MINC_ENABLE;
hdma_usart3_rx.Init.Mode = DMA_CIRCULAR;
HAL_DMA_Init(&hdma_usart3_rx);

__HAL_LINKDMA(&huart3, hdmarx, hdma_usart3_rx);

// 启用空闲中断
__HAL_UART_ENABLE_IT(&huart3, UART_IT_IDLE);

HAL_UART_Receive_DMA(&huart3, rx_buffer, BUFFER_SIZE);

中断服务例程：

void USART3_IRQHandler(void) {
    if (__HAL_UART_GET_FLAG(&huart3, UART_FLAG_IDLE)) {
        __HAL_UART_CLEAR_IDLEFLAG(&huart3);
        HAL_UART_DMAStop(&huart3);
        uint32_t len = BUFFER_SIZE - hdma_usart3_rx.Instance->NDTR;

        parse_received_frame(rx_buffer, len);

        // 重启DMA接收
        HAL_UART_Receive_DMA(&huart3, rx_buffer, BUFFER_SIZE);
    }
}

这种方式的好处是：
- CPU几乎不参与数据搬运；
- IDLE中断自动识别一帧结束；
- 支持不定长数据接收；
- 即使波特率稍有偏差也不会丢帧。

简直是为状态通知这类低频通信量身定制的方案 🔥

指示灯怎么控？不只是亮灭，更是语言！

终于到了用户看得见的部分——灯光反馈。别小看这盏小小的LED，它是设备与人类沟通的第一界面。

RGB LED驱动：PWM调光的艺术

我们选用共阴极RGB LED，分别控制R/G/B三个通道的亮度，混合出不同颜色。

使用STM32定时器生成PWM：

TIM_HandleTypeDef htim2;

void RGB_PWM_Init(void) {
    __HAL_RCC_TIM2_CLK_ENABLE();
    __HAL_RCC_GPIOA_CLK_ENABLE();

    GPIO_InitTypeDef gpio = {0};
    gpio.Mode = GPIO_MODE_AF_PP;
    gpio.Speed = GPIO_SPEED_FREQ_LOW;
    gpio.Pin = GPIO_PIN_0 | GPIO_PIN_1 | GPIO_PIN_2;
    HAL_GPIO_Init(GPIOA, &gpio);

    htim2.Instance = TIM2;
    htim2.Init.Prescaler = 71;      // 72MHz / 72 = 1MHz
    htim2.Init.CounterMode = TIM_COUNTERMODE_UP;
    htim2.Init.Period = 999;       // 1kHz PWM
    HAL_TIM_PWM_Start(&htim2, TIM_CHANNEL_1);
    HAL_TIM_PWM_Start(&htim2, TIM_CHANNEL_2);
    HAL_TIM_PWM_Start(&htim2, TIM_CHANNEL_3);
}

然后就可以自由调节颜色了：

void set_rgb(uint16_t r, uint16_t g, uint16_t b) {
    __HAL_TIM_SET_COMPARE(&htim2, TIM_CHANNEL_1, r);
    __HAL_TIM_SET_COMPARE(&htim2, TIM_CHANNEL_2, g);
    __HAL_TIM_SET_COMPARE(&htim2, TIM_CHANNEL_3, b);
}

比如红色常亮： set_rgb(1000, 0, 0)
绿色慢闪：启动一个定时器，周期性切换0和1000……

灯光语义设计：让用户一眼看懂状态

颜色本身没有意义， 只有当它和行为绑定时，才成为一种语言 。

我们制定一套清晰的状态-灯光映射规则：

这个设计遵循几个原则：

• ✅ 绿色=正常，红色=故障，黄色=过渡 ：符合通用认知；
• ✅ 频率差异化 ：快闪表示紧急，慢闪表示提示；
• ✅ 兼顾色盲用户 ：除了颜色，还用频率辅助区分；
• ✅ 预留扩展空间 ：0xFF保留，未来可用于OTA进度显示。

最终的控制函数长这样：

void Set_LED_Pattern(uint8_t status_code) {
    switch(status_code) {
        case 0x00: set_rgb(0, 0, 800); stop_blink(); break;
        case 0x01: blink_pattern(COLOR_YELLOW, 500, 500); break;
        case 0x02: set_rgb(0, 1000, 0); stop_blink(); break;
        case 0x03: blink_pattern(COLOR_RED, 250, 250); break;
        case 0x04: alternate_pattern(COLOR_RED, COLOR_BLUE, 333); break;
        case 0x05: blink_pattern(COLOR_ORANGE, 1000, 1000); break;
        default: blink_pattern(COLOR_WHITE, 100, 100); break;
    }
}

是不是有种“呼吸感”一下子就出来了？✨

低功耗怎么搞？STM32也能休眠唤醒

如果是电池供电设备，STM32不能一直开着啊！我们需要让它在空闲时进入Stop模式，仅靠串口中断唤醒。

void Enter_Stop_Mode(void) {
    HAL_SuspendTick();
    __HAL_RCC_PWR_CLK_ENABLE();
    HAL_PWR_EnterSTOPMode(PWR_LOWPOWERREGULATOR_ON, PWR_STOPENTRY_WFI);

    // 唤醒后恢复
    SystemClock_Config();
    HAL_ResumeTick();
}

// 主循环中判断是否进入休眠
if (system_idle && !pending_uart_data) {
    Enter_Stop_Mode();
}

关键点：
- 使用 WFI 指令等待中断；
- USART接收数据会产生RXNE中断，自动唤醒；
- 唤醒后需重新配置系统时钟（HSE重新启动）；

实测功耗可降至几十μA级别，续航能力大幅提升 ⏳

系统测试怎么做？10个典型场景全覆盖

最后一步，实战检验成果！

建议搭配逻辑分析仪抓包，确认每一帧数据都能正确收发。

Python辅助调试脚本也很有用：

import serial
import time

ser = serial.Serial('/dev/ttyUSB0', 115200, timeout=1)
state_map = {0x00:"Disconnected", 0x01:"Connected", ...}

try:
    while True:
        if ser.in_waiting:
            data = ser.read(1)
            state_code = ord(data)
            print(f"[{time.strftime('%H:%M:%S')}] State: {state_code:02X} - {state_map.get(state_code)}")
except KeyboardInterrupt:
    ser.close()

工程化部署建议：从原型到产品的跨越

当你准备量产时，以下几点至关重要：

1. 固件版本管理

typedef struct {
    uint32_t magic;
    uint8_t major, minor, patch;
    uint32_t timestamp;
    uint8_t sha256[32];
} firmware_info_t;

烧录时签名，启动时校验，防止非法刷写。

2. 远程诊断接口

在ESP32上开放轻量HTTP服务：

• GET /status → 返回JSON状态
• POST /reboot → 安全重启（需Token）

3. 维护支持体系

• 提供PC端调试工具（Qt编写）
• 制定故障代码手册（如“红灯5次长闪”=Flash损坏）
• PCB预留SWD和UART调试口
• 加入看门狗防止单片机卡死
• 关键参数掉电保存（SSID、波特率等）

4. EMC预测试

特别是辐射发射（RE）和静电放电（ESD），避免在现场环境中出现莫名重启或通信失败。

写在最后：这不是终点，而是起点 🌟

看到这里，你应该已经掌握了构建一个专业级双MCU协同系统所需的核心技能。但这不仅仅是一个技术方案，更是一种思维方式：

把复杂问题拆解，让专业的人做专业的事 。

ESP32负责联网，STM32负责控制，UART作为桥梁，再加上精心设计的灯光语言——这套架构完全可以推广到智能家居中控、工业网关、医疗设备等多种场景。

下次当你看到某个设备上的LED优雅地呼吸闪烁时，不妨想想：那背后，是不是也有这样一个默默协作的“双脑系统”呢？💡

如果你正在做一个类似的项目，欢迎留言交流！我们一起把想法变成现实 ❤️