📚 课程目录第3章对象字典(OD)详解

对象字典（OD）详解：CANopen 协议栈的“灵魂”

各位同学，今天我们来聊聊 CANopen 里最核心、也最绕不开的一个东西——对象字典（Object Dictionary，简称 OD）。

我刚开始接触 CANopen 的时候，看了半天文档，感觉这东西就是个“大表格”。后来做项目踩了坑才明白，OD 就是协议栈的“灵魂”。你想想看，一个 CANopen 设备，它有什么参数、能干什么、怎么控制它，全都写在 OD 里。没有 OD，你的设备就是个“哑巴”。

一句话总结：对象字典是 CANopen 设备所有数据的“中央仓库”。SDO 用来读写它，PDO 用来映射它，NMT 用来管理它。搞懂了 OD，你就搞懂了 CANopen 的一半。

OD 的结构：一个“三层”的树

OD 的结构其实不复杂。它就像一棵树，有三层：索引（Index）、子索引（Subindex）、数据（Data）。

索引（Index）：16 位，范围 0x0000 ~ 0xFFFF。它代表一个“对象”或“参数组”。比如 0x1000 是设备类型，0x6000+ 是厂家自定义参数。
子索引（Subindex）：8 位，范围 0x00 ~ 0xFF。它代表一个“对象”里的具体条目。比如 0x1001 是错误寄存器，它只有一个子索引 0x00。
数据（Data）：就是实际存的值。可以是整数、浮点数、字符串、数组、结构体……

我习惯把 OD 想象成一个“三层书架”：索引是书架编号，子索引是层数，数据就是书。你要找一本书，先找到书架（索引），再找到层（子索引），最后拿到书（数据）。

我的经验：刚开始写 OD 时，我总把索引和子索引搞混。后来我画了个图，贴在工位上，再也没错过。你也不妨试试。

索引与子索引：怎么用？

CANopen 标准把索引空间分成了几个区段。我整理了一张表，你一看就明白：

索引范围	用途	说明
0x0000	保留	不用
0x0001 ~ 0x001F	数据类型定义	比如 BOOLEAN、INTEGER8、UNSIGNED32 等
0x0020 ~ 0x003F	复杂数据类型	比如 PDO 映射结构、时间结构等
0x1000 ~ 0x1FFF	通信对象	设备类型、错误寄存器、COB-ID 等
0x2000 ~ 0x5FFF	厂家自定义	你随便用，想放什么放什么
0x6000 ~ 0x9FFF	标准设备子协议	比如 DS-301、DS-402 等定义的参数
0xA000 ~ 0xFFFF	保留或厂家自定义	看具体协议

举个例子。0x1000 是“设备类型”，它只有一个子索引 0x00，数据是一个 32 位整数。0x1001 是“错误寄存器”，也是单子索引。但像 0x1600（接收 PDO 映射参数）就有多个子索引：0x00 是“子索引数量”，0x01、0x02……是具体的映射条目。

注意：子索引 0x00 通常用来表示“子索引的数量”或“最大值”。这是 CANopen 的约定，别乱改。我曾经见过一个新手把子索引 0x00 当普通数据用，结果 SDO 读出来全是错的……

数据类型定义：OD 里的“语言”

OD 里存的数据，不是随便放的。每个数据都有明确的数据类型。CANopen 标准定义了一套基础数据类型，我列几个常用的：

BOOLEAN：1 字节，0 或 1。
INTEGER8/16/32：有符号整数，长度分别是 1、2、4 字节。
UNSIGNED8/16/32：无符号整数。
REAL32/FLOAT32：32 位浮点数（IEEE 754）。
VISIBLE_STRING：可见字符串，比如设备名称。
OCTET_STRING：字节串，比如固件版本。
DOMAIN：大块数据，比如固件升级用的二进制文件。

你可能会问：“为什么要有这么多类型？” 说白了，就是为了节省带宽和内存。CAN 总线一帧只有 8 字节，你用 32 位整数存一个开关状态，太浪费了。用 BOOLEAN 就够了。

我在项目中遇到过一个问题：一个温度传感器，温度范围是 -40 ~ 125℃，精度 0.1℃。我一开始用 INTEGER16，后来发现 INTEGER8 就够了（-128 ~ 127），省了一半内存。嗯，细节决定成败。

OD 在协议栈中的存储方式：EDS、XDD 与运行时结构

OD 在协议栈里怎么存？这个问题很实际。你写代码时，OD 不是凭空存在的。它有三种形态：

1. EDS 文件（Electronic Data Sheet）

EDS 是文本文件，用 INI 格式描述 OD。它用于配置工具（比如 CANopen 配置软件）来读取设备的能力。你开发时，先写 EDS，再生成代码。

; 示例：EDS 文件片段
[1000]
ParameterName=Device Type
ObjectType=0x07
DataType=0x0007
AccessType=ro
DefaultValue=0x00000000

2. XDD 文件（XML Device Description）

XDD 是 XML 格式，比 EDS 更灵活。它支持更复杂的数据结构，比如数组、结构体、枚举。现在新项目基本都用 XDD 了。

<?xml version="1.0"?>
<CANopenDevice>
  <ObjectDictionary>
    <Object Index="0x1000">
      <Name>Device Type</Name>
      <DataType>UNSIGNED32</DataType>
      <AccessType>ro</AccessType>
    </Object>
  </ObjectDictionary>
</CANopenDevice>

3. 运行时结构（C 语言实现）

这是协议栈在 MCU 里实际跑起来的样子。我见过很多种实现方式，但核心思路都一样：用一个结构体数组或链表来管理所有 OD 条目。

举个例子，我常用的一个简化版 OD 结构：

typedef struct {
    uint16_t index;        // 索引
    uint8_t  subindex;     // 子索引
    uint8_t  data_type;    // 数据类型（如 UNSIGNED32）
    uint8_t  access_type;  // 访问权限（ro/rw/wo）
    void*    data_ptr;     // 指向实际数据的指针
    uint8_t  data_len;     // 数据长度（字节）
} OD_Entry_t;

// 示例：定义一个 OD 表
OD_Entry_t OD_Table[] = {
    {0x1000, 0x00, UNSIGNED32, RO, &device_type, 4},
    {0x1001, 0x00, UNSIGNED8,  RO, &error_reg,   1},
    // ... 更多条目
};

你看，每个 OD 条目都包含索引、子索引、数据类型、访问权限、数据指针和长度。SDO 服务就是通过遍历这个表，找到对应的条目，然后读写数据。

我的建议：写 OD 表时，一定要把索引按顺序排好。这样查找时可以用二分法，效率高。我见过有人用链表，结果 SDO 响应慢得不行……

SVG 图：OD 结构全景

下面这张图，我画了 OD 的完整结构。从 EDS/XDD 文件，到运行时 OD 表，再到 SDO/PDO 如何访问它。你一看就明白。

避坑指南：我踩过的 OD 坑

最后，分享几个我实际项目中遇到的 OD 问题，你以后遇到了能少走弯路。

索引重复：OD 表里不能有两个相同的索引+子索引。我见过有人复制粘贴忘了改索引，结果 SDO 读到的数据永远是第一个条目的。
数据类型不匹配：OD 里定义的数据类型，和实际存的数据类型必须一致。比如你定义 UNSIGNED32，但实际存了一个 8 位整数，SDO 读出来就是错的。
访问权限搞错：有些参数是只读的（比如设备类型），你如果写成可写，配置工具可能会乱改。我有个项目，客户用配置工具把设备类型改了，结果设备不认了……
子索引 0x00 的值不对：子索引 0x00 表示“子索引数量”。如果你有 5 个子索引，0x00 的值应该是 5。写错了，SDO 会报错。

曾经有一次：我调试一个电机驱动器，SDO 读 0x6000 总是返回 0。查了两天，最后发现是 OD 表里 0x6000 的 data_ptr 指向了一个未初始化的变量。嗯，从那以后，我每次写完 OD 表都会做一次“指针检查”。

好了，对象字典的内容就讲到这里。你只要记住：OD 是 CANopen 的“中央仓库”，索引+子索引是钥匙，数据类型是锁。搞懂了这些，后面学 SDO 和 PDO 就轻松多了。