对象字典（OD）基础：CANopenNode 的“灵魂”

聊 CANopen，绕不开对象字典。我刚开始接触时也觉得这名字挺唬人，什么“对象”、“字典”的。说白了，它就是一张标准化的表格，里面存着设备的所有参数、数据和配置。

你想想看，一个驱动器，它的转速、电流、报警码、节点 ID……这些东西总得有个地方放吧？对象字典就是干这个的。它让主站能通过索引和子索引，精准地找到并操作这些数据。

索引与子索引：地址怎么编？

对象字典的每个条目，都由两部分定位：索引（Index）和子索引（Subindex）。

• 索引：16 位地址，范围 0x0000 ~ 0xFFFF。你可以把它想象成书的“章”。比如 0x1000 是设备类型，0x6000+ 是数字量输入。
• 子索引：8 位地址，范围 0x00 ~ 0xFF。它是“章”下面的“节”。比如一个数组对象，子索引 0x00 通常存数组长度，子索引 0x01 存第一个元素。

我习惯把索引看作“门牌号”，子索引看作“房间号”。主站发 SDO 请求时，必须同时带上这两个号，才能找到正确的数据。

对象字典在 CANopenNode 中的实现

CANopenNode 的实现非常“C 语言”。它用结构体数组来模拟这张表。每个条目都是一个 OD_entry_t 结构体。

我直接贴一段核心代码，你一看就明白：

// 对象字典条目结构体（简化版）
typedef struct {
    uint16_t        index;          // 索引
    uint8_t         subIndexCount;  // 子索引数量
    OD_subentry_t   *subentries;    // 指向子索引数组的指针
    // ... 其他属性
} OD_entry_t;

// 子索引结构体
typedef struct {
    uint8_t         subIndex;       // 子索引号
    uint8_t         attribute;      // 读写属性（只读/只写/读写）
    uint32_t        dataLength;     // 数据长度（字节）
    void            *dataPtr;       // 指向实际数据的指针
    // ... 其他属性
} OD_subentry_t;

你看，每个子索引都存了数据指针 dataPtr。这意味着，对象字典里的条目，直接映射到你的 C 语言变量上。你改了变量，对象字典的值也跟着变。反过来，主站通过 SDO 改了对象字典，你的变量也会被更新。

对象字典的“骨架”：OD 存储

对象字典不能只活在 RAM 里，掉电就没了。CANopenNode 提供了 OD_storage 机制，用来把对象字典的初始值固化在 Flash 或 EEPROM 中。

它的工作流程是这样的：

1. 编译时：通过一个 OD.c 和 OD.h 文件，定义好所有条目的初始值。
2. 启动时：OD_init() 函数把这些初始值从 Flash 拷贝到 RAM 中的对象字典。
3. 运行时：主站可以修改 RAM 中的值。如果需要保存，主站会发 SDO 命令，触发 OD_write() 回调，把数据写回非易失存储。

我曾经在一个项目中，忘了配置 OD_storage 的保存触发条件。结果每次断电重启，设备参数都恢复出厂设置。排查了半天才发现，是保存回调没写对。嗯，这里要注意，保存操作不能太频繁，否则会磨损 Flash。

对象字典结构图

下面这张图，是我自己画的对象字典在 CANopenNode 中的整体结构。你可以看到，主站通过 SDO 或 PDO 访问对象字典，而对象字典内部通过指针，直接操作应用层的变量。

避坑指南：我踩过的几个坑

• 子索引 0x00 的约定：对于数组或记录类型，子索引 0x00 必须存子索引数量（最高支持数）。很多新手会忽略这个，导致主站读到的数组长度是错的。
• 数据长度对齐：CANopenNode 要求子索引的 dataLength 必须与实际变量类型匹配。比如 uint32_t 就是 4 字节，别写成 2。否则 SDO 读写会出莫名其妙的问题。
• 属性设置：attribute 字段控制读写权限。我见过有人把只读参数设成可写，结果主站误修改了关键配置，设备直接罢工。安全起见，能只读的就别给写权限。

好了，对象字典的基础就聊到这。它是 CANopen 通信的基石，也是你后续配置 SDO 和 PDO 的“数据仓库”。把这块搞透，后面的路会顺很多。