做嵌入式这行久了，最怕听到需求方轻描淡写来一句"这不就是个单片机通过串口发几条指令连个网嘛"。真上手做过量产项目的人都知道，MCU+AT这套组合拳在十几年前确实是性价比之王，但今天它越来越像一件穿了很久的外套——还能穿，只是每个动作都别扭。而OpenCPU这个概念的走红，并不是厂商为了造新词卖芯片，而是大量项目在真实场景里被逼出来的架构选择。这篇文章我想把这条演进路径掰开揉碎讲清楚：MCU+AT 到底是怎么工作的、它在哪些环节偷偷吃掉你的开发时间和物料成本、OpenCPU 把应用搬进模组之后又带来了哪些新的约束。上篇重点放在架构对比、MCU+AT 的深度拆解和迁移前的准备工作，下篇再展开 OpenCPU 内部的开发细节。不管你是刚接触通信模组的入门开发者，还是已经带着团队做过几款联网终端的老手，都能从里面找到对得上号的东西。

1. 把两条路线摆上台面：本质区别在哪

1.1 从一张典型的产品框图说起

先想象一个最常见的场景：一台装在配电柜里的数据采集终端，要采集几路电压电流、两路温度，每三十秒往平台上报一次数据包。传统做法是这样的：一颗主控单片机上跑着应用逻辑，通过 UART 串口连到通信模组，模组内部有自己的基带芯片、协议栈和一套 AT 指令解析器。单片机想联网，就发一条指令让模组拨号；想发数据，就发一条指令把数据塞进模组的发送缓冲区，模组回一个 OK 表示收到了。

这套结构里有两个"大脑"：单片机负责业务，模组负责通信。它们之间唯一的沟通渠道就是那两根串口线。图上画起来干干净净，实际跑起来的复杂度全在这条细细的链路上——谁先发、谁在发、发到一半被打断怎么办、模组自己重启了单片机知不知道，这些细节没有任何一份规格书会完整告诉你。

OpenCPU 的思路完全反过来：把原来单片机干的活，直接搬到模组内部的处理器上跑。模组芯片里通常有应用核和通信核，通信核还是负责协议栈和射频，应用核则开放给开发者写业务代码。物理上少了一颗芯片、少了一段串口、少了一层指令封装，软件上从"两个进程隔着门喊话"变成了"同一个房间里协作"。

1.2 两种架构的成本账与时间账

很多人一上来就算 BOM，觉得省一颗 MCU 才是 OpenCPU 的最大卖点。实际上真正做过核算的人会发现，物料成本只是账本里的一小部分，后面跟着的一长串隐性成本才是决定性的。我按实际项目经验整理了一张对照表，数字是量级参考，不同产品差异很大，但比例关系基本成立。

单看这张表，新手很容易得出"OpenCPU 全面占优"的结论，这就跑偏了。首版开发周期的劣势是真实存在的，一个团队第一次做 OpenCPU 项目，光是摸清任务优先级怎么分、哪些 API 不能在中断里调、内存池怎么规划，就可能耗掉两三个月。所以选型从来不是选"先进"，而是选"匹配"。

2. MCU+AT 为什么能统治这么多年

2.1 AT 指令的本质是一套文本对话协议

AT 指令这套东西的历史可以追溯到上世纪拨号调制解调器时代，最初就是让人通过一串以 "AT" 开头的可读字符串去控制设备。它最大的优点同时也是最大的缺点：它是给人看的，不是给机器看的。

一条典型指令长这样：AT+XXX=1,2,"abc"，设备回OK或者ERROR，异步事件则以+XXX: ...的形式主动冒出来。这种设计对人类调试极其友好，接个串口助手就能手动跑通全流程，不需要任何工具链。厂商也乐得如此——一套指令集文档就能覆盖几十款模组，客户迁移成本低。

但站在工程角度，这套协议的三个特征会持续制造麻烦：一是文本编码带来的带宽浪费，一个整数 12345 用文本要 5 个字节，用二进制只要 2 个字节；二是解析必须依赖字符串匹配，+XXX:这种前缀一旦出现在业务数据里就会误判；三是请求和响应没有严格的事务 ID，多条指令并发时只能靠"发一条等一条"的串行方式保证不出错。

我在早期项目里写过一套指令解析器，最初用的就是简单的字符串查找，上线后遇到过一次数据里恰好包含指令前缀导致的误触发，排查了两天才定位。后来改成带状态机的逐字节解析，并且要求所有下行数据必须先做转义或者长度前缀，问题才彻底解决。这个教训很典型：AT 协议的"简单"是表面上的简单，工程化之后一点都不简单。

2.2 串口链路里的隐性成本

串口看起来是最没有技术含量的接口，两根线，配置好波特率就能通。但真正把它当成产品级通道来用，需要处理的事情一点不少。

第一个是粘包与分包。串口的本质是字节流，没有消息边界。模组返回一条OK\r\n和上一条指令的响应可能连在一起到达，业务数据也可能是半包。所以接收端必须有一个环形缓冲区，加上一套"找到完整帧才处理"的逻辑。这套逻辑写起来不难，但写对不容易，尤其是缓冲区满、溢出、丢弃策略这些边界条件。

第二个是异步事件抢占。URC（非请求结果码）会在任何时候插进来，比如网络注册状态变化、收到下行数据、信号质量上报。如果你的程序正在等某条指令的响应，中间夹了一条 URC，简单的"读到 OK 就认为成功"的逻辑立刻失效。必须做成"边收边分发"的结构，把 URC 和指令响应分流处理。

第三个是流控缺失。很多小模组的串口不带硬件流控，只有两根数据线。当模组内部缓冲区快满时，它没法通知单片机停下来，只能丢数据。高速率场景下这个问题非常致命，我见过项目为了绕开它，硬生生把波特率降到 38400 来换取可靠性，代价是吞吐直接砍掉三分之二。

下面这段是我常用的环形缓冲区 + 帧分发的简化骨架，用 C 写，去掉业务逻辑后大概就是这个形态：

#define RB_SIZE 2048 typedef struct { uint8_t buf[RB_SIZE]; volatile uint16_t head; volatile uint16_t tail; } ringbuf_t; static inline uint16_t rb_used(const ringbuf_t *rb) { return (uint16_t)((rb->head - rb->tail) & (RB_SIZE - 1)); } /* 中断里调用，只做入队，绝不做解析 */ void rb_push_isr(ringbuf_t *rb, uint8_t byte) { uint16_t next = (uint16_t)((rb->head + 1) & (RB_SIZE - 1)); if (next == rb->tail) { return; /* 满则丢弃，配合上层统计丢包数 */ } rb->buf[rb->head] = byte; rb->head = next; } /* 主循环里调用，逐字节喂给状态机 */ void modem_poll(ringbuf_t *rb) { while (rb_used(rb)) { uint8_t b = rb->buf[rb->tail]; rb->tail = (uint16_t)((rb->tail + 1) & (RB_SIZE - 1)); frame_feed(&g_parser, b); /* 状态机内部区分 URC / 响应 / 数据 */ } }

缓冲区大小不是随便定的。按 115200 波特率、8 数据位、无校验、1 停止位计算，每字节约 10 bit，理论速率是 115200 / 10 ≈ 11520 字节每秒。如果主循环最坏情况下被其他任务卡住 50 毫秒，那么这段时间最多会涌进约 576 字节。留两到三倍余量，2KB 是个比较稳妥的取值；如果用了 DMA 搬运，缓冲区可以相应减小，但要额外注意 DMA 半满中断和空闲中断的配合。

2.3 什么时候 MCU+AT 依然是最优解

讲到这里不是在唱衰 MCU+AT，恰恰相反，它在很多场景下就是最合理的选择，硬上 OpenCPU 反而是给自己找麻烦。

第一类是老平台延续型项目。产品已经在市场上跑了五六年，硬件平台成熟，认证齐全，客户认这个型号。这时候更换架构意味着重新做射频认证、重新做可靠性验证、重新培训产线，投入产出比极低。给老平台加个小功能，用 AT 指令发两包数据，一周就能交付，没有任何理由推倒重来。

第二类是多模组并存的复杂设备。有的设备要同时支持蜂窝、定位、短距通信好几种能力，这些能力分散在不同芯片上。如果主控本来就是一颗资源充足的 MCU，让它当"总调度"，各个模组各司其职，架构反而清晰。把其中一部分功能塞进某一个模组内部，会破坏这种清晰的边界。

第三类是实时性要求高的控制类产品。电机控制、精密采样这类场景，对中断响应时间的要求是微秒级的。通信模组的应用核通常还要兼顾协议栈的调度，任务优先级和中断延迟不完全由你掌控，把关键控制环放进去风险太大。这种产品保留独立 MCU 做实时控制，模组只负责联网，是更稳妥的做法。

第四类是团队结构决定的。有些团队里做业务逻辑的工程师对 RTOS、网络编程不熟，而通信调试有专人负责。强行合并到 OpenCPU，等于要求一个人同时精通两套技能，短期内质量风险很高。架构选择必须考虑团队的实际能力，这一点经常被技术讨论忽略。

3. 现场倒推：MCU+AT 的几道硬坎

3.1 吞吐与时延：被波特率和轮询吃掉的时间

先做一道简单的算术题。假设一个终端需要上报 4KB 的固件日志或者图像缩略图，串口跑在 115200，理论速率 11520 字节每秒，光传输时间就是 4096 / 11520 ≈ 356 毫秒。这还没算指令交互开销：发一条发送指令、等一个>提示符、再灌数据、最后等OK，每一步都有往返延迟和模组的处理时间。

实测中，同样 4KB 数据从 MCU 到模组内部缓冲区，用指令模式走完整个流程，耗时往往在 600 到 900 毫秒之间，取决于模组固件的实现效率。如果业务要求每 10 秒上报一次，这个开销占比就到 10% 了；如果是每分钟一次，那还好。

真正难受的是交互式场景。比如设备要响应平台下发的控制命令，链路是：平台下发 → 模组收到并触发 URC → MCU 解析 URC → MCU 执行动作 → MCU 发上报指令 → 模组上传。整条链路里 MCU 和模组之间的串口往返至少两次，每次几十毫秒起步。要命的是这个过程中 MCU 如果还在轮询其他外设，响应时间会进一步拉长。做过智能家居面板的同行应该深有体会，按键按下到灯光响应，用户能明显感觉到"慢半拍"。

提高波特率是一条路，从 115200 提到 921600 甚至更高，但代价是误码率上升、线材要求提高、PCB 布线更讲究。而且很多模组的指令通道本身就对高速率支持有限，提升到一定程度后瓶颈就不在物理层了，而在模组内部的指令解析线程。这也是为什么后来很多方案改走"透传模式"或者"数据模式"——把指令通道和数据通道分开，数据走裸流，只在需要控制时才切回指令态。这个思路其实已经是在向 OpenCPU 靠拢了。

3.2 状态撕裂：两套大脑的同步难题

这个问题我觉得比性能问题更隐蔽，也更折磨人。

MCU+AT 架构里，模组是一个有自己脾气的黑盒。它会因为信号弱而主动掉网重搜，会因为欠压而自己复位，会因为心跳超时被网络侧踢下线然后自己重连。这些动作发生时，模组只会甩出一条 URC，或者干脆什么都不说。而 MCU 那边维护着自己的一套状态机：已注册、已激活、已连接、空闲。两套状态机之间没有强制同步机制。

典型故障长这样：设备在弱信号区待了两小时，模组自己重连了七八次，每次 MCU 都收到了+XXX: 0之类的提示，但 MCU 的状态机里"socket 已连接"这个标志一直没清。等到 MCU 高高兴兴发数据过去，模组回一个ERROR，MCU 不知道为什么，重试三次后进入故障态，上报一条错误日志，运维人员看到的就是"设备离线"。

解决办法只能是加一层心跳与状态对账：MCU 每隔一段时间主动查询一次模组的真实状态，跟自己的本地状态比对，不一致就以模组为准强制同步。这套机制写起来不难，但每个项目都要重写一遍，而且总有覆盖不到的边角情况。做过三四个项目之后我基本形成了一个固定套路，把这个对账逻辑封装成一个独立模块，所有项目复用，才算把这块的坑填平。

OpenCPU 之所以吸引人，很大一部分原因就在这里：状态只有一份，不存在对账。网络断了下层直接回调通知业务层，业务层不需要猜。

3.3 资源与 BOM：多一颗芯片的连锁反应

省一颗 MCU 看起来只是省了几块钱，但它牵动的是一整条链。

布局上，多一颗芯片意味着多一组去耦电容、多一个晶振（如果是外部晶振方案）、多一路电源域、多一片 PCB 面积。对于指甲盖大小的模组化产品，这几平方毫米可能就是能不能塞进外壳的决定因素。

电源设计上，两颗芯片通常意味着两套供电和两套低功耗策略。MCU 可以进深度睡眠，模组可以进省电模式，但两者必须协同：MCU 睡了，模组还在等数据；模组醒了，MCU 还没醒。如果协同没做好，实测待机电流会比理论值高一个数量级。我见过一个电池供电的定位终端，理论待机 30 天，实测只有 9 天，最后查出来是 MCU 睡眠时串口引脚悬空导致漏电，加上模组没及时进入深度休眠。

可靠性上，任何一个环节出问题，排查路径都会变长。设备死机了，是 MCU 挂了还是模组挂了？现场没法接调试器，只能靠两个固件各自的日志来倒推。而两个固件的时间戳往往对不齐，日志拼起来的难度很高。

生产与库存上，两颗料变成两条供应链，两条料号管理，两套固件烧录工序。小批量的时候感受不明显，上了月产几万台的规模，这些环节的管理成本会很直观。

3.4 功耗账：两套低功耗模型的叠加

电池类产品对这个特别敏感。MCU+AT 方案的功耗模型是两套低功耗状态的叠加，而这两套状态的时间基准往往不同步。

模组侧的省电靠的是协议栈提供的周期性休眠机制，醒来的时间点由网络侧配置决定，开发者只能被动接受。MCU 侧的休眠是自己控制的，想睡多久睡多久，但必须保证在模组醒来之前把数据准备好。一旦 MCU 的唤醒时刻错过了模组的接收窗口，这一轮就白醒了，只能等下一个周期，功耗白白多消耗一次。

做得讲究的方案会用一个 GPIO 做"模组唤醒指示"，模组快醒的时候拉一个电平，MCU 检测到就往串口里灌数据。但这又引出一个新问题：这个引脚的状态在模组复位后会怎样？规格书上写的不一定跟实际固件行为一致，得拿示波器实测。

我个人的经验是，在 MCU+AT 架构下做超低功耗产品，至少要留出两周时间专门做功耗标定，逐个状态用电流表实测，把每个环节的电流和持续时间都记下来，做成一张表。这张表的价值远超你的想象，后面任何一次固件改动都可以拿它做回归对比。

3.5 维护账：固件升级的两个入口

产品卖出去之后，升级是常态。MCU+AT 架构天然有两个固件：主控固件和模组固件。主控固件你可以随便升级，但模组固件呢？很多时候是出厂烧死的，出了问题只能返厂。如果模组支持差分升级，那又多了一套流程和一套服务器资源。

更麻烦的是版本错配。主控固件 V2.3 配模组固件 V1.7 是验证过的组合，现场如果只升级了其中一半，就可能出现奇怪的问题。这种问题在实验室几乎复现不了，因为实验室里永远是配套的版本。

单固件的 OpenCPU 方案在这件事上优势非常明显：一个升级包，一套版本号，一次升级动作，不存在错配。这个好处在项目初期完全体现不出来，等到产品铺到几千台设备上，价值就凸显了。

4. OpenCPU 到底是什么：把应用搬进模组之后

4.1 三种常见形态的差别

市面上叫 OpenCPU 的东西其实不止一种，混淆概念会导致选型踩坑。按开放程度从低到高，我大致分成三类。

第一类是受限 API 型。模组厂商提供一个 RTOS 环境，开放一组封装好的接口，包括网络套接字、文件系统、GPIO、串口、定时器等，开发者在固定的任务框架里写业务代码。这种形态最主流，优点是安全边界清晰、厂商能保证通信功能的可靠性，缺点是受限于厂商提供的 API 集合，想做点偏门的事情就没路可走。

第二类是脚本型。在模组内嵌一个轻量脚本引擎，用脚本语言写业务逻辑。上手极快，改一行不用重新编译烧录，适合快速验证和小批量定制。代价是执行效率、内存占用和调试能力都弱一档，复杂业务写起来会很难受。

第三类是接近完整系统的形态。有的模组直接跑一个精简的类 Unix 系统或者功能完备的实时系统，开发者几乎可以按普通嵌入式的思路开发，能编译第三方库。这种形态能力最强，但也最重，启动时间、内存占用、功耗都会上一个台阶，而且对开发者的要求也最高。

选型的时候第一件事不是看参数表，而是问清楚：这个模组的 OpenCPU 到底开放了哪些接口，有没有完整文档和可跑通的示例工程。我见过项目立项时以为能直接调系统的网络接口，结果发现只有一套高度封装的、连超时都改不了的接口，最后不得不改需求。

4.2 软硬件栈的变化

从硬件看，OpenCPU 模组内部通常是双核结构：一个核跑通信协议栈和射频控制，另一个核跑用户应用。两个核之间通过共享内存加消息机制通信。这意味着用户代码和协议栈之间有一道明确的边界，跨边界的调用都有开销，频繁的小数据交互会拖慢整体性能。

从软件看，开发者面对的不再是"发指令等回复"的模型，而是"注册回调等事件"的模型。打开一个连接是异步的，返回成功只代表请求已提交，真正的结果通过回调通知。很多从 MCU 转过来的开发者第一周就卡在这里——习惯性地写同步等待，结果把整个任务阻塞住，看门狗直接复位。

内存模型也是个大变化。MCU 上你清楚知道有多少 RAM，全局数组随便开。OpenCPU 里可用堆空间是有限的，而且被多个任务共享，长时间运行后如果存在内存泄漏或者碎片，表现就是随机性的分配失败。所以在这个环境下，能静态分配就别动态分配，这是我从踩坑里换来的第一条铁律。

4.3 甜点区与雷区

说完形态，得说清楚什么项目适合、什么项目别碰。

适合迁移的典型场景有这么几类：单一功能的联网终端，比如抄表、环境监测、共享设备锁控，业务逻辑简单，主要工作量在联网和数据收发上；对体积和成本极度敏感的产品，比如可穿戴、微型传感器；低功耗长待机的产品，因为单芯片可以把电源管理做到极致；以及需要单一固件升级入口、运维压力大的规模化部署产品。

不适合的场景同样明确：需要复杂人机界面和大量外设的；实时控制环要求微秒级响应的；算力需求超过模组应用核能力的，比如本地图像处理、语音识别；以及需要跑成熟操作系统和大量第三方库的。这些场景硬上 OpenCPU，最后一定是把模组当 MCU 用，还失去了 MCU 的灵活性和生态。

5. 迁移实操：一个采集上报项目怎么拆

5.1 第一步是任务切分，不是写代码

拿到一个已有的 MCU+AT 项目准备迁移，最忌讳的是直接照着原代码往新平台上抄。正确的顺序是先做一次彻底的任务盘点。

把所有功能列出来，逐条标注三件事：执行频率、实时性要求、依赖的外设。然后按这三条把功能归成三档：高频高实时的、低频但重要的、纯后台的。第一档要慎重，如果某功能的实时性要求超过毫秒级，就要考虑它是否真的适合搬进模组应用核；第二档是迁移的主力；第三档随便放。

资源预算也得提前算。假设模组应用核可用堆空间是 200KB 量级（具体数值一定要查手册实测，不能信宣传口径），那么网络收发缓冲区、JSON 组包缓冲、日志缓冲、文件缓存加起来不能超过一半，剩下的留给协议栈和运行时。我一般会做一个简单的表格，把每个模块的内存需求列清楚，加起来超过 60% 就砍功能或者优化数据结构。

这张表看起来土，但它能救你。项目做到一半发现内存不够再回头改结构，成本是前期做这张表的几十倍。

5.2 把 AT 交互换成接口调用，但保留必要的串口能力

迁移中最容易出问题的地方是原来靠 AT 指令完成的事情，新平台上对应什么。这里必须逐个功能去对，不能想当然。

拨号联网这件事，OpenCPU 里通常由系统自动完成，开发者只需要注册一个网络状态回调，在"已连接"事件里开始业务。发数据这件事，直接调套接字接口，参数就是 IP、端口、数据指针和长度，没有文本解析，也没有>提示符。查询信号质量、查询注册状态，一般有专门的接口返回结构体。

但有一件事不能丢：很多产品仍然需要保留一路串口去接外部传感器或者从设备。这时候串口代码不是删掉，而是从"跟模组对话"变成"跟外设对话"，通信对端变了。这种情况下原来的环形缓冲和帧解析代码可以完整复用，只需要把协议内容换掉。我在迁移时通常会把这部分代码原样搬过来，改一下引脚配置和波特率，能省掉大量调试时间。

5.3 掉线重连和看门狗必须重新设计

MCU+AT 时代，掉线处理是"发指令失败 → 重试 → 重试几次不行就复位模组"。OpenCPU 里没有"复位模组"这个选项了，因为你自己就在模组里。

新的设计需要三层防护。第一层是连接层重连：套接字断开时触发回调，在回调里起一个退避定时器，按 1 秒、2 秒、4 秒、8 秒逐步拉长间隔重新连接，上限封顶，避免在网络差的环境里疯狂重连耗尽电量。第二层是会话层保活：应用层自己做心跳，超时未收到应答就主动断开重连，不要指望底层会告诉你链路已经废了。第三层是系统层兜底：硬件看门狗定时喂狗，喂狗动作必须放在主业务循环里，绝不能在定时器中断里无条件喂，否则主循环卡死了看门狗也发现不了。

关于第三层我得多说一句。新手常见的错误是在一个高优先级定时任务里喂狗，觉得这样最保险。恰恰相反，这会让看门狗彻底失效——主业务卡死，定时任务照样跑，狗照样被喂，设备就成了"活着但死了"的状态，现场表现为设备在线但不响应任何指令，处理起来极其麻烦。

5.4 功耗策略要重新标定，不能沿用旧参数

这一块最容易被忽略。原来的低功耗参数是在两颗芯片协同的前提下调出来的，搬到单芯片之后，原来的休眠周期、唤醒时序、外设断电顺序全部要重来。

我的做法是先做一次"裸测"：烧一个只有休眠和唤醒、不做任何网络动作的固件，用电流表记录每个阶段的电流和持续时间，画出完整的电流波形。有了这条基线，再逐步把网络注册、数据上报加进去，每加一项测一次，看增量在哪里。这个过程枯燥，但能让你对整机的功耗构成心里有数。

特别提醒一点：模组在搜网和注册阶段的电流峰值很高，持续时间也长。如果产品设计成每次唤醒都要重新注册网络，那功耗会非常难看。合理做法是尽量保持网络注册状态，只在不必要时才断开，用协议栈提供的省电机制维持连接。具体用哪种机制、参数怎么配，下篇会展开讲。

5.5 联调阶段的验证清单

迁移完成后，别急着上量。我整理了一份自己必过的验证清单，逐项打勾，缺一项都不发版。

这张表里"内存水位"那一项最有价值。OpenCPU 环境下很多问题都是内存慢慢漏导致的，表现出来是运行几天后随机重启。定期打印剩余堆空间，做成趋势图，一眼就能看出有没有漏。养成这个习惯之后，我至少在三个项目里提前发现了隐患。

6. 高频问题与排查实录

6.1 迁移初期的问题速查表

下面这些是迁移过程中出现频率最高的问题，基本每个项目都会撞上其中几个。放在一起便于对照排查。

6.2 几条用时间换来的经验

第一条：不要相信"理论上支持"。参数表上写着支持某个功能，跟你实际能不能用起来是两回事。有些接口文档写得漂亮，实际调用就返回不支持；有些功能要在特定固件版本上才有；还有些功能和另一个功能互斥，文档里只在一个不起眼的脚注里提了一句。拿到模组的第一件事应该是把所有你需要的接口写一个最小验证工程，全部跑一遍，跑不通的当场问清楚，别等到项目中期才发现。

第二条：日志一定要能落到非易失存储。OpenCPU 环境里没有仿真器可用，出了问题只能靠日志。但现场设备你不可能一直连着串口，所以必须有一套能把关键日志写进内部存储的机制，配合环形覆盖策略，出问题时能捞出来最近几小时的记录。这套机制我在项目第一周就会搭好，后期省下的排查时间无法估量。

第三条：把网络状态看成随时会变的外部输入。从 MCU 转过来的开发者容易潜意识里认为"连上了就是连上了"。蜂窝网络的现实是，基站切换、信号遮挡、网络侧策略调整都会导致连接中断，而且可能没有任何征兆。所以业务逻辑里每一个网络操作都必须处理失败路径，不能出现"假设已经连上就直接发"的代码。

第四条：先做减法再做加法。第一次迁移，功能范围一定要收窄。把最核心的上报和下发跑通，验证整个链路、功耗、可靠性都没问题，再往上堆功能。我见过团队一上来就追求功能对齐，把原 MCU 上的所有功能一次性搬过去，结果问题交织在一起，根本分不清是哪个模块引起的。

关于这条演进路线，我个人实际的体会是：技术选型从来不是"新的一定好"，而是"约束条件变了，最优解就跟着变"。十年前模组贵、MCU 便宜、联网功能简单，MCU+AT 是最经济的组合；今天模组成本下来了、联网需求复杂了、产品对体积和功耗的要求苛刻了，重心自然往 OpenCPU 偏。但偏移不等于全面替代，那些对实时性、对外设丰富度有硬要求的产品，依然会长期保留独立的控制单元。把两种架构各自的边界摸清楚，比争论谁更先进有用得多。后面下篇我会把 OpenCPU 里的任务划分细节、协议栈省电机制的参数配置、以及实际项目里的内存优化手法拆开讲，那部分内容更偏工程落地，值得单独展开。