ESP32发送HTTP请求，STM32F407采集响应

ESP32与STM32F407协同实战：让Wi-Fi通信和实时控制各司其职 🚀

你有没有遇到过这样的窘境？想做个联网温控系统，主控STM32采样精度够高、控制响应也快，但一上TCP/IP协议栈，RAM直接爆掉，Wi-Fi还时不时断连。更头疼的是，网络卡一下，PID控制就失灵了——这哪是智能设备，简直是“智障”设备。

别急，这个问题其实早有成熟解法： 把网络交给擅长的人，把控制留给专业的选手 。就像乐队里不需要每个乐手都去弹钢琴一样，在嵌入式系统中，我们也完全可以搞个“分工协作”——用ESP32负责联网发HTTP请求，STM32F407专心做数据采集和实时控制。两者通过UART握手，一个管“云”，一个管“端”，各干各的，互不打扰。

听起来是不是有点像“甩锅”？但这次的“甩锅”可是工程智慧的体现！👏

为什么非得“双MCU”？单片机不行吗？

说实话，我也曾天真地尝试过在STM32F407上直接跑LWIP + FreeRTOS + HTTP客户端……结果呢？代码编译完Flash刚够用，堆栈一不小心就溢出；Wi-Fi连接时CPU占用飙到80%以上；ADC采样周期被中断打乱，温度曲线抖得像心电图……

问题出在哪？ 资源错配 。

我们来算笔账：

看到了吗？网络部分吃内存，控制部分吃实时性。而STM32F407虽然性能强，但它毕竟不是Wi-Fi原生芯片，移植WPA2加密、处理射频干扰、应对AP漫游……这些琐事会严重拖累它的实时表现。

相比之下，ESP32呢？它天生就是为Wi-Fi而生的。乐鑫给它配了专用射频模块、硬件加速的TLS引擎、成熟的Wi-Fi驱动，还有esp-idf这种“保姆级”SDK。你要做的，往往只是调个API， http_client.perform() ——搞定！

所以结论很清晰：
👉 让ESP32去做它最擅长的事：联网
👉 让STM32F407去做它最擅长的事：控制

这不是妥协，这是架构上的升维 🧠

ESP32怎么当好这个“网络代理”？

先来看个真实场景：你的设备需要每隔5秒从云端拉一次目标温度值，比如：

{
  "target_temp": 26.5,
  "mode": "heating",
  "interval_sec": 10
}

这个任务交给ESP32再合适不过。我们用Arduino框架写几行代码就能实现：

#include <WiFi.h>
#include <HTTPClient.h>

const char* ssid = "your_wifi";
const char* password = "your_password";
const char* api_url = "http://your-server.com/api/climate";

void setup() {
  Serial.begin(115200); // 这个Serial将连接STM32的USART
  delay(1000);

  WiFi.begin(ssid, password);
  while (WiFi.status() != WL_CONNECTED) {
    delay(500);
    Serial.println("📶 Connecting to WiFi...");
  }
  Serial.println("✅ WiFi Connected!");
}

void loop() {
  if (WiFi.status() == WL_CONNECTED) {
    HTTPClient http;
    http.begin(api_url);

    int code = http.GET();
    if (code > 0 && code == 200) {
      String payload = http.getString();

      // 🔥 关键操作：加标记发送给STM32
      Serial.println("[HTTP:BEGIN]");
      Serial.print(payload);
      Serial.println("[HTTP:END]");

    } else {
      Serial.printf("❌ HTTP Failed, code: %d\n", code);
    }

    http.end();
  }

  delay(5000); // 每5秒请求一次
}

看到那两个标记了吗？ [HTTP:BEGIN] 和 [HTTP:END] ——这是我们在两个MCU之间约定的“暗号”。STM32只要监听串口，抓到这两个边界，就知道一段完整的HTTP响应来了。

💡 小技巧 ：别用换行符 \n 作为唯一分隔符！万一JSON里带了 \n （比如日志字段），你就解析错了。定界符一定要 唯一且不易冲突 。

STM32F407如何优雅接收并解析？

现在轮到STM32登场了。它的任务可不止是“读串口”这么简单，而是要在不影响控制逻辑的前提下， 零负担地接收、识别、提取、应用 来自ESP32的数据。

硬件配置建议

• 使用 USART1 （APB2总线，最高支持10.5Mbps）
• 波特率设为 115200 或 230400
• 启用 RX DMA通道 + IDLE Line Detection中断

为啥要用DMA？因为如果你用轮询或普通中断接收，每来一个字节就进一次ISR，频率太高会严重影响主控性能。而DMA+IDLE的方式，可以让STM32“躺平等待”——直到一整包数据传完，总线安静下来，才触发一次中断，一口气把所有数据搬走。

这才是真正的“低功耗+高性能”组合拳 💪

HAL库实现示例（精简版）

#include "main.h"
#include <string.h>
#include <stdlib.h>

UART_HandleTypeDef huart1;
DMA_HandleTypeDef hdma_usart1_rx;

uint8_t uart_rx_buf[256];
volatile uint16_t uart_rx_len = 0;
volatile uint8_t rx_complete = 0;

// IDLE中断服务函数（需在stm32f4xx_it.c中注册）
void USART1_IRQHandler(void) {
    if (__HAL_UART_GET_FLAG(&huart1, UART_FLAG_IDLE)) {
        __HAL_UART_CLEAR_IDLEFLAG(&huart1);

        // 停止DMA，计算实际接收长度
        HAL_UART_DMAStop(&huart1);
        uart_rx_len = 256 - ((DMA_Stream_TypeDef*)huart1.hdmarx->Instance)->NDTR;

        rx_complete = 1; // 标记接收完成

        // 重启DMA接收
        HAL_UART_Receive_DMA(&huart1, uart_rx_buf, 256);
    }
    HAL_UART_IRQHandler(&huart1);
}

// 主循环中处理数据
int main(void) {
    HAL_Init();
    SystemClock_Config();
    MX_GPIO_Init();
    MX_USART1_UART_Init();
    MX_DMA_Init();

    // 启动DMA循环接收
    HAL_UART_Receive_DMA(&huart1, uart_rx_buf, 256);

    float target_temp = 25.0f; // 默认值

    while (1) {
        if (rx_complete) {
            rx_complete = 0;

            // 查找 [HTTP:BEGIN] 和 [HTTP:END]
            char* start = strstr((char*)uart_rx_buf, "[HTTP:BEGIN]");
            char* end   = strstr((char*)uart_rx_buf, "[HTTP:END]");

            if (start && end) {
                *(end) = '\0'; // 截断结尾
                parse_http_response(start + 11); // 跳过标记
            }

            memset(uart_rx_buf, 0, sizeof(uart_rx_buf));
        }

        // ✅ 此处可安全执行ADC/PID等任务，不受网络影响
        run_temperature_control(target_temp);

        HAL_Delay(10);
    }
}

注意到没有？整个过程中， 主循环几乎没被干扰 。DMA默默搬运数据，IDLE中断只在整包到达后才唤醒CPU一次。这种设计下，即使ESP32每秒发几次HTTP响应，STM32依然能保持稳定的1ms控制周期。

JSON解析：轻量才是王道 ⚖️

你说，能不能直接上cJSON？当然可以。但我要问一句：你真的需要吗？

考虑这样一个响应：

{"t":26.5,"m":1,"i":10}

才20多个字节，字段明确，结构固定。这时候引入cJSON，等于为了开瓶啤酒专门买个电动起子——太重了！

我更推荐这种“极简派”做法：

float extract_float_value(const char* json, const char* key) {
    char pattern[16];
    sprintf(pattern, "\"%s\":", key);

    const char* pos = strstr(json, pattern);
    if (pos) {
        return strtof(pos + strlen(pattern), NULL);
    }
    return NAN;
}

// 使用方式
void parse_http_response(char* json) {
    float t = extract_float_value(json, "t");
    int   m = (int)extract_float_value(json, "m"); // 强制转int
    int   i = (int)extract_float_value(json, "i");

    if (!isnan(t)) {
        set_target_temperature(t);
    }
}

✅ 优点：代码不到50行，RAM占用<1KB，执行速度快
❌ 缺点：不支持嵌套对象、数组等复杂结构

但话说回来， 物联网边缘设备真的需要解析复杂JSON吗？ 大多数时候，你只需要几个关键参数而已。保持简单，才能稳定。

当然，如果你的应用确实要处理复杂数据（比如OTA固件信息、多传感器配置），那再引入cJSON也不迟。记住： 功能按需引入，绝不提前过度设计 。

实际工程中的那些“坑”，我们都踩过了 😅

这套架构看着美好，但在真实项目中，还是会遇到不少“意料之外”的问题。下面这几个，都是我和团队亲手踩过的雷👇

1. “粘包”问题：两个响应粘在一起了！

现象：某次重启后，STM32收到的数据是这样的：

[HTTP:BEGIN]{"t":26.5}[HTTP:END][HTTP:BEGIN]{"t":27.0}[HTTP:END]

本来应该两次独立处理的响应，变成了一大坨。如果只找第一个 [HTTP:END] ，后面的就被丢弃了。

🔧 解决方案：
- 在解析完一段后，继续检查后面是否还有未处理的 [HTTP:BEGIN]
- 或者干脆改成“长度前缀”协议：

LEN:89\r\n[HTTP:BEGIN]{"t":26.5}...[HTTP:END]\r\n

这样STM32可以根据长度精确截取每一帧。

2. ESP32死机了，STM32怎么办？

网络异常、看门狗未喂、内存泄漏……ESP32挂了，STM32还在傻等新数据，结果温度失控。

🔧 解决方案：心跳机制 + 超时降级

// STM32侧维护一个时间戳
uint32_t last_update_ms = 0;

if (new_data_received) {
    last_update_ms = HAL_GetTick();
}

// 主循环检查是否超时
if (HAL_GetTick() - last_update_ms > 15000) { // 超过15秒无更新
    enter_safe_mode(); // 切换到本地默认设定
}

这样即使Wi-Fi断了半小时，设备也不会“自焚”。

3. 数据校验不能少！

UART传输虽短距离，但也可能出错。尤其是工业现场有电机启停时，电磁干扰会让某些位翻转。

🔧 加个CRC16吧，很简单：

ESP32发送前：

uint16_t crc = calc_crc16(payload.c_str(), payload.length());
Serial.printf("[HTTP:BEGIN]%s|CRC:%04X[HTTP:END]", payload.c_str(), crc);

STM32接收后验证：

if (!verify_crc(received_json, received_crc)) {
    Serial.println("⚠️ CRC mismatch, discard packet");
    return;
}

别小看这一行校验，关键时刻能避免一次产品召回 🛡️

性能实测：到底省了多少资源？

我们做过一组对比测试，在相同功能下：

看到差距了吗？双MCU不仅性能更好，开发也更快。因为你可以 并行开发 ：一个人调ESP32的Wi-Fi，另一个人写STM32的控制算法，最后串起来就行。

更进一步：不只是HTTP，还能玩出什么花样？

你以为这就完了？No no no～ 这套架构的扩展性非常强，稍作升级就能支持更多高级功能：

✅ 支持HTTPS加密

ESP32内置mbedTLS，只需几行代码开启SSL验证：

http.setCACert(root_ca); // 预置证书
http.begin("https://api.yoursite.com/data");

敏感数据再也不怕中间人攻击。

✅ MQTT长连接替代轮询

比起HTTP GET，MQTT更适合实时推送：

// ESP32连接MQTT Broker
client.onMessage([](String &topic, String &payload){
    Serial.printf("[MQTT]%s:%s\n", topic.c_str(), payload.c_str());
});

STM32也能及时收到“立即降温”这类紧急指令。

✅ OTA远程升级

固件更新由ESP32统一处理：

// 接收新固件并通过UART转发给STM32
Serial.write(firmware_chunk, len);
// STM32进入bootloader模式接收写入Flash

一套系统，两地升级，运维成本直线下降。

最后一点思考：什么时候该用，什么时候不该用？

任何技术都有适用边界。这套“双MCU”方案也不是银弹。我总结了一个决策树帮你判断👇

🟢 推荐使用场景 ：
- 需要稳定Wi-Fi连接的工业设备
- 对实时性要求高的运动控制、电力电子
- 已有成熟STM32控制代码，只想加个联网功能
- 产品需要长期维护，希望降低后期风险

🔴 不建议使用场景 ：
- 成本极度敏感的小家电（如插座、灯泡）
- 数据量极小、更新频率很低的应用（如每日天气播报）
- 已有ESP32直驱传感器的能力（比如DHT11）

一句话总结： 当你发现“联网”开始影响“控制”时，就是时候拆开了 。

这套ESP32 + STM32F407的组合拳，我们已经在智能充电桩、医疗透析机、农业温室控制器等多个项目中落地验证。它不像某些“炫技方案”那样花哨，但却足够稳健、足够灵活、足够扛得住工厂里的各种意外。

毕竟，最好的技术不是最复杂的，而是 能在关键时刻不掉链子的那个 。🛠️

你觉得呢？你们的项目里，有没有类似的“职责分离”实践？欢迎留言聊聊 👇💬