ESP32-S3 开发：什么时候该选它，以及 PSRAM、屏幕与功耗怎么算

ESP32、ESP32-S3 与 ESP32-C3 怎么选

多数找到我们说"想用 ESP32"的产品，其实还没定用哪一颗，而这个差别比共享的品牌名所暗示的要大得多。最初的 ESP32 是双核 Xtensa LX6，带 WiFi 与经典蓝牙。C3 是单核 RISC-V，带 WiFi 与 BLE，主打成本。S3 是双核 Xtensa LX7，带 WiFi 与 BLE、原生 USB-OTG、更多 GPIO、支持更大的外部 PSRAM，以及面向神经网络与信号处理的向量指令。

实际选型归结为四个问题，而且值得在画原理图之前就回答。

• 有没有屏？彩屏加现代 GUI 框架，是选 S3 最有力的单一理由。PSRAM 的容量与带宽、显示接口、再加上第二颗核心，共同决定了产品摸上去是"跟手"还是"像样机"。
• 要不要端侧推理？关键词唤醒、简单视觉、传感器流的异常检测——S3 的向量指令就是为这一类活准备的。产品里没有推理，这个优势就只是纸面上的。
• 产品对外有没有 USB？S3 有原生 USB-OTG。如果产品需要被主机识别成设备，或者需要不借助串口桥接芯片就能 USB 升级固件，这就从 BOM 里去掉一颗料、从设计里去掉一个失效点。
• 成本是不是硬约束？如果活儿就是"读个传感器、往 MQTT 发"，C3 更便宜就能做完，开发工作量差不多。为 C3 能干的活选 S3，等于为产品用不上的硅片付钱。

我们的固件工作覆盖乐鑫全系，也覆盖 STM32、Ambiq Apollo、STC 与 AVR，选型按产品定而不是按习惯定。诚实的默认值是：带屏和要推理的，往 S3 靠；纯联网节点，留在更便宜的型号上。

PSRAM 是一项设计决策，不是打个勾

把 WiFi 缓冲、TCP/IP 协议栈和应用都算进去之后，S3 的片内 SRAM 并不宽裕。任何认真的显示工作都需要外部 PSRAM，而 PSRAM 怎么选型、怎么配置，对产品的响应感受的影响不亚于选哪颗主控。

有三件事要尽早定下来：

• 四线还是八线 PSRAM。八线大致把可用带宽翻倍，当帧缓冲被持续读出、同时应用又在往里写的时候，这个差别很要命。对大尺寸或高刷新率的屏，它往往就是界面流畅与画面撕裂之间的分界。
• 要多少，给谁用。在设计 UI 之前先把内存预算写下来：帧缓冲或绘制缓冲、图片资源、网络缓冲、应用堆，以及余量。我们在每个 GUI 项目上都这么做——预算排在第一屏设计之前，分量和电源预算一样重。
• 时钟与布线。跑在高速下的 PSRAM 就是一个高速接口。走线长度、回流路径与时钟配置，共同决定标称带宽是在你的板子上实现，还是只在评估板上实现。

我们反复见到的翻车方式是：GUI 照着 PSRAM 宽裕的开发板设计，然后移植到降成本后换了小容量颗粒的量产板。到那一步，每个修法都是妥协。

带屏方案：S3 上的 LVGL

S3 配 PSRAM 跑 LVGL，已经成了一类产品的常见组合——需要彩色触摸屏，但不愿承担应用处理器的成本与复杂度：温控器、仪表前面板、手持设备、门禁、家电界面。

我们在资源受限硬件上交付 LVGL 的经验可以直接套用。尽可能在启动时静态分配 GUI 内存，界面切换时的动态分配正是内存碎片藏身之处。利用 LVGL 的局部刷新，把绘制缓冲按屏幕条带来配，而不是整帧。每一张图片资源进仓库之前先登记在册，字体集要狠狠克制——每一种字重和字号都是实打实的 Flash 与 RAM。这些做法来自我们在杰里 AC79xx 平台上交付的产品，详见我们那篇 LVGL 开发文章；S3 上的约束宽松一些，但纪律完全相同。

面板接口的选择和框架同样重要。S3 支持 SPI 屏、并口 RGB，配置得当还能跑更高带宽的方案。SPI 简单便宜，但在不高的分辨率和刷新率上就会耗尽带宽。并口要付出 GPIO 和布线代价，换来余量。这件事应当按分辨率、色深与目标帧率算出来再定，而不是等点亮阶段才发现——屏都已经下单了。

触摸是另一摊活：控制器选型、I2C 或 SPI 接线、中断处理、校准。在我们交付的树莓派 DSI 显示项目里——平台不同，但属于同一类问题——4.3、5、7、10 英寸多尺寸面板的触摸校准占掉了点亮阶段相当一部分时间，诊断通路靠的是 I2C 调试日志。这部分工时要预留。

WiFi 功耗：决定电池类产品生死的数字

WiFi 是突发式耗电，电池供电的 S3 产品活不活得下去，取决于占空比而不是平均电流。预算里真正要紧的几项：

• 深睡电流，而且要算上产品实际保留供电的一切——PSRAM 保持、RTC 外设、外接传感器、上拉电阻，以及没人记得的那颗指示灯。
• 唤醒与连接的代价。关联 AP、获取地址、建立 TLS 会话，能量主要花在这里。一个每分钟醒一次的设备，预算的大头花在连接上，不在发送上。
• 发射占空比。射频真正开启的时长，由报文大小、协议开销，以及真实信号条件下的重传决定——不是台面条件下的。

值得采用的手法：上报间隔短时保持会话而不是反复重连；把多次读数攒成一批，让射频少醒几次；网络允许的话用静态 IP 跳过 DHCP；以及有意识地设定 MQTT 保活间隔，而不是沿用库的默认值。

我们的做法是按产品定义的工作周期先算理论续航，再用实测校正，因为数据手册的典型值和接上真实传感器后的实测值经常差得远。这和我们在其他低功耗平台上做物联网终端的方法一致——RTC 定时唤醒加射频按需启动，才是几个月续航的实现方式。

USB-OTG 到底值多少

S3 的原生 USB 把 USB 转串口桥接芯片从 BOM 里去掉了，这笔料钱不多，但实际价值比元件成本大。

它让 USB 固件升级变得直接，不需要桥接芯片，也不用把 UART 引脚暴露出去。它让产品可以呈现为复合设备——用大容量存储提供日志或配置文件、用串口提供诊断、用 HID 做简单控制——从而把一个定制的上位机工具，换成任何技术员都会用的东西。到了产线上，烧录工装也更简单。

代价是设计上要上心：USB 是差分接口，有 ESD 要求、连接器机械要求，还要在用户插入任意一条线缆时都能正常枚举。防护器件紧贴接口放，差分对走短走等长，并且要用不同品质的线缆测试，而不是只用台面上那条好线。

端侧推理：向量指令什么时候真正有用

S3 的向量指令加速的是小型神经网络中占主导的那些运算，乐鑫的工具链也支持部署量化模型。在适配的产品上——关键词唤醒、基于少量传感器的存在或手势分类、简单的视觉检查——它可以免去一次云端往返，以及随之而来的延迟、成本与隐私暴露。

工程上的现实是：模型必须从一开始就按预算来设计。int8 量化、剪枝、输入分辨率与特征提取方式，共同决定模型能不能装进内存与延迟的信封里。我们做边缘 AI 的方式是把模型和硬件当作同一个设计问题：在投入训练之前，就按芯片内存与产品延迟要求把模型规模定下来，而不是训练完再说。

也要诚实地说清天花板。S3 是一颗单片机。需要真正 NPU 或 GPU 的负载——持续视频分析、大模型——属于应用处理器的范畴，比如我们同样在做的瑞芯微或树莓派平台。为一件 S3 干不了的活选 S3，浪费的时间比选一颗更贵的芯片所多花的钱更多。

配网与量产

联网产品要让终端用户能把它接进自己的网络，消费类产品往往就在这一步丢客户。买回家十分钟内上不了网，产品其他方面做得再好也没用。

S3 产品常见的几条路：SoftAP 配网，设备开一个临时热点并提供网页；BLE 配网，手机 App 通过蓝牙会话下发 WiFi 配置；以及扫码辅助流程，免去手输 SSID 和密码。App 侧的配网我们有量产交付——在 433MHz 安防联动系统里，Flutter App 扫码绑定设备，再用 WiFi 扫描引导接入，去掉了容易出错的手工输入环节。无论走哪条路，设计规则一样：每一步失败都必须给出明确反馈和下一步出路，日志要能分清失败出在设备还是网络。

量产还有自己的清单：产线烧录与测试、逐台的凭据与证书、MAC 与序列号管理，以及一条在现场真的能用的固件升级通路。S3 支持安全启动与 Flash 加密，这两项要在设计阶段就决定，因为事后启用会改变配网流程，而且对单台设备可能是不可逆的。

一份简短的实战清单

• 带屏、要 USB、要端侧推理的选 S3；纯联网节点选更便宜的乐鑫型号。
• PSRAM 的类型与容量，按写下来的内存预算定，在 UI 设计之前。
• 按分辨率、色深与帧率算出显示带宽，再去订面板。
• 续航先按占空比算，再用真实硬件上的实测电流校正。
• 用原生 USB 做升级与诊断，并把 ESD 与布线认真做好。
• 模型规模在训练之前就按芯片定下来，不是训练之后。
• 安全启动与 Flash 加密在设计阶段决定，它们会影响产线流程。
• 配网流程要按失败来设计，因为真实用户正是在这一步遇见产品。

如果你正在规划一款 ESP32-S3 产品，希望固件、板子与 App 由同一支团队承接，我们的固件开发服务覆盖从选型到量产支持的全过程。