3. 对象字典(OD)基础：对象字典概念、索引与子索引、数据类型定义、OD存储结构
各位同学，咱们今天聊聊对象字典。说实话，我刚接触CANopen那会儿，觉得这玩意儿就是个“大表格”，没啥了不起的。直到我在一个伺服驱动项目里，因为OD配置搞错了，电机直接“飞车”……嗯，从那以后，我再也不敢小看它了。
对象字典，英文叫Object Dictionary，简称OD。说白了，它就是CANopen设备的“身份证”加“说明书”。你想想看，两个设备要通信，总得知道对方能干啥、数据长啥样吧？OD就是干这个的。
3.1 对象字典的核心概念
每个CANopen设备，都有一个OD。它本质上是一张标准化的数据表。这张表里，存放了设备的所有参数、配置、状态信息。
我个人习惯把OD比作一个“抽屉柜”。每个抽屉有个编号，抽屉里还有小格子。你通过SDO（服务数据对象）协议，就能读写这些抽屉里的数据。
核心要点：OD是CANopen通信的“中间人”。应用层读写OD，通信层也读写OD。两边不直接打交道，全靠OD传话。
我在一个多轴同步项目里遇到过，两个驱动器因为OD中“设备类型”索引没对齐，导致主站一直识别错误。排查了整整两天……后来发现就是0x1000这个索引的值写错了。所以，OD的规范性，直接决定了系统能不能跑起来。
3.2 索引与子索引
OD的每个条目，都由两个东西定位：索引和子索引。
- 索引（Index）：16位无符号整数，范围0x0000~0xFFFF。相当于“抽屉号”。
- 子索引（Subindex）：8位无符号整数，范围0x00~0xFF。相当于“抽屉里的小格子”。
举个例子，你读一个设备的名字，索引是0x1008，子索引是0x00。为什么要有子索引？因为有些数据是数组或结构体。比如一个驱动器的“位置实际值”，可能包含多个轴的数据，每个轴占一个子索引。
| 索引范围 | 用途 | 说明 |
|---|---|---|
| 0x0000~0x0FFF | 通信对象 | 设备类型、错误寄存器、SDO参数等 |
| 0x1000~0x1FFF | 制造商特定 | 各厂家自定义的参数 |
| 0x2000~0x5FFF | 设备配置文件 | 比如DS402驱动器的控制字、状态字 |
| 0x6000~0x9FFF | 标准化设备 | 数字量输入输出、模拟量等 |
| 0xA000~0xFFFF | 保留/扩展 | 一般不用 |
避坑指南：我曾经在配置0x1017（心跳生产者时间）时，把索引写成了0x1018，结果设备一直不发心跳。记住，索引和子索引必须精确匹配，差一个字节都不行。
3.3 数据类型定义
OD里的数据，不是随便存的。CANopen标准定义了一套完整的数据类型。说白了，就是告诉设备：这个数据是整数还是浮点数？占几个字节？
常用的数据类型有这些：
- BOOLEAN：布尔型，1字节，0或1。
- INTEGER8/16/32：有符号整数，分别占1、2、4字节。
- UNSIGNED8/16/32：无符号整数，分别占1、2、4字节。
- FLOAT32：单精度浮点数，4字节，符合IEEE754标准。
- VISIBLE_STRING：可见字符串，比如设备名称。
- OCTET_STRING：字节串，用于传输原始数据。
你想想看，如果两个设备对同一个索引的数据类型理解不一致，会发生什么？我遇到过，一个设备把0x6040（控制字）当UNSIGNED16读，另一个当INTEGER16写，结果数值对不上，电机死活不转。所以，数据类型定义必须严格遵循标准。
重要提醒：在CANopenNode中，每个OD条目都包含一个“数据类型”字段。这个字段的值，对应CiA标准中的数据类型编号。比如0x07代表UNSIGNED32，0x05代表INTEGER16。写代码时，一定要查表确认。
3.4 OD存储结构
OD在内存里怎么存？这直接关系到读写效率和代码复杂度。CANopenNode采用了一种“数组+链表”的混合结构。
说白了，就是用一个大的结构体数组，每个元素代表一个OD条目。每个条目里，包含了索引、子索引、数据类型、访问权限、当前值指针等信息。
我给大家看一个简化版的OD条目结构体：
typedef struct {
uint16_t index; // 索引
uint8_t subIndex; // 子索引
uint8_t dataType; // 数据类型编号
uint8_t accessType; // 访问权限：只读、读写、只写
void* dataPtr; // 指向实际数据的指针
uint32_t dataLength; // 数据长度（字节）
} OD_entry_t;为什么用指针？因为OD里的数据，可能分散在程序的不同地方。比如设备名称存在Flash里，控制字存在RAM里。用指针，就能灵活地指向这些位置，不用把数据复制来复制去。
实际项目中，OD数组可能很大。一个复杂的伺服驱动器，OD条目可能超过200个。我建议把OD数组放在Flash里，只把需要频繁修改的条目（比如控制字、状态字）映射到RAM。这样既省空间，又保证速度。
注意：OD的存储结构，直接影响SDO的响应速度。我曾经在一个项目里，把OD数组放在了外部Flash，结果每次SDO读写都要等几十微秒。后来改到内部Flash，速度提升了10倍。所以，关键数据尽量放在内部存储。
3.5 实际应用中的OD设计
好了，理论说完了，咱们聊聊实战。设计OD时，我一般遵循几个原则：
- 先标准，后自定义：能用标准索引的，绝不用自定义。比如设备类型用0x1000，错误寄存器用0x1001。这样别的设备一看就懂。
- 数据类型要统一：同一个参数，在整个系统中数据类型必须一致。别一个地方用INTEGER16，另一个地方用UNSIGNED16。
- 访问权限要合理：只读的参数，别设成读写。否则主站误写，可能导致设备异常。
- 预留扩展空间：在自定义区域（0x2000~0x5FFF），留一些未使用的索引。方便后续升级。
我记得有一次，客户要求增加一个“温度补偿系数”参数。因为我在OD里预留了索引0x2100~0x210F，直接填进去就行，不用动其他代码。这就是预留的好处。
小技巧：在CANopenNode中，OD的初始化代码是自动生成的。你只需要编辑一个OD描述文件（通常是.eds或.xdd格式），然后运行代码生成工具。这样既规范，又不容易出错。我个人习惯用.xdd格式，因为它基于XML，可读性更好。
最后，总结一下。对象字典是CANopen设备的灵魂。索引和子索引是定位数据的“坐标”，数据类型是解析数据的“规则”，存储结构是组织数据的“骨架”。把这三点搞透了，CANopen开发就成功了一半。
下一章，咱们聊聊SDO协议，看看怎么通过OD读写数据。到时候，我会分享一个我调试SDO超时的真实案例，保证让你印象深刻。