4、MCU选型与资源规划：主流MCU（STM32/ESP32）对比、Flash/RAM需求估算、外设资源分配
好，咱们进入第四讲。这一章很实在，直接关系到你板子能不能跑起来、OTA能不能稳住。
选MCU这事儿，说白了就是一场「资源博弈」。Flash够不够？RAM会不会爆？外设引脚有没有被OTA流程抢走？我见过太多项目，前期拍脑袋选了芯片，后期发现Flash差几KB，硬生生砍功能。嗯，咱们今天就把这笔账算清楚。
4.1 主流MCU对比：STM32 vs ESP32
目前HVAC固件升级领域，这两家是绝对主力。我个人习惯把STM32看作「稳重型选手」，ESP32则是「集成型选手」。怎么选？看场景。
| 对比维度 | STM32（以F4/H7系列为例） | ESP32（以ESP32-S3为例） |
|---|---|---|
| 内核 | Cortex-M4/M7，单核为主 | Xtensa LX7，双核 |
| 主频 | 168MHz ~ 480MHz | 240MHz |
| Flash | 512KB ~ 2MB（内置） | 384KB ~ 16MB（外挂SPI Flash） |
| RAM | 192KB ~ 1MB（SRAM） | 512KB（SRAM）+ 外挂PSRAM |
| WiFi/BLE | 需外挂模组 | 内置双模 |
| OTA方案成熟度 | 需自行移植（如基于YModem或HTTP） | 官方ESP-IDF自带OTA组件 |
| 功耗 | 低功耗模式丰富，适合电池供电 | WiFi开启时功耗较高 |
| 成本（批量） | 中高（尤其H7系列） | 中低（集成度高） |
我的建议：
- 如果你做的是分体式空调内机，需要低功耗、高可靠性，且WiFi模块外挂——选STM32。
- 如果你做的是智能温控器，需要WiFi直连、快速原型验证——选ESP32。
我在项目中遇到过一件事：某款商用空调控制器，原方案用STM32F407，Flash 1MB。后来客户要求增加OTA断点续传和双备份，Flash直接飙到1.6MB。最后只能换F429，板子重做，工期延误两周。你想想看，如果一开始就按1.5MB估算，是不是省事很多？
4.2 Flash/RAM需求估算——这笔账必须算细
很多新手问：「我该选多大Flash？」我的回答永远是：先算，再选。
咱们以一套典型的HVAC OTA固件为例，拆开来看：
4.2.1 Flash占用估算
| 模块 | 典型大小（KB） | 说明 |
|---|---|---|
| Bootloader | 16 ~ 32 | 包含Flash擦写、校验、跳转逻辑 |
| RTOS内核（FreeRTOS） | 8 ~ 12 | 任务调度、队列、信号量 |
| 应用主逻辑 | 80 ~ 150 | 温度控制、风机、阀件逻辑 |
| 通信协议栈 | 30 ~ 60 | Modbus、MQTT、HTTP Client |
| OTA升级模块 | 20 ~ 40 | 下载、校验、解压、回滚 |
| 参数存储区 | 4 ~ 8 | EEPROM模拟、校准参数 |
| 合计（应用区） | 158 ~ 302 | |
| OTA备份区（双备份） | 158 ~ 302 | 与主应用区大小相同 |
| 总计需求 | 316 ~ 604 | 不含Bootloader |
⚠️ 注意： 以上是「裸奔」估算。如果你用了LVGL图形库、TLS加密、OTA压缩包解压缓冲区，Flash需求会再增加100~300KB。我曾经有个项目，就是因为没算TLS证书存储，最后硬挤了8KB出来，代码写得跟杂技似的。
4.2.2 RAM需求估算
| 模块 | 典型大小（KB） | 说明 |
|---|---|---|
| RTOS任务栈（5~8个任务） | 20 ~ 40 | 每个任务栈2~8KB |
| 全局变量/静态缓冲区 | 10 ~ 20 | 传感器数据、状态机 |
| 通信缓冲区 | 8 ~ 16 | Modbus帧、MQTT消息 |
| OTA下载缓冲区 | 4 ~ 16 | 通常为1个Flash扇区大小 |
| 堆（Heap） | 16 ~ 32 | 动态分配，如JSON解析 |
| 合计 | 58 ~ 124 |
你看，RAM需求其实相对可控。但这里有个坑：OTA下载缓冲区。如果你用ESP32，WiFi接收数据是一帧一帧来的，缓冲区设太小会丢包；设太大，RAM直接爆。我一般设8KB，配合流式写入Flash，刚好够用。
💡 避坑指南： 我曾经在STM32F103上做OTA，RAM只有64KB。为了省RAM，我把OTA缓冲区压缩到2KB，结果每次写入Flash前都要等擦除完成，下载速度慢得像蜗牛。后来换成4KB缓冲区，配合双缓冲机制，速度提升3倍。记住：缓冲区大小 = Flash扇区大小的整数倍，否则会有对齐问题。
4.3 外设资源分配——别让OTA抢了你的引脚
选完芯片、算完资源，接下来就是「分地盘」。外设引脚是有限的，OTA功能会占用哪些资源？我列个清单：
4.3.1 OTA必备外设
- SPI Flash接口（如果外挂）：至少需要CS、SCK、MOSI、MISO四根线。ESP32常用，STM32如果内置Flash够大可以省掉。
- UART：用于调试日志输出，OTA过程中打印进度。我习惯用UART1，波特率115200。
- 定时器：OTA超时检测、下载进度计时。一个通用定时器就够了。
- 看门狗（IWDG）：OTA过程中防止死机。注意：在擦写Flash时要适时喂狗，否则会复位。
4.3.2 OTA可选外设
- 以太网MAC+PHY：商用空调常用，比WiFi稳定。占用RMII接口，约9个引脚。
- SDIO：如果OTA固件包先下载到SD卡再刷写，需要SDIO接口。占用6个引脚。
- USB OTG：用于本地固件升级（U盘模式）。占用D+/D-两个引脚。
4.3.3 引脚冲突典型案例
我遇到过最头疼的事：某项目用STM32F407，SPI1被LCD占用，SPI2被WiFi模块占用，SPI3被预留。结果OTA需要外挂Flash，没SPI可用了。最后只能把LCD改成并口，折腾了一周。
所以我的建议是：在原理图阶段，就预留一个独立的SPI接口给OTA Flash。哪怕你暂时用内置Flash，也要留出引脚。这叫「设计裕量」。
4.4 总结与选型决策树
说了这么多，咱们理一下思路。你选MCU时，可以按这个顺序问自己：
- 是否需要WiFi/BLE？ 是 → ESP32；否 → STM32。
- Flash需求是否超过1MB？ 是 → 考虑外挂SPI Flash或换大容量型号。
- RAM是否紧张？ 是 → 优化OTA缓冲区，考虑使用PSRAM（ESP32）或外扩SRAM（STM32）。
- 引脚够不够？ 列出所有外设，画一张引脚分配表，确保OTA接口不被占用。
最后说一句： MCU选型没有「最好」，只有「最合适」。你想想看，一个智能温控器用STM32H7，是不是有点大炮打蚊子？反过来，一个商用多联机用ESP32，WiFi稳定性又让人捏把汗。搞清楚你的产品定位，再动手选型。嗯，这一章就到这儿，下一章咱们聊聊OTA通信协议的选择。