单片机选型踩坑：Flash和RAM算小了板子打回重画

单片机选型会出岔子的地方，往往不在"选 8 位还是 32 位"这种大方向上，而在内存——Flash 和 RAM 留少了，样机跑得好好的，功能一叠加就爆，板子只能打回重画。

这个坑我见过太多次，而且每次都是同一个剧本：原理图定了、PCB 投了、回来调软件，加个协议栈、存点日志、顺便预留个 OTA，编译器一报"region overflow"，才知道当初抠那几 KB 抠错了。

先查 Flash：别只算你的应用代码

新手算 Flash，习惯拿自己写的那点逻辑代码估大小。实际吃 Flash 的大头常常是这些：

协议栈。上了蓝牙、Zigbee、或者哪怕只是个像样的 Modbus/串口协议，库一链进来就是几十 KB 起步。中间件和算法。浮点运算、滤波、简单的运动控制算法，编译器优化没开满的话体积能涨一倍。预留升级。OTA 要么双 bank 分区(Flash 直接翻倍预留)，要么搞差分，怎么都得留余量。

经验上，应用代码算出来的量，至少乘 1.5 再去看规格。别卡着线选，后面加功能会哭。

RAM 才是真正的隐形杀手

RAM 比 Flash 更狠，因为它在运行时实时占用，爆了就是跑飞、看门狗复位，查起来比 Flash 溢出还玄学。

几个容易被忘的 RAM 大户：协议栈的收发缓冲和连接表、GUI 的帧缓冲(哪怕一小块 LCD 也不便宜)、递归或大型局部数组、RTOS 每个任务的栈(任务一多，栈总和很可观)。

有个现场排查的笨办法但管用：把链接脚本里的栈溢出保护打开，跑满工况抓最大水位。很多项目是到量产后偶发复位，才回头发现 RAM 余量是负的。

怎么算才不踩坑

给个落地流程：

先把要跑的协议栈、OS、算法库全部链进一个最小工程，编译看真实占用。在这个占用基础上，Flash 留 30% 余量，RAM 留 40% 余量——RAM 之所以留更多，是因为运行时峰值往往比静态分析高。

还有一个常被忽略的点：选同系列里 Flash/RAM 相邻的两档型号 pin-to-pin 兼容的。真爆了，换大一号不用改板，这是选型阶段就能给自己留的后路。

选型这事，内存留余量比选对内核更影响项目命。浮思特代理的 ABOV 单片机，8 位和 32 位产品线覆盖挺全，同系列相邻档位大多 pin-to-pin，临时升级不慌。选型阶段拿不准留多少余量的，把功能清单发过来，我们一起对着算一遍。