4、CANopenNode核心数据结构：OD对象结构、CO_NMT、CO_PDO、CO_SDO模块解析
好，咱们今天来啃一块硬骨头——CANopenNode的核心数据结构。说实话，我刚接触CANopenNode那会儿，看着那一堆结构体，头都大了。但后来我发现，只要把几个关键模块理清楚，整个框架就豁然开朗了。
这一章，我会带你逐个拆解OD对象字典、NMT、PDO和SDO这四个核心模块。嗯，咱们不搞教科书式的罗列，而是从实战角度出发，看看这些结构体到底怎么用。
4.1 对象字典（OD）——CANopenNode的“灵魂”
对象字典是什么？说白了，它就是CANopen设备的一个“数据库”。所有参数、配置、状态都放在这里。你想想看，一个设备要跟别人通信，总得有个统一的“接口规范”吧？OD就是这个规范。
在CANopenNode里，OD的核心结构是CO_OD。我直接上代码，咱们边看边聊：
typedef struct {
CO_OD_entry_t *entries; // 所有OD条目
uint16_t entriesCount; // 条目数量
uint32_t storageSize; // 存储大小
void *storage; // 存储指针
} CO_OD_t;这个结构看着简单，但每个CO_OD_entry_t才是重头戏。它长这样：
typedef struct {
uint16_t index; // 索引号
uint8_t subIndex; // 子索引
uint32_t attribute; // 属性（读写权限）
uint32_t dataType; // 数据类型
void *data; // 数据指针
uint32_t dataLength; // 数据长度
} CO_OD_entry_t;关键点：每个OD条目由“索引+子索引”唯一标识。比如0x1000是设备类型，0x1017是心跳生产者时间。这些索引号在CiA 301标准里都有定义，别自己瞎编。
我个人习惯把OD看作一个“大数组”。每个元素就是一个条目。访问的时候，通过索引和子索引直接定位。效率很高，但前提是你得把索引号背熟——至少常用的那几个要记住。
小技巧：我在项目中经常用CO_OD_find()函数来查找OD条目。这个函数内部做了二分查找，比线性查找快得多。如果你的OD条目超过100个，建议用这个。
4.2 CO_NMT——网络管理的“大脑”
NMT（Network Management）负责控制设备的状态机。CANopen设备有四种状态：初始化、预操作、操作、停止。NMT就是在这几个状态之间切换的“开关”。
核心结构是CO_NMT_t：
typedef struct {
CO_NMT_state_t state; // 当前状态
uint8_t nodeID; // 节点ID
uint32_t heartbeatTime; // 心跳时间
void *em; // 紧急错误对象
} CO_NMT_t;这里有个坑，我踩过。你看state字段，它是个枚举：
typedef enum {
CO_NMT_STATE_INITIALIZATION = 0,
CO_NMT_STATE_PRE_OPERATIONAL = 127,
CO_NMT_STATE_OPERATIONAL = 5,
CO_NMT_STATE_STOPPED = 4
} CO_NMT_state_t;为什么这些数字这么奇怪？0、127、5、4？其实这是CANopen协议规定的。初始化是0，预操作是127，操作是5，停止是4。别问我为什么这么设计，反正协议就是这么定的。
注意：设备上电后，默认进入预操作状态。这时候只能通过SDO通信，PDO是禁用的。必须收到NMT启动命令（0x01）后，才能进入操作状态。我曾经有个项目，调试了半天发现PDO发不出去，结果就是忘了发NMT启动命令。
4.3 CO_PDO——过程数据的“高速公路”
PDO（Process Data Object）用于实时传输数据。它不像SDO那样需要应答，而是“发完就完”。所以速度很快，适合传输传感器数据、控制指令等。
PDO分为两种：TPDO（发送PDO）和RPDO（接收PDO）。核心结构是CO_PDO_t：
typedef struct {
uint32_t cobID; // COB-ID
uint8_t transmissionType; // 传输类型
uint16_t inhibitTime; // 禁止时间
uint16_t eventTimer; // 事件定时器
uint8_t syncNum; // SYNC计数
uint8_t *data; // 数据指针
uint16_t dataLength; // 数据长度
} CO_PDO_t;这里最让人头疼的是transmissionType。它决定了PDO什么时候发送。我简单总结一下：
| 传输类型 | 触发方式 | 典型应用 |
|---|---|---|
| 0 | SYNC后，非周期 | 同步采集 |
| 1-240 | 每N个SYNC发送一次 | 周期性同步 |
| 254 | 事件触发（数据变化） | 传感器数据 |
| 255 | 事件触发（定时器） | 周期性上报 |
实战经验：我一般用类型254做传感器数据上报。数据变化了才发，省带宽。但要注意，如果数据变化太频繁，可能会把总线塞满。这时候可以配合inhibitTime（禁止时间）来限制发送频率。
4.4 CO_SDO——服务数据的“快递员”
SDO（Service Data Object）用于读写OD中的任意条目。它是一问一答的模式，可靠但慢。适合配置参数、诊断等场景。
核心结构是CO_SDO_t：
typedef struct {
uint32_t cobIDClient; // 客户端COB-ID
uint32_t cobIDServer; // 服务端COB-ID
uint16_t index; // 当前操作的索引
uint8_t subIndex; // 当前操作的子索引
uint8_t *data; // 数据缓冲区
uint32_t dataLength; // 数据长度
CO_SDO_state_t state; // 通信状态
} CO_SDO_t;SDO通信有四种状态：空闲、上传、下载、中止。每个状态对应不同的协议流程。我刚开始写SDO客户端时，总搞不清状态切换。后来画了个状态机图，才彻底搞明白。
避坑指南：我曾经在SDO下载（写数据）时，忘记检查dataLength是否匹配。结果写了一个4字节的数据到2字节的OD条目里，直接把后面的内存覆盖了。嗯，从那以后，我每次写SDO都会先读一下OD条目的长度。
4.5 四个模块的协作关系
这四个模块不是孤立的。它们通过OD这个“中心枢纽”协同工作：
- NMT控制设备状态，决定PDO和SDO是否可用
- PDO直接读写OD中的数据，实现快速交换
- SDO通过索引访问OD，实现任意条目的读写
- OD存储所有数据，是其他三个模块的“数据仓库”
举个例子：一个温度传感器设备，温度值存在OD的0x6401条目里。PDO可以配置成每100ms自动发送这个值。而SDO则可以用来修改PDO的传输周期（存在OD的0x1400条目里）。
总结一下：搞懂这四个模块，CANopenNode你就掌握了80%。剩下的就是配置和调试了。下一章，我会带你实战配置一个完整的CANopen节点。
嗯，今天就到这里。代码示例我都贴出来了，建议你动手在开发板上跑一跑。光看不练，等于白看。