对象字典核心结构：索引、子索引与数据类型映射

对象字典（Object Dictionary，简称 OD）是 CANopen 协议栈的灵魂。说白了，它就是一张标准化的“数据登记表”，所有通信对象、设备参数、应用数据都按固定格式放在里面。我刚开始接触 CANopen 时，觉得 OD 就是个数组，后来踩了不少坑才明白——它的结构设计直接决定了从站能不能稳定工作。

2.1 对象字典的三层骨架

每个 OD 条目由三个要素唯一确定：索引（Index）、子索引（Subindex）、数据类型（Data Type）。你可以把它想象成一个三维坐标：

• 索引：16 位地址，范围 0x0000~0xFFFF，相当于“文件柜的抽屉号”。
• 子索引：8 位编号，范围 0x00~0xFF，相当于“抽屉里的文件夹”。
• 数据类型：规定每个条目占几个字节、怎么解析，相当于“文件夹里的文件格式”。

2.2 索引区域划分（CiA 301 标准）

CiA 301 标准把 0x0000~0xFFFF 分成了几个功能区。我个人习惯把这张表贴在工位上：

索引范围	用途	说明
0x0000	保留	不使用
0x0001~0x001F	静态数据类型	预定义类型描述，一般只读
0x0020~0x003F	复杂数据类型	结构体、数组等复合类型
0x1000~0x1FFF	通信对象	设备类型、错误寄存器、COB-ID 等
0x2000~0x5FFF	制造商特定	用户自定义参数，我最常用的区域
0x6000~0x9FFF	标准化设备行规	如 CIA 401 I/O 设备、CIA 402 驱动
0xA000~0xFFFF	保留/补充	协议扩展或网络管理

嗯，这里要注意：0x2000~0x5FFF 是留给我们的“自留地”。我在项目中习惯把电机参数、传感器校准值、运行模式都放在 0x2000~0x2100 这一段，方便管理。

2.3 子索引的约定

子索引 0x00 有特殊含义——它通常表示“条目数量”或“默认值”。比如一个数组对象，子索引 0x00 存数组长度，子索引 0x01 开始才是实际数据。

举个例子，一个存储 4 个温度值的对象：

索引 0x2000：温度数组
  子索引 0x00：值 = 4（表示有 4 个元素）
  子索引 0x01：温度值 1（INT16）
  子索引 0x02：温度值 2（INT16）
  子索引 0x03：温度值 3（INT16）
  子索引 0x04：温度值 4（INT16）

2.4 数据类型映射

CANopen 定义了标准数据类型，每个类型都有固定的字节长度和编码方式。我见过不少新手在这里栽跟头——数据类型不匹配，SDO 读写直接报错。

数据类型	CANopen 名称	字节数	取值范围
BOOLEAN	BOOLEAN	1	0x00 / 0x01
UNSIGNED8	U8	1	0~255
UNSIGNED16	U16	2	0~65535
UNSIGNED32	U32	4	0~4294967295
INTEGER8	I8	1	-128~127
INTEGER16	I16	2	-32768~32767
INTEGER32	I32	4	-2147483648~2147483647
FLOAT32	REAL32	4	IEEE 754 单精度
VISIBLE_STRING	VS	N	ASCII 字符串
OCTET_STRING	OS	N	原始字节流

2.5 对象字典在 STM32 中的内存映射

在 STM32 工程里，OD 通常实现为一个结构体数组。每个条目包含索引、子索引、数据类型、数据指针、访问权限等字段。我习惯用 const 数组定义静态 OD，运行时只修改数据值。

typedef struct {
    uint16_t index;        // 索引
    uint8_t  subindex;     // 子索引
    uint8_t  dataType;     // 数据类型编码
    uint8_t  accessType;   // 读写权限
    void*    dataPtr;      // 指向实际数据缓冲区
    uint8_t  dataLen;      // 数据长度（字节）
} OD_Entry_t;

// 示例：定义两个 OD 条目
const OD_Entry_t odTable[] = {
    {0x1000, 0x00, UNSIGNED32, RO, &deviceType, 4},
    {0x2000, 0x00, UNSIGNED8,  RO, &tempCount,  1},
    {0x2000, 0x01, INTEGER16,  RW, &tempValue1, 2},
    // ... 更多条目
};

为什么这样设计？因为 SDO 服务器收到请求后，直接查表就能找到数据地址，读写效率很高。你想想看，如果每次都要遍历链表，实时性就保不住了。

2.6 对象字典结构总览

下面这张图把索引、子索引、数据类型的关系画清楚了。我每次培训都会先画这张图——理解了它，CANopen 就懂了一半。

2.7 实际工程中的 OD 配置要点

基于上面的结构，我在 STM32 工程里总结了几条经验：

1. 索引规划要预留空间：不要把 0x2000~0x2100 塞满，留 20% 的空索引给后期升级。
2. 子索引 0x00 必须定义：即使只有一个数据，子索引 0x00 也要返回条目数 1。这是 CiA 标准的要求。
3. 数据类型与 MCU 对齐：STM32 是 32 位 MCU，但 CANopen 数据类型是固定的。比如 UNSIGNED32 在 STM32 里用 uint32_t 对应，千万别用 int。
4. 访问权限要严格：只读参数（如设备版本）设 RO，可写参数（如目标速度）设 RW。我见过有人把所有参数都设成 RW，结果上位机误写导致设备异常。