2. 硬件资源评估：MCU/MPU选型要点、内存容量评估、外设接口资源盘点
做嵌入式系统分区设计，第一步不是画框图，也不是写代码。
而是老老实实坐下来，把硬件资源摸清楚。
我见过太多项目，前期拍脑袋选了个芯片，做到一半发现Flash不够、RAM爆了、外设接口冲突……最后只能换平台，从头再来。那滋味，真不好受。
所以这一章，咱们就聊聊硬件资源评估这件事。说白了，就是回答三个问题：
- 用哪颗芯片？
- 内存够不够？
- 接口能不能接上？
核心原则：硬件资源评估不是一次性的，它应该贯穿整个设计周期。选型阶段做粗估，详细设计阶段做精算，最终实现阶段做验证。
2.1 MCU/MPU选型要点
选MCU还是MPU？这个问题其实没那么复杂。
我个人习惯这样判断：如果你的系统需要跑Linux或者复杂的RTOS，需要管理大容量内存（比如64MB以上），那基本就是MPU的活儿。如果只是跑裸机或者轻量级RTOS，控制几个外设，MCU更合适。
选型时，我重点关注这几个维度：
2.1.1 处理性能
别只看主频。主频高不代表跑得快。
我建议你看三个指标：
- MIPS（百万指令每秒）—— 适合简单控制任务
- DMIPS（Dhrystone MIPS）—— 更适合通用计算
- CoreMark —— 现在业界更认可的标准
举个例子。我曾经在一个工业控制项目里，选了某款200MHz的MCU，算下来DMIPS有300多。结果跑一个PID控制算法，加上Modbus通信，CPU占用率直接飙到85%。后来换了同主频但带FPU的型号，同样的代码，CPU占用率降到40%。
嗯，这里要注意：浮点运算单元（FPU）对控制类算法影响巨大。如果你的算法涉及大量浮点运算，务必选带硬件FPU的型号。
2.1.2 功耗约束
电池供电的设备，选型时功耗是第一优先级。
我一般看这几个模式：
- 运行模式：正常工作的功耗
- 睡眠模式：能保留RAM和寄存器状态的最低功耗
- 深度睡眠模式：几乎关掉所有外设，只留RTC和唤醒逻辑
记得有一次做可穿戴设备，选了一款标称“超低功耗”的MCU。数据手册上写深度睡眠0.5μA，看着挺美。结果实际测试，因为外设没完全关掉，实际功耗是5μA。后来仔细看手册才发现，要达到0.5μA需要把GPIO全部配置成模拟输入模式……
避坑指南：我曾经被数据手册上的“典型值”坑过。记住，选型时看“最大值”而不是“典型值”。典型值是在理想条件下测的，你实际用的时候大概率达不到。
2.1.3 工作温度与可靠性
工业级（-40°C ~ 85°C）和商业级（0°C ~ 70°C）差别很大。
如果你的设备要放在户外、机柜、或者靠近电机的地方，老老实实选工业级。别问我怎么知道的……
2.2 内存（Flash/RAM）容量评估
内存评估是分区设计的基础。Flash不够，代码放不下；RAM不够，跑不起来。
2.2.1 Flash容量估算
我一般用这个公式做粗估：
Flash需求 = 代码体积 × 1.5 + 固件升级预留 + 配置文件/参数存储为什么乘1.5？因为实际编译出来的代码，通常比你想象的更大。加上调试信息、库函数、中间件，很容易翻倍。
具体来说：
- 裸机程序：一般几十KB到几百KB
- 轻量级RTOS + 应用：几百KB到1-2MB
- Linux系统 + 应用：几十MB到几百MB
我在一个物联网项目里，最初估算固件只需要512KB Flash。结果加了OTA升级、TLS加密、JSON解析库之后，直接飙到1.2MB。最后不得不换芯片，项目延期两周。
警告：永远不要卡着Flash上限选型。留出至少30%的余量。因为你永远不知道后面会加什么功能。
2.2.2 RAM容量评估
RAM评估比Flash复杂。因为RAM是动态使用的。
我习惯这样算：
RAM需求 = 全局变量 + 堆空间 + 栈空间 + 各任务栈 + DMA缓冲区其中：
- 全局变量：编译后直接能算出来
- 堆空间：取决于malloc的使用量，一般预留总RAM的10%-20%
- 栈空间：每个任务至少1KB，中断服务函数至少512B
- DMA缓冲区：这个容易被忽略。比如以太网DMA描述符、USB缓冲区，动辄几十KB
举个例子。一个典型的RTOS项目：
| 项目 | 大小 |
|---|---|
| 全局变量 | 32 KB |
| 堆空间 | 16 KB |
| 主栈 | 4 KB |
| 任务1栈（控制） | 2 KB |
| 任务2栈（通信） | 4 KB |
| DMA缓冲区 | 8 KB |
| 总计 | 66 KB |
所以选型时，至少选128KB RAM的芯片。留出一倍余量，心里踏实。
2.3 外设接口资源盘点
外设接口盘点，说白了就是数一数你需要多少个UART、SPI、I2C、GPIO……然后看看芯片够不够用。
我一般按这个步骤来：
2.3.1 列出所有外设需求
把系统里每个模块需要的接口列出来：
- 传感器：I2C或SPI
- 显示屏：SPI或并行接口
- 无线模块：UART或SPI
- 存储：SPI或SDIO
- 调试接口：UART（至少一个）
- 按键/LED：GPIO
2.3.2 检查复用冲突
这是最容易踩坑的地方。
很多MCU的外设是复用的。比如某个引脚，既可以做UART TX，也可以做SPI SCK。你选了UART，就不能同时用SPI。
我曾经在一个项目里，选了STM32F103，需要3个UART和2个SPI。结果发现UART2和SPI1共用同一组引脚……最后只能降速用软件模拟SPI，通信速率直接砍半。
避坑指南：选型时，打开芯片的引脚功能表，把所有要用到的外设引脚列出来，检查有没有冲突。这一步花半小时，能省后面两周的调试时间。
2.3.3 考虑特殊外设
有些外设对硬件有特殊要求：
- USB：需要内置PHY或者外接PHY
- 以太网：需要MAC+PHY，或者内置PHY
- CAN：需要CAN控制器+收发器
- ADC/DAC：注意采样率和分辨率
- PWM：注意定时器资源和输出通道数
嗯，这里还要注意一点：外设的时钟树。有些外设需要特定的时钟频率，如果芯片的PLL配置不出来，那就尴尬了。
2.4 知识体系总览
说了这么多，咱们用一张图把整个硬件资源评估的脉络理清楚：
这张图把硬件资源评估的三个核心维度串起来了。你想想看，选型、内存、外设，这三者其实是互相影响的。选了一颗高性能芯片，内存可能也大，外设也丰富。但成本也上去了。
所以实际做的时候，我习惯先列需求清单，再去找芯片。而不是先选芯片，再往上堆需求。顺序搞反了，后面全是坑。
总结一下：硬件资源评估没有捷径。老老实实列需求、算容量、查冲突。我做了这么多年，每次跳过的步骤，最后都会回来补上，而且代价更大。