1. CANopen协议概述：从站设备模型、对象字典与SDO/PDO

各位同学，咱们今天正式开讲。CANopen这个协议，说实话，刚接触的时候会觉得它有点「重」——又是对象字典，又是各种通信对象。但你别怕，我做了这么多年嵌入式，可以负责任地告诉你：一旦你把从站设备模型和对象字典这两个概念吃透，剩下的全是套路。

这一章，咱们就先把地基打牢。我会结合自己踩过的坑，把CANopen的骨架给你拆开看。

1.1 从站设备模型——CANopen节点的「三件套」

每个CANopen节点，不管主站还是从站，内部都长一个样。我习惯把它想象成一台迷你电脑：有CPU、有内存、有网卡。对应到CANopen里，就是下面这三部分：

• 通信接口：负责收发CAN报文。说白了就是物理层+数据链路层那点事，咱们用STM32的bxCAN外设搞定。
• 对象字典（OD）：这是核心。所有能被访问的数据，都放在这个「字典」里。每个条目有个16位索引和8位子索引。
• 应用层程序：你的业务逻辑。比如读取传感器、控制电机、处理IO。它通过对象字典和外界交换数据。

我当年第一个项目，就是没搞懂这个模型。我直接在应用层里写了个全局变量，想让主站通过SDO直接读。结果折腾了两天，报文死活不对。后来才发现，我根本没把这个变量注册到对象字典里。嗯，这个坑，你们别踩。

1.2 对象字典（OD）——CANopen的「灵魂」

对象字典，本质上是一张标准化的表格。每个条目由三要素组成：

要素	说明	举例
索引（Index）	16位地址，0x0000~0xFFFF	0x1000（设备类型）、0x6000（数字量输入）
子索引（SubIndex）	8位编号，用于访问复合对象	0x00（子索引数量）、0x01（第一个通道）
数据	实际存储的值，类型由对象定义	UINT8、INT32、OCTET_STRING等

CiA 301标准把对象字典划分了几个区域：

• 0x1000~0x1FFF：通信对象区。存放设备类型、错误寄存器、COB-ID等。
• 0x2000~0x5FFF：制造商特定区。你可以在这里放自己的私有数据。
• 0x6000~0x9FFF：标准设备行规区。比如IO模块的输入输出、驱动器的控制字状态字。

1.3 SDO与PDO——两种通信方式的「道」与「术」

CANopen提供了两种数据交换方式：SDO和PDO。很多初学者搞不清它们的区别。我打个比方：

• SDO（服务数据对象）：像「快递员上门取件」。一对一，可靠，但慢。每次传输都需要确认。
• PDO（过程数据对象）：像「广播喇叭喊话」。一对多，无确认，但快。适合周期性发送实时数据。

咱们用表格对比一下：

特性	SDO	PDO
通信模式	客户端/服务器（点对点）	生产者/消费者（广播）
确认机制	有（CCS/SCS握手）	无（火速发射，不回头）
数据长度	最多4字节（普通SDO）或分段传输	最多8字节（一帧CAN报文）
典型用途	配置参数、下载固件、读写对象字典	实时控制字、状态字、模拟量输入输出
COB-ID范围	0x580+NodeID（从站发送） 0x600+NodeID（从站接收）	0x180+NodeID（TPDO1） 0x200+NodeID（RPDO1）等

你想想看，为什么要有这两种方式？

因为工业现场的需求是多样的。你配置一个伺服驱动器的电子齿轮比，肯定希望确认它写进去了——这时候用SDO。但你读取编码器位置，每毫秒都要刷新一次，如果每次都用SDO，总线就炸了——这时候必须用PDO。

1.4 知识结构图——CANopen从站全景

下面这张图，把咱们这一章的核心概念串起来了。你可以把它当作整个课程的地图：

从这张图你可以看到：CAN报文从总线进来，先经过通信接口，然后根据COB-ID判断是SDO还是PDO。SDO直接读写对象字典，PDO则通过映射参数间接访问。应用层程序只和对象字典打交道，不直接处理CAN报文。

1.5 本章小结——你该带走什么

这一章的内容，说白了就是三个核心认知：

1. 从站设备模型：通信接口 + 对象字典 + 应用层。三者各司其职，缺一不可。
2. 对象字典：一切数据的「中央仓库」。所有外部访问都必须经过它。
3. SDO vs PDO：SDO用于配置和诊断，可靠但慢；PDO用于实时数据，快但不可靠。选哪个，看你的场景。