企业官网建设流程全解析

做智能硬件这几年，身边不少人一提到 Wi-Fi 模组，第一反应就是乐鑫的 ESP 系列；但真要把产品铺到量产、并且同时考虑成本和供货稳定性时，Realtek Ameba 这颗棋反而经常是最后的赢家。

我最早接触 Ameba 是从 RTL8710 开始的，当时是被它的单价和射频性能吸引。后来陆续在网关、门锁、带屏设备上把 Ameba 全家族基本用了个遍。去年帮客户做选型评估时，正好把 Realtek Ameba 系列九款有代表性的芯片一次性梳理了一遍，分别是：RTL8710AF、RTL8710BN、RTL8195AM、RTL8720DN、RTL8720DF、RTL8720CM、RTL8720BW、RTL8722DM 和 RTL8735B。这篇文章就把这九款的定位差异、硬件参数逻辑、开发生态和真实选型方法讲清楚。如果你是嵌入式硬件工程师、固件工程师，或者正在做 IoT 产品定义，这篇内容可以帮你省下大量查数据手册和逛论坛的时间。

1. Ameba 与九款芯片的定位全景

1.1 Realtek 做 IoT 芯片，不是玩票

Realtek 在很多人的印象里是做网卡芯片、路由器主控的，甚至有人只知道“Realtek 高清晰音频管理器”。但恰恰是这些 PC 和网络设备领域积累下来的技术底蕴，成了它做 IoT 芯片的护城河。

一颗 Wi-Fi SoC 能不能做好，最核心的其实是射频前端、基带处理和协议栈这三件事。Realtek 在路由器主控和无线网卡上出货量极大，这让它的射频链路设计经验非常充足。体现在 Ameba 芯片上，最直观的感受就是信号覆盖和抗干扰能力。我做过对比，同样的天线设计和摆放位置，Ameba 的 RSSI 衰减和重传率，普遍比我预想的更稳。对于 IoT 产品来说，Wi-Fi 不丢链，比峰值速率更重要。

它的产品线布局也很有意思：从最低成本的 RTL8710 系列，到带 BLE 的 RTL8720 系列，再到带 NPU 的 RTL8735 系列，几乎覆盖了 IoT 的中低端全部需求。这也是我敢在多个项目中押注 Ameba 的原因——同一套软件体系内可以覆盖不同档次的产品，迁移成本低。

1.2 型号命名里藏着产品逻辑

把九款芯片放在一起看，型号命名其实是理解产品定位的钥匙。

• RTL8710 系列：纯 Wi-Fi 方案，Cortex-M 内核，主打成本敏感、不需要蓝牙的场景。典型代表 RTL8710AF、RTL8710BN。
• RTL8720 系列：Wi-Fi 加 BLE 双模，解决了配网和近场交互的问题。其中 RTL8720DN、RTL8720DF 是主流，RTL8720CM、RTL8720BW 是成本优化版本。
• RTL8722DM：同样是双模，但在 flash、SRAM、外设和封装上做了升级，适合需要跑更复杂业务逻辑的产品。
• RTL8735 系列：带 NPU 的 AIoT 芯片，面向语音、图像等本地智能处理场景。
• RTL8195AM：早期 Ameba 开发平台使用的芯片，现在更多被当作学习评估用，量产产品里已经很少见了。

如果你只是粗略扫一眼，会觉得这些芯片都差不多。但真正做选型时，每一颗的差异都会直接决定你的 BOM 成本和研发周期。

1.3 九款芯片的选型速览表

下面这张表是我实际选型时常用的对照，九款芯片的关键差异都在里面了。数据是典型模组普遍使用的配置，不同批次和封装可能会有差异，具体以官方数据手册为准。

这张表里最需要注意的是 RTL8735B，它和前面八款不是一个维度的产品。前面八颗解决的是“怎么连、怎么跑业务”，RTL8735B 解决的是“设备怎么在本地做简单思考”。选型的时候如果把 AI 方向的产品误选成普通双模芯片，后期加外部处理单元的成本会非常痛苦。

2. 九款芯片的硬件参数拆解与横向对比

2.1 RTL8710AF 和 RTL8710BN：单 Wi-Fi 方案里的常青树

RTL8710AF 是我最早量产的 Ameba 芯片，Cortex-M3 内核，主频做到 166MHz，在当时的 Wi-Fi MCU 里算是不错的水平。它的 Flash 一般在 1MB 左右，SRAM 在 256KB 级别。这个资源放在今天看并不大，但跑一个完整的 Wi-Fi 协议栈、一个 MQTT 客户端加基本的业务逻辑，还是绰绰有余的。

当时我用它做的是智能插座。产品需求很简单：Wi-Fi 联网、手机 App 控制、定时开关、电量统计。RTL8710AF 的硬件资源刚好卡在够用的位置上，而且它的射频性能在低价格段位里表现相当突出。插座这种产品，周围往往有继电器、电源模块这些强干扰源，RTL8710AF 的抗干扰能力经过实际验证，重传率一直控制得不错。

RTL8710BN 可以理解为 8710AF 的改进款，主要在 flash 容量和低功耗表现上做了优化，同时修正了一些早期批次的外设小问题。如果你是一个全新的 Wi-Fi 单品项目，且确定不需要 BLE，我会建议直接选 RTL8710BN，而不是再回头用 8710AF。开发接口和 SDK 基本一致，但可用存储更大，后期加 OTA 也好安排分区。

这一组芯片最大的限制是没有 BLE。现在很多产品配网还停留在“手机连热点”或者“SmartConfig 一键配网”的方式，体验上确实不如 BLE 配网顺滑。如果你的产品对配网体验有要求，或者需要和手机 App 做频繁的近场交互，那就不要在这一档上纠结，直接上双模系列。

2.2 RTL8195AM：老一代开发平台的印记

RTL8195AM 严格来说是 Ameba 初代开发板使用的芯片，也是很多老玩家认识 Ameba 的起点。它的 CPU 同样是 Cortex-M3，资源和 RTL8710AF 接近，但 Realtek 早期对它的定位更多是“开发评估”，而不是单纯的低成本量产。

现在再拿 RTL8195AM 做产品，我个人是不推荐的。原因有三个：一是 SDK 版本老，社区和工具链都已经慢慢迁移到新平台；二是芯片供货周期和价格都没有优势；三是它在功耗和外围集成度上不如后出的 RTL8720 系列。如果只是想做学习，或者研究 Realtek 的无线协议栈实现，拿它当参考倒是可以。

选型一定要避免这种“看着熟悉就顺手用了”的惯性。芯片选的是未来两年的供货和软件维护，老平台即便现在没问题，后面也容易变成负担。

2.3 RTL8720DN 和 RTL8720DF：双模主力，最值得关注的一档

RTL8720DN 是我个人最常用的一颗 Ameba 芯片，也是我认为整个 Ameba 系列里性价比最均衡的一颗。它升级到了 Cortex-M4F 内核，带了硬件浮点单元。主频保持 166MHz，Flash 做到 4MB 的水平，SRAM 512KB。这个资源跑一个完整的双模协议栈，再加载云平台 SDK 和业务代码，都还有很充裕的余量。

无线部分它支持 Wi-Fi 4 加 BLE 5.0。这里要重点强调一下双模的价值：配网体验可以直接用 BLE 通道，设备广播、手机发现、密钥协商、Wi-Fi 配网，一套流程走下来非常顺滑。而且 BLE 通道在产品出厂后的调试、固件升级、近场参数配置上都有很大用处。

RTL8720DF 则是 8720DN 的成本优化版本。从命名和 Realtek 的产品策略来看，DF 在封装尺寸和外围 BOM 上做了精简，适合对体积敏感的模块设计。如果你做的是智能门锁、传感器这类对 PCB 面积和成本都有要求的设备，DR 8720DF 是比 8720DN 更合适的选择。它们使用的 SDK 基本一致，从 DN 迁移到 DF 的工作量很小，这点对研发节奏紧张的团队非常友好。

功耗方面，RTL8720DN 系列支持多种低功耗模式。实际做电池供电设备时，合理使用休眠和事件唤醒，能把平均功耗控制到很低的水平。不过要注意，低功耗设计不只看芯片的休眠电流，还涉及外围器件的漏电和管理，这部分我在第 4 节会详细讲。

2.4 RTL8720CM 和 RTL8720BW：把成本压到极致

RTL8720CM 和 RTL8720BW 这组芯片，定位非常明确：双模能力不变，但在封装、flash 和外围设计上把成本压到更低。

RTL8720CM 的 flash 通常会缩减到 2MB，RAM 保持在 512KB 级别，对于一些业务逻辑不那么重的场景，比如简单的温湿度传感器、智能按钮、LED 控制器，这些资源完全够用。RTL8720BW 则是进一步针对 b 模块封装和天线设计的成本做了优化，适合那些对模组尺寸和价格极其敏感的小型设备。

这两颗芯片我在选型时通常作为“Plan B”来评估。也就是说，如果项目算完 BOM 后发现成本超了，且产品功能通过裁剪可以适配小资源环境，就把方案从 RTL8720DN/DF 下探到这一档。但需要提前确认清楚：如果后续产品要加 OTA、加一定的本地逻辑，2MB flash 可能会捉襟见肘，分区规划要从第一天就想好。

2.5 RTL8722DM：当业务逻辑变重时，它顶上

有些产品需要的不是“更多连接”，而是“更大空间”。比如带屏的设备、带本地语音交互的设备、需要跑较复杂状态机的产品，这时候 RTL8720DN 的存储可能就不太够了。RTL8722DM 就是为这类场景准备的。

RTL8722DM 同样基于 Cortex-M4F，主频 166MHz，但 flash 和 SRAM 的配置更宽裕，外设也更加丰富，像 SDIO、更多 UART、更多 PWM 通道、模拟前端等，都给了更大的余量。我当时在做一个带屏的家庭信息终端时，就是用它来同时处理屏的刷新、触摸事件、MQTT 通信和本地业务逻辑。整个系统跑下来，内存水位依旧可控，没有出现频繁的 GC 或者内存不足问题。

如果拿它和 RTL8720 系列相比，你会发现从芯片本身来看它性能提升不算“革命性”，但存储和外设带来的系统稳定性提升是实打实的。选型的时候，我建议你把“未来 6 个月可能加的功能”也折算进存储需求里。很多项目死就死在“先按最小配置选，后期加功能发现空间不够”。

2.6 RTL8735B：剑指 AIoT 本地智能

RTL8735B 是 Ameba 系列里比较特殊的一颗，它在传统 MCU 的基础上加入了 NPU 模块，可以本地运行轻量级神经网络模型。这意味着设备可以做离线语音命令识别、简单的图像分类、人脸检测、手势识别这类功能，而不需要把所有数据都送到云端。

它的软件工具链围绕模型转换、量化和部署做了一套流程，虽然不如 PC 端那么成熟，但在嵌入式 AI 芯片里已经算是上手门槛较低的。我用它做过一个简单的本地语音唤醒和指令识别 demo，从模型训练到部署到开发板，整体路径是通的，没有那种“官方承诺很强、实际工具链稀烂”的感觉。

不过也要说句实话，RTL8735B 的 NPU 算力定位是轻量级 AI，不能拿它跟 RK3588 这种应用处理器级别的 NPU 去比。它适合的是“加一点点智能”的产品，比如语音开关、简单的人体检测、设备状态诊断。如果你要跑大模型、高清视频流分析，那它并不合适。

另外，RTL8735B 的开发方式和前几款有一点区别，它更接近“双核加专用加速器”的整体系统，烧录、调试、内存布局都需要重新适应。选型时要把这部分学习成本算进项目周期里。

3. 选型决策要看的几个硬指标，别被参数表带偏

3.1 无线协议栈决定产品能上线还是上不了线

很多人选芯片第一眼看主频、看 flash、看价格，但对我而言，最重要的其实是“无线协议栈到底支持到什么程度”。因为连接是 IoT 产品的生命线，而这个生命线不是光看“支不支持 Wi-Fi/BLE”就能判断的。

实际选型时要问几个更具体的问题：协议栈是单模还是双模同时工作？是否支持 Matter？对亚马逊 AWS IoT、谷歌、阿里云、腾讯云这些平台有没有现成适配？BLE 是主设备还是从设备？支持多少同时连接？

这些能力直接决定了你的软件研发工作量。比如项目要求支持 Matter 协议，那你最好直接确认芯片官方有没有提供标准方案。自己从零移植一套 Matter 栈，在 MCU 资源上几乎是不可能完成的任务。再比如你的产品需要手机 App 通过 BLE 配网，那么芯片就必须支持 Wi-Fi 和 BLE 双模，而且协议栈要支持 BLE 的同时保持 Wi-Fi 连接。

Ameba 的双模芯片在这块做的是真不错。RTL8720DN 系列打开双模后，两边都能稳定工作。这在代码层面省了很多心，不用自己搞“分时复用”那一套。相比之下，如果你选了纯 Wi-Fi 芯片，又非要硬加 BLE 功能，那就只能外挂一颗蓝牙芯片，BOM 成本、PCB 面积和固件联调工作量都会成倍增加。

3.2 功耗预算不是看一个休眠电流数字

做电池供电设备的工程师，肯定都遇到过这种场景：芯片数据手册上写着休眠电流只有几微安，结果整机量产以后，电池一两个月就没电了。问题出在哪里？出在大多数人对“功耗预算”的理解过于简化。

真正的功耗预算是一个平均值，它等于“休眠电流×休眠时间占比 + 工作电流×工作时间占比 + 网络保活电流和时间的累计”，还要算上电压转换效率、外围器件漏电、传感器待机电流等。芯片的休眠电流只是其中一个变量。

举例来说，一颗芯片休眠电流是 5uA，Wi-Fi 工作时平均电流是 80mA，假设设备每小时醒来一次，每次工作 2 秒完成数据上报。那么一小时下来，工作电流的贡献是 80mA × 2/3600，约等于 0.044mAh；休眠电流的贡献是 0.005mA × 1 小时，约等于 0.005mAh。看起来休眠电流占比并不大，工作电流才是大头。所以选低功耗芯片时，不要只盯着“最低休眠电流”这个参数，还要看从休眠唤醒要多久、唤醒后完成一次业务要多久、Wi-Fi 重连和 TCP/TLS 握手会增加多少额外时间。

这类“动态功耗”往往才是决定电池续航的真正变量。RTL8720DN 和 RTL8735B 都支持比较灵活的唤醒方式和低功耗模式，但最终整机能不能达到预期续航，还要靠电源管理和业务调度来配合。

3.3 Flash 和 RAM 的余量要按“半年后”算

选型时最容易犯的错，就是把当下功能跑通作为存储选型的唯一依据。我见过太多项目，固件开发到一半，需求方说要加一个 OTA 升级功能，结果发现 flash 分区根本腾不出足够的升级缓冲区；或者要加一个安全协议，结果 RAM 不够放证书和会话状态。

我的经验是：硬件选型阶段就把“未来半年的功能预期”折算成存储余量。基础固件占掉一半 flash，剩下的一半至少要留三分之一给 OTA 和日志，再留一些给未来扩展。RAM 方面，除了业务逻辑需要的堆栈，还要考虑 Wi-Fi/BLE 协议栈、TLS 握手缓冲区、云平台 SDK 的资源占用。

拿 RTL8720DN 的 4MB flash 来说，跑完双模协议栈和基础业务后，还能剩出不少空间，这让我在做 OTA 分区时非常从容。而 RTL8720CM 如果只有 2MB flash，就需要精打细算，甚至必要时牺牲 OTA 或者减少日志功能。类似的差异，在选型阶段就要想清楚。

3.4 封装、天线和模块供应链

芯片选完只是第一步，真正落地的产品设计里，封装形式和天线方案往往才是让硬件团队头疼的地方。Ameba 系列不同型号的封装差别很大，有的是 QFN，有的是 LCC 封装，外围器件要求也各不相同。如果你的团队 PCB 设计经验一般，我更建议直接采购靠谱厂商做好的 Ameba 模组，而不是从芯片开始自己设计。

模组的好处是把天线匹配、射频布线、晶振这些高难度环节都处理好了，硬件团队只需要关注天线净空和摆放位置。量产阶段，天线一致性、阻抗匹配这些都是模组厂已经调好的，售后问题会少很多。自己做芯片级设计虽然能省一点成本，但射频调试的周期可能非常长，核算下来并不划算。

供应链方面，Realtek 的芯片在现货市场和模块厂的覆盖度都比较广，这也是我敢在量产项目里用它的重要原因。缺货风险相对可控，不像一些小众芯片，买几十颗样品都要等一个月。

3.5 软件生态和 OpenCPU 开发方式

Ameba 系列从一开始就支持 OpenCPU 开发模式，也就是不需要外挂主控 MCU，直接用芯片内部资源跑业务逻辑。这对 BOM 成本的压缩是决定性的，省掉一颗主控 MCU 加一颗 Wi-Fi 透传模组的传统方案，省掉的成本、面积和开发工作量都很可观。

开发资源上，Ameba 的 SDK 分为几类：一类是基于 Arduino 的封装，适合快速验证和原型开发；一类是 Realtek 官方提供的带 FreeRTOS 的 SDK，适合正式产品开发；还有面向 RTL8735B 的专用 AI 工具链。做正式量产项目，我建议直接用官方完整 SDK，而不是在 Arduino 环境上堆产品代码。

另外，开发调试时很多工程师习惯拿 STM32 的经验往 Ameba 上套，这里要特别提醒：Ameba 是无线 SoC，不是普通 MCU。它的启动流程、时钟管理、电源模式和外设使用方式，都和 STM32 这类 MCU 差别很大。直接用老经验容易在低功耗唤醒和外设初始化上踩坑，建议拿到开发板后先跑官方例程，再改自己的业务。

4. 三类真实产品场景的选型案例与量产避坑

4.1 低成本联网插座：RTL8710AF/BN 已经足够

智能插座是我最喜欢的举例场景，因为它的需求边界非常清晰：成本敏感、功能固定、不需要复杂的近场交互。当时我们定的方案是 RTL8710AF，Wi-Fi 模组采用模组厂的封装，主控直接承担按键检测、继电器控制和电量统计逻辑。

开发过程中遇到的最大坑是继电器吸合瞬间对 Wi-Fi 射频的干扰。第一次打样后做信号测试，发现继电器一动作，Wi-Fi 的 RSSI 就出现明显跳变，甚至偶尔出现重连。排查下来是继电器线圈没有做续流和隔离，电源轨上的噪声直接串到了射频区域。后来在继电器两端并联续流二极管、优化 PCB 布局、把天线走线尽量远离继电器之后，问题才消除。这个经验说明，Wi-Fi 产品能不能稳定工作，很多时候不是芯片的问题，而是硬件设计的问题。

如果今天再让我做同类的插座，我会直接选 RTL8710BN 而不是 8710AF。原因很简单：BN 的 flash 更大、功耗表现更好，而且价格相差不大。留出的空间可以放更完善的 OTA 流程，对批量产品的售后维护帮助很大。

4.2 智能门锁和电池传感器：RTL8720DN/DF 的低功耗双模方案

智能门锁的产品形态很有意思：它有 Wi-Fi 需求，因为用户要远程查看门锁状态、接收报警通知；它又迫切需要 BLE，因为门锁靠近手机，BLE 配网和近场开锁的体验远好于 Wi-Fi。这类需求基本是为 RTL8720DN 这类双模芯片量身定做的。

我当时用 RTL8720DN 做锁控模块时，重点在功耗和唤醒机制上做了很多优化。门锁大多时间处于待机状态，必须做到“按一下就能响应，但不按键时几乎不耗电”。方案上我们把系统调度成：常态深度休眠，只有按键事件或定时事件才唤醒做短暂工作。BLE 广播也只在需要配网时才开启，平时关闭以省电。

这个过程中踩过的一个坑是 GPIO 外部中断唤醒的漏电问题。芯片进入休眠后，外部中断引脚如果配置成上拉模式，且外部按键电路没有做合理的电平设计，唤醒引脚会持续漏电，整机待机电流远高于预期。后来在按键电路上加了合适的电阻分压和二极管隔离，才把待机电流压回正常水平。这个坑在数据手册里不会明确写，只能靠实测和经验积累。

RTL8720DF 在这个方案里是备选。如果产品外观设计对主板面积限制更严，或者成本压力更大，可以换成 DF 的封裝。功能代码基本不用大改，最多调整一下引脚映射和初始化配置。

4.3 带本地语音和简单视觉的中控设备：RTL8735B

带屏中控、语音面板这类的产品，普通双模芯片往往跑不动本地语音识别，更不用说图像类的简单识别。而如果全部依赖云端，又会有延迟、隐私和断网可用性的问题。RTL8735B 的 NPU 就是用来解决这部分问题的。

我用 RTL8735B 做离线语音指令识别时，整体感觉是：工具链的基本路径已经跑通，但从模型选型到量化部署仍有不少手工调优工作。比如模型剪枝和量化后，识别率会下降，需要在硬件算力和精度之间做平衡。另外，RTL8735B 的开发调试流程比普通 Ameba 芯片复杂，涉及的烧录工具、内存布局都需要仔细阅读官方文档。

如果你准备在 RTL8735B 上做产品，我建议团队里至少要有一个懂模型量化和嵌入式部署的工程师。否则，光是把模型跑起来可能就要耗掉不少时间。但如果做成了，产品竞争力确实提升一个档次——离线可用、响应快、成本可控，这些都是用户能直接感知到的价值。

4.4 量产阶段最容易踩的五个坑

最后把我在 Ameba 系列产品量产过程中踩过、或者身边同行踩过的坑统一列一下：

第一，烧录和加密流程必须提前定义。Ameba 芯片支持烧录工具批量下载固件，也支持固件加密。如果不做加密，产品固件很容易被抄板提取，智能硬件行业的方案保护就形同虚设。量产前要把加密密钥的烧录和保管流程定好，免得产线上一堆设备烧错了密钥。

第二，Flash 分区在项目一开始就要规划好。Bootloader、App、OTA 下载区、参数存储区，每一块都要留够空间。我见过项目做到一半发现 OTA 区不足，最后只能压缩业务代码，非常被动。

第三，天线位置是产品结构的“一等公民”，不是硬件的后置任务。金属外壳、电池、FPC 排线、马达这些都会影响天线性能。打样阶段就要用实际结构件做天线测试，不要等模具定型了再测，那时候改结构成本就大了。

第四，SDK 版本不要随意追新，也不要长期不升。Realtek 的 SDK 迭代会有一些行为变化，升级前一定要看 Release Note。我们曾因为升级 SDK 后 BLE 连接参数发生变化，导致老版本 App 兼容出问题，最后花了不少精力排查。

第五，低功耗整机验证一定要做“长时间老化测试”，而不是只测静态电流。把设备放在真实网络环境里跑一周，记录电池电压曲线和网络重连次数，才能发现偶发的唤醒异常或者网络保活逻辑问题。

最后分享一个我自己的选型习惯

无论是 Ameba 九款芯片还是其他 IoT 芯片，我拿到一颗新芯片后，第一件事不是看数据手册，而是先搭一块最小的测试板，把 Wi-Fi 吞吐、掉线重连、低功耗唤醒这三个基础项目跑一遍，并且至少连续跑 72 小时。基础链路稳了，再开始做功能开发。这个习惯帮我避开了很多后续量产中的大坑，也希望对你做 Ameba 选型有帮助。