简介这套压缩包是一例面向嵌入式初学者的STM32物联网实战工程主控采用STM32系列单片机通信侧使用移远RM500U 5G模块传感器选用AHT20采集温湿度数据后通过MQTT协议上传至OneNET平台完成从硬件驱动、网络接入到云端显示的全链路参考实现。工程基于Keil HAL库开发源码按模块划分注释清晰管脚接线定义均标注在代码中适合学习5G模组AT指令、MQTT报文交互以及物联网项目调试方法。压缩包内共972个文件大小13.38MB以c源码和h头文件为主体另含启动文件、链接脚本、Keil和IAR工程文件、STM32CubeMX的ioc配置以及最终编译生成的hex、axf等镜像文件便于直接烧录与验证。丰富的编译中间文件可以帮助读者分析构建过程配合代码注释理解各子模块关系。该工程目前已有617人学习/下载作者还针对J-Link/ST-Link选择、芯片型号与Flash容量调整给出了提醒可按自身硬件做适配也可替换其他传感器进行二次开发是较好的课设、毕设或产品预研参考。1. 5G模组串起STM32到OneNET的完整链路这个项目在解决什么一个STM32开发板、一块移远RM500U 5G模组、一颗AHT20温湿度传感器外加OneNET物联网平台的MQTT接入这条链路看起来像是把多个成熟模块拼在一起实际做起来却会卡在不少隐性的地方。最常见的情况是模组的AT指令已经回了OK5G信号也显示满格但平台上就是看不到一条数据点。真正难的从来不是5G这个名词而是OneNET改造版MQTT的鉴权格式、RM500U的拨号附着流程、以及AHT20在I2C总线上的时序细节这三件事互相咬合。这篇文章把这三段拆开讲清楚从硬件接线、AT指令到上报代码每一步都给出可以直接抄的参数和排错思路。适合手里正好有RM500U或是想用5G模组做物联网采集项目的开发者尤其是卡在OneNET上数这一步的人。2. 硬件链路与初始化确认RM500U和AHT20都在STM32能管控的范围里2.1 RM500U用UART还是USB虚拟串口对接STM32RM500U作为移远的5G模组对外接口非常丰富USB、PCIe、UART都有。和STM32单片机对接常见做法是用UART串口发AT指令而不是走USB。原因在于USB接口在RM500U上会枚举出多个虚拟串口不同的AT口、数据口、日志口混在一起在MCU侧处理起来需要引入USB Host控制器画蛇添足。RM500U的UART接口支持AT指令和PPP拨号两种数据通道波特率默认可以是115200硬件上只需要两个引脚交叉连接。接线参考如下表RM500U引脚STM32引脚说明UART_TX (Pin 56附近)USARTx_RX模组发送MCU接收UART_RX (Pin 55附近)USARTx_TX模组接收MCU发送GNDGND共地VCC 4.0V~4.4V外部DC-DC供电峰值电流2A以上不能直接用3.3V LDOPWRKEYGPIO输出拉低至少500ms触发开机RESETGPIO输出或悬空低电平有效上电初期建议拉高这里有一个容易被忽视的地方RM500U的UART电平是1.8V不是常见的3.3V TTL。多数STM32开发板的串口号称兼容3.3V逻辑直接接上去虽然能通讯但长期运行时可能出现偶发乱码。稳妥的做法是在RM500U的UART_RX/TX和STM32之间加一个电平转换芯片比如TXS0108或简单的二极管电平匹配电路。如果你手边的RM500U是带开发底板的版本底板一般已经把电平转到3.3V此时直接接STM32没问题。2.2 模组上电时序为什么AT指令回不了OKRM500U不是一颗简单的无线芯片它内部跑了完整的Linux操作系统上电到AT指令可用通常需要10秒到20秒这和ESP8266那种上电几百毫秒就能工作的模组完全是两个节奏。正式项目里STM32在复位后不能立刻发AT要先给模组留出启动时间。我一般会在代码里做这样一个流程模组PWRKEY拉低500ms松开然后循环发送不带回车的AT字符每500ms一次最多等到30秒。当收到OK响应时才认为模组就绪。这个机制的代码逻辑很简单但能避免项目前期把大量时间浪费在为什么AT没反应上。另外注意RM500U冷启动时电流会冲高到2A以上如果用USB线供电的STM32开发板直接给模组供电电压跌落会导致模组反复重启现象就是AT偶尔通偶尔不通。给RM500U单独配一个可输出3A的DC-DC模块是省心方案。2.3 STM32侧的外设分配与CubeMX参数AHT20是I2C接口传感器RM500U走UART主控只需要两个外设一个I2C、一个USART。在STM32CubeMX里把I2C速率设为100kHz标准模式AHT20在400kHz下也能工作但信号线稍长或者上拉电阻偏大时容易读数飘100kHz最稳。USART设置为115200 8N1打开中断关闭硬件流控。RM500U的UART接口不支持RTS/CTS硬件流控这里务必关闭否则模组会等流控信号而一直不吐数据。外设初始化完成后别忘了处理延时问题。STM32标准库和HAL库的HAL_Delay在系统时钟配置错时会明显偏短或偏长会直接影响AHT20读取时序。用CubeMX配置外部高速晶振HSE把系统时钟倍频到最高再回头测一次延时是否准确。很多人AHT20读出的温度偏高排查到最后发现是HAL_Delay实际只延时了十分之一。3. RM500U拨号与网络附着AT指令把5G通道真正跑通3.1 建立数据通道的最小AT指令序列RM500U支持移远统一AT指令集和EC20、RM500Q等模组的指令风格一致熟悉4G模块的人可以直接上手。上电后依次输入下面的命令每一条都等到OK再发下一条。AT ATCPIN? ATCSQ ATCOPS? ATCGDCONT1,IP,cmiot ATCGACT1,1 ATCGPADDR1 ATQPING1,183.230.40.39逻辑说明AT探活ATCPIN?查SIM卡是否识别返回READY才能继续ATCSQ看信号强度数值代表接收信号电平大于15基本能正常工作ATCOPS?确认运营商注册状态返回里的第二个字段如果是0到3之间表示已经注册上网络。ATCGDCONT1设置PDP上下文APN要填当前SIM卡运营商实际使用的值比如电信的ctnet、联通的wonet移动物联网卡常见cmiot。ATCGACT1,1激活PDP上下文这一步成功了才有IP地址。最后ATCGPADDR1查询分配到的IP并用ATQPING验证到OneNET平台的网络通路。参数说明ATCGDCONT1,IP,cmiot中的第一个1是PDP上下文编号IP指IPv4cmiot是APN。如果这张卡是定向流量卡APN一定要填对否则5G虽然注册上了但任何TCP连接都建立不起来这是物联网卡最常见的问题。ATQPING1,183.230.40.39中的1也是上下文编号后面的IP是OneNET MQTT接入地址能收到字节回复说明模组的网络侧已经通了。3.2 5G和LTE的附着差异别被CSQ值骗了RM500U支持NSA和SA两种5G组网模式也向下兼容4G。实际环境中5G信号强度很好但不代表数据通道就通畅尤其在NSA组网下模组需要同时维持5G和LTE两条链路。检查是否真的工作在5G网络下用ATQNWPREFCFGmode_pref,NR5G强制优先5G再看ATQNWINFO回显的network mode是不是NR5G。一个实际的坑是在室内测试时5G信号显示满格但ATCGACT1,1返回ERROR。这种情况多数是当前小区的5G载波没有配置上行资源或者SIM卡的DNN配置不允许该APN走5G承载。此时把网络模式改为ATQNWPREFCFGmode_pref,LTE用LTE把数据业务先跑通项目联调期间效率更高。5G模组不是必须工作在5G网络关键在于数据业务链路是否可用。3.3 拨号方式选择AT指令自带协议栈还是外部PPPRM500U提供了两种上云路径。一种是模组内部完成TCP/IP协议栈MCU只管发AT指令比如ATQHTTP、ATQMTOPEN等这种方式MCU开销最小。另一种是走PPP拨号把模组当成一个网卡数据经过PPP链路后由MCU侧去处理TCP/IP。在单片机项目里前者更常用原因很简单STM32的RAM和Flash有限跑一个完整TCP/IP协议栈再叠加MQTT压力不小而模组自带协议栈处理这些绰绰有余。后面的MQTT接入全部基于移远的socket AT指令展开。4. OneNET MQTT鉴权与数据帧把AHT20数值送进物联网平台4.1 OneNET的MQTT不是标准MQTT差在鉴权OneNET平台提供MQTT接入能力但它的第一版接入方式对MQTT协议做了一层特殊封装网上流传的mqtt协议详解大多是从标准MQTT讲起直接套到OneNET上会连不上。差别主要体现在CONNECT报文的三个核心字段上标准MQTT中clientId、username、password是用户自己定义的OneNET则规定clientId填产品IDusername填设备IDpassword填设备接入的apiKey。这三个信息在OneNET控制台创建产品和设备后都能找到apiKey类似设备的访问令牌丢了可以重新生成。连接参数常见是MQTT地址183.230.40.39端口6002。R5模组侧的AT指令写法是ATQMTOPEN0,183.230.40.39,6002 ATQMTCONN0,产品ID,设备ID,apiKey逻辑说明ATQMTOPEN建立到OneNET的TCP连接0是socket连接编号后面是服务器地址和端口。ATQMTCONN发送MQTT CONNECT报文完成接入三个字符串依次对应OneNET要求的clientId、username、password。需要注意OneNET对apiKey的大小写敏感从控制台复制时不要加多余的换行或空格。参数说明如果ATQMTCONN返回ERROR大概率不是网络问题而是产品ID、设备ID、apiKey三者不匹配。可以先自查一遍ID中间是否混入空格再把apiKey重新生成一次。4.2 上行数据报文的topic与JSON格式OneNET MQTT接入中设备上报数据固定发布到sys/$dp这个topic平台才会把数据解析成数据流。payload是JSON格式结构如下{datastreams:[{id:temp,datapoints:[{value:25.3}]},{id:hum,datapoints:[{value:68.5}]}]}其中id要和控制台产品里已经创建的数据流名称一致。如果平台的数据流叫temperature而JSON里写temp上报会成功但平台侧显示不出折线图这是排查时最容易漏掉的一环。value可以是float平台端展示时保留一位小数。模组侧发布这条数据用ATQMTPUB指令ATQMTPUB0,0,0,0,sys/$dp,{\datastreams\:[{\id\:\temp\,\datapoints\:[{\value\:25.3}]}]}逻辑说明ATQMTPUB的参数里第一个0是连接编号第二个0是消息编号第三个0表示QoS等级为0第四个0表示不保留消息然后是topic和payload。QoS实际使用时保持0即可OneNET对QoS1的支持表现并不好反而容易出现重复数据点。而JSON字符串里双引号在AT指令中必须用\转义不然模组解析指令会在第一个双引号处截断。转义是多数人第一次做ATMQTT上报时最容易卡住的点。4.3 更稳妥的上报状态机把发布动作做成状态机比一次性阻塞式发送可靠得多。模组处于Onenet连接态时每次发布前先发ATQMTPUB等待模组返回提示符后再发JSON载荷。如果直接拼一条长指令发出去有些固件版本会因为缓冲问题丢尾部数据。正确时序是ATQMTPUB0,0,0,0,sys/$dp,60 {datastreams:...}其中60是payload长度必须在发送JSON前明确告知模组。模组收到完整载荷后会返回OK表示已进入发送流程再返回QMTPUB: 0,0,0表示发送完成。建议在收到QMTPUB: 0,0,0之后再做下一次采集和上报避免多个报文在模组内部排队。5. STM32采集AHT20并发布MQTT完整驱动代码拆解5.1 AHT20的I2C读取时序与温湿度换算AHT20出厂时已经校准MCU读取的流程是初始化、触发测量、等待、读取六字节数据。读取到的六个字节中状态字占一个字节后面是湿度20bit和温度20bit。需要注意AHT20的I2C设备地址是0x38左移一位后在HAL库的写函数里传入0x70作为引脚地址。uint8_t AHT20_Measure(void) { uint8_t cmd[3] {0xAC, 0x33, 0x00}; uint8_t raw[6] {0}; uint32_t hum_raw, temp_raw; float hum, temp; HAL_I2C_Master_Transmit(hi2c1, 0x70, cmd, 3, 100); HAL_Delay(80); HAL_I2C_Master_Receive(hi2c1, 0x71, raw, 6, 100); if ((raw[0] 0x80) ! 0) { return 1; // 测量忙 } hum_raw ((uint32_t)raw[1] 12) | ((uint32_t)raw[2] 4) | (raw[3] 4); temp_raw (((uint32_t)raw[3] 0x0F) 16) | ((uint32_t)raw[4] 8) | raw[5]; hum (float)hum_raw * 100.0f / 1048576.0f; temp (float)temp_raw * 200.0f / 1048576.0f - 45.0f; printf(temp%.1f hum%.1f\r\n, temp, hum); return 0; }逻辑说明0xAC是AHT20的触发测量指令后面紧跟两个参数0x33和0x00这个是数据手册规定的固定序列。触发后芯片需要大约80ms完成测量HAL_Delay大于这个时间才能读到有效数据。读取时先判断状态字二进制首位是否为11表示芯片还在忙此时读取出来的数据是上一次的旧值。换算公式的细节尤其要注意AHT20的温度公式是T -45 200 * raw / 2^20而它的兄长AHT10用的是-40起算。如果把AHT10的公式套到AHT20上读出的温度会整体偏高5度。湿度公式两端是相同的RH 100 * raw / 2^20。2^20对应代码中的1048576直接用浮点运算就可以。5.2 拼装OneNET JSON帧并走UART下发AT指令采集到温度和湿度后下一步就是把浮点数格式化成OneNET要求的JSON字符串。用sprintf拼出payload再通过UART发送给RM500U。char payload[128]; char at_cmd[160]; sprintf(payload, {\datastreams\:[{\id\:\temp\,\datapoints\:[{\value\:%.1f}]},{\id\:\hum\,\datapoints\:[{\value\:%.1f}]}]}, temp, hum); sprintf(at_cmd, ATQMTPUB0,0,0,0,\sys/$dp\,%d\r\n, strlen(payload)); HAL_UART_Transmit(huart1, (uint8_t*)at_cmd, strlen(at_cmd), 1000); HAL_Delay(50); HAL_UART_Transmit(huart1, (uint8_t*)payload, strlen(payload), 1000); HAL_UART_Transmit(huart1, (uint8_t*)\r\n, 2, 1000);逻辑说明第一条ATQMTPUB指令中的%d是payload的字节数必须和实际发送的payload长度完全一致。%.1f控制小数点后一位OneNET平台显示折线图时偏好一位小数过多的有效位数反而会让Y轴刻度变得难读。发送完AT指令后不要立即发payload加一个短延时等待模组先返回字符这个字符是模组给出的可以接收数据的信号。参数说明HAL_UART_Transmit的最后一个参数是超时时间这里设1000ms。如果模组因为信号不好而处理变慢超时太短会导致payload发出去时模组还没进入接收模式数据直接丢失。另一个隐含问题是如果temp或hum的值是负数%.1f会正常输出负号OneNET数据流也接受负值AHT20测到零下温度时不需要特殊处理。5.3 发布完成判定与掉线重连判断模组在发布完成后会主动回一条QMTPUB: 0,0,0到串口。STM32的UART中断里要把这一帧完整收下来作为发布成功的标志。对于每次采集上报正确的闭环是串口收到完整响应后置位一个全局标志主循环看到标志后清零再进行下一次采集。这个做法避免了定时采集周期到了就盲目发AT指令结果模组还在处理上一次报文缓冲溢出后表现为主题正常但平台长时间不更新数据。RM500U的MQTT连接掉线后不会自动重连判断方法是看串口是否出现QMTSTAT: 0,1之类的URC上报或者ATQMTCONN?查询到的连接状态不是0。重连动作不要紧跟着掉线就执行常见的重连策略是启动一个5秒到10秒的延时然后重新执行ATQMTOPEN和ATQMTCONN因为模组在掉线瞬间网络栈还没有完全释放立即重连容易失败。6. 平台折线图验证与三层排错把问题定位到具体环节6.1 OneNET控制台创建数据流并确认折线图时间戳登录OneNET控制台在产品详情页的数据流管理里手动创建temp和hum两个数据流类型都是数值型。这里没有先建数据流或数据流名称和JSON里的id不一致平台侧根本不会画出折线图。设备详情页打开数据展示选择更新时间段一分钟后应该能看到新的数据点。确认平台显示正常的关键是看时间戳有没有一直往前走如果时间戳停留在几小时前说明设备的上报并没有真正到达平台。验证时可以手动在串口工具里发一条JSON把值固定为25.0和50.0平台折线图立刻出现这两个值再切回STM32实测数据就能区分问题是出在采集环节还是上报环节。OneNET折线图默认按时间聚合显示数据点过密时看起来是一条直线可以把时间粒度调到1分钟观察单点数据。6.2 三层排错顺序与常见错误码对照排查顺序按照信号链路从底层往上走严格按照下面的顺序来可以少走弯路层级检查手段常见结果模组网络层ATCSQ信号值、ATCGACT?PDP激活状态信号值过低或PDP未激活协议接入层ATQMTCONN?查询MQTT连接状态检查CONNACK返回码返回非0表示鉴权或网络参数错误应用数据层平台数据流时间戳是否为当前时间JSON的id与数据流名称不一致error: no stm32 target found!这类报错在烧录阶段频繁出现跟5G链路无关常见原因是没有安装配套的STM32芯片包或者ST-Link的SWDIO和SWCLK两根线在板子上没有接对目标芯片。先用stm32 st-link utility读一下IDCODE能读到芯片ID再上Keil比在烧录界面反复报错里找原因都快。6.3 AT指令交互的调试技巧RM500U的UART回显默认开着收下来的每个字符都有回显第一次看会很乱。可以在AT指令集调试时用ATE0关闭回显串口输出会干净很多。另外RM500U有个ATQCFGdbgctl之类的日志开关不建议在正常调试时打开它会把模组内部日志混在AT响应里输出干扰判断。还有一点RM500U的串口默认是本机回显模式接线只接TX和RX不接GND时现象往往是模组能收到AT但没有任何响应因为信号回路不完整。排查串口通信时第一件事就是确认共地第二件事才是换波特率。OneNET数据流的更新频率和MQTT心跳有关模组默认心跳间隔较长长时间只采集不发布会让平台判定设备离线。每次完成数据上报后同步执行一次ATQMTPING0来维持连接保活这样即便数据采集周期拉长到几分钟一次平台上的设备状态也始终显示在线。这算是整套链路里性价比最高的一个小动作强烈建议加上。本文还有配套的精品资源点击获取 STM32+RM500U 5G模组接入OneNET：温湿度采集全链路实战
简介这套压缩包是一例面向嵌入式初学者的STM32物联网实战工程主控采用STM32系列单片机通信侧使用移远RM500U 5G模块传感器选用AHT20采集温湿度数据后通过MQTT协议上传至OneNET平台完成从硬件驱动、网络接入到云端显示的全链路参考实现。工程基于Keil HAL库开发源码按模块划分注释清晰管脚接线定义均标注在代码中适合学习5G模组AT指令、MQTT报文交互以及物联网项目调试方法。压缩包内共972个文件大小13.38MB以c源码和h头文件为主体另含启动文件、链接脚本、Keil和IAR工程文件、STM32CubeMX的ioc配置以及最终编译生成的hex、axf等镜像文件便于直接烧录与验证。丰富的编译中间文件可以帮助读者分析构建过程配合代码注释理解各子模块关系。该工程目前已有617人学习/下载作者还针对J-Link/ST-Link选择、芯片型号与Flash容量调整给出了提醒可按自身硬件做适配也可替换其他传感器进行二次开发是较好的课设、毕设或产品预研参考。1. 5G模组串起STM32到OneNET的完整链路这个项目在解决什么一个STM32开发板、一块移远RM500U 5G模组、一颗AHT20温湿度传感器外加OneNET物联网平台的MQTT接入这条链路看起来像是把多个成熟模块拼在一起实际做起来却会卡在不少隐性的地方。最常见的情况是模组的AT指令已经回了OK5G信号也显示满格但平台上就是看不到一条数据点。真正难的从来不是5G这个名词而是OneNET改造版MQTT的鉴权格式、RM500U的拨号附着流程、以及AHT20在I2C总线上的时序细节这三件事互相咬合。这篇文章把这三段拆开讲清楚从硬件接线、AT指令到上报代码每一步都给出可以直接抄的参数和排错思路。适合手里正好有RM500U或是想用5G模组做物联网采集项目的开发者尤其是卡在OneNET上数这一步的人。2. 硬件链路与初始化确认RM500U和AHT20都在STM32能管控的范围里2.1 RM500U用UART还是USB虚拟串口对接STM32RM500U作为移远的5G模组对外接口非常丰富USB、PCIe、UART都有。和STM32单片机对接常见做法是用UART串口发AT指令而不是走USB。原因在于USB接口在RM500U上会枚举出多个虚拟串口不同的AT口、数据口、日志口混在一起在MCU侧处理起来需要引入USB Host控制器画蛇添足。RM500U的UART接口支持AT指令和PPP拨号两种数据通道波特率默认可以是115200硬件上只需要两个引脚交叉连接。接线参考如下表RM500U引脚STM32引脚说明UART_TX (Pin 56附近)USARTx_RX模组发送MCU接收UART_RX (Pin 55附近)USARTx_TX模组接收MCU发送GNDGND共地VCC 4.0V~4.4V外部DC-DC供电峰值电流2A以上不能直接用3.3V LDOPWRKEYGPIO输出拉低至少500ms触发开机RESETGPIO输出或悬空低电平有效上电初期建议拉高这里有一个容易被忽视的地方RM500U的UART电平是1.8V不是常见的3.3V TTL。多数STM32开发板的串口号称兼容3.3V逻辑直接接上去虽然能通讯但长期运行时可能出现偶发乱码。稳妥的做法是在RM500U的UART_RX/TX和STM32之间加一个电平转换芯片比如TXS0108或简单的二极管电平匹配电路。如果你手边的RM500U是带开发底板的版本底板一般已经把电平转到3.3V此时直接接STM32没问题。2.2 模组上电时序为什么AT指令回不了OKRM500U不是一颗简单的无线芯片它内部跑了完整的Linux操作系统上电到AT指令可用通常需要10秒到20秒这和ESP8266那种上电几百毫秒就能工作的模组完全是两个节奏。正式项目里STM32在复位后不能立刻发AT要先给模组留出启动时间。我一般会在代码里做这样一个流程模组PWRKEY拉低500ms松开然后循环发送不带回车的AT字符每500ms一次最多等到30秒。当收到OK响应时才认为模组就绪。这个机制的代码逻辑很简单但能避免项目前期把大量时间浪费在为什么AT没反应上。另外注意RM500U冷启动时电流会冲高到2A以上如果用USB线供电的STM32开发板直接给模组供电电压跌落会导致模组反复重启现象就是AT偶尔通偶尔不通。给RM500U单独配一个可输出3A的DC-DC模块是省心方案。2.3 STM32侧的外设分配与CubeMX参数AHT20是I2C接口传感器RM500U走UART主控只需要两个外设一个I2C、一个USART。在STM32CubeMX里把I2C速率设为100kHz标准模式AHT20在400kHz下也能工作但信号线稍长或者上拉电阻偏大时容易读数飘100kHz最稳。USART设置为115200 8N1打开中断关闭硬件流控。RM500U的UART接口不支持RTS/CTS硬件流控这里务必关闭否则模组会等流控信号而一直不吐数据。外设初始化完成后别忘了处理延时问题。STM32标准库和HAL库的HAL_Delay在系统时钟配置错时会明显偏短或偏长会直接影响AHT20读取时序。用CubeMX配置外部高速晶振HSE把系统时钟倍频到最高再回头测一次延时是否准确。很多人AHT20读出的温度偏高排查到最后发现是HAL_Delay实际只延时了十分之一。3. RM500U拨号与网络附着AT指令把5G通道真正跑通3.1 建立数据通道的最小AT指令序列RM500U支持移远统一AT指令集和EC20、RM500Q等模组的指令风格一致熟悉4G模块的人可以直接上手。上电后依次输入下面的命令每一条都等到OK再发下一条。AT ATCPIN? ATCSQ ATCOPS? ATCGDCONT1,IP,cmiot ATCGACT1,1 ATCGPADDR1 ATQPING1,183.230.40.39逻辑说明AT探活ATCPIN?查SIM卡是否识别返回READY才能继续ATCSQ看信号强度数值代表接收信号电平大于15基本能正常工作ATCOPS?确认运营商注册状态返回里的第二个字段如果是0到3之间表示已经注册上网络。ATCGDCONT1设置PDP上下文APN要填当前SIM卡运营商实际使用的值比如电信的ctnet、联通的wonet移动物联网卡常见cmiot。ATCGACT1,1激活PDP上下文这一步成功了才有IP地址。最后ATCGPADDR1查询分配到的IP并用ATQPING验证到OneNET平台的网络通路。参数说明ATCGDCONT1,IP,cmiot中的第一个1是PDP上下文编号IP指IPv4cmiot是APN。如果这张卡是定向流量卡APN一定要填对否则5G虽然注册上了但任何TCP连接都建立不起来这是物联网卡最常见的问题。ATQPING1,183.230.40.39中的1也是上下文编号后面的IP是OneNET MQTT接入地址能收到字节回复说明模组的网络侧已经通了。3.2 5G和LTE的附着差异别被CSQ值骗了RM500U支持NSA和SA两种5G组网模式也向下兼容4G。实际环境中5G信号强度很好但不代表数据通道就通畅尤其在NSA组网下模组需要同时维持5G和LTE两条链路。检查是否真的工作在5G网络下用ATQNWPREFCFGmode_pref,NR5G强制优先5G再看ATQNWINFO回显的network mode是不是NR5G。一个实际的坑是在室内测试时5G信号显示满格但ATCGACT1,1返回ERROR。这种情况多数是当前小区的5G载波没有配置上行资源或者SIM卡的DNN配置不允许该APN走5G承载。此时把网络模式改为ATQNWPREFCFGmode_pref,LTE用LTE把数据业务先跑通项目联调期间效率更高。5G模组不是必须工作在5G网络关键在于数据业务链路是否可用。3.3 拨号方式选择AT指令自带协议栈还是外部PPPRM500U提供了两种上云路径。一种是模组内部完成TCP/IP协议栈MCU只管发AT指令比如ATQHTTP、ATQMTOPEN等这种方式MCU开销最小。另一种是走PPP拨号把模组当成一个网卡数据经过PPP链路后由MCU侧去处理TCP/IP。在单片机项目里前者更常用原因很简单STM32的RAM和Flash有限跑一个完整TCP/IP协议栈再叠加MQTT压力不小而模组自带协议栈处理这些绰绰有余。后面的MQTT接入全部基于移远的socket AT指令展开。4. OneNET MQTT鉴权与数据帧把AHT20数值送进物联网平台4.1 OneNET的MQTT不是标准MQTT差在鉴权OneNET平台提供MQTT接入能力但它的第一版接入方式对MQTT协议做了一层特殊封装网上流传的mqtt协议详解大多是从标准MQTT讲起直接套到OneNET上会连不上。差别主要体现在CONNECT报文的三个核心字段上标准MQTT中clientId、username、password是用户自己定义的OneNET则规定clientId填产品IDusername填设备IDpassword填设备接入的apiKey。这三个信息在OneNET控制台创建产品和设备后都能找到apiKey类似设备的访问令牌丢了可以重新生成。连接参数常见是MQTT地址183.230.40.39端口6002。R5模组侧的AT指令写法是ATQMTOPEN0,183.230.40.39,6002 ATQMTCONN0,产品ID,设备ID,apiKey逻辑说明ATQMTOPEN建立到OneNET的TCP连接0是socket连接编号后面是服务器地址和端口。ATQMTCONN发送MQTT CONNECT报文完成接入三个字符串依次对应OneNET要求的clientId、username、password。需要注意OneNET对apiKey的大小写敏感从控制台复制时不要加多余的换行或空格。参数说明如果ATQMTCONN返回ERROR大概率不是网络问题而是产品ID、设备ID、apiKey三者不匹配。可以先自查一遍ID中间是否混入空格再把apiKey重新生成一次。4.2 上行数据报文的topic与JSON格式OneNET MQTT接入中设备上报数据固定发布到sys/$dp这个topic平台才会把数据解析成数据流。payload是JSON格式结构如下{datastreams:[{id:temp,datapoints:[{value:25.3}]},{id:hum,datapoints:[{value:68.5}]}]}其中id要和控制台产品里已经创建的数据流名称一致。如果平台的数据流叫temperature而JSON里写temp上报会成功但平台侧显示不出折线图这是排查时最容易漏掉的一环。value可以是float平台端展示时保留一位小数。模组侧发布这条数据用ATQMTPUB指令ATQMTPUB0,0,0,0,sys/$dp,{\datastreams\:[{\id\:\temp\,\datapoints\:[{\value\:25.3}]}]}逻辑说明ATQMTPUB的参数里第一个0是连接编号第二个0是消息编号第三个0表示QoS等级为0第四个0表示不保留消息然后是topic和payload。QoS实际使用时保持0即可OneNET对QoS1的支持表现并不好反而容易出现重复数据点。而JSON字符串里双引号在AT指令中必须用\转义不然模组解析指令会在第一个双引号处截断。转义是多数人第一次做ATMQTT上报时最容易卡住的点。4.3 更稳妥的上报状态机把发布动作做成状态机比一次性阻塞式发送可靠得多。模组处于Onenet连接态时每次发布前先发ATQMTPUB等待模组返回提示符后再发JSON载荷。如果直接拼一条长指令发出去有些固件版本会因为缓冲问题丢尾部数据。正确时序是ATQMTPUB0,0,0,0,sys/$dp,60 {datastreams:...}其中60是payload长度必须在发送JSON前明确告知模组。模组收到完整载荷后会返回OK表示已进入发送流程再返回QMTPUB: 0,0,0表示发送完成。建议在收到QMTPUB: 0,0,0之后再做下一次采集和上报避免多个报文在模组内部排队。5. STM32采集AHT20并发布MQTT完整驱动代码拆解5.1 AHT20的I2C读取时序与温湿度换算AHT20出厂时已经校准MCU读取的流程是初始化、触发测量、等待、读取六字节数据。读取到的六个字节中状态字占一个字节后面是湿度20bit和温度20bit。需要注意AHT20的I2C设备地址是0x38左移一位后在HAL库的写函数里传入0x70作为引脚地址。uint8_t AHT20_Measure(void) { uint8_t cmd[3] {0xAC, 0x33, 0x00}; uint8_t raw[6] {0}; uint32_t hum_raw, temp_raw; float hum, temp; HAL_I2C_Master_Transmit(hi2c1, 0x70, cmd, 3, 100); HAL_Delay(80); HAL_I2C_Master_Receive(hi2c1, 0x71, raw, 6, 100); if ((raw[0] 0x80) ! 0) { return 1; // 测量忙 } hum_raw ((uint32_t)raw[1] 12) | ((uint32_t)raw[2] 4) | (raw[3] 4); temp_raw (((uint32_t)raw[3] 0x0F) 16) | ((uint32_t)raw[4] 8) | raw[5]; hum (float)hum_raw * 100.0f / 1048576.0f; temp (float)temp_raw * 200.0f / 1048576.0f - 45.0f; printf(temp%.1f hum%.1f\r\n, temp, hum); return 0; }逻辑说明0xAC是AHT20的触发测量指令后面紧跟两个参数0x33和0x00这个是数据手册规定的固定序列。触发后芯片需要大约80ms完成测量HAL_Delay大于这个时间才能读到有效数据。读取时先判断状态字二进制首位是否为11表示芯片还在忙此时读取出来的数据是上一次的旧值。换算公式的细节尤其要注意AHT20的温度公式是T -45 200 * raw / 2^20而它的兄长AHT10用的是-40起算。如果把AHT10的公式套到AHT20上读出的温度会整体偏高5度。湿度公式两端是相同的RH 100 * raw / 2^20。2^20对应代码中的1048576直接用浮点运算就可以。5.2 拼装OneNET JSON帧并走UART下发AT指令采集到温度和湿度后下一步就是把浮点数格式化成OneNET要求的JSON字符串。用sprintf拼出payload再通过UART发送给RM500U。char payload[128]; char at_cmd[160]; sprintf(payload, {\datastreams\:[{\id\:\temp\,\datapoints\:[{\value\:%.1f}]},{\id\:\hum\,\datapoints\:[{\value\:%.1f}]}]}, temp, hum); sprintf(at_cmd, ATQMTPUB0,0,0,0,\sys/$dp\,%d\r\n, strlen(payload)); HAL_UART_Transmit(huart1, (uint8_t*)at_cmd, strlen(at_cmd), 1000); HAL_Delay(50); HAL_UART_Transmit(huart1, (uint8_t*)payload, strlen(payload), 1000); HAL_UART_Transmit(huart1, (uint8_t*)\r\n, 2, 1000);逻辑说明第一条ATQMTPUB指令中的%d是payload的字节数必须和实际发送的payload长度完全一致。%.1f控制小数点后一位OneNET平台显示折线图时偏好一位小数过多的有效位数反而会让Y轴刻度变得难读。发送完AT指令后不要立即发payload加一个短延时等待模组先返回字符这个字符是模组给出的可以接收数据的信号。参数说明HAL_UART_Transmit的最后一个参数是超时时间这里设1000ms。如果模组因为信号不好而处理变慢超时太短会导致payload发出去时模组还没进入接收模式数据直接丢失。另一个隐含问题是如果temp或hum的值是负数%.1f会正常输出负号OneNET数据流也接受负值AHT20测到零下温度时不需要特殊处理。5.3 发布完成判定与掉线重连判断模组在发布完成后会主动回一条QMTPUB: 0,0,0到串口。STM32的UART中断里要把这一帧完整收下来作为发布成功的标志。对于每次采集上报正确的闭环是串口收到完整响应后置位一个全局标志主循环看到标志后清零再进行下一次采集。这个做法避免了定时采集周期到了就盲目发AT指令结果模组还在处理上一次报文缓冲溢出后表现为主题正常但平台长时间不更新数据。RM500U的MQTT连接掉线后不会自动重连判断方法是看串口是否出现QMTSTAT: 0,1之类的URC上报或者ATQMTCONN?查询到的连接状态不是0。重连动作不要紧跟着掉线就执行常见的重连策略是启动一个5秒到10秒的延时然后重新执行ATQMTOPEN和ATQMTCONN因为模组在掉线瞬间网络栈还没有完全释放立即重连容易失败。6. 平台折线图验证与三层排错把问题定位到具体环节6.1 OneNET控制台创建数据流并确认折线图时间戳登录OneNET控制台在产品详情页的数据流管理里手动创建temp和hum两个数据流类型都是数值型。这里没有先建数据流或数据流名称和JSON里的id不一致平台侧根本不会画出折线图。设备详情页打开数据展示选择更新时间段一分钟后应该能看到新的数据点。确认平台显示正常的关键是看时间戳有没有一直往前走如果时间戳停留在几小时前说明设备的上报并没有真正到达平台。验证时可以手动在串口工具里发一条JSON把值固定为25.0和50.0平台折线图立刻出现这两个值再切回STM32实测数据就能区分问题是出在采集环节还是上报环节。OneNET折线图默认按时间聚合显示数据点过密时看起来是一条直线可以把时间粒度调到1分钟观察单点数据。6.2 三层排错顺序与常见错误码对照排查顺序按照信号链路从底层往上走严格按照下面的顺序来可以少走弯路层级检查手段常见结果模组网络层ATCSQ信号值、ATCGACT?PDP激活状态信号值过低或PDP未激活协议接入层ATQMTCONN?查询MQTT连接状态检查CONNACK返回码返回非0表示鉴权或网络参数错误应用数据层平台数据流时间戳是否为当前时间JSON的id与数据流名称不一致error: no stm32 target found!这类报错在烧录阶段频繁出现跟5G链路无关常见原因是没有安装配套的STM32芯片包或者ST-Link的SWDIO和SWCLK两根线在板子上没有接对目标芯片。先用stm32 st-link utility读一下IDCODE能读到芯片ID再上Keil比在烧录界面反复报错里找原因都快。6.3 AT指令交互的调试技巧RM500U的UART回显默认开着收下来的每个字符都有回显第一次看会很乱。可以在AT指令集调试时用ATE0关闭回显串口输出会干净很多。另外RM500U有个ATQCFGdbgctl之类的日志开关不建议在正常调试时打开它会把模组内部日志混在AT响应里输出干扰判断。还有一点RM500U的串口默认是本机回显模式接线只接TX和RX不接GND时现象往往是模组能收到AT但没有任何响应因为信号回路不完整。排查串口通信时第一件事就是确认共地第二件事才是换波特率。OneNET数据流的更新频率和MQTT心跳有关模组默认心跳间隔较长长时间只采集不发布会让平台判定设备离线。每次完成数据上报后同步执行一次ATQMTPING0来维持连接保活这样即便数据采集周期拉长到几分钟一次平台上的设备状态也始终显示在线。这算是整套链路里性价比最高的一个小动作强烈建议加上。本文还有配套的精品资源点击获取