做硬件原型时，选开发板经常会被两个方向拉扯。一个方向是尽量小，最好一开始就像最终产品；另一个方向是尽量好调，屏幕、接口、供电、示例代码都要方便。真开始动手以后，我更倾向于后者。早期原型不是为了证明外壳有多小，而是为了尽快确认传感器能不能读、数据显示是否稳定、网络是否能连、页面能不能看到真实数据。

这也是我先用 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 作为 SCL，SDI 接 GPIO8 作为 SDA，SDO 接 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 属于后者。它不够小，但足够好调；它不够像产品，但能让我更快看到状态；它不是最终答案，但能把后续问题暴露出来。

如果你也在做类似的环境传感器项目，第一块板子不一定要追求最小。先问自己几个问题：能不能看见状态？能不能接传感器？能不能联网？能不能快速烧录？出问题时有没有足够的日志和页面可查？

这些问题回答清楚以后，再谈小型化会更稳。否则很容易把时间花在外观和结构上，最后发现最基础的传感器数据还没有真正跑顺。