STM32传感器采集实战：从物理量到数字量的完整链路解析

把车停在露天停车场，回来拉开门的一瞬间那股热浪，我相信很多人都经历过。夏天暴晒几个小时之后，车内温度能冲到六七十度，坐进去第一件事就是开空调等半天。当时我就在想，要是有一个小装置能提前告诉我车外这会儿大概多少度、太阳晒得有多凶、有没有突然下起雨，那该多方便。

后来我自己动手用一块 STM32 做了个小终端，发现这件事的底层逻辑其实非常朴素：传感器负责感知车外的物理变化，STM32 负责读取、判断和响应。传感器是什么？简单说，它就是让单片机"长"出眼睛、耳朵和皮肤的那层器官。传感器把温度、距离、光照、震动这些物理量翻译成电信号，STM32 再把这些电信号读进来，变成代码里的一个变量、一次判断、一个动作。

这篇文章我想把整个链条拆开讲清楚：传感器和单片机之间究竟是怎么"交流"的，车外有哪些值得感知的信息，怎么把一个传感器真正接入 STM32 跑起来，以及我在实际调试中踩过的那些坑。如果你刚开始玩嵌入式，或者想给自己的项目加一个"感知外界"的能力，这篇应该能帮你省掉不少弯路的成本。

1. 传感器和单片机之间发生了什么：一条从物理量到数字量的完整链路

很多人第一次接触传感器，看了一堆数据手册还是不太明白：为什么温度变了，引脚上的电压也会变？为什么同一个传感器换个单片机，读数就完全不一样？要回答这些问题，得把传感器到单片机之间的完整链路走一遍。

1.1 传感器的本质：把"变化"翻译成"电信号"

传感器的核心是一个换能元件，它能把一种物理量变化转换成另一种更容易测量的物理量，绝大多数情况下是转换成电信号。拿最常见的热敏电阻来说，它的阻值会随温度升高而变化；再比如压力应变片，受外力变形时阻值也会变。这类元件本身并不"智能"，它只是对物理变化敏感，然后把变化表现在电学参数上。

你可以把传感器想象成一个翻译。外界的温度、光线、震动、距离是"外语"，电信号是"中文"，单片机只认中文，所以传感器的工作就是把外界的一切翻译成电信号。这个翻译过程有的传感器做得比较原始，只输出一个连续的电压或电流，这叫模拟输出；有的传感器内部加了模数转换和数字逻辑，直接通过 I2C、SPI、单总线或串口把处理好的数值发给单片机，这叫数字输出。

不少初学者有个误区，觉得"传感器的输出就是准的"。实际上，传感器只负责忠实反映它感知到的物理变化，准不准取决于换能元件的加工精度、标定质量、信号调理电路的噪声水平，甚至供电电压的稳定程度。你真正要做的是理解这条链路里每一环可能引入的误差，而不是盲目相信最后的读数。

1.2 一条完整的感知链路：五级拆解

从外界物理量到 STM32 内部的一个变量，完整路径大致是三步：

1. 敏感元件感知物理量，转换成微弱的电阻或电容变化。比如温度变化导致 NTC 热敏电阻阻值变化。
2. 信号调理电路把微弱变化放大、滤波，变成适合 ADC 采样的电压范围。很多数字传感器的内部就是干这个的。
3. ADC 采样把连续的模拟电压离散成数字量。STM32 自带的 ADC 一般是 12 位，也就是把参考电压等分成 4096 份。
4. 如果传感器自带 MCU，它还会做一点线性化、校准、单位换算，然后把结果通过某种协议发出来。
5. 单片机端收到原始数据或处理好的数据后，再根据自己的业务逻辑去使用。

我之前读过不少人的提问，经常看到"为什么我读到的温度是 4095 满量程"这类问题。十有八九是第二步出了问题：传感器的输出阻抗太高，或者分压电阻选得不对，导致 ADC 输入引脚直接被拉到了参考电压。换句话说，不是传感器坏了，是信号链断了或者信号链的静态工作点配错了。

1.3 为什么数字接口传感器更适合新手

如果自己的第一个项目想快速跑通，我建议优先选带数字接口的传感器，比如 DS18B20、DHT11、BMP280、AHT20 这类。原因很简单：你不需要处理 ADC 的换算和滤波，传感器已经把最难的部分封装好了，你只需要按照时序把数据读出来就行。

模拟传感器当然也不是不能用。光敏电阻、NTC 热敏电阻、电位器这类元件非常便宜，学起来也快，但它们的输出和供电电压、分压电阻、ADC 参考电压都有关联，一个环节没配好，数据就会漂。数字传感器在这些方面省心不少，代价是价格稍高一点，以及你需要严格按照时序协议去读它。

提示：选择数字接口传感器时，尽量选那些数据手册里写清楚了寄存器地址和采样时序的型号。有些传感器虽然也是数字输出，但寄存器说明藏起来或者只有英文资料，新手读起来很容易卡壳。

2. 车外到底有哪些值得感知的信息：一个车载小终端的功能拆解

说完了原理，我们落到具体场景：想让 STM32 知道车外发生了什么，到底需要感知哪些信息？不同的用车场景，关注点完全不同。

2.1 停车场景：震动、倾斜、距离和"安全感"

很多人改车载传感器，第一需求其实是停车监控。车停在路边，有没有被别人剐蹭，有没有人被碰到，车有没有被外力推动，这类事件在物理层面表现为震动和位移。

震动可以用振动开关或加速度计来感知。振动开关类似一个弹簧加金属球的机械结构，有震动时就导通一下，电路简单得很。加速度计则高端不少，它能输出三轴的加速度数据，你不仅知道"震了"，还能知道震动的方向和大致的剧烈程度。

倾斜传感器适合判断车是否被异常顶起或拖走。很多拖车场景下，车首先会被抬起一端，倾斜角会明显变化。用一颗带三轴加速度计的模块，通过计算重力在三个轴上的分量，就能得到当前的倾斜角度。

距离感知则更接近"近距离防撞"的需求。倒车时车尾离障碍物还有多远，停车入位时车头会不会碰到墙壁，超声波的测距模块（常见型号是 HC-SR04）就是干这个的。STM32 发一个触发脉冲，超声波模块发射声波并等待回波，回波的时间乘以声速再除以二，就是距离。

2.2 环境场景：温度、湿度、光照和雨滴

车外环境的感知是另一个大块。太阳暴晒时车内温度会非常高，提前知道车外的温度和光照强度，你就能在手机上判断"现在要不要先去挪车"。温湿度传感器我们后面会详细讲怎么接入。光照强度可以用光敏电阻，或者集成的数字光强度传感器，直接读取一个光照指数。

下雨是很多人容易忽略的感知点。车窗没关，雨突然下起来，如果车能感知到雨滴，就能及时提醒车主。常见做法是雨滴传感器模块，它的表面有两组露出的叉指电极，雨水落在上面会改变电极间的导电性，从而影响输出的模拟电压或开关信号。

2.3 一张表理清选型思路

为了让你对"车外感知"的全貌有个直观把握，我整理了一张表，按场景、传感器、输出类型和典型用途排列：

2.4 选传感器的五把尺子：量程、精度、接口、电压、成本

很多人选传感器只看精度，这其实是个误区。项目最需要的不是"最准"，而是"够用且稳定"。我一般按五个维度来筛选：

1. 量程：被测量的范围是否覆盖你的场景。比如车内温度可能到 70 摄氏度，你买一个量程上限 50 摄氏度的传感器就白搭。
2. 精度：看实际需求。只是判断"热不热""有没有下雨"，误差一两度、模糊一点没关系；如果是做数据统计分析，才需要高精度传感器。
3. 接口：数字接口和模拟接口，工作量差别明显。新手优先选数字接口。
4. 电压：车载环境下供电电压波动大，注意传感器的工作电压范围是否足够宽。
5. 成本：起步阶段没必要堆昂贵的高精度器件，一个十几块甚至几块钱的模块，足够让你把流程跑通。

注意：车载环境是强干扰环境，点火、用电设备启停都会造成电源电压波动和电磁干扰。传感器模块的电源端最好加一个 100nF 的退耦电容，必要时再加一颗低压差稳压芯片，否则你调了半天滤波算法，最后发现是电源纹波在作祟。

3. 把感知变成代码：STM32 读取一款常用传感器的完整过程

光讲原理和选型还不够，这篇文章的核心是"让 STM32 知道车外发生了什么"，所以必须落到具体代码上。我用最经典的单总线数字温度传感器 DS18B20 为例，带着你把它完整读一遍。

3.1 硬件连接：别小看一颗上拉电阻

DS18B20 有三只引脚：VDD、DQ、GND。VDD 接 3.3V 或 5V，GND 接地，DQ 是数据线，这个数据线同时负责供电和通信的部分功能。它工作在寄生供电模式下时，甚至可以只靠 DQ 和 GND 两根线工作。

接线的关键是 DQ 引脚必须接一个约 4.7kΩ 的上拉电阻到 VDD。很多新手直接用杜邦线把 DQ 接到 STM32 的 GPIO 上，发现读数全是 85 摄氏度，就是因为少了这个上拉电阻。85 摄氏度是 DS18B20 的上电默认值，说明你根本没有和它完成一次有效的通信，它只是在报告"我还没工作，先给你个默认值"。

STM32 这边，把 DQ 接到任意一个普通 GPIO，配置为开漏输出模式即可。为什么是开漏？因为单总线协议需要主机和设备都能拉低这根线，开漏模式配合外部上拉电阻，正好满足这种双向驱动需求。

3.2 软件读取的关键：单总线时序的实现

DS18B20 的通信协议叫单总线协议，核心特征就一条：靠拉低总线的时间长短来表达逻辑 0 和逻辑 1。具体来说，主机想发送一位数据的流程是：

• 先把总线拉低，然后延时一段时间。
• 如果延时约 60~240 微秒，释放总线，这一位就是逻辑 0。
• 如果只拉低 1~15 微秒，释放总线，这一位就是逻辑 1。

读取设备响应的原理也类似，主机拉低总线至少 480 微秒发起复位脉冲，然后释放总线，设备会在一段时间内把总线拉低，表示"我在"。

简单说，单总线对时序的要求很严格，延时函数必须准确。之前我用了一个不精确的软件延时，结果 DS18B20 经常读不到数据，后来换了定时器方式做微秒级延时，问题就消失了。这里给出一段基于 HAL 库的读取示例：

// 定义数据引脚 #define DS18B20_GPIO_PORT GPIOB #define DS18B20_GPIO_PIN GPIO_PIN_0 // 拉低/释放总线 static void DS18B20_SetLow(void) { HAL_GPIO_WritePin(DS18B20_GPIO_PORT, DS18B20_GPIO_PIN, GPIO_PIN_RESET); } static void DS18B20_SetHigh(void) { HAL_GPIO_WritePin(DS18B20_GPIO_PORT, DS18B20_GPIO_PIN, GPIO_PIN_SET); } // 读取一位数据：主机拉低1~15us，释放后采样 static uint8_t DS18B20_ReadBit(void) { uint8_t bit = 0; DS18B20_SetLow(); delay_us(2); DS18B20_SetHigh(); delay_us(5); bit = HAL_GPIO_ReadPin(DS18B20_GPIO_PORT, DS18B20_GPIO_PIN); delay_us(60); return bit; } // 初始化并读取一次温度值（单位：0.1摄氏度） int16_t DS18B20_ReadTemp(void) { if (!DS18B20_Reset()) return 0; // 跳过ROM匹配，只读一个传感器 DS18B20_WriteByte(0xCC); // 启动温度转换 DS18B20_WriteByte(0x44); delay_ms(750); DS18B20_Reset(); DS18B20_WriteByte(0xCC); // 读取暂存器 DS18B20_WriteByte(0xBE); uint8_t lsb = DS18B20_ReadByte(); uint8_t msb = DS18B20_ReadByte(); int16_t raw = (msb << 8) | lsb; return (int16_t)(raw * 0.625); }

这段代码在 72MHz 主频、HAL 库环境下可以直接跑通。需要留意的是 delay_us 的精度，建议用硬件定时器来实现，或者至少用空循环校准一次。

3.3 读到数据之后：怎么判断车外情况

读到一个温度数值本身没有意义，你得把它变成业务判断。比如我当时的逻辑是：

• 温度高于 55 摄氏度，屏幕上或串口输出"暴晒警告，建议挪车"。
• 温度在 25 到 40 摄氏度之间，正常。
• 温度低于 5 摄氏度，输出"低温提示，小心路面结冰"。

类似地，如果用超声波模块，读到距离小于 30 厘米时，可以触发蜂鸣器短鸣；如果用雨滴传感器，输出引脚变成低电平，就说明有水珠，输出"可能下雨"。

STM32 的串口在这里也非常重要。把采集到的数据打包成一行字符串，通过串口发到电脑的串口助手，或者通过蓝牙模块发到手机，你人不在车边也能看到车外状态。我一般习惯用这种格式：

printf("temp=24.5C humi=61%% dist=120cm rain=0\r\n");

这个串口输出是你整个系统调试和后续扩展的基础。数据上了串口，后面怎么处理都方便。

4. 读数不准背后是滤波、阈值与校准问题

代码跑通了，数据也出来了，但你会发现一个很现实的问题：传感器的数据没那么"干净"。同一个温度，一秒内跳来跳去；同一个光强度值，忽高忽低。这一章就是专门聊这些麻烦事。

4.1 传感器数值为什么会跳

传感器读数跳动的原因有很多。一种是传感器本身的分辨率有限，量化过程带来的小幅跳变，比如 12 位 ADC 在 3.3V 参考电压下，最低位代表的电压就有 0.8mV 左右，叠加上环境噪声，读数末尾几位不断变化很正常。另一种是传感器自热效应，芯片内部工作会产生热量，让温度读数略微偏高。

还有供电问题。如果传感器和继电器、电机共用一路电源，电机一启动，供电电压被拉低，传感器读数马上就偏。遇到这种情况，别先怀疑算法，先用万用表量一下供电电压在负载启动瞬间的波动幅度。

4.2 从"能读到"到"信得过"：滑动平均、中值滤波与迟滞比较

我自己常用的处理手段有三个，各有各的适用场景。

滑动平均适合温湿度这种缓慢变化的信号。维护一个长度固定的队列，新数据进来，最旧的数据移出去，输出队列平均值。这个办法简单又有效，缺点是有一定延迟，比如队列长度 10 个点，每个点采样间隔 2 秒，那输出会滞后约 20 秒。不过对于温度和光照这类变化慢的物理量来说，这点延迟完全无所谓。

#define FILTER_N 10 static float filter_buf[FILTER_N]; static uint8_t filter_index = 0; static uint8_t filter_count = 0; float MovingAverage(float new_value) { filter_buf[filter_index] = new_value; filter_index = (filter_index + 1) % FILTER_N; if (filter_count < FILTER_N) filter_count++; float sum = 0.0f; for (uint8_t i = 0; i < filter_count; i++) { sum += filter_buf[i]; } return sum / filter_count; }

中值滤波适合有突发干扰的场景，比如震动传感器偶尔产生一个很大的尖峰。做法是取最近 N 个数据排序，取中间值。N 一般取奇数，比如 3、5、7。代价是排序需要稍微多一点计算量，不过 STM32 跑这点计算毫无压力。

迟滞比较则适合告警判断。比如设定温度高于 60 度告警，如果只有单一阈值，读数在 59.9 和 60.1 之间抖，告警就会反复触发。解决办法是设置两个阈值：超过 61 度触发，低于 59 度才解除，中间这段区域叫迟滞区，能有效避免抖振。

4.3 我踩过的一个坑：排查"温度读数一直偏高"的完整链路

有一次我调试一块温湿度采集板，读数一直比实际室温高 3 到 5 度，怎么滤波都救不回来。当时我没有直接怀疑传感器，而是按链路一步步排查：

第一步，检查供电。用万用表测传感器 VDD 引脚，发现电压是 3.28V，非常稳定，排除供电问题。

第二步，排查芯片自热。我把传感器从 PCB 上拆下来，用杜邦线悬空连接，读数依然偏高。这说明问题不在板子上的铜箔导热，也不在旁边的电源芯片发热。

第三步，对比校准。我拿了两颗同型号传感器并排放在同一个位置，发现读数非常一致。这说明传感器本身的重复性没问题，它们可能都偏，但不是个别器件的问题。

第四步，怀疑转换公式。我仔细读了一遍数据手册，才发现我用的某款传感器在读取原始值时，换算公式里的偏移常数和手册最新修订版不一样。我用的是旧版公式，差了约 3 度。换成新版公式之后，读数立刻就和标准温度计对上了。

这个排查过程给我最大的教训是：遇到读数不准，先做链路排查，别一上来就堆滤波算法。滤波只能平滑噪声，不能纠正系统误差。系统误差只能靠换算公式、校准和对照测试来解决。

4.4 每个项目都要重新回答的四个基本问题

不同项目对数据的质量要求完全不同，但以下四个问题是共通的：

• 采样周期多少合适？温度 1 秒一次够了，雨滴可能需要 50 毫秒就判断一次，这取决于物理量的变化速度。
• 滤波窗口多大？窗口越大越平滑，但延迟也越大，需要权衡。
• 告警阈值定多少？不能拍脑袋，最好先采集一段基线数据，看看正常状态下的数值分布。
• 校准怎么做？至少准备一个已知的参考值，比如用另一台标准温度计放在一起，测出偏移量后在代码里补偿。

这些问题没有标准答案，因为每个项目的外界环境不一样，但只要你把四个问题都认真回答一遍，系统的稳定性会有质的提升。

5. 数据读出来了，然后呢：车外信息如何变成实用价值

传感器采集、滤波、判断都做完，这只是上半场。数据如果不能变成有价值的信息，那 STM32 仍然只是一个自娱自乐的读数器。把车外信息真正用起来，通常有几步。

5.1 本地响应：让单片机自己先做判断

最简单的用法是在 STM32 本地做判断和响应。刚才说的蜂鸣器告警、LED 提示就是这一类。优点是响应快、不依赖网络，缺点是信息只停留在本地，你不在车边就看不到。

本地响应的关键是设计好状态机。比如"正常-提醒-告警"三档状态，每个状态对应不同的输出动作。轮询读到的数据进入状态机，状态发生跳变时才触发动作，而不是每次读数都触发一遍。这个思路在资源紧张的嵌入式系统里很实用，能避免大量重复操作。

5.2 联网上抛：把数据打包送到服务端

本地处理之外，更常见的做法是把数据通过无线模块上抛。STM32 通过串口接一个 WiFi 模块或者 4G 模块，定时把采集到的数据打包成 JSON 格式发送到一个服务端。

发送的内容不用太复杂，比如：

{"device":"car01","temp":24.5,"humi":61,"dist":120,"rain":0,"ts":1720000000}

服务端收到数据后，存入数据库，再做一个简单的 Web 页面或者小程序，你打开手机就能看到车外实时的温度、湿度、雨滴状态。这个方案的技术栈跨度比较大，涉及单片机、网络协议、服务端开发三块，周期会长一些，但每一步都有现成方案可参考。

如果不想自己写整套服务端，也可以跳过云端，直接用串口蓝牙模块把数据发到手机上的串口调试助手，或者拼一个简单的仪表盘页面，效果也够用。

5.3 多传感器融合：从单点数据到综合判断

单个传感器能描述一个物理量，多个传感器放在一起，就能描述一个"场景"。比如把温湿度、光照、雨滴三个数据放在一起，就能判断"当前车外是否适合开窗通风"：

• 温度 24~28 度、湿度 40%~60%、光照柔和、没有雨滴：开窗舒适。
• 温度超过 32 度：不建议开窗，建议开空调。
• 湿度超过 80% 且雨滴传感器触发：关窗，可能下雨。

这种判断用一段简单的条件判断代码就能实现，不需要什么复杂算法。但你会发现，"让 STM32 知道车外发生了什么"这句话的含金量，恰恰体现在这里：数据本身不值钱，数据和业务场景结合之后的判断才值钱。

5.4 一个更进阶的思路：低功耗与边缘判断

车载场景还有个特殊需求是低功耗。车停着的时候系统一直在供电，如果功耗太高，可能几天就把蓄电池耗干了。常用的做法是让 STM32 进入睡眠模式，定时器每 30 秒唤醒一次，采集数据、判断状态、如果一切正常就继续睡，只有检测到异常（比如震动、距离突变）才立即全速运转并上报。

这种边缘判断的思路是：传感器数据并不是全部需要上报，大部分时间它只需要在本地做最原始的安全判断，只有异常事件才值得联网上报。这个思路放到很多物联网项目里都适用，值得你好好理解。

6. 给第一次动手做传感器采集的人：四个工程习惯

最后分享几条我自己做这类项目沉淀下来的习惯，可能比代码本身更有用。

第一条，先把传感器接到 USB-TTL 上看原始数据，别急着加 WiFi、加屏幕、加各种外设。一个传感器一个传感器地调，每条数据都看到原始值确认无误，再往系统里加东西。我见过不少新手一上来就搭一个"完整系统"，结果传感器数据根本不对，还找不出问题在哪。

第二条，电源质量永远排在算法前面。尤其车载环境，12V 蓄电池、点烟口取电、各种电机继电器干扰，电源做不好，采集的数据再滤波也是垃圾。至少加一颗稳压芯片和退耦电容，能省下后面无数排查时间。

第三条，务必记录正常状态的基线数据。在环境稳定的时候，连续采集几个小时，看看自然状态下的数据分布是什么样子，再根据这个分布去定告警阈值和滤波窗口。没有基线，所有阈值都是拍脑袋。我当时就是拿串口把数据记了一天，才发现光照数据在下午四五点会有一个特别长的缓坡，单靠简单阈值根本判断不准"太阳开始落山"这个事。

第四条，学会自己给自己挖坑然后填坑。比如把传感器的线故意弄松一点，看看系统会不会误报；把供电电压调高到 5V 或调低到 3.2V，看看读数怎么变。这种"压力测试"能在你正式使用之前发现一堆隐患，比出了问题再排查效率高得多。

按这个思路做下来，你会发现"让 STM32 知道车外发生了什么"其实并不神秘。传感器是一层感知，代码是一套翻译和判断，真正有价值的，是你把数据用起来之后对场景的把握。从一个温度和一颗雨滴开始，慢慢做出一整套能感知外界的小系统，这个过程的乐趣和大项目是一样的。