简介：这份资源面向Zigbee与物联网开发的学习者和工程师，围绕CC2530微控制器、Paj7620手势传感器与ZStack-2.5.1a协议栈，提供一套可编译运行的短地址组网工程源码，帮助读者理解传感器数据采集与无线传输的完整链路。压缩包共1372个文件，约36.67MB，以c与h源码、s51与r51汇编、lst列表、cout与pbi编译中间文件为主，另含ewp、ewd等IAR工程配置、lib库文件、hex固件与map映射文件，覆盖从源码到烧录的完整构建产物。资源中已包含协调器与路由器的示例工程，可对照学习网络参数设置、节点入网与数据收发流程，并借助Paj7620驱动获取手势数据封装成Zigbee数据包。目前已有229人学习下载，适合希望深入Zigbee协议栈实践、搭建无线传感器网络原型的开发者参考。
1. 拿到 ZStack-2.5.1a 手势组网工程，先别急着烧录
如果你手头正好有一份ZStack-2.5.1a_paj7620_zigbeecc2530_的源码包，里面躺着znp.bat、SampleApp.CoordinatorEB.cspy.bat、SampleApp.RouterEB.cspy.bat、zcl_se.c、ZDSecMgr.c、esp.c、zcl.c这些文件，第一反应大概率是「这堆东西到底哪个能跑」。这不是一个从零开始的教程，而是一份已经被人拆过、改过、加过料的 ZStack 工程快照——它在 TI 官方 ZStack-2.5.1a 的基础上，塞进了 Paj7620 手势传感器的驱动逻辑，目标很明确：让 CC2530 通过 Zigbee 短地址组网，把手势识别结果从一个节点无线传到另一个节点。
适合谁看？手上已经有 CC2530 开发板（或者至少两块，一块做协调器一块做路由器）、装过 IAR Embedded Workbench for 8051、对 Zigbee 的 PAN ID、信道、短地址这些概念不陌生的人。如果你连 ZStack 的 OSAL 任务调度都没碰过，这份工程会让你在编译阶段就卡住。反过来，如果你正在找一个「传感器 + 无线组网」的完整参考，不想从空白工程一行行搭，这份源码的价值就在于它把 Paj7620 的 I2C 读取、手势事件解析、Zigbee 数据包封装这几段逻辑已经串好了，你改改引脚和端点就能用。
但先说一个反直觉的结论：这份工程里最容易被忽略的不是zcl.c或ZDSecMgr.c，而是那几个.bat文件。它们决定了你用哪个编译配置、生成什么类型的固件。很多人拿到源码直接双击.cspy.bat就开跑，结果烧进去发现设备根本不入网——问题往往出在协调器和路由器的编译目标搞混了。
2. 工程结构与编译目标：CoordinatorEB 和 RouterEB 到底差在哪
2.1 从.bat文件反推编译配置
ZStack-2.5.1a 的工程组织方式比较老派，它用.cspy.bat这类批处理文件来调用 IAR 的编译命令，而不是像新版 IAR 那样直接在 IDE 里切换配置。你看到的三个.bat：
| 文件名 | 对应角色 | 编译输出 | 典型用途 |
|---|---|---|---|
SampleApp.CoordinatorEB.cspy.bat | 协调器 | CoordinatorEB 固件 | 建网、分配短地址 |
SampleApp.RouterEB.cspy.bat | 路由器 | RouterEB 固件 | 入网、转发数据 |
SampleApp.cspy.bat | 默认/通用 | 取决于工程配置 | 快速验证编译 |
znp.bat是另一条线，它对应 ZNP（Zigbee Network Processor）模式，把 CC2530 当成纯射频模块，由外部 MCU 发串口命令控制。如果你只是想让两块板子互相传手势数据，用 CoordinatorEB + RouterEB 就够了，ZNP 那条路适合你已经有主控 MCU、只想把 Zigbee 当透传用的场景。
编译顺序上，我一般会先跑 CoordinatorEB 的 bat，确认 IAR 能正常链接，再跑 RouterEB。两个配置共用大部分源文件，但预编译宏不同——协调器会定义ZDO_COORDINATOR，路由器定义RTR_NWK。如果你只编译了一个就往两块板子烧同样的固件，要么两个都建网冲突，要么两个都不建网干等。
2.2 Paj7620 驱动在工程里的挂载点
Paj7620 是 I2C 接口的手势传感器，CC2530 本身没有硬件 I2C，工程里大概率是用 GPIO 模拟的。你需要在源码里找到类似paj7620_init()和paj7620_read_gesture()的函数，它们通常被挂在 SampleApp 的任务事件处理里。常见做法是：
// 在 SampleApp_ProcessEvent 的周期事件里轮询手势 if ( events & SAMPLEAPP_PERIODIC_EVENT ) { uint8 gesture = paj7620_read_gesture(); if ( gesture != GESTURE_NONE ) { // 把手势值塞进 Zigbee 数据包 SampleApp_SendPeriodicMessage( gesture ); } osal_start_timerEx( SampleApp_TaskID, SAMPLEAPP_PERIODIC_EVENT, 200 ); }这段逻辑的关键参数是轮询周期。200ms 是我试过比较稳的值，太快了 I2C 模拟时序容易翻车，太慢了手势会丢。Paj7620 本身有中断引脚，如果你把中断接上，可以改成中断触发读取，功耗会低很多。但这份工程里如果没配中断，轮询就是最直接的办法。
zcl.c和zcl_se.c是 ZCL（Zigbee Cluster Library）层的实现，zcl_se.c偏 SE（Smart Energy）profile。如果你只是传自定义手势数据，不一定非要走 ZCL 标准 cluster，直接用 AF（Application Framework）的AF_DataRequest发自定义端点数据更省事。ZDSecMgr.c是安全管理层，涉及链路密钥和网络密钥的处理，短地址组网时如果不开安全，这个文件基本不参与流程。
3. 短地址组网实操：PAN ID、信道与入网流程
3.1 协调器建网参数怎么设
短地址组网的核心是协调器建网后给每个入网设备分配一个 16 位短地址。在 ZStack 里，这些参数集中在f8wConfig.cfg和SampleApp.c的初始化部分。你需要关注的几个：
// f8wConfig.cfg 里的关键网络参数 -DZDAPP_CONFIG_PAN_ID=0x1234 // PAN ID，协调器和路由器必须一致 -DDEFAULT_CHANLIST=0x00000800 // 信道 11（bit11），可根据环境改 -DMAX_DEVICE_DEPTH=5 // 网络最大深度PAN ID 选 0x1234 只是示例，实际部署时如果周围有多个 Zigbee 网络，PAN ID 冲突会导致入网失败。我一般会先用频谱工具扫一下 2.4GHz 段，或者干脆把信道固定在 15、20、25 这几个相对干净的频点。DEFAULT_CHANLIST是位掩码，0x00000800 对应信道 11，0x00008000 对应信道 15，别直接写十进制。
协调器上电后会调用NLME_NetworkFormationRequest，如果返回ZSuccess，说明建网成功，此时短地址固定为 0x0000。你可以在SampleApp_HandleKeys里加一个按键触发建网，或者让它上电自动建。
3.2 路由器入网与短地址获取
路由器端的逻辑是上电后扫描信道、发送入网请求、等待协调器分配短地址。关键代码在ZDApp.c的ZDApp_NetworkInit和NLME_JoinRequest调用链里。你不需要改这些底层，但需要确认路由器的 PAN ID 和信道与协调器一致。
入网成功后，路由器的短地址可以通过NLME_GetShortAddr()获取。常见做法是在ZDO_STATE_CHANGE事件里判断状态：
if ( pMsg->hdr.event == ZDO_STATE_CHANGE ) { uint16 shortAddr = NLME_GetShortAddr(); if ( shortAddr != 0xFFFF && shortAddr != 0x0000 ) { // 入网成功，短地址有效 osal_start_timerEx( SampleApp_TaskID, SAMPLEAPP_SEND_PERIODIC_MSG_EVT, 1000 ); } }0xFFFF 是无效地址，0x0000 是协调器自己。路由器拿到短地址后就可以往协调器发数据了。这里有个坑：如果你在入网成功前就调用AF_DataRequest，数据会直接丢掉，不会报错也不会缓存。
3.3 手势数据从 Paj7620 到 Zigbee 数据包的完整链路
把前面几段串起来，完整链路是：Paj7620 通过模拟 I2C 输出手势值 → SampleApp 周期任务读取 → 封装成 AF 数据包 → 通过短地址发送到目标设备 → 目标设备在SampleApp_MessageMSGCB里解析。
// 发送端：封装手势数据 void SampleApp_SendGesture( uint8 gesture ) { afAddrType_t dstAddr; dstAddr.addrMode = afAddr16Bit; // 短地址模式 dstAddr.addr.shortAddr = 0x0000; // 发给协调器 dstAddr.endPoint = SAMPLEAPP_ENDPOINT; // 端点号，默认 8 AF_DataRequest( &dstAddr, &SampleApp_epDesc, SAMPLEAPP_GESTURE_CLUSTERID, 1, // 数据长度 &gesture, // 数据指针 &SampleApp_TransID, AF_DISCV_ROUTE, AF_DEFAULT_RADIUS ); }afAddr16Bit表示用短地址寻址，这是短地址组网的核心优势——数据包头部比 64 位长地址少 6 个字节。SAMPLEAPP_GESTURE_CLUSTERID是你自定义的 cluster ID，接收端要用同样的 ID 才能解析。AF_DEFAULT_RADIUS是路由跳数，默认值通常够用，网络深的时候可以加大。
接收端在SampleApp_MessageMSGCB里根据 cluster ID 分支处理，把pkt->cmd.Data[0]取出来就是手势值。
4. 避坑排查：编译、入网、I2C 时序的五个血泪经验
4.1 编译报错「无法打开 ZDSecMgr.h」
现象：IAR 编译时提示找不到头文件，但文件明明在工程目录里。原因通常是.bat文件里的相对路径和你实际解压路径不一致，或者 IAR 的 include 路径没配全。解决：打开 IAR 工程后，在 Project → Options → C/C++ Compiler → Preprocessor 里检查 Additional include directories，把ZStack-2.5.1a\Components\stack\sec这类路径补进去。别直接改 bat，改工程配置更稳。
4.2 协调器建网成功但路由器一直入不网
现象：协调器串口打印建网成功，路由器反复打印入网失败。原因排第一的是 PAN ID 或信道不一致，排第二的是ZDSecMgr.c里的安全策略——如果协调器开了安全而路由器没开，或者密钥不匹配，入网请求会被静默拒绝。解决：先确认两边f8wConfig.cfg的 PAN ID 和 CHANLIST 完全一致；如果开了安全，确认zgPreConfigKeys设置一致。实在不行先把安全关掉验证链路。
4.3 Paj7620 读出来的手势值全是 0 或乱跳
现象：I2C 能读到数据但手势识别结果不稳定。原因通常是模拟 I2C 的延时不够，Paj7620 的时序要求比普通 I2C 器件严格。解决：在 GPIO 翻转之间加asm("NOP")或者微秒级延时，具体几微秒要看你的 CC2530 主频。另一个可能是传感器初始化没完成就开读，加 100ms 上电延时再初始化。
4.4 短地址发送成功但接收端收不到
现象：AF_DataRequest返回ZSuccess，但接收端SampleApp_MessageMSGCB不触发。原因可能是端点号不匹配、cluster ID 不匹配，或者接收端的SampleApp_epDesc没有正确注册。解决：确认两边的SAMPLEAPP_ENDPOINT和SAMPLEAPP_GESTURE_CLUSTERID一致，检查SampleApp_RegisterEndpoint是否在初始化时被调用。
4.5 烧录后设备频繁掉网
现象：路由器入网后几分钟就掉线，协调器显示设备离开。原因常见于电源不稳——CC2530 在射频发射瞬间电流会跳变，如果供电不足会复位。解决：用示波器看 VCC 在发射时有没有跌落，加 100uF 电容就近去耦。另一个可能是看门狗没喂，检查osal_start_timerEx的周期任务里有没有阻塞操作。
5. 进阶技巧：用长地址绑定绕过短地址冲突
短地址组网效率高，但有一个边界：协调器重启后短地址可能重新分配，如果你在代码里硬编码了某个短地址，重启后就对不上了。我一般会加一层长地址绑定作为兜底。
ZStack 提供APSME_BindRequest，可以把发送端的长地址和接收端的长地址绑定，之后即使短地址变了，绑定关系还在。具体做法是在入网成功后，用NLME_GetExtAddr()拿到自己的 64 位长地址，通过协调器转发一次绑定请求。
// 绑定请求示例：把本地端点绑定到协调器的手势接收端点 ZDO_RegisterForZDOMsg( SampleApp_TaskID, Bind_rsp ); APSME_BindRequest( SAMPLEAPP_ENDPOINT, SAMPLEAPP_GESTURE_CLUSTERID, &coordAddr, SAMPLEAPP_ENDPOINT, &bindReq );coordAddr用afAddr64Bit模式填协调器的长地址。绑定成功后，后续AF_DataRequest可以直接用afAddrNotPresent模式，协议栈会自动查绑定表。这个技巧在设备数量多、短地址动态分配的场景下特别有用。
验证绑定是否生效，可以在发送端调用AF_DataRequest后看返回状态，或者直接在接收端加串口打印。我习惯在SampleApp_MessageMSGCB里加一行HalUARTWrite把收到的数据打出来，比用抓包器快。
从那以后我每次拿到 ZStack 的工程，都会先确认.bat对应的编译目标、再核对两边的 PAN ID 和信道、最后才动传感器驱动。这三步走完，基本不会在入网阶段翻车。希望帮到你。
本文还有配套的精品资源，点击获取
