前三章我们把硬件环境搭好，ESP8266也成功连云，MQTT链路总算跑通了。当时我在测试笔记里写下"设备上线成功"，群里几个朋友跟着复现，一片欢呼。可热闹劲儿还没过，就有人开始问：传感器数据怎么组织才能让云端正确识别？断网之后要不要补报？那些采集、组包、心跳、重连的逻辑到底该写在 MCU 里还是扔给 ESP8266？说白了，大家卡在了同一个地方——MCU 的应用范围。这一章我就专门把这个事拆开聊清楚，讲明白在 STM32 + ESP8266 + 公有云 IoT 平台这套架构里，MCU 到底该管哪些活、不该管哪些活，以及边界怎么划才让项目稳定、好维护。适合正从"能连上云"走向"能用得稳"的开发者。
1. 连上云只是起点，MCU 的"责任田"才是真问题
1.1 很多 demo 只是"能连"，离"能用"还差一次职责梳理
先说我观察到的普遍现象。网上能跑通的 STM32+ESP8266 上云例程，十有八九是这么写的：main 函数里一个 while(1)，先用 AT 指令连 WiFi，再建 TCP 连接，然后把预置好的数据往串口一丢，完事。看起来一切正常，设备也确实能在云端上线。但一旦换成真实场景，问题立刻冒出来。
设备断电重启之后，云端可能要等两三分钟才显示离线——因为 MQTT 的遗嘱消息（LWT）压根没做。WiFi 抖动导致 ESP8266 断开重连的几十秒里，MCU 还在傻乎乎地按固定节奏发数据，结果 AT 缓冲区里堆满了未响应的指令，恢复后又把旧数据和新数据搅在一起。想加一个新传感器，结果发现采集、组包、发送都耦合在同一段代码里，改一处得动三处。
这些问题表面上是"代码写得乱"，本质上都是同一个根源：没有人提前定义 MCU 的应用范围。MCU 作为主控，到底要把自己的工作边界划在哪里，直接决定了系统的稳定性、可维护性和后续扩展空间。这一章就是要帮你把这张"责任划分表"在写代码之前先列清楚。
1.2 应用范围本质是任务分配表，不是越快越全越好
很多初学者有个误解，觉得"MCU 应用范围"是指 MCU 要尽可能多做事情，才显得这个主控"有能力"。我一开始也这么干过，恨不得把 JSON 解析、TLS 握手、OTA 下载全塞进 STM32，结果可想而知：RAM 报警、主循环卡顿、调试时根本分不清是网络问题还是代码问题。
正确的理解方式是：MCU 应用范围 =在整体系统里，哪些职责必须由 MCU 亲自承担，哪些可以下沉给通信模组，哪些应该上抛给云端。它是一张任务分配表，不是能力竞赛表。划得好不好，看的是每个任务是否落在了最合适的位置上。
比如"读 DHT22 温湿度传感器"这个任务，它依赖 GPIO 时序操作，必须由 MCU 在微秒级别精确控制，这就天然属于 MCU。"建立 WiFi 连接"涉及射频协议栈，你不可能在裸机 STM32 上重新实现一整套 802.11 协议栈，所以它天然属于 WiFi 模组。而"设备数据存储、历史曲线展示"这种重活，放在云端做再合适不过。
2. 拆开看：MCU 在这个系统里的三层角色
为了把应用范围讲得可操作，我把 MCU 在 STM32+ESP8266+云平台这套架构里的职责拆成三层。每一层都对应一类明确的任务，也对应不同的资源消耗和实现难度。
2.1 第一层：感知与执行，这是 MCU 天生的领地
最底层也是最不可撼动的部分，就是和传感器、执行器直接打交道的工作。读 ADC 采样电压、通过 I2C 读温湿度芯片、用 PWM 控制电机转速、翻转 GPIO 控制继电器通断，这些任务要求微秒级的时序控制，而且往往需要和外部电路实时交互。这部分不用讨论，几乎永远属于 MCU 的应用范围。
以我常用的 DHT22 为例，它的单总线协议本身就是一段精确到微秒的时序：主机拉低电平至少 18us，释放后等待传感器响应，然后按高低电平的持续时间解析 0 和 1。这种时序如果在 RTOS 里被任务调度打断，或者被高优先级中断挤掉，解析必出错。所以把它放在 MCU 的定时器中断里，用阻塞式读取或者状态机方式处理，才是稳的做法。
2.2 第二层：数据翻译，最容易低估的隐性边界
这一层是很多人没意识到的"隐性应用范围"。传感器读回来的原始数据，往往不能直接上报。DHT22 返回的是 40 位原始数据，要经过 CRC 校验、位拼接、十进制换算，才能变成 26.4℃、58%RH 这样有意义的数值。这还不算完，云平台通常要求设备上报特定格式的 JSON Payload，比如：
{ "method": "thing.event.property.post", "params": { "temperature": 26.4, "humidity": 58.2 }, "version": "1.0" }在 STM32+ESP8266 的典型 AT 透传方案里，ESP8266 只负责建立和维持 TCP 链接，它不会帮你组 JSON，更不会帮你构造 MQTT 报文。于是这些活——单位换算、均值滤波、JSON 字符串序列化、MQTT 报文帧封装——全都要落到 MCU 头上。这就是为什么很多项目"跑着跑着内存不够了"，因为开发者低估了数据翻译层带来的缓冲区和 CPU 开销。
2.3 第三层：业务决策，边界弹性最大的部分
最上层是业务逻辑，也是 MCU 应用范围里弹性最大的地方。你可以选择把所有决策都交给云端，MCU 只当"手和脚"；也可以让 MCU 具备一定的本地决策能力，比如温度超过阈值本地直接响警报，或者断网后缓存数据等恢复再补传。
这一层的划分没有标准答案，完全取决于你的应用场景。如果是室内环境监测，云端决策完全来得及，MCU 做简单的透传即可。如果是工业设备保护，要求断电或断网时本地立刻执行急停逻辑，那么本地决策就必须纳入 MCU 应用范围，而且优先级要足够高。我见过一个项目，把设备保护逻辑完全放在云端，网络抖动一次，设备就因为没有及时收到指令而处于危险状态，这就是典型的应用范围划错了层。
3. 三种 MCU 应用范围的划分方式，我为什么选了"MCU 主控 + WiFi 透传"
明确了三层角色之后，下一个问题是：具体到 STM32 + ESP8266 + 云平台，MCU 的边界到底画在哪？我整理了三种最常见的划分方式，把各自的适用场景列出来，再说说我为什么在系列教程里选了第二种。
3.1 方案 A：MCU 一体化直连云
这种方案里，MCU 不通过外挂 WiFi 模组，而是直接集成以太网控制器或者蜂窝通信能力，整个网络协议栈、MQTT 客户端、TLS 加密全部由 MCU 自己扛下来。比如一些带以太网的 MCU 或者高配蜂窝模组内嵌 OpenCPU 方案的芯片。
好处是架构简洁，数据链路短，安全可控性最强。代价是 MCU 的资源开销极大，TLS 握手要消耗大量 RAM 和 CPU 周期，代码复杂度也明显更高。对于新手阶段，我不推荐直接上这种方案，除非你的产品对数据安全、链路可靠性有硬性要求，而且你有足够的调试经验。
3.2 方案 B：MCU 主控 + 通信模组 AT 透传（本系列采用）
这是当前 STM32+ESP8266 最常见的组合方式。MCU 负责传感器采集、数据解析、业务逻辑，以及 MQTT 报文的上层封装；ESP8266 通过 AT 指令集负责 WiFi 接入、TCP 链路建立和维持。两个角色之间通过串口通信，分工清晰，隔离性好。
这个方案的 MCU 应用范围其实比很多人想象的要宽。MQTT 连接的建立、心跳 PINGREQ 的定时发送、订阅 Topic 的报文解析，这些在 ESP8266 只做透传的前提下，都需要 MCU 来实现。但也正因为如此，MCU 对整个通信过程有完全的控制权，出了问题可以自己加日志、加状态机、加断线重连策略，不像黑盒模组那样只能对着指令文档干瞪眼。
3.3 方案 C：多 MCU + 边缘网关
如果设备数量多、分布广，可以在终端用多个便宜 MCU 只做采集，然后通过 RS485、CAN 等总线汇聚到一个网关，由网关统一负责云平台接入。这种模式下，终端 MCU 的应用范围被压缩到最小，只保留采集和执行；网关承载了协议转换、数据汇聚、远程控制逻辑。
这种方案适合规模化部署，但调试链路长，架构复杂，对网关的稳定性要求很高。我建议等你在单设备方案上积累了足够经验后再考虑，否则很容易被"多了一层转发"的故障排查折磨疯。
3.4 三种模式的选型对比
| 对比维度 | 方案 A：MCU 一体化直连云 | 方案 B：MCU + WiFi AT 透传 | 方案 C：多 MCU + 边缘网关 |
|---|---|---|---|
| MCU 应用范围 | 最宽，涵盖网络协议栈 | 较宽，涵盖业务 + MQTT 上层封装 | 最窄，仅采集与执行 |
| 开发难度 | 高，需要 TCP/IP、TLS 基础 | 中等，需掌握 AT 指令和 MQTT 报文 | 较高，链路复杂 |
| 成本 | 偏高 | 适中 | 终端便宜但网关成本高 |
| 故障排查 | 难，链路状态全在 MCU 内部 | 相对容易，串口日志直接可见 | 难，故障定位要跨设备 |
| 适用场景 | 安全要求高、单点设备 | 入门学习、中小规模产品 | 工业分布式采集 |
我在系列里选方案 B，理由有三条。第一，它学习曲线最平滑——STM32 和 ESP8266 之间就是串口通信，出错时可以直接抓串口日志定位，相比方案 A 的"全黑盒"好追得多。第二，它的可扩展性好——以后想扩大 MCU 应用范围，可以逐步把缓存、本地告警、OTA 校验加进来；想缩小，也可以换支持 MQTT 的模组固件，下层代码改动很小。第三，云平台可移植性强——只要在 MCU 和模组之间定义好抽象接口，换一家云平台只需要改 Topic 和签名逻辑，传感器采集层完全不用动。
4. 实操：把 MCU 应用范围落到代码里，温湿度上报实例
理论讲完了，这一节我们用实际项目过一遍。我以 STM32F103C8T6 + DHT22 + ESP8266-01S 为例，目标是把温度和湿度每分钟上报一次到公有云 IoT 平台的属性 Topic。这套流程跑通了，你对 MCU 应用范围的感受会直观很多。
4.1 任务分配表：先把责任列清楚再写代码
动手之前，我强烈建议你先画一张像下面这样的责任划分表。这不是形式主义，而是为了避免写着写着就把所有逻辑又堆回 MCU 的 while(1) 里。
| 任务 | 承担者 | 说明 |
|---|---|---|
| DHT22 数据读取与 CRC 校验 | MCU | 微秒级时序操作，必须本地实时完成 |
| 温湿度换算与均值滤波 | MCU | 将原始位数据转为数值，并做 3 次采样取平均 |
| JSON Payload 组包 | MCU | 拼出平台要求的属性上报 JSON |
| MQTT 报文帧封装 | MCU | 构造 CONNECT、PUBLISH、PINGREQ 报文 |
| WiFi 接入与 TCP 链路 | ESP8266 | 通过 AT 指令完成，MCU 只发指令与解析响应 |
| 心跳定时与断线重连 | MCU（策略）+ ESP8266（链路） | MCU 决定何时重连，ESP8266 执行连接动作 |
| 设备数据存储与展示 | 云端 | 物模型、规则引擎、可视化面板 |
4.2 MCU 侧状态机设计
把应用范围划分清楚之后，MCU 侧代码就不是一坨顺序执行的流程了，而是一个有限状态机。我常用的状态如下：
STATE_POWER_ON 上电初始化，读取传感器并检查模组在线；STATE_WIFI_CONNECT 通过 AT+CWJAP 连接路由器；STATE_TCP_CONNECT 使用 AT+CIPSTART 建立到云平台 MQTT 端点的 TCP 连接；STATE_MQTT_CONNECT 发送 MQTT CONNECT 报文并等待 CONNACK；STATE_RUNNING 正常运行，按周期上报数据并定时发送心跳；STATE_RECONNECT 断线或异常时进入，按指数退避重新走一遍 WiFi、TCP、MQTT 流程。
这里最核心的思路是：MCU 不允许在某个状态里死等。比如发完 AT+CIPSTART 之后，如果 5 秒没收到 OK，直接进入 STATE_RECONNECT，而不是卡在串口读取那里等一辈子。现实中的网络不可靠，状态机的每一步都要带超时处理，这本身就是 MCU 应用范围内必须承担的责任。
4.3 关键代码逻辑：从数据读取到 MQTT 发布
由于篇幅限制，我不贴完整工程，只挑三段最关键的逻辑展示 MCU 的工作方式。
第一段，DHT22 读取与数据换算。重点是读取完成后立刻做 CRC 校验，校验不通过直接放弃本次采样，而不是把脏数据继续往上送：
uint8_t dht22_read_raw(uint8_t data[5]) { // 拉低总线 18us 触发，然后释放并等待响应 // 按位读取 40bit：50us 低电平后的高电平时间长短判断 0 / 1 // 读取结果按 5 字节存放到 data[0..4] } float dht22_to_temperature(uint8_t data[5]) { uint16_t raw = ((uint16_t)data[2] << 8) | data[3]; return raw * 0.1f; }第二段，构造 MQTT PUBLISH 报文。这里我不展开整个 MQTT 协议细节，只强调一点：报文里的剩余长度字段是变长的，构造时一定要先计算好，再决定是否使用长度续接字节。很多初次手搓 MQTT 报文的人都会在这一步踩坑，云端一直不响应，日志里却看不出原因。
uint16_t mqtt_build_publish(uint8_t *buf, const char *topic, const char *payload, uint16_t msg_id) { uint16_t len = 0; buf[len++] = 0x30; // PUBLISH，QoS 0 // 先在临时位置写入主题长度和主题内容 uint8_t topic_len = strlen(topic); // 注意：剩余长度字段需要按 MQTT 规范编码，超过 127 时要使用续接字节 ... return len; }第三段，通过串口把数据交给 ESP8266 透传。在透传模式下，MCU 只要收到 ESP8266 返回的 "> " 提示符，就可以直接发送原始数据，不需要每次带上 AT+CIPSEND 指令。
void send_over_transparent(const uint8_t *data, uint16_t len) { // 确保已进入透传模式（AT+CIPMODE=1，AT+CIPSEND） // 等待串口收到 "> " 后，一次性写入数据 // 数据发送完毕后，如果需要退出透传，必须发送 "+++" 且前后保持停顿 }4.4 实操中非常容易踩的四个坑
第一坑：AT 指令后的换行符。ESP8266 固件对 AT 指令结尾的 \r\n 要求很严格，有些出厂固件要求 \r\n，有些只认 \n。量产前务必先写一个小程序扫描模组固件版本，确认换行格式，不然你会看到"AT 回显正常但 CIPSEND 永远不发数据"的诡异现象。
第二坑：透传模式的退出方式。发完数据后要退出透传，正确的做法是发送三个加号"+++"，但加号前后必须各保证一段静默时间（通常 1 秒以上），否则模组会把加号当作普通数据传输。我第一次写的时候直接在发送成功后立刻调用"+++"，结果加号被原样发到了云平台，解析成了非法字符。
第三坑：心跳周期和平台限流。阿里云这类平台一般要求 MQTT 心跳周期短于保活时间的一半，比如你设置 keepalive=60s，MCU 就得每 30 秒发一次 PINGREQ。同时注意上报频率限制，有些平台单设备属性上报超过一定次数会直接踢掉连接，别在测试时用 while(1) 疯狂上报，我朋友就是这么把设备封了 5 分钟。
第四坑：断网缓存的数据没有时间戳。如果 MCU 应用范围里包含"断网缓存、恢复补传"这个职责，那么缓存记录里必须带上采集时刻的时间戳，否则云端收到补传数据时会按当前时间入库，历史曲线全乱了。这是很多人容易忽略的问题。
5. MCU 应用范围的硬边界：资源、实时性、安全性的三个"千万别"
有时候知道边界在哪，比知道边界内做什么更重要。这一节我讲讲 MCU 应用范围上的硬约束，这些约束不是代码风格问题，而是物理层面、系统层面绕不过去的坎。
5.1 资源边界：Flash 和 RAM 决定你能承担多少职责
以 STM32F103C8T6 为例，它只有 64KB Flash 和 20KB SRAM。你以为这挺大？真在工程里分配起来就会觉得捉襟见肘。我按实际项目给出一个参考分配方案：
| 内存用途 | 建议大小 | 说明 |
|---|---|---|
| MQTT 收发缓冲区 | 各 128 字节 | 用于存放 CONNECT、PUBLISH、PINGREQ |
| JSON 组包缓冲区 | 256 字节 | 属性上报 Payload，够用但有上限 |
| AT 指令响应缓冲区 | 128 字节 | 存储串口回显与响应状态码 |
| 主任务栈 | 至少 1.5KB | 如果使用 RTOS，各任务栈需单独计算 |
这里有个血泪教训：我曾在项目里为了省事，把 JSON 装配和解析全部交给 cJSON 这种动态内存库。频繁的 malloc/free 在 RAM 上产生碎片，运行两天后设备随机重启，查了一个礼拜才发现是堆碎了。后来我把 JSON 组包改为固定长度静态数组手写拼接，并把最大长度校验加死，问题彻底消失。
判断 MCU 应不应该承担某个任务，先问一句：这个任务的常驻内存和峰值内存我付不付得起？付不起就不要硬塞，把它迁移到云端或模组侧。
5.2 实时性边界：中断里只做标记，不做协议处理
MCU 作为实时控制器的优势，在于它能对硬件事件做微秒级响应。但如果你在中断服务函数里做 JSON 组包、发 AT 指令、或者调用耗时长的传感器读取，那这个实时性优势就荡然无存了。
我的原则是：中断服务函数里只做两件事——读/写硬件事务的数据，然后置一个标志位；耗时逻辑放到主循环或定时任务里根据标志位去处理。比如 DHT22 的读取时序我用定时器中断完成，但换算、滤波、组包全部放到 200ms 周期的软件定时任务里。这样才能保证 2ms 的 PWM 控制任务不被 20ms 的网络处理阻塞。
5.3 安全边界：密钥存储和 TLS 到底谁来管
很多教程把三元组（ProductKey、DeviceName、DeviceSecret）直接明晃晃地写在代码里，这放在个人学习没问题，但离产品化还差得远。MCU 应用范围里应当包含"密钥安全存储"这一项。我的做法是把密钥拆分后存储在 MCU 内部 Flash 的独立分区，并开启读保护；即便固件被导出，也难以直接提取明文密钥。
至于 TLS 加密，这个要看 ESP8266 固件能力。如果模组固件内置 TLS 支持并允许存储 CA 证书，我优先让模组承担 TLS 握手，因为 MCU 那点 RAM 和 CPU 跑 ECC 握手非常吃力。但云平台要求设备端生成 HMAC 签名作为 MQTT 密码时，这个签名计算任务会落到 MCU 身上。这是 MCU 应用范围里新增的一项"密码学轻任务"，需要额外评估 CPU 开销，实测 STM32F103 跑 HMAC-SHA256 的时间在几十毫秒级别，可接受。
5.4 自检：四个问题判断 MCU 是否"越界"
我在每次做架构评审时，都会用四个问题检查 MCU 应用范围是否合理。这里也分享给你：
- 我新加的这个逻辑，会不会在某种条件下阻塞心跳？如果可能，必须给这个逻辑加超时或降级策略。
- 我新加的缓存，最长长度有没有上限？如果不上限，RAM 一定会被拖垮。
- 断网时，这个逻辑是在空转还是在做有意义的事？空转的逻辑应该被状态机挂起。
- 如果通信模组固件升级了，我的上层代码需要改多少？如果很多，说明 MCU 和模组的边界耦合太深了。
6. 越界自查与扩展建议：从"能用"到"好用"的几条经验
6.1 划定 MCU 应用范围的三条实操原则
几年项目做下来，我把划定 MCU 应用范围的经验浓缩成三条原则，每次新项目都按这个来，基本不会出大乱子。
第一条，从最小闭环开始。第一版先让 MCU 只做采集、上传、心跳这三件事。跑通之后，再逐步把断线重连、数据缓存、本地告警、OTA 这些职责一点点加进来。不要在第一版就追求大而全，出问题你根本定位不到是哪一层的锅。
第二条，每次只扩展一个"职责"。我可以负责任地说，同时新增缓存功能和本地告警功能的那个版本，是我调试最痛苦的一版，因为两个问题交织在一起时，根本无法判断是缓存逻辑写错了，还是告警条件被错误触发。
第三条，链路状态是 MCU 的"可选项"而不是"必选项"。MCU 可以通过 AT 指令主动查询网络状态，但绝不能在 RE连接时死循环阻塞等待应答。正确的做法是：把网络异常当作"过一会儿再说"的定时任务，MCU 该采集采集、该执行执行，保存好现场数据，等链路恢复后再补传。
6.2 从 MCU 应用范围延伸出去的几个扩展方向
把边界理顺之后，你会发现后续能做的事情非常多。比如断网缓存与补传：这需要 MCU 在 Flash 里开辟一块环形缓冲区，记录带时间戳的采集数据，恢复连接后按顺序补传，同时做好容量上限管理，满了就丢弃最旧的数据。比如远程配置更新：订阅一个配置下发的 Topic，让 MCU 在运行时修改上报频率、告警阈值，不用每次烧录固件。再比如 OTA 升级：MCU 开发双分区方案，下载固件时校验签名和哈希，升级失败自动回滚。这些每一个都能单独写一整章，也都是 MCU 应用范围从"能用"走向"好用"的必经之路。
在我做过的实际项目里，把 MCU 应用范围定义清楚的团队，后续加功能、换云平台、换模组都非常顺畅；而上来就闷头写代码、不划边界的团队，基本都会在中途为"这个 bug 到底算谁的"争论不休。所以，我建议你下次拿到类似项目，先花半小时把责任划分表画出来，再开始写第一行代码。这样你后面每一个调试的夜晚，都会轻松不少。
