从原理图到仿真：STM32环境监测开源项目的完整拆解

最近把一个基于STM32F103C8T6的环境监测小板子彻底开源了代码、原理图、仿真工程一口气全部打包放出来。开源之后陆陆续续收到不少私信问的最多的不是“这个项目能干什么”而是“我照着你的工程做为什么跑不起来”。这个问题其实挺有代表性的。很多刚接触STM32的朋友习惯性把开源项目当成一个黑盒下载代码、烧录、看现象出问题了就不知道从哪下手。而真正的做法应该是把项目拆成三块来看代码怎么组织、原理图怎么设计、仿真怎么验证。这三块是互相印证的代码里的每一个引脚定义在原理图里都能找到对应的网络连接仿真里的每一个波形变化都对应着程序里的某一段逻辑。你只看其中一块永远只能看到项目的三分之一。今天就借着这个开源的“STM32环境监测站”项目把这三块内容完整拆开讲一遍包括我在实际开发中踩过的一些坑希望能给准备上手嵌入式开源项目的朋友一点参考。1. 项目全貌一个STM32开源项目该怎么看1.1 项目背景与目标这个项目的定位很明确做一个低成本的STM32入门综合示例。硬件上用的是一块蓝板子级别的STM32F103C8T6最小系统板板载资源不多但通过外接传感器模块扩展功能。整体实现了三个核心功能超声波测距、环境温湿度监测、OLED实时显示同时通过USB虚拟串口把采集到的数据上传到PC端上位机。选择STM32F103C8T6而不是更新的G0、L4系列原因其实很朴素资料多、例程全、耐折腾。很多学习资料和开源工程都是以F103为基准写的新手遇到问题搜索解决方案时几乎每一条报错都能找到前人的经验。对于开源项目来说尽量降低读者复现的难度比追求硬件上的先进性更重要。整体架构上传感器层、处理层、输出层三层分开。传感器层包括HC-SR04超声波模块和DHT11温湿度模块处理层就是STM32的固件程序输出层是OLED屏幕和USB虚拟串口。信号流向很清晰传感器采集物理量主控解析数据显示和上传结果。1.2 硬件选型与整体架构硬件连接有一个基本原则数字传感器和简单外设优先使用普通GPIO模拟时序复杂外设和高速通信才占用硬件外设资源。原因后面会展开说先看这次的硬件方案外设型号/接口连接引脚说明主控STM32F103C8T6-64KB Flash20KB RAM超声波HC-SR04 / GPIO模拟时序PA1 (TRIG)PA0 (ECHO)5V供电需要电平兼容处理温湿度DHT11 / 单总线PB4单根数据线完成读写显示SSD1306 / I2CPB6 (SCL)PB7 (SDA)0.96寸OLED128x64分辨率串口USB转TTL / USART1PA9 (TX)PA10 (RX)通过CH340连接PC看到这个表格你会发现这几个外设居然没用到一个定时器输入捕获、没用到一个硬件I2C全部是GPIO模拟。这么做的原因有两个。第一这几个传感器的通信速率都不高DHT11的单总线波特率约等于只有几千bpsSSD1306的I2C用软件模拟跑100kHz也完全够用GPIO模拟的可靠性足够。第二用模拟时序写代码能够让你真正理解协议本身的时序逻辑而不是简单调用HAL库函数就完事。原理图设计上我是在嘉立创EDA里画的遵循的是最小系统加电源、外设接口分开布局的思路。电源部分用了AMS1117-3.3把USB的5V降到3.3V每个电源引脚旁边都放了0.1uF去耦电容基本上遵循了数据手册的推荐设计。外设接口全部做成2.54mm排针方便杜邦线连接。这套设计和市面上绝大多数STM32开发板的思路一致理解了一个其它都能看懂。2. 代码解析从外设初始化到多任务调度2.1 工程结构与模块划分代码结构上我用的是标准HAL库工程在STM32CubeMX里生成底层初始化然后自己编写业务逻辑。工程目录如下STM32_EnvMonitor/ ├── Core/ │ ├── Inc/ // 头文件 │ └── Src/ │ ├── main.c // 主逻辑轮询调度 │ ├── gpio.c // GPIO初始化CubeMX生成 │ ├── usart.c // 串口初始化CubeMX生成 │ └── tim.c // 定时器初始化 ├── Drivers/ │ ├── CMSIS/ │ └── STM32F1xx_HAL_Driver/ └── USER/ ├── app/ │ ├── ultrasonic.c // 超声波测距 │ ├── dht11.c // 温湿度采集 │ ├── oled.c // OLED显示 │ ├── usb_vcom.c // 虚拟串口逻辑 │ └── scheduler.c // 简单调度器主程序采用超级循环加时间片轮询的方式不跑RTOS。这种方案在资源紧张的MCU上很常见对于只有20KB RAM的F103C8T6来说跑一个完整的FreeRTOS虽然可行但留给业务逻辑的RAM空间就比较紧张了。调度逻辑很简单main函数里一个while循环分别调用超声波的测量函数、DHT11的读取函数和OLED的刷新函数每个函数内部有自己的时间戳判断到了采样周期才真正执行。这样做的核心思想是每个模块独立维护自己的“节拍”互不阻塞。比如OLED刷新是50Hz超声波测量是10HzDHT11读取是1Hz它们不需要严格的时序同步时间片轮询最合适。2.2 超声波测距模块的实现细节HC-SR04测距的原理一句话概括就是给TRIG引脚拉至少10us的高电平模块内部会自动发出8个40kHz的超声波脉冲并等待回波回波到达后ECHO引脚会输出一个与距离成正比的高电平脉冲测量这个高电平的持续时间除以58.2厘米每微秒就得到距离。uint16_t HC_SR04_GetDistance(void) { uint32_t startTick, waitTick, echoTime 0; // 触发信号拉低 - 拉高10us - 拉低 HAL_GPIO_WritePin(TRIG_GPIO_Port, TRIG_Pin, GPIO_PIN_RESET); delay_us(2); HAL_GPIO_WritePin(TRIG_GPIO_Port, TRIG_Pin, GPIO_PIN_SET); delay_us(10); HAL_GPIO_WritePin(TRIG_GPIO_Port, TRIG_Pin, GPIO_PIN_RESET); // 等待ECHO引脚变高 waitTick DWT-CYCCNT; while (HAL_GPIO_ReadPin(ECHO_GPIO_Port, ECHO_Pin) GPIO_PIN_RESET); startTick DWT-CYCCNT; while (HAL_GPIO_ReadPin(ECHO_GPIO_Port, ECHO_Pin) GPIO_PIN_SET) { // 防死循环超时处理Max距离约4m if ((DWT-CYCCNT - startTick) 4800 * 72) break; } echoTime (DWT-CYCCNT - startTick) / 72; // 转换成us if (echoTime 23000) { return 0; } // 超出量程 return echoTime / 58; // 单位cm }这段代码里用到了DWT-CYCCNT来做微妙级延时和计时这是一个很多人不知道的用法。Cortex-M3内核里有一个DWT计数器它以CPU主频为时钟自动递增溢出后自动回绕。用它做微秒级延时比HAL_Delay精确得多也省去了额外配置定时器的麻烦。注意需要在初始化时使能DWTCoreDebug-DEMCR | CoreDebug_DEMCR_TRCENA_Msk; DWT-CYCCNT 0; DWT-CTRL | DWT_CTRL_CYCCNTENA_Msk;不过这里有个细节值得注意HC-SR04模块是5V供电的而STM32的GPIO耐压只有3.3V如果直接把ECHO引脚接到PA0上长期使用有烧毁IO的风险。原理图里我在ECHO引脚上串了一个1k电阻再加3.3V稳压二极管做钳位保护。这在实际项目中很重要但很多教学性质的原理图不会画。2.3 DHT11单总线时序处理DHT11是单总线协议一条数据线既做输入又做输出时序要求比超声波更容易出错。读取一次完整数据需要主机拉低总线至少18ms作为起始信号释放总线后DHT11会回传80us低电平加80us高电平的响应信号然后依次输出40bit数据8位湿度整数、8位湿度小数、8位温度整数、8位温度小数、8位校验和。程序上的难点在于区分50us的“0”和70us的“1”。我的处理方式是在每一个bit的起始低电平之后测量高电平持续的时间如果大于60us判为1否则判为0。uint8_t DHT11_ReadData(uint8_t *humidity, uint8_t *temperature) { uint8_t data[5] {0, 0, 0, 0, 0}; // 起始信号 DHT11_SetPinOutput(); DHT11_SetPinLow(); HAL_Delay(20); DHT11_SetPinHigh(); DHT11_SetPinInput(); // 等待DHT11响应低电平 while (DHT11_ReadPin() GPIO_PIN_SET); // 响应低电平80us while (DHT11_ReadPin() GPIO_PIN_RESET); // 响应高电平80us while (DHT11_ReadPin() GPIO_PIN_SET); // 读取40bit数据 for (int i 0; i 40; i) { while (DHT11_ReadPin() GPIO_PIN_RESET); // 等待bit起始低电平 delay_us(30); // 采样点 if (DHT11_ReadPin() GPIO_PIN_SET) { data[i / 8] (data[i / 8] 1) | 1; } else { data[i / 8] (data[i / 8] 1); } while (DHT11_ReadPin() GPIO_PIN_SET); // 等待bit结束 } // 校验 uint8_t checksum data[0] data[1] data[2] data[3]; if (checksum ! data[4]) return 0; *humidity data[0]; *temperature data[2]; return 1; }DHT11协议中有一个常见陷阱读取过程中任何一次中断都可能导致时序错乱进而读到全0或者固定的错误值。所以我在读取DHT11期间关闭了所有可能产生中断的外设包括关闭SysTick之外的其他定时器中断。这里提一个比较好的习惯使用DHT11这类严格时序的传感器时尽量把读取操作放到采集任务中一次性完成避免在读取过程中被其它模块抢占CPU。之所以说“基于常见实践的补充”不同的DHT11模块存在个体差异应答时间和数据位时序会有微小的偏差。实测发现有些模块的高电平“1”只有55us严格按60us阈值判断可能误判。所以我加了一个容错连续读取3次取多数判定结果有效降低误码率。2.4 OLED显示与USB虚拟串口OLED显示用的是SSD1306驱动芯片0.96寸128x64。我选择I2C接口版本而非SPI版本原因是连线少焊接简单。软件模拟I2C的代码很简单核心就是控制SCL和SDA两根线的电平时序产生开始、停止和每个bit的传输。SSD1306本质上是一块128x64的显存你想要显示什么内容就往对应的显存地址里写数据。我把显示内容分成了三个区域第一行显示标题第二行显示超声波距离第三行和第四行显示温度和湿度。刷新策略是只在数据发生变化时刷新对应区域而不是每次都全屏刷新——这么做虽然OLED的反应速度足够全屏刷新但局部刷新能减少I2C总线的占用给其它任务留出更多的带宽。USB虚拟串口这部分STM32F103的USB模块如果选的是HAL库VCP的配置和回调处理会相对繁琐。F103没有内置硬件USB PHY它的USB是模拟全速设备需要外部晶振提供48MHz时钟这一点在原理图上已经特别标注把USB相关的晶振选择为8MHz通过PLL倍频到72MHz主频再经过USB预设分频器得到48MHz。如果晶振实际误差偏大PC端就可能出现无法识别设备或者反复断开重连的现象。实测最常见的原因就是晶振匹配电容焊错或者虚焊。3. 原理图设计从最小系统到完整评估板3.1 最小系统的三件套不管是什么样的STM32项目原理图里最基础的部分永远是这三块电源、时钟、复位/启动配置。电源部分STM32F103C8T6的工作电压是2.0V到3.6V常见做法是5V USB供电经过AMS1117-3.3稳压器降为3.3V给MCU供电。AMS1117的输出电容这里多说一句手册要求输出端至少接一个10uF的钽电容或者电解电容再并联一个0.1uF的陶瓷电容高频去耦。如果你只放了一个0.1uF的电容负载电流波动大时输出电压可能产生纹波极端情况下会导致MCU无故复位。我在这次项目中同时放了10uF和0.1uF两个电容实测纹波在30mV左右完全满足要求。时钟部分F103可以通过内部HSI启动但使用USB外设时要求时钟精度较高必须使用外部晶振。我用了一个8MHz的无源晶振并联两个20pF负载电容。注意8MHz晶振的两端要连接在OSC_IN和OSC_OUT引脚上这两个引脚同时还需要1MΩ反馈电阻连接在晶振两端这个电阻在很多精简版原理图里被省略了虽然大多数情况下晶振照样起振但长期来看可靠性不好。复位电路最简单就是一个10k上拉电阻加一个按键按键按下时NRST引脚接地即为复位。启动配置则需要特别注意BOOT0和BOOT1引脚的接法BOOT0接10k下拉电阻到GNDBOOT1同样下拉。两个引脚都用跳线帽引出方便后续需要串口ISP下载时切换启动方式。这里有一个新手常犯的错误BOOT0悬空不接。悬空状态下引脚电平不确定可能导致芯片进入ISP模式而不是Flash启动模式表现就是程序烧进去完全不跑。3.2 电源电路与去耦设计电源设计是原理图里最容易被低估的部分实际上电源处理得好不好决定了一个板子扎不扎实。这次项目的电源输入是USB 5V分成了两个分支一路通过AMS1117-3.3给STM32和OLED供电另一路直接给HC-SR04模块供电。为什么不让AMS1117统一给所有设备供电因为HC-SR04的超声波发送瞬间电流可达几十毫安如果和MCU共用同一条3.3V电源轨这个电流冲击可能会在电源线上产生毛刺干扰MCU的工作。所以我把模拟传感器和数字主控的电源在物理上隔离开虽然共用一个输入端但经过各自的滤波电容和磁珠再进入设备。去耦电容的布置也有讲究每个VDD引脚旁边放置一个0.1uF的陶瓷电容且电容要尽可能靠近引脚放置连接线尽量短直。PCB布局时如果去耦电容和MCU引脚之间有较长的走线电容的去耦效果会大打折扣高频噪声依然会进入芯片内部。电源入口处再加一个10uF的钽电容做低频储能这样高低频去耦都有了。还有一个容易被忽略的细节是VCAP引脚。STM32F103C8T6内部有一个1.8V核心电源稳压器VCAP引脚需要外接一个2.2uF的电容到地这个电容不能省略也不能减小容量否则内部稳压器可能工作不稳定导致芯片运行时异常复位。很多“最小系统板”的原理图应该都包含这个电容但新手自己画板子时常常漏掉。3.3 外设接口的电气设计要点外设接口部分是原理图设计的精华也是最体现工程经验的地方。先说SWD调试接口。这是我最推荐的下载调试方式仅需四根线SWDIOPA13、SWCLKPA14、GND、3.3V。另外最好引出一个NRST引脚用于调试器复位目标芯片。这些引脚需要接上拉电阻吗数据手册上建议SWDIO和SWCLK可以不接上拉因为ST-Link调试器内部已经有上拉。但我在实际项目里给这两根线都加了10k上拉电阻原因是给STM32的供电断电或调试器单独接电时引脚状态不稳定可能导致调试器识别失败。再看超声波模块的接口。HC-SR04的ECHO输出是5V电平而STM32的PA0是3.3V容忍引脚虽然兼容5V输入但长期直接连接还是存在漏电流风险。原理图中我在PA0和ECHO之间串联了一个1k电阻并在PA0引脚对地并联了一个3.3V稳压管这样当ECHO输出5V时PA0处被钳位到3.3V保护了引脚。TRIG方向是STM32输出5V不兼容不过因为TRIG只是输入信号模块内部的逻辑会把它当作高电平处理所以直接连接问题不大。DHT11的数据线也有讲究。DHT11模块本身内部已经带了上拉电阻所以MCU端不需要额外上拉。但单总线的设备对上拉电阻的阻值比较敏感如果是自己用裸DHT11元件搭电路需要在数据线上接一个4.7k到10k的上拉电阻到VCC。模块化的DHT11板子在出厂前已经处理好了直接杜邦线连接即可。OLED的I2C接口同理SSD1306模块板载了I2C上拉电阻。但注意如果OLED的供电电压和MCU不同例如OLED用5V供电I2C线上必须加电平转换或串联电阻分压否则I2C通信可能不稳定甚至损坏设备。本项目统一3.3V供电不需要额外处理。4. 仿真验证软件仿真与硬件实测的闭环4.1 为什么必须仿真仿真解决什么问题仿真环节在这个项目里起到的作用是“逻辑验证先行硬件调试兜底”。嵌入式开发的常态是代码写完直接上板子调试如果现象不对你很难判断是程序逻辑问题还是焊接问题。而仿真可以在硬件尚未焊接完成或者硬件出现故障时先把程序逻辑的bug过滤掉一部分。我常用的仿真工具是Proteus专业版支持STM32F103系列的仿真可以直接加载hex文件运行。在Proteus里搭建目标电路把STM32、HC-SR04、DHT11、OLED都拖到画布上连好线加载hex文件点击运行。如果OLED有显示、超声波距离数值在变化说明程序的主逻辑没问题。这时再回到实物板子上调试出现问题时就可以放心地把焦点放在硬件电路上。用Proteus仿真时有一个必须搞清楚的事情它仿真的是逻辑行为不是真实的电气特性。比如DHT11在Proteus里是理想模型可能不会出现实际模块那种时序抖动和偶发误码HC-SR04的回波时间也是理想参数。所以仿真通过不代表实机一定没问题反过来实机出现问题也不能直接归咎于程序。正确的定位方法是仿真当作逻辑检查工具实机调试当作电气验证工具两者互补。4.2 Wokwi在线仿真的实用技巧除了Proteus我还推荐一个在线仿真平台Wokwi。它支持ESP32、STM32、Arduino等多种主控不需要安装任何软件浏览器打开就能用。对这个项目来说Wokwi的优势在于支持搭配虚拟的逻辑分析仪和串口监视器方便查看时序波形。Wokwi的STM32仿真模型基于QEMU它在模拟外设行为方面做得相当细致。比如超声波模块在Wokwi里是一个虚拟器件你需要为它配置好触发引脚、回波引脚以及虚拟距离参数。在代码里修改距离后重新运行Wokwi会在虚拟的ECHO引脚上产生对应宽度的脉冲和真实模块的行为一致。我在调试超声波测距的代码时先用Wokwi跑了一遍把虚拟距离设为100cm程序计算出来98cm左右误差在可接受范围。然后又测了两个边界值2cm和350cm。2cm时程序依然能算出来350cm时已经接近HC-SR04的量程上限程序正确输出了超量程提示。这个边界测试在实物上操作难度较大——你很难在实验室里随手搭建一个精确的350cm测试环境但仿真里只需要拖动滑块。4.3 实物联调与数据对比从仿真回到实物这一步是每个做项目的人都会经历的一个关键环节。我建议采用“先静态后动态、先局部后整体”的调试顺序。静态调试先检查电源上电后用万用表测量3.3V是否正常、各个芯片的VCC引脚电压是否正常、是否存在短路。然后通过ST-Link连接目标板读取芯片ID信息这一步能同时验证芯片是否正常工作、SWD电路是否焊接正确。如果ST-Link Utility能正确识别到STM32F103C8T6的IDCODE说明芯片已进入调试模式最小系统没有问题。动态调试就是烧录程序看现象。我习惯分模块验证先烧录一个最简单的LED闪烁程序确认GPIO输出正常然后烧录OLED的I2C扫描代码确认OLED通信链路正常接着单独跑超声波代码通过串口打印距离值最后加入DHT11读取逐渐叠加所有功能。每一步的验证结果都有明确预期哪一步现象不对问题就锁定在哪一个局部排查范围很小。串口这个调试手段真的很重要。我在项目里加了一个调试宏通过串口输出每个模块的原始数据和解析结果。例如超声波模块不仅打印最终距离还会打印ECHO引脚的高电平脉冲时间微秒这样一旦距离值异常就能判断是触发信号的问题还是回波测量的问题。DHT11的数据也是先把5个原始字节全部打出来确认校验和正确再解析成温度湿度。实测数据对比下来超声波测距在20-150cm范围内测量误差基本在正负1cm以内DHT11的温度和标准温度计对比误差在正负0.5度左右湿度在高湿度环境下有滞后这是DHT11本身的特性。这些验证数据我在开源文档里全部标注清楚了读者在复现时如果测出来的数值偏差比较大至少能有一个参考基准。5. 常见问题与排查技巧实录5.1 ST-Link无法连接目标芯片这个问题的出现频率在所有问题里排第一通常有几种情况。最常见的是接线错误SWDIO、SWCLK、GND三根线没有一一对应其次是目标板供电不足ST-Link的3.3V输出电流能力有限如果板上还有其他大电流设备建议用外部USB给板子供电只连接SWDIO和SWCLK信号线共地仍然必须还有一种是芯片被锁死Flash里的程序把SWD引脚复用成了普通GPIO功能导致无法连接。排查思路检查IDCODE是否能读取如果完全检测不到设备先用万用表确认板和ST-Link之间的连接线是完好的。如果IDCODE能读到但下载失败看一下Flash写保护是否开启用ST-Link Utility全片擦除后再尝试。最后如果把BOOT0拉高再上电芯片进入ISP模式SWD引脚不再被用户程序占用此时尝试连接成功率会大幅提升。5.2 超声波测距数值乱跳或固定显示0超声波数据不稳定的情况分几种。第一种是供电不足HC-SR04在发射时电流需求较大如果供电线太细或者电源模块负载能力弱发射瞬间电压跌落会导致回波信号异常。第二种是测量环境中存在障碍物反射干扰超声波经过多次反射后到达接收头测出的距离可能是实际距离的几倍。程序里可以对相邻两次测距结果做差值限制突变过大时判定为无效数据。还有一种容易被忽略的情况ECHO引脚接到STM32上没有做保护电路长时间5V电平输入导致PA0引脚内部保护二极管漏电回波信号低电平无法正确识别程序一直卡在等待回波超时输出0。加了钳位保护以后这个问题就没有再出现过。噪声消除方面我加了一个简单有效的滤波算法连续测5次去掉最大值和最小值取剩下3次的平均值。这个中值平均滤波法的好处是用代码就解决了大部分随机噪声问题不需要额外硬件。5.3 仿真通过但实机不工作的排查思路仿真通过但实物不工作这个问题在博客评论区讨论得很热烈。我的经验判断顺序是电源和时钟是第一排查对象。先用示波器看8MHz晶振的波形如果起振正常示波器上能看到频率为8MHz的正弦波。没示波器的话可以写一个测试程序让PA8引脚输出PWM波形如果PA8有输出说明HSE已作为系统时钟源正常启用。第二排查启动配置确认BOOT0确实为低电平。这里有一个常见翻车场景BOOT0引脚接了下拉电阻到地但是PCB板上这个电阻虚焊了芯片上电后BOOT0浮空恰好被干扰拉高进入ISP模式。表现就是仿真烧录的flash程序完全不跑但ST-Link还能正常连接。第三排查复位电路尽量避开一个典型的坑复位引脚的电容过大超过1uF导致上电瞬间NRST引脚电位跌落速度过慢芯片一直处于复位状态。实测100nF电容的复位时间是几毫秒完全够用。如果你用了10uF电容或复位引脚上还并联了大电容做防抖芯片上电后会延迟很久才运行甚至让人误以为压根没工作。5.4 DHT11数据一直为0或校验错误DHT11在实机调试中读不到数据的情况我总结下来有两类原因。一类是模块电路本身的问题。DHT11模块的数据线并联的电阻阻值不对或者上拉电阻根本没有接。如果模块是自己焊的裸DHT11元件一定要确认数据线有一个4.7k到10k的上拉电阻到VCC。没有这个电阻单总线在释放状态时电平是浮动的从机的响应脉冲无法形成明确的高电平主机程序就会一直卡在等待响应。另一类是程序时序问题。前面2.3节里提过读取DHT11期间要避免中断干扰。如果你的工程里开了几个定时器中断恰好中断频率很高DHT11的时序就很容易错乱。解决思路是读取DHT11之前屏蔽中断读完恢复或者把DHT11读取放到中断优先级最低的任务里这样即使被打断也至少能保证在下一个采样周期完成读取。还有一点容易误导很多例程里DHT11读取失败直接返回0然后主程序把0显示在OLED上。这样就会同时显示“温度0度湿度0%”的荒谬结果。我的代码里加了一个持续失败计数连续3次读取失败才认为模块故障在OLED上显示“DHT11 ERR”如果是偶发失败则保留上一次的正确数据这个设计明显更合理实用。写在最后的一些实际感触项目开源之后我在配置文件和README里反复强调了一句话不要只盯着代码跑起来把仿真、原理图、代码三样东西对照着看一遍收获会比单独调通程序大得多。这次分享的“STM32环境监测站”虽然功能简单但从传感器选型、原理图设计、代码实现到仿真验证每一步都尽量做到“知其然也知其所以然”。偶尔也会遇到读者问我“为什么你的原理图不用更高级的电路仿真软件”我个人的看法是工具只是一个载体关键是你是否清楚每个元件在电路中的作用。如果你能把自己画的原理图里的每一个电阻、电容都讲明白为什么需要它那你拿着这张图做出来的板子成功率会比照抄一份复杂的参考设计高得多。后续有时间的话我打算在这个项目基础上做一个升级版换成带蓝牙BLE的STM32WB系列或者把电源部分做成电池供电的低功耗版本。这些内容会继续以开源的方式发出来代码和原理图依旧一起打包。希望这两次分享能给正在嵌入式路上摸索的朋友一点点帮助。