开发板选型复盘：为什么我先用 ESP32-S3-LCD-1.47 做原型

做硬件原型时选开发板经常会被两个方向拉扯。一个方向是尽量小最好一开始就像最终产品另一个方向是尽量好调屏幕、接口、供电、示例代码都要方便。真开始动手以后我更倾向于后者。早期原型不是为了证明外壳有多小而是为了尽快确认传感器能不能读、数据显示是否稳定、网络是否能连、页面能不能看到真实数据。这也是我先用 ESP32-S3-LCD-1.47 的原因。它不是最终设备的形态但它适合作为第一块把事情跑通的板子。对环境感知这种项目来说第一块板子的价值不是“长得像成品”而是能帮我少猜一点、多看一点。我选板子时先看调试效率如果只看最终外观ESP32-S3-LCD-1.47 肯定不算小。它带一块屏幕板子上也有不少开发接口放到随身设备里显然不现实。但原型开发早期我更关心的是另一件事出问题时能不能快速知道问题在哪。环境传感器项目里可能出问题的地方很多。传感器没有响应可能是接线错了读数跳动可能是预热不够也可能是环境真的变了网页打不开可能是 WiFi 没连上也可能是 HTTP 服务没起来页面里没有数据可能是接口没返回也可能是前端没有正确解析。如果开发板没有屏幕很多时候只能接串口一点点看日志。串口当然重要但它不适合给每个状态都做直观反馈。有屏幕后至少能把设备当前 IP、联网状态、传感器状态和几个关键读数直接显示出来。这样一来很多低级问题不用打开电脑日志就能先判断方向。这块板子的价值就在这里它把硬件状态变得可见。早期调试时可见性比尺寸更重要。屏幕不是装饰它能少走很多弯路带屏幕的板子容易被误解成“为了好看”。实际做下来屏幕最有用的地方不是展示漂亮界面而是把几个关键状态固定显示出来。我最希望屏幕显示的是这些信息当前是否进入主程序WiFi 是否已连接当前 IP 地址BME690 是否读到数据温度、湿度、气体阻值是否在变化数据是否正在上传设备是不是处于配网模式。这些字段看起来很基础但调试时很救命。比如网页打不开时先看屏幕上有没有 IP。如果屏幕上都没有 IP就不要先怀疑网页代码如果屏幕上有 IP但网页打不开再去查 HTTP 服务和路由器网络。这里有个常见坑很多人一看到浏览器打不开页面就开始改前端、改接口、改跨域最后才发现设备根本没连上 WiFi。屏幕把这种问题提前暴露出来能少走不少弯路。WiFi 能力决定了它不只是串口小板如果这个原型只在串口里输出数据它就更像一个传感器实验。串口能证明驱动工作但很难证明后续页面、接口和数据展示这一层是否可用。ESP32-S3 自带 WiFi这一点让原型可以从“能读数”往“能被网页访问”走一步。我希望设备上电后至少能做三件事。第一没配置过 WiFi 时打开一个临时热点让手机或电脑连进去配网。第二连上路由器后在局域网里打开一个后台页面能看到传感器读数和设备状态。第三把最新数据上传到一个接口网页 Demo 不一定非要和开发板在同一个局域网也能看到硬件最新状态。这些功能不一定一口气做完但开发板必须支持继续往这个方向加。ESP32-S3 的 WiFi 能力刚好够用不需要额外加通信模块也不会让第一版硬件变得太复杂。不要低估板厂示例的价值这块板子最省时间的地方不是芯片本身而是有现成板级示例。带屏幕的开发板并不是插上就能显示LCD 初始化、背光、SPI 时序、LVGL 刷新、RGB 灯这些细节都要有人处理。如果从零开始写屏幕驱动当然能学到很多东西但对这个项目来说不划算。当前重点是环境传感器数据和网页展示不是重新造一套屏幕驱动。更现实的路径是先跑通板厂原始 Demo确认屏幕、背光和基础外设都正常再把不需要的功能删掉把自己的 BME690 采集和 WiFi 后台加进去。我通常会按这个顺序检查先跑空 ESP-IDF 工程看工具链是否正常 再跑板厂原始 Demo看屏幕和板级驱动是否正常 然后加入 BME690看 I2C 和传感器是否正常 最后再加 WiFi、网页后台和上传逻辑。这个顺序看起来慢其实最省时间。因为每一步只增加一个变量哪里坏了比较容易查。I2C 接口够用但接线要留余地BME690 这类传感器用 I2C 接起来并不复杂。当前接法里SCK 接 GPIO9 作为 SCLSDI 接 GPIO8 作为 SDASDO 接 GND 固定地址CS 接 3V3 进入 I2C 模式。真正容易踩坑的地方不在表格而在接线细节。比如 3V3 和 GND 常常不够用需要面包板或一分多杜邦线分出来。再比如 SDO 如果没接好I2C 地址可能和代码里配置的不一致。还有一个容易忽略的问题杜邦线太松时传感器并不是完全没数据而是偶尔失败这种故障比完全不工作更烦。所以我不建议一开始就把线塞进封闭外壳里。先在桌面上把 I2C 扫描、芯片 ID、连续读数都确认清楚再考虑固定结构。否则后面外壳装好了回头查一根线松没松会非常痛苦。为什么不直接用更小的板子当然可以用更小的 ESP32-C3、ESP32-S3 Mini甚至后续自己画板。但第一版不一定要这么做。更小的板子会把问题集中到供电、接口、显示、调试和外设扩展上。尺寸小了排查成本往往上升。早期原型最怕的是同时追求太多目标既要小又要能联网又要能显示又要能接传感器还要能长时间稳定运行。这样做很容易让问题互相干扰。比如数据异常时不知道是传感器问题、供电问题、外壳进气问题还是代码算法问题。我的取舍是第一版先用大一点、好调一点的板子把传感器到网页这一段跑顺。等数据路径稳定以后再换更小的板子做第二版。这样迁移时目标更明确只需要回答“怎样在更小硬件上复现已有能力”而不是从零摸索所有问题。这块板子也不是没有缺点选 ESP32-S3-LCD-1.47 并不代表它适合最终设备。它的缺点也很明显。首先尺寸和外观不适合直接做随身设备。开发板上的接口、排针和屏幕布局都是为了调试不是为了佩戴。其次功耗还需要单独评估。带屏幕的板子在调试时方便但如果后面要做随身形态屏幕常亮、WiFi 上传频率、传感器采样频率都会影响续航。第三板厂示例虽然省时间但代码结构不一定适合长期维护。拿来用之前要删掉不需要的功能把传感器、网络、界面逻辑拆开否则后面会越来越难改。第四开发板接口虽然方便但也容易让人忽视真实产品里的结构问题。比如传感器进气位置、外壳开孔、充电接口、震动提醒这些在桌面板子上都还没有真正解决。所以它适合做第一块验证板不适合直接假装成最终产品。我会怎么判断这块板子选得值不值判断一块开发板值不值得用不是看参数表有多漂亮而是看它有没有帮你更快排查问题。对这次原型来说我会看这些结果屏幕能不能稳定显示设备状态串口能不能持续输出 BME690 读数WiFi 配网能不能跑通局域网后台能不能访问网页能不能看到真实硬件数据出问题时能不能快速分辨是传感器、网络、屏幕还是前端问题。如果这些都能做到这块板子就完成了早期任务。它不需要在第一天就证明自己适合量产也不需要证明自己能塞进小外壳。早期开发板的任务就是把问题拆开让每一步都能被看见。照着选板时我会先列一张排查表如果重新选一块板子我不会只看芯片型号也不会只看店铺详情页里的参数。我会先列一张排查表看它能不能支持自己的调试方式。能不能稳定串口输出 有没有足够方便的供电方式 有没有现成屏幕或至少有状态灯 有没有 WiFi 或其他通信方式 传感器接口是不是好接 有没有官方或板厂示例 坏了以后能不能快速判断是哪一层问题。这张表比单纯比较主频和内存更实用。主频高一点不一定能帮你少踩坑但屏幕能显示 IP、示例能跑通 LCD、I2C 引脚好接这些会直接影响开发速度。这里还有一个经验第一块板子可以“笨重一点”但不要“难查一点”。早期原型最怕的是设备很小、接线很紧、状态不可见。一旦读数不对你需要同时怀疑供电、传感器、代码、网络和外壳排查会非常痛苦。我宁愿第一块板子看起来不像最终产品也不愿它让我每一步都靠猜。等传感器、屏幕、WiFi、网页这些基础能力都跑顺以后再把它迁移到更小的板子上反而更容易知道自己在删什么、保留什么。所以选板不是一次性决定未来所有形态而是给第一轮开发选一个好用的脚手架。脚手架可以不漂亮但必须稳、清楚、方便排查。这也是我后面继续沿用这块板子的原因它不是最小答案却能把问题暴露得足够早。写到这里选板子的思路其实很简单我现在更愿意把开发板分成两类一类适合做最终形态一类适合把原型跑通。ESP32-S3-LCD-1.47 属于后者。它不够小但足够好调它不够像产品但能让我更快看到状态它不是最终答案但能把后续问题暴露出来。如果你也在做类似的环境传感器项目第一块板子不一定要追求最小。先问自己几个问题能不能看见状态能不能接传感器能不能联网能不能快速烧录出问题时有没有足够的日志和页面可查这些问题回答清楚以后再谈小型化会更稳。否则很容易把时间花在外观和结构上最后发现最基础的传感器数据还没有真正跑顺。