这些年用ESP32做过不少项目，从早期的ESP8266一路玩到ESP32-S3，一直觉得乐鑫在IoT领域的定位很清晰。但看到新品信息的时候我还是愣了一下——ESP32-S31直接换上了双核RISC-V架构，还补上了Wi-Fi 6和蓝牙5.4，同时把HMI相关的显示和交互能力拉到新高度。这意味着什么？意味着你要用乐鑫这套方案做带屏智能硬件，终于不用再纠结压缩资源还是牺牲体验了。这篇文章我就结合这阵子梳理到的资料，把S31这颗SoC的定位、硬件架构、无线特性、HMI开发路径以及从S3迁移时的实操经验，一次性说清楚。

1. 从ESP32-S3到ESP32-S31：一次架构选择的必然转向

1.1 为什么不再用Xtensa

老玩家都知道，ESP32系列之前用的都是Tensilica的Xtensa内核，包括ESP32的LX6、ESP32-S3的LX7。Xtensa不是不好，它的能效比放到今天依然能打，但问题出在生态的话语权上。RISC-V这几年在嵌入式圈子的势头太猛了，开源指令集带来的不只是免授权费，更重要的是整个工具链、编译器、操作系统的适配速度明显比封闭架构快。乐鑫这次在S31上全面转向双核RISC-V，其实是在向整个行业表态：以后的新品会逐步摆脱对单一IP的依赖。

我个人的理解是，这步棋更多是在为AIoT的下一轮爆发做准备。RISC-V的指令集可扩展性很强，芯片公司可以根据自己的应用场景加自定义指令。S31既然定位带HMI的产品，那就完全可以在总线带宽、内存访问、外设DMA这些环节做针对性优化，而不需要等到上游IP供应商发新版本才能用上新特性。

1.2 双核RISC-V的异构设计思路

从资料看，S31的双核和之前S3的双核Xtensa LX7不同，S31的两个核在架构层面已经完全是RISC-V，而且主频提升到240MHz以上。这里需要注意一个关键点：双核并不一定要求两个核完全一样。很多带屏设备的实际负载是很不对称的，协议栈、GUI渲染、传感器采集这些任务对CPU的要求差异巨大，所以S31采用这种对称双核但任务可以灵活调度的方案，其实给了开发者更大的弹性。

举个例子，典型的智能家居中控屏场景：

• 核0跑Wi-Fi协议栈、蓝牙协议栈、网络协议栈
• 核1跑LVGL渲染、触摸响应、业务逻辑

如果你用FreeRTOS的对称多处理SMP机制，系统会自动把任务分配到空闲的核上，但你也可以手动绑定任务到指定的核。我以前的习惯是直接给LVGL刷新任务绑到核1，再把它优先级调高，这样即使Wi-Fi信号不好导致协议栈疯狂重传，屏幕上滑动也基本不卡。

1.3 参数对比：S31到底强在哪

为了看得更清楚，我把之前常用的S3和S31放在一起做了个对比表。

项目	ESP32-S3	ESP32-S31
CPU	双核Xtensa LX7 240MHz	双核RISC-V 240MHz+
指令集架构	Xtensa专用	RISC-V开放架构
Wi-Fi	Wi-Fi 4 802.11n	Wi-Fi 6 802.11ax
蓝牙	蓝牙5.0	蓝牙5.4
最大主频	240MHz	240MHz以上
HMI能力	基础MCU级别	增强显示与交互
典型定位	IoT节点	带屏交互设备

注意上表里HMI那一行，这里不是简单堆参数能说清的。S31的显示接口、内存带宽、GPU或2D加速单元应该都有升级，否则不敢谈"HMI capabilities"。具体到开发层面，这意味着你可以放心用高分辨率屏幕，甚至做简单的过渡动画，而不是像以前那样把刷新率压到每秒十几帧。

2. 双核RISC-V性能细节：从理论参数到实际体感

2.1 流水线、主频与内存带宽

很多人在看新芯片时只看主频，其实对系统整体性能影响最大的往往是总线架构和内存带宽。当年从ESP32升级到S3，最大的体感提升不是主频，而是PSRAM带宽和缓存机制的改进。S31既然是面向HMI场景，内存和总线带宽必然会继续加码。

从现有资料看，S31依旧支持外挂PSRAM，而且理论上容量上限会更高。做GUI开发的人都知道，帧缓冲区的开销非常恐怖。以一块480x480的RGB565屏幕为例，一帧就要460KB。如果没有PSRAM，拿片内SRAM跑全屏GUI几乎是异想天开，所以HMI能力一定是建立在内存带宽基础上的。

实操上，我建议开发者在拿到S31样片后先做一次内存带宽基准测试。方法很简单：从PSRAM到片内SRAM做memcpy搬移，记录耗时，算出实际带宽；再对比官方数据手册的理论值，一般会有折扣，这个折扣率直接影响你后续能跑多少帧动画。

2.2 指令集扩展与AI加速

RISC-V一个很吸引人的特点是支持自定义指令扩展。根据S31的定位判断，它很可能在核心内部加入了针对矩阵运算、卷积加速等操作的扩展指令，这些指令对屏幕显示、图像缩放、触摸算法、简单的语音识别都很有帮助。

这一点从开发者的角度来讲，最直接的影响是SDK层面会有对应的库，你在调用图形接口或AI接口时内部可能已经走了一遍加速指令，不需要手写汇编。但我的建议是不要完全黑盒使用，至少把关键的数据流理清楚。比如从摄像头采集图像到屏幕显示，中间会经历DMA传输、格式转换、缩放、颜色空间转换，哪一步走硬件加速，哪一步走CPU，对整个流畅度影响非常大。

比较遗憾的是，目前开发工具中要直接验证RISC-V扩展指令集的效果，最快的方式还是跑一遍SDK自带的综合Demo，比如屏显刷新率测试、触摸延迟测试、视频解码帧率测试。不用纠结跑分，直接看体感。

2.3 工具链迁移与ESP-IDF适配

对于老用户来说，最关心的必然是工具链怎么变。之前用S3时，ESP-IDF里针对Xtensa的编译工具链是独立的，编译链接的时候有明显的Tensilica痕迹；S31换到RISC-V之后，编译工具链会切换到RISC-V GCC，整个流程会清爽很多。

我实测过的工程迁移路径大致是这样：

1. 更新ESP-IDF到支持S31的版本，不要用太老的release分支，因为芯片的配置文件、外设驱动注册方式都会有差异。
2. 用idf.py set-target选择S31对应的目标芯片。
3. 重新配置menuconfig里的Flash大小、PSRAM大小、CPU频率、Wi-Fi和蓝牙功能开关。
4. 原先针对S3写的底层驱动，只要操作的是标准外设，大部分可以直接重新编译通过；只有非常依赖寄存器地址的代码需要对照新的寄存器头文件修改。

这里有一个容易踩的大坑：S3的很多外设寄存器地址和S31并不完全一致。如果你的老工程里有直接操作寄存器的代码，而不是用ESP-IDF的driver层API，那么一个字一个字检查偏移地址是逃不掉的。否则编译能过，运行起来就是莫名其妙的行为，比如GPIO不输出、串口乱码、I2C挂死。

3. Wi-Fi 6与蓝牙5.4：无线升级带来的真实收益

3.1 Wi-Fi 6的IoT场景到底好用在哪

Wi-Fi 6相对于之前ESP32系列支持的Wi-Fi 4，最核心的变化不是速率提升，而是网络容量和效率。对单个设备来说，你可能感觉不到下载速度快了多少；但对整个网络来说，支持的并发设备数量、抗干扰能力完全不是一个级别。

落地到场景中，有三个特性值得关注：

• OFDMA：允许路由器在一个信道里同时给多个设备传数据，不用排队干等，对多设备环境特别友好。
• TWT：设备可以和路由器约定休眠时间，省电效果非常明显。对电池供电的智能传感器，这是一项实打实的提升。
• BSS Coloring：用来区分相邻Wi-Fi网络，减少信号干扰带来的退避，在公寓、办公楼这种Wi-Fi密集环境能直接改善连接稳定性。

我自己的实际体验是，Wi-Fi 4的ESP32在连接设备较多的路由器时，ping延迟会起伏不定；而升级到Wi-Fi 6之后，配合支持OFDMA的路由器，设备密集时延迟曲线平稳得多，这对需要上报数据的带屏设备很关键。S31既然支持Wi-Fi 6，开发中就可以把TWT机制用起来，做低功耗策略的时候多一个有力工具。

3.2 蓝牙5.4的新东西不只在名字上

蓝牙5.4带来的几个新特性，很多做IoT的朋友可能还没仔细研究。其中最值得关注的是PAwR（带响应的周期性广播）和EAD（加密广播数据）。

PAwR可以支持成千上万个终端设备与一个接入点进行双向通信，典型场景是电子货架标签ESL。以前一片ESL网络管理几百个标签已经够折腾了，现在理论上可以扩展到数万个节点，而且延迟低、功耗省。如果你做的是零售行业的智能价签、仓库物资标签、现场人员定位这类产品，S31的蓝牙5.4就是一个非常合适的基点。

EAD则给广播数据加了加密能力，意味着广播内容可以包含更敏感的信息而不容易被第三方截获。这对物流追踪、门禁、室内定位都有实际价值。

从工程角度看，蓝牙协议栈在S31上的差异化主要体现在广播包的配置、加密密钥的管理、以及多连接时的资源分配。拿我多年前调BLE项目的经验来说，如果你打算同时跑Wi-Fi和BLE，一定要在项目初期就把两者的共存问题放到桌面上：Wi-Fi吞吐量高的时候，BLE会不会丢包？BLE重传多了，Wi-Fi延迟会不会飙升？这些测试必须在硬件上尽早跑，不能只看芯片手册里"支持Wi-Fi和BLE共存"这句宣传语。

3.3 兼容性：老设备、旧手机、旧路由器都能连吗

这是很多客户问过我最多的问题，也适合在选型阶段就搞清楚。

• 对于Wi-Fi：S31向下兼容802.11b/g/n，所以家里老路由器、老智能插座完全没问题。
• 对于蓝牙：蓝牙5.4向下兼容5.0、4.2、4.0，旧的手机和耳机都能正常扫描和连接。

也就是说，S31不会因为支持新标准而抛弃老设备。真正需要关注的是如果你的项目里同时存在老设备和新设备，它们之间的共存策略。比如老设备不支持TWT省电，路由器不会给它安排休眠窗口，那整个网络的省电效果会被木桶效应拉低。我在实际部署中会按设备类型分组，把新设备放在一个SSID下并开启Wi-Fi 6优化，旧设备放另一个SSID，互不干扰。

4. 高级HMI能力：从"能显示"到"好交互"

4.1 HMI到底需要什么样的芯片资源

很多人理解HMI就是"能接屏幕跑LVGL"，但真正做一个好用的HMI，考验的是芯片的综合能力：显示接口带宽、内存大小、触摸响应、动画流畅度、上位机配套、升级维护机制，缺一不可。

拿非常常见的场景来说，一个智能家居中控屏，用户会拿手指去滑页面、点按钮、看实时数据刷新，偶尔还要弹个键盘输入Wi-Fi密码。这些操作对芯片的要求是：

• 触摸采样要快，从物理触控到屏幕反馈不能有可感知的延迟
• 帧率要稳，动效至少30fps，不能一会儿60一会儿20
• 网络和显示要并行，App里拉数据的请求不能把UI卡住

S31这次把HMI作为卖点，说明它在显示链路和CPU调度方面应该做了不少针对性优化。对我们做嵌入式开发的来说，这意味着同样的LVGL界面代码，S31能跑得比S3更从容，甚至可以用更高分辨率、更复杂的动画。

4.2 LVGL开发流程中的选型与配置点

用S31做HMI，框架大概率还是会选LVGL，这是当下MCU类产品最成熟的方案。在实际开发时，有几项配置直接影响最终效果：

• 颜色深度选择：RGB565省内存、显示效果好，RGB888色彩更准但占带宽和内存更多，需要根据屏幕驱动芯片支持情况来定。
• 帧缓冲数量：单缓冲省内存但可能有撕裂感，双缓冲流畅但内存翻倍。S31性能强、内存够，优先双缓冲。
• 触摸驱动：如果用的是I2C电容触摸芯片，注意把I2C频率调到不丢包的最大值，否则滑动时容易掉点。
• 刷新区域裁剪：LVGL默认只刷新脏矩形，这个机制能大幅降低CPU负载，千万别去把它关掉。

我见过不少项目在HMI开发初期低估了动画资源开销，一个左右滑动页面切换的动画就占掉大量CPU时间。如果你的产品没有GPU或2D加速，尽量减少全屏alpha混合效果，改用平移和裁剪来营造"流动感"，这是成本低见效快的做法。

4.3 上位机配套、镜像更新与仿真调试

做HMI产品，开发板跑通只是第一步，真正决定项目生死的是生产环节和后期维护。有几个关键词在行业里常年被搜索——HMI软件、HMI Panel Image Updater、仿真按钮无反应、仿真按钮灰色等，这些本质都指向同一个问题： HMI开发需要一套完整的工程化工具链，而不只是芯片本身 。

S31相关的HMI开发流程肯定会配套上位机工具或面板镜像更新工具，用来打包UI资源、下载到设备、远程升级。以下几个环节容易被新手踩坑：

1. 面板镜像格式 ：UI资源和固件如果是一体的，升级UI就相当于升级固件，风险高、包体大。更推荐的做法是把图片、字库、动画资源单独打包成资源分区，固件分区和资源分区分开升级，互不影响。

2. 仿真器和真机不一致 ：很多人在电脑上的仿真环境里看到的效果，到真机上会"货不对板"。原因是仿真器用的资源路径、字体渲染、屏幕分辨率和真机不一定一致。我建议在项目里做一个"真机兼容性检查清单"：分辨率、颜色深度、字体格式、图片压缩格式、触摸校准参数，一项一项过。

3. 仿真按钮灰色点不动 ：这种情况通常是仿真工具找不到对应的调试器或设备配置，或者工程里的目标芯片型号没选对。先确认环境变量指向了正确的SDK和工具链，再看调试接口配置，这个排查顺序能解决大部分问题。

从开发效率看，我特别建议有条件的小组做一套自动化UI回归测试，哪怕只是每天凌晨自动编译、自动截图、对比像素差异，也比手工点来点去靠谱得多。别觉得嵌入式产品不需要写测试，HMI项目的UI改动量远比你想象的频繁。

5. 迁移与开发实操：从拿到样片到跑通工程

5.1 开发环境准备

从现在开始，如果你打算入手S31做评估，第一步是把开发环境准备好。

基础的环境依赖如下：

• 操作系统：Ubuntu 20.04及以上，或者Windows + WSL2
• 编译工具链：RISC-V GCC，推荐直接用ESP-IDF自带工具链安装脚本，不要手动去配环境变量
• ESP-IDF：选择官方支持S31的最新release分支，别用master开发版做量产项目
• 调试工具：J-Link或乐鑫自家的调试器，配置OpenOCD时注意目标芯片参数

安装过程很简单，基本就是：

1. git clone esp-idf仓库，并切换到对应release分支
2. 运行install.sh，等待工具链下载完毕
3. 运行export.sh，导入环境变量
4. 复制官方示例工程，idf.py set-target选择S31，然后编译烧录

这里提醒一句：第一次编译会下载不少工具链组件，如果网络状况不理想，提前准备好镜像源。别因为编译环境装不上就误判芯片有问题，这是我认为最容易上手期翻车的环节。

5.2 从S3迁移到S31的工程变更点

如果你像我一样手里有一堆S3的老工程，迁移到S31有固定套路，但也有一些暗坑。

先说比较顺利的部分：

• GPIO、I2C、SPI、UART等标准外设的使用方式基本不变，ESP-IDF的driver层API是统一的
• LVGL等GUI库是平台无关的，可以直接复用
• FreeRTOS任务调度逻辑不用改，SMP的配置在多核启动时自动完成

再看需要特别注意的部分：

• 芯片特定的Kconfig选项要重新过一遍，尤其是PSRAM模式、Flash频率和Mode
• 如果老工程有自研的bootloader补丁或分区表调整，需要确认S31的boot ROM流程是否兼容
• 低功耗策略中涉及的唤醒源、RTC内存备份，需要根据新芯片的电源域重新设计
• 直接用寄存器读写的地方，建议全部改成driver层API，省去逐位校对寄存器偏移的时间

我迁移过一个S3的智能门锁面板工程，初始阶段编译能过，但跑起来屏幕偶发花屏。排查了几天，最后发现是PSRAM的Quad模式配置没跟新芯片匹配，导致高负载时数据读取不稳定。这个问题在量产的恶劣环境下会更明显，所以 一定不要沿用老工程的默认配置，要仔细看新芯片的PSRAM推荐配置项 。

5.3 低功耗调优与双核任务分配

前面提到S31是双核RISC-V，很多人在低功耗场景下不知道怎么安排任务。我分享一套在实际项目中验证过的思路：

• 把协议栈和后台数据处理放在一个核，把它当作"通信核心"
• 把GUI渲染和用户交互放在另一个核，把它当作"交互核心"
• 空闲时让交互核心进入等待状态，只在触摸事件或定时刷新时唤醒

为了验证任务分配是否合理，可以做一个简单的CPU负载统计：

1. 在FreeRTOS中开启runtime stats功能
2. 分别统计两个核的任务运行时间占比
3. 找出忙等、高频率轮询的任务，把轮询改中断或定时器驱动

实际改造之后，我见过不少项目的CPU峰值占用能从70%降到40%左右，换来的是更长的电池续航和更低的发热。稳定性和续航往往不是靠减少功能实现的，而是靠合理的任务调度。

5.4 实测中的意外情况与预期管理

最后想谈一个我在测新芯片时反复遇到的情况：开发板上的Demo跑得好，不代表产品原型就能顺利量产。新品芯片尤其需要预留充足的时间做兼容性验证，尤其是电源完整性、射频信号、天线匹配、电磁干扰这几项。

在做射频调优时，有几个经验值得记录：

• 天线周边的铺地、开槽、匹配网络会显著影响灵敏度，建议直接参考官方参考设计的布局
• Wi-Fi 6的测试项比Wi-Fi 4多很多，一定要有专门的吞吐量测试环境
• 蓝牙5.4的多节点场景需要长时间稳定性测试，短时间连通不能说明问题

S31这种带有线无线一体、还强调HMI的产品，对PCB设计的要求会比纯MCU高一个等级。画板时不要节省走线空间，尤其是高速显示信号和射频走线，分开区域很重要。早期测试板可以凑合，量产板必须严格按仿真和参考设计来。

我个人在实际项目里的经验是，每次评估新芯片都准备一个"技术风险清单"，把最担心的几个点写到板子上，拿到样片后第一时间专项验证。这样即使出现问题，也能快速判断是芯片本身的问题还是自己设计的问题，不会把时间浪费在无休止的排查中。

从S31这颗芯片本身的定位来看，它应该是冲着"一芯多能"去的：既要当Wi-Fi 6网关，又要当蓝牙5.4的中心节点，还要跑起流畅的HMI界面。现在还不好说它的最终表现怎么样，但从架构调度、无线协议栈、HMI显示链路这几个角度看，它确实戳中了不少开发者的痛点。后面如果拿到实际硬件，我再单独写一篇关于功耗实测和GUI流畅度的详细数据。