采集终端#

终端以 CC2530 为主控，主要外设连接如下：

终端完成 ZigBee 入网后，大约每 2.000～2.255 秒采集并发送一次数据。增加少量随机抖动，可以降低多个终端同时发送造成碰撞的概率。

协调器与 4G 网关#

协调器板上同时包含 CC2530 和 STM32F103RCT6。两颗 MCU 分工明确：CC2530 处理 ZigBee 协议栈，STM32 负责网关业务。

三路串口均采用 115200、8N1：USART1 输出调试日志，UART4 接收 CC2530 数据，USART3 与 ML307R 通信，从硬件和软件层面避免了串口资源冲突。

终端到协调器：ZigBee 数据帧#

终端成功读取 DHT11 后发送 5 字节数据：

1
['T', 'H', temperature, humidity, checksum]

校验值为前 4 个字节相加后取低 8 位：

1
checksum = 'T' + 'H' + temperature + humidity;

协调器收到数据后会检查帧头、长度、校验值和温湿度范围。数据有效时，它从 Z-Stack 的接收包结构中读取真实的 ZigBee 网络短地址：

1
pkt->srcAddr.addr.shortAddr

因此，网关不仅能知道温湿度，还能区分数据来自哪个终端节点。协调器接收成功后会向终端广播 D1 确认帧，终端通过 LED 显示本次数据已被接收。

协调器到 STM32：ASCII 串口帧#

为了方便串口调试和跨平台解析，CC2530 将无线数据转换为固定格式的 ASCII 帧：

1
$TH,IIII,TTT,HHH*CC\r\n

各字段含义如下：

示例：

1
$TH,E839,025,060*CC\r\n

STM32 的 UART4 中断只负责把字节写入 128 字节环形缓冲区，避免在中断中执行耗时操作。主循环再以 $ 为同步字符，以换行符为帧结束标志，完成格式检查、异或校验、数值转换和量程判断。

这种设计即使遇到丢字节、粘包或无效数据，也能在下一次出现 $ 时重新同步。网关还记录累计接收字节数和无效帧数，并显示为：

1
UART B:<接收字节数> E:<无效帧数>

这组计数在排查引脚、波特率和数据格式问题时非常实用。

STM32 到 OneNET：4G 属性上报#

STM32 通过 USART3 向 ML307R 发送 AT 指令，主要初始化过程包括：

1. 连续发送 AT，确认模块已经完成启动且串口通信稳定；
2. 选择 OneNET RTU 任务；
3. 写入产品、设备和鉴权参数；
4. 配置会话清理、保活时间和多消息模式；
5. 订阅属性上报回复与属性设置通道；
6. 重启模块并等待蜂窝网络注册完成；
7. 发布一次设备属性，并以平台返回的 code:200 作为真正成功的依据。

每次上报的数据不仅包含温度和湿度，还包含本地输出设备的当前状态：

1
{
2
  "id": "1",
3
  "version": "1.0",
4
  "params": {
5
    "temp": { "value": 25 },
6
    "humi": { "value": 60 },
7
    "LED1": { "value": false },
8
    "LED2": { "value": false },
9
    "buzzer": { "value": false }
10
  }
11
}

程序只有在收到 OneNET 的成功回复后才增加 OLED 上的上传计数，避免将“AT 指令已经发出”误判为“数据已经被云平台接受”。

终端流程#

1. 初始化 CC2530、OLED 和 DHT11；
2. 启动 Z-Stack 并搜索 ZigBee 网络；
3. 入网成功后启动周期任务；
4. 读取 DHT11 的 40 位数据并校验；
5. 在 OLED 显示节点地址、温度和湿度；
6. 通过 ZigBee 发送传感器帧；
7. 等待协调器确认，并进入下一次采集周期。

DHT11 读取失败时，OLED 会显示 DHT11 ERROR，程序不会发送无效数据。

网关流程#

1. 初始化调试串口、UART4、OLED、LED、蜂鸣器和 ML307R；
2. 配置 ML307R 并连接 OneNET；
3. 持续从 UART4 环形缓冲区取出 CC2530 数据；
4. 对串口帧执行重新同步、格式检查和校验；
5. 更新 OLED、LED 和蜂鸣器状态；
6. 将最新属性上传到 OneNET；
7. 处理云端属性下发；
8. 连续发布失败达到上限后，将网络标记为离线并定期重连。

即使 4G 网络暂时不可用，ZigBee 数据接收、OLED 显示和现场告警仍然可以继续运行，避免云端故障影响本地监测功能。

CC2530#

使用 IAR Embedded Workbench for 8051 打开：

1
Projects/zstack/Samples/SampleApp/CC2530DB/SampleApp.ewp

工程包含终端与协调器 Target，需要分别选择对应目标进行编译和下载。

STM32#

使用 Keil MDK 打开：

1
协调器4G上云/Project.uvprojx

根据自己的 OneNET 产品配置修改 app_config.h，编译后下载到 STM32F103RCT6。

仓库的 烧录文件 目录已经提供三个最终固件：

1
EndDevice_CC2530.hex
2
Coordinator_CC2530.hex
3
Gateway_STM32.hex

推荐烧录顺序：

1. 将 Gateway_STM32.hex 烧录到协调器板上的 STM32；
2. 将 Coordinator_CC2530.hex 烧录到协调器 CC2530；
3. 将 EndDevice_CC2530.hex 烧录到终端 CC2530；
4. 先启动协调器，再启动终端。

1. STM32 串口引脚判断错误#

最初将 CC2530 数据接收配置为 PA3/USART2_RX，但开发板原理图中的板内网络 RXD4 实际连接到 PC11/UART4_RX，导致网关一直显示 UART B:0。

修正 UART4 引脚与中断入口后，STM32 才能正确接收协调器数据。这次问题说明，在使用集成开发板时，不能只根据 MCU 的常用串口引脚猜测连接关系，必须以原理图上的网络名和实际走线为准。

2. 中断中执行过多业务导致时序风险#

早期实现如果在串口中断内直接解析协议或处理业务，很容易延长中断占用时间。最终方案让中断仅负责写环形缓冲区，将协议解析放到主循环中，既减少丢字节风险，也便于实现错误恢复。

3. DHT11 时序与 ZigBee 任务冲突#

DHT11 对微秒级时序较敏感，但长时间关闭中断会影响 Z-Stack 的系统节拍和无线任务。最终只在约 4 ms 的关键 40 位读取窗口中进行必要的临界区保护，而 18～20 ms 的启动阶段保持中断开启，在传感器时序与协议栈实时性之间取得平衡。

4. 发送成功不等于云端接收成功#

串口发送完 AT 指令只能说明命令已经交给 4G 模块，不能证明 OneNET 已经接受数据。因此程序将平台返回的 code:200 作为成功依据，并且只在收到成功回复后增加上传计数。

5. 本地告警与云端控制的状态冲突#

如果云端控制直接覆盖本地状态，可能出现云端关闭蜂鸣器后现场高温告警失效的问题。本项目将本地告警与云端请求分别保存，最后合并输出，使远程控制不会破坏基本的安全告警逻辑。

6. 旧版工程与新工具链的兼容问题#

项目还处理了 IAR 10 启动文件虚拟寄存器、Z-Stack Target 内存空间不足、HAL LCD 与终端 P1.7 蜂鸣器引脚冲突，以及自定义 UART 与 Z-Stack HAL UART 对象冲突等问题。这些问题大多不是业务代码错误，而是旧协议栈、编译器版本和硬件复用共同产生的工程兼容问题。