简介面向物联网嵌入式开发者的STM32F030多点温度采集系统完整代码包适用于需要构建低功耗远程温湿度监控方案的工程师与学生。资源以源文件为主体包含10个C源文件与10个头文件覆盖DHT20传感器驱动、BC260Y-CN模块NB-IoT通信、OLED显示、定时器、告警及硬件初始化等模块辅以2个Markdown说明文档及gitignore、inscode工程配置共24个文件压缩包大小仅40KB。代码模块划分清晰可直接基于STM32F030最小系统编译运行采集到的温度数据可经NB-IoT与MQTT协议上传至OneNet平台并同步在本地OLED屏幕显示。已有36人学习下载。通过研读该工程开发者既能快速上手STM32F030外设配置与低功耗设计思路也能掌握NB-IoT模组入网、MQTT参数生成及云平台交互等物联网关键环节为二次开发或多点扩展提供可复用的参考实现。 之前赶项目工期手头接了一个环境监控的小需求现场要采集七个点的温度范围大概在-20℃到85℃之间精度要求±1℃节点分布在一条二十多米的线缆上主机要能轮询显示实时温度还要能通过串口把数据丢给上位机。我第一反应就是拿STM32F030做主机、DS18B20做传感器半个月从画板到跑通测试整体效果很稳。这套方案的选型逻辑、硬件注意点、软件代码和踩坑实录我一起整理出来给正在搞类似多点测温项目的朋友做个参考。先说为什么盯上STM32F030这颗料。Cortex-M0内核48MHz主频Flash最大32KB、RAM 4KB的资源在入门级MCU里属于够用但不算富裕的水平关键是单价低、供货稳做成本敏感的多点采集节点非常合适。对比过51和STM32F1系列51的片上资源太少多路ADC、多个串口、大点数轮询都得外扩麻烦STM32F1是M3内核主频和内存都富余但成本也上去了对这种测温场景属于杀鸡用牛刀。F030的定位正好卡在中间温度采集本身是慢速外设不需要高频PWM和复杂运算F030的GPIO翻转速度、定时器和DMA能力完全够用省下来的钱攒着买排骨不香吗。1. 项目整体设计与思路拆解1.1 核心需求解析接到需求之后我没有直接开干先把需求拆成了四个要点七个温度节点分布在二十多米的现场线缆上逐一采集并显示测温范围-20℃~85℃精度±1℃分辨率0.1℃就够主机实时刷新显示同时通过串口向PC端发送数据方便上位机存储曲线系统要能稳定长期运行某个节点掉线不能拖垮整个总线基于这四点我很快做了一个方案对比方案路线单节点成本布线复杂度开发难度可靠性NTC热敏电阻多路ADC极低每点至少两根线校准麻烦每路都要标定一般I2C传感器如TMP102中两线I2C地址有限简单但地址位限制挂载数量较高DS18B20单总线低一根数据线串联时序稍讲究代码成熟高PT100变送器很高需变送模块简单但成本爆炸高1.2 为什么选DS18B20因为我验证了几天后发现NTC方案看似便宜但七路每路都要分压电阻、滤波电容、ADC校准曲线生产麻烦不说散热条件一变读数就飘。I2C传感器TMP102这类芯片挂在一条I2C总线上最多只能挂8个通过地址引脚组合限制比较死。而DS18B20天生就是一总线器件每颗芯片出厂就烧录了一个唯一的64位序列号一根线可以挂几十个主机通过ROM指令去寻址每一颗传感器的序列号然后把它们区分开。DS18B20支持-55℃到125℃的测温范围精度在-10℃~85℃范围内能做到±0.5℃分辨率可以通过配置寄存器在9~12位之间选默认12位下温度分辨率为0.0625℃远超项目需求。内置的EEPROM还能保存告警阈值和分辨率配置掉电不丢失。更重要是代码成熟社区方案一大堆就算我这种老油条踩一次坑也能很快爬起来。1.3 整体系统架构系统分三层最底层是七个DS18B20传感器节点中间是STM32F030主机板最上层是PC端显示。传感器全部并联挂到同一根单总线数据线上统一走三线制VCC、DQ、GNDSTM32F030通过PA0口作为1-Wire总线按需轮询每个传感器的ROM地址并读取温度。数据解析完成后温度值在0.96寸OLED屏幕上逐点刷新同时通过USART1以Modbus-RTU协议上报给上位机。这里有个设计取舍要说明七个传感器全部挂一条总线优点是布线少、IO占用小缺点是总线长度超过一定范围后寄生电容和信号反射会明显增大容易导致时序错乱。如果传感器分布范围超过三十米稳妥做法是分两路总线比如PA0带四个点、PA1带三个点这样既降低每条总线的负载又能在软件上做双路独立轮询一路总线短路不会拖死另一路。我这次现场是二十多米一条总线测下来波形还行就先用单总线方案但代码里保留了多总线扩展的接口。2. 硬件设计与核心细节2.1 主控最小系统STM32F030最小系统非常精简一颗F030C8T6或者C6T6如果Flash够用的话、一个8MHz晶振加两个20pF负载电容、一个10KΩ复位上拉电阻、一个0.1μF和10μF去耦电容组合、BOOT0下拉到地。如果程序量不大F030C6T6的32KB Flash完全够用能省个一两块钱。不过我做样机时直接上了C8T6因为要边调试边加功能省得后面Flash紧张再换料。电源部分我犯了老司机也会犯的错图省事用了AMS1117-3.3V线性稳压但现场有市电环境输入电压通过AC-DC模块降到12V再进来的AMS1117从12V跌到3.3V的压差接近9V就算负载只有100mA它的功耗也有0.9W不加散热片烫得能煎鸡蛋。后来我加了MP1584或者直接改用宽压DCDC模块温度才正常。单片机是3.3V供电DS18B20的VCC接3.3V没有问题总线电平逻辑也是兼容的。2.2 DS18B20接线与上拉电阻选择DS18B20的数据线是开漏输出结构所以总线上必须接一个外部上拉电阻到VCC。规格书上推荐4.7KΩ但这是在传感器紧挨着主机的情况下。我这次的总线拉出去二十多米如果还用4.7K上拉总线在释放高电平的时候上升沿会特别软快到临界点时主机采样容易误判表现为读回来的温度随机跳变或者干脆搜不到设备。实际调下来单总线长度十米以内用4.7KΩ没问题二十米左右换2.2KΩ上拉波形改善非常明显如果超过五十米直接上1KΩ并且最好在远端总线末端也加一个上拉相当于两端各挂一个电阻。要注意上拉电阻不能太小否则总线低电平拉不下去读时序会一直被识别成高电平反而更糟。对于F030来说GPIO配置成开漏模式配合外部上拉是最推荐的接法。2.3 接口保护与防雷防静电工业现场布线比较随意传感器线缆经常和动力电缆走同一个线槽感应浪涌和静电是真实存在的。我在主机端的总线和电源线上串了PTC自恢复保险丝以及TVS管TVS的地要直接接数字地不要转一圈过孔才落地。数据线上再串联一个100Ω到220Ω的电阻能抑制寄生电容和总线反射。如果条件允许DS18B20的电源线走双绞线中的一根地线走另一根和信号线保持一点距离稳定性会好很多。3. 软件架构与代码实现3.1 1-Wire协议时序到底在干什么说代码之前先把单总线时序用大白话理一遍不然看代码很容易一头雾水。DS18B20和主机之间靠一条线通信没有时钟线所以所有的时间同步全靠约定好的高低电平宽度来完成。主要就是三种基本操作复位时序主机先把总线拉低480μs以上然后释放。传感器收到这个低电平脉冲后会在1560μs内把总线拉低60240μs发出“存在脉冲”告诉主机“我在线”。这个动作相当于每次通信前的握手。写时序主机要写一个0就把总线拉低60120μs然后释放写一个1就只拉低115μs就释放。传感器会在主机拉低后的1560μs窗口内采样总线电平。读时序主机拉低总线至少1μs然后释放紧接着在15μs内读取总线电平。传感器如果返回0它会继续保持总线低电平到整个时隙结束如果返回1它就会释放总线让上拉电阻把电平拉高。每个位时隙至少要维持60μs连续读写位之间要有1μs以上的恢复时间。DS18B20的时序本质上就是“在单位时隙里用电平宽度传达0/1”只要时序波形没有严重变形通信就能稳定可靠。3.2 两种采集策略的取舍DS18B20获取温度有两种常见方式跳过ROMSkip ROM方式主机发0xCC跳过ROM匹配然后发0x44启动转换再发0xCC跳过ROM、发0xBE读取同一个传感器的温度。这种方式简单快速适合总线上只挂一个传感器的情况。但它无法区分总线上多个设备多个传感器同时往总线上发数据会冲突。匹配ROMMatch ROM方式主机先发0x55匹配ROM命令然后跟64位ROM序列号总线上的每个传感器都会对比这个序列号匹配的才响应后续转换和读取指令。这是多点采集的标准做法但要求程序在初始化阶段先把每个传感器的64位序列号扫描并保存下来。我这次做七个点用的就是匹配ROM方式上电后程序自动扫描总线上所有DS18B20把序列号存进数组后续每次轮询的时候逐个匹配读取。3.3 核心代码实现与说明单总线底层时序我用的是GPIO模拟没有用片上外设因为1-Wire协议本身对时序要求比较“挑剔”而GPIO模拟在F030上延时控制得更直接。先看底层几个关键函数// 拉低总线并等待微秒级延时 static void DS18B20_DQ_LOW(void) { HAL_GPIO_WritePin(GPIOA, DS18B20_PIN, GPIO_PIN_RESET); } static void DS18B20_DQ_HIGH(void) { HAL_GPIO_WritePin(GPIOA, DS18B20_PIN, GPIO_PIN_SET); } // 复位时序拉低至少480us然后释放检测存在脉冲 uint8_t DS18B20_Reset(void) { uint8_t presence 0; DS18B20_DQ_LOW(); Delay_Us(500); // 拉低500us DS18B20_DQ_HIGH(); // 释放 Delay_Us(60); // 等传感器拉低 presence HAL_GPIO_ReadPin(GPIOA, DS18B20_PIN); // 读到低电平说明存在 Delay_Us(500); // 等待时隙结束 return presence ? 0 : 1; // 返回1表示检测到设备 }需要特别注意的是写位和读位的时序窗口必须严格按照数据手册来。见下面的代码// 写一个bit void DS18B20_WriteBit(uint8_t bit) { if (bit) { DS18B20_DQ_LOW(); Delay_Us(5); // 写1时隙拉低1-15us然后释放 DS18B20_DQ_HIGH(); Delay_Us(60); // 保证整个时隙至少60us } else { DS18B20_DQ_LOW(); Delay_Us(60); // 写0时隙拉低60-120us DS18B20_DQ_HIGH(); Delay_Us(5); // 时隙恢复时间 } } // 读一个bit uint8_t DS18B20_ReadBit(void) { uint8_t bit 0; DS18B20_DQ_LOW(); Delay_Us(1); // 拉低至少1us DS18B20_DQ_HIGH(); // 释放总线 Delay_Us(10); // 15us窗口内采样 bit HAL_GPIO_ReadPin(GPIOA, DS18B20_PIN); Delay_Us(50); // 等待时隙结束 return bit; }延时函数我直接用SysTick做的微秒级延时注意F030主频48MHz时一个SysTick周期是1/48MHz≈20.8ns所以微秒延时循环要做精确一点否则时序偏了读数就飘。写完之后是字节级的封装void DS18B20_WriteByte(uint8_t data) { for (uint8_t i 0; i 8; i) { DS18B20_WriteBit((data i) 0x01); } } uint8_t DS18B20_ReadByte(void) { uint8_t data 0; for (uint8_t i 0; i 8; i) { if (DS18B20_ReadBit()) { data | (0x01 i); } } return data; }然后是获取温度的核心逻辑。这里特别强调一个优化点不要读一个传感器就等着转换完成这样子效率太低。正确流程是先遍历所有传感器发送转换命令然后等至少750ms12位分辨率再逐个读取温度寄存器这样总耗时从七个串行转换的5.25秒压缩到一轮并行转换的0.75秒加读取时间实际测量体验几乎秒更。void DS18B20_StartAllConversion(void) { for (uint8_t i 0; i sensor_count; i) { if (DS18B20_Reset() 0) continue; DS18B20_WriteByte(0x55); // Match ROM DS18B20_WriteRom(sensor_rom[i]); // 发送64位序列号 DS18B20_WriteByte(0x44); // 启动温度转换 } HAL_Delay(750); // 等待所有传感器转换完成 } float DS18B20_ReadTemperature(uint8_t index) { uint8_t low 0, high 0; if (DS18B20_Reset() 0) return -999.0f; // 掉线 DS18B20_WriteByte(0x55); DS18B20_WriteRom(sensor_rom[index]); DS18B20_WriteByte(0xBE); // 读暂存器 low DS18B20_ReadByte(); high DS18B20_ReadByte(); int16_t raw (high 8) | low; return raw * 0.0625f; // 12位分辨率单位℃ }注意raw是补码形式负数温度的时候高字节是0xFC这类值直接转short再乘分辨率系数就对了不用单独判符号。我第一版代码忘了把raw声明成int16_t负温度读出来直接变成三百度排查了半天才发现是数据类型的问题。3.4 自动扫描总线上所有DS18B20序列号这个函数是整个方案的灵魂。上电后先执行复位然后发送0xF0Search ROM命令通过逐位搜索算法找出总线上所有传感器的64位ROM码。原理是DS18B20在收到Search ROM命令后会分两次输出当前位的值和该值的反码主机通过这两次读取判断每个位上的设备冲突情况然后决定走向哪条分支。uint8_t DS18B20_SearchROM(uint8_t *romList, uint8_t maxDevices) { uint8_t numDevices 0; uint8_t lastDiscrepancy 0; uint8_t searchDirection 0; uint8_t found 0; uint8_t bitIndex, byteIndex, bitMask; uint8_t lastZero -1; while (numDevices maxDevices) { if (DS18B20_Reset() 0) break; DS18B20_WriteByte(0xF0); // Search ROM found 0; uint8_t rom[8] {0}; for (bitIndex 0; bitIndex 64; bitIndex) { uint8_t bitA DS18B20_ReadBit(); uint8_t bitB DS18B20_ReadBit(); if (bitA bitB) { return numDevices; // 没有设备 } if (bitA ! bitB) { searchDirection bitA ? 1 : 0; // 只有一个分支可选 } else { // 冲突位处理第一次从0走第二次从1走 if (bitIndex lastDiscrepancy) { searchDirection (rom[bitIndex / 8] (1 (bitIndex % 8))) ? 1 : 0; } else if (bitIndex lastDiscrepancy) { searchDirection 1; // 从0切换成1 } else { searchDirection 0; } if (searchDirection 0) { lastZero bitIndex; } } if (searchDirection 1) { rom[bitIndex / 8] | (1 (bitIndex % 8)); } DS18B20_WriteBit(searchDirection); } // 复制ROM到列表 for (byteIndex 0; byteIndex 8; byteIndex) { romList[numDevices * 8 byteIndex] rom[byteIndex]; } numDevices; lastDiscrepancy lastZero; lastZero -1; } return numDevices; }这个搜索算法是单总线协议里面最绕的一部分。我第一版照着网上代码抄结果搜出来重复设备后来把冲突位处理改成按lastDiscrepancy分类逻辑才理顺。它的核心思想就是第一轮搜索所有冲突位都选0记录最后一个冲突位的位置第二轮从1分支接着搜层层递归直到把所有分支都走完最终就能得到总线上所有唯一的ROM序列号。实际跑下来七颗DS18B20全部扫出来序列号打印到手后续轮询就稳了。4. 串口通信与上位机对接4.1 通信协议设计串口数据上报我采用了简单可靠的Modbus-RTU风格帧结构其实背地里就是自己定义的一帧数据格式帧头0xAA、功能码0x01、设备数量、第一个设备的地址、温度高字节、温度低字节、第二个设备地址、温度高低字节……最后加一个CRC16校验字节低字节在前然后帧尾0x55。帧头帧尾是为了上位机做同步CRC用来检查整帧数据有没有被干扰。这样设计的好处是上位机哪怕收到半包数据也可以等帧头出现后重新对齐CRC错了直接丢弃这一帧不影响后续解析。对于20多米的总线环境偶发干扰帧很正常有校验就能保证显示不跳变。4.2 STM32F030串口DMA发送F030的串口发送我建议用DMA不然主循环一直在那里等发送完成还得去轮询总线时序就乱了。初始化的核心代码大概是这样void UART_SendDataDMA(uint8_t *data, uint16_t len) { // 等待上一次DMA传输完成 while (HAL_DMA_GetState(hdma_usart1_tx) ! HAL_DMA_STATE_READY); HAL_UART_Transmit_DMA(huart1, data, len); }数据帧拼好之后调用一次DMA发送程序马上回到主循环继续干别的事发送完成后DMA中断里什么都不用干。OLED显示和单总线轮询都不耽误整机响应非常流畅。5. 常见问题与排查技巧实录5.1 温度读数正常但是偶尔跳成-127.0或者85.0这个问题出现的频率极高。85.0其实是DS18B20上电复位后的默认暂存器值读到85说明传感器没有真正执行转换命令就进入了读取流程。-127是读取失败时总线返回的异常值。排查时优先怀疑时序延时不准尤其是用HAL_Delay来做微秒延时——HAL_Delay本身是毫秒级的千万不要直接拿它当us用。我踩过这个坑把Delay_Us(60)写成了HAL_Delay(60)结果一次位时隙变成了60毫秒能通信才怪。5.2 总线上只挂一个传感器没问题挂多了就读不到或读错多半是上拉电阻不够“硬”。多点并联后总线整体电容变大4.7K上拉驱动的上升沿变缓慢高速位时序时主机采样容易采到错误电平。解决办法前面说过把上拉换成2.2K甚至1K并在总线末端再并一个电阻。还有一个是电源问题如果七个DS18B20全部寄生供电只用两根线转换电流峰值的瞬间总线电压会被拉垮直接导致通信失败我建议还是都用三线制独立供电。5.3 搜索ROM能搜到设备但读取温度始终是某一个传感器的值这是匹配ROM指令发错了或者序列号存错了。注意发送序列号时用的是64位8字节发送顺序是LSB先发也就是先发ROM码的低字节。很多代码库为了简化会写成从高字节开始发这种错误不会报错只是匹配不上。我调试时把扫描到的ROM码和钢印上的序列号一对发现字节顺序是反的立刻定位到问题。5.4 快速排查速查表现象可能原因排查方法所有传感器读回85.0转换命令没发成功或等待时间不足检查启动转换命令和延时确认是否等待750ms个别传感器偶发掉线总线接触不良、线缆过长检查接头减小上拉电阻缩短总线段温度值乱跳时序延时不准、干扰用示波器抓波形查电源纹波加TVS管搜索ROM搜出的设备重复搜索算法冲突位处理错误检查lastDiscrepancy更新逻辑上位机CRC老报错电磁干扰、波特率误差串口加磁珠和TVS检查晶振精度负温度显示成两百多度raw变量被当成无符号数把温度变量声明成int16_t6. 最后的经验和扩展建议整套系统从画板到跑通最花时间的不是写代码而是排查异常温度值和搜索算法的边界情况。如果你只是验证功能可以直接用跳过ROM的方式代码量减半但要做真正可用的多点系统搜索ROM这关绕不过去。最后再分享一个实用技巧DS18B20的分辨率是可以配的12位分辨率转换时间750ms如果现场对实时性要求高你可以把分辨率配置成10位甚至9位转换时间降到187ms和93ms代价是温度抖动会变大一点点。实测工业现场场景用10位基本看不出波动但显示刷新快了两三倍。分辨率配置写入EEPROM后掉电不丢失所以你可以现场通过串口命令动态切换不用每次都重新烧固件。这套温度采集方案目前稳定跑了三个月除了有一路传感器线缆被老鼠咬断导致掉线外没有出现其他异常。如果后续点位再多可以考虑用RS485转单总线网关做分布式采集或者直接把F030换成一颗带CAN的芯片但原理都差不多单总线时序还是那套。希望这篇笔记能帮你少走点弯路有问题评论区随时聊。本文还有配套的精品资源点击获取