3. 对象字典（OD）：CANopen设备的灵魂
好，咱们今天来聊聊对象字典。说实话，这是整个CANopen协议里最核心的东西，没有之一。我经常跟团队里的新人说，你搞懂了对象字典，CANopen就算入门一半了。
对象字典是什么？说白了，它就是一个标准化的数据清单。每个CANopen设备都有一份自己的对象字典，里面记录了设备的所有参数、配置、状态和数据。你可以把它想象成设备的“身份证”加“使用说明书”。
核心观点：对象字典是CANopen设备与外界通信的唯一接口。所有网络通信，本质上都是在读写对象字典里的某个条目。
3.1 对象字典的结构
对象字典的结构其实很简单，就是一个线性表。每个条目由索引（Index）和子索引（Subindex）唯一确定。
- 索引：16位无符号整数，范围0x0000~0xFFFF。相当于一本书的“章节号”。
- 子索引：8位无符号整数，范围0x00~0xFF。相当于章节里的“小节号”。
举个例子，我做过一个伺服驱动器的项目。它的“设备类型”存在索引0x1000，子索引0x00。而“制造商设备名称”存在索引0x1008，子索引0x00。你看，索引号是有规律的，0x1000系列专门放设备信息。
嗯，这里要注意：索引0x0000~0x0FFF是CANopen协议强制保留的，用来存放通用参数。比如：
| 索引范围 | 用途 | 我见过的坑 |
|---|---|---|
| 0x1000~0x1FFF | 通信对象（COB-ID、同步、心跳等） | 有人把0x1005的同步ID写错了，整个网络乱套 |
| 0x2000~0x5FFF | 制造商特定参数（随便你用） | 我习惯从0x2000开始放自定义参数 |
| 0x6000~0x9FFF | 标准化设备参数（比如驱动器的位置、速度） | CiA 402标准定义得很细，别自己乱改 |
| 0xA000~0xFFFF | 网络变量或补充参数 | 用得少，但有些网关设备会用到 |
3.2 索引与子索引的细节
你可能会问：为什么要有子索引？直接一个索引搞定不行吗？
我刚开始也这么想。直到有一次，我需要在一个设备里存32个IO通道的配置。每个通道有类型、极性、滤波时间三个参数。如果没有子索引，我得用96个索引号，太浪费了。有了子索引，一个索引就够了：
- 索引0x2100，子索引0x00：表示通道数量（这里是32）
- 索引0x2100，子索引0x01：通道1的配置
- 索引0x2100，子索引0x02：通道2的配置
- ……
- 索引0x2100，子索引0x20：通道32的配置
你看，子索引0x00通常用来表示“这个数组有多大”。这是CANopen的约定俗成，我个人建议你也这么用。
小技巧：子索引0x00的数据类型通常是UNSIGNED8，表示后面有多少个有效子索引。如果你的设备支持动态配置，记得在初始化时更新这个值。
3.3 对象字典的数据类型
CANopen定义了一套标准数据类型。别小看这个，我见过有人把32位数据当16位传，结果数值对不上，排查了一整天。
常用的数据类型有：
- BOOLEAN：其实就是UNSIGNED8，0表示假，非0表示真。嗯，这里要注意，有些设备用1表示真，有些用255，最好统一。
- UNSIGNED8/16/32：无符号整数。我最常用的是UNSIGNED16，够用又不浪费。
- INTEGER8/16/32：有符号整数。处理温度、位置偏差这些带符号的值时用。
- REAL32：浮点数。处理PID参数、比例系数时必备。
- VISIBLE_STRING：可见字符串。比如设备名称、版本号。
- OCTET_STRING：字节串。用来传一些自定义的二进制数据。
我曾经在一个项目里，需要存一个64位的计数器。CANopen标准里没有UNSIGNED64，怎么办？我用了两个UNSIGNED32拼起来，高32位和低32位分别放在两个子索引里。虽然麻烦点，但兼容性没问题。
避坑指南：我曾经在字节序（Endian）上吃过亏。CANopen默认是大端模式（Motorola格式），但有些MCU是小端（Intel格式）。如果你不做转换，读出来的数据就是反的。记住：索引和子索引用大端，数据内容用设备本地字节序。但为了保险，我建议所有数据都统一成大端。
3.4 对象字典的访问方式
对象字典里的每个条目，都有对应的访问权限。这就像文件系统里的读写权限一样，不能乱来。
常见的访问方式有：
- 只读（ro）：只能读，不能写。比如设备序列号、固件版本。你想想看，如果谁都能改序列号，那设备管理不就乱套了？
- 只写（wo）：只能写，不能读。用得少，但有些命令类参数会这么设计。比如“复位设备”命令，你写1进去就复位了，读它没意义。
- 读写（rw）：既能读也能写。大部分配置参数都是这种，比如波特率、节点ID。
- 常量（const）：固化的值，运行时不能改。比如对象字典本身的结构描述。
我建议你在设计对象字典时，把访问权限定义清楚。别图省事全设成rw，万一上位机误操作把关键参数改了，设备可能就罢工了。
另外，还有两种特殊的访问方式：
- 只读且不可映射（ro, no mapping）：这种参数不能通过PDO映射到实时通道。比如设备名称，你没必要在实时控制里频繁读取它。
- 读写且可映射（rw, mapping）：这种参数可以参与PDO通信。比如目标位置、运行速度，这些需要在实时循环里交换的数据。
经验之谈：我在设计对象字典时，会先画一张表。列清楚每个条目的索引、子索引、名称、数据类型、访问权限、默认值、是否可映射。这张表就是你的“对象字典说明书”，后续开发、测试、文档都靠它。
3.5 对象字典的实现要点
最后，聊聊实现层面的东西。对象字典在代码里怎么存？
我见过几种做法：
- 结构体数组：每个条目用一个结构体描述，包含索引、子索引、数据类型、数据指针、访问权限等。简单直观，适合资源受限的MCU。
- 链表：动态管理，适合需要热插拔或动态配置的设备。但实时性差一些。
- 哈希表：查找快，但实现复杂，一般用在高端处理器上。
我个人习惯用结构体数组。给你看个简化版的例子：
typedef struct {
uint16_t index; // 索引
uint8_t subindex; // 子索引
uint8_t data_type; // 数据类型（UNSIGNED8, UNSIGNED16...）
uint8_t access_type; // 访问权限（ro, rw, wo...）
void* data_ptr; // 指向实际数据的指针
uint8_t data_len; // 数据长度（字节数）
} OD_Entry_t;
// 对象字典表
const OD_Entry_t OD_Table[] = {
{0x1000, 0x00, UNSIGNED32, RO, &device_type, 4},
{0x1008, 0x00, VISIBLE_STRING, RO, &device_name, 16},
{0x2000, 0x00, UNSIGNED8, RO, &channel_count, 1},
{0x2000, 0x01, UNSIGNED16, RW, &channel_config[0], 2},
// ... 更多条目
};你看，每个条目都指向一个实际变量。当SDO请求来的时候，CANopen协议栈就根据索引和子索引去查这张表，找到对应的数据指针，然后读写数据。
提示：如果你的MCU内存够大，可以把对象字典表放在RAM里，这样运行时可以动态修改。如果内存紧张，就放Flash里，但要注意写Flash的寿命问题。
好了，对象字典这部分就讲到这里。记住一句话：对象字典是CANopen设备的灵魂，设计好它，你的设备就成功了一半。下一章咱们聊聊SDO通信，看看怎么通过网络来读写这个对象字典。