设计制作公益广告牌教案郑州seo外包平台
文章目录
- 协议层
- 命令结构 —— 主->从
- 命令
- 正响应
- 负响应
- CMD
- RES
- ERR
- EV
- SERV
- Calibration Prameters in the Slave
协议层
XCP 数据以基于消息的方式在 Master 和 Slave 之间交换。在以太网上的 XCP 与 UDP 数据包中的 UDP 的情况下， XCP 消息帧嵌入在传输层的帧中。 帧由三部分组成：XCP 头、XCP 包和 XCP 尾。
下表显示了已定义的 PID：
| PID(主到从) | 定义内容 | PID(从到主) | 定义内容 |
|---|---|---|---|
| 0xFF | CMD | 0xFF | RES |
| ... | 0xFE | ERR | |
| 0xC0 | 0xFD | EV | |
| 0xBF | STIM 的绝对或相对 ODT 数 | 0xFE | SERV |
| ... | 0xFB | DAQ 的绝对或相对 ODT 数 | |
| 0x00 | ... | ||
| - | - | 0x00 |
通过 XCP 数据包进行的通信可以细分为两个区域，一个 CTO(命令区域) 和一个DTO (发送同步数据区域。具体的分布见下图：
| 缩写 | 全程 | 作用 |
|---|---|---|
| CMD | Command Packet | 发送命令 |
| RES | Command Response Packet | 命令响应包 |
| ERR | Error | 负响应 |
| EV | Event Packet | 异步事件 |
| SERV | Service Request Packet | 服务请求 |
| DAQ | Data Acquisition | 发送定期测量值 |
| STIM | Stimulation | 定期刺激从节点 |
命令结构 —— 主->从
命令
| 位置 | 类型 | 描述 | 说明 |
|---|---|---|---|
| 0 | Byte | 命令包代码 CMD | 每个命令分配一个唯一编号 |
| 1 | Byte | 命令内特定参数 | 最大参数个数在这里定义为 MAX_CTO-1。 MAX_CTO 表示 CTO 数据包的最大长度，以字节为单位。 |
| ... | |||
| MAX_CTO-1 |
正响应
| 位置 | 类型 | 描述 |
|---|---|---|
| 0 | Byte | 命令正响应代码（0xFF） |
| 1 | Byte | 命令内特定参数 |
| ... | ||
| MAX_CTO-1 |
负响应
| 位置 | 类型 | 描述 |
|---|---|---|
| 0 | Byte | 命令负响应代码（0xFE） |
| 1 | Byte | 故障码 |
| 2 | Byte | 命令内特定参数 |
| ... | ||
| MAX_CTO-1 |
&esmp;XCP定义了三种主从节点的工作模式：Standard Mode，Block Mode 和 Interleaved Mode。
Standard Mode —— 每个从主节点发出来的命令，从节点都应有一个单一的响应。除了CAN上的XCP命令之外，该模式下不允许多个从节点对主节点发出的命令进行响应。在此背景下，每个XCP消息是可以追溯到唯一的从节点。
Block Mode —— 该模式是可以进行选择的，且该模式下会节省大数据传输的时间。在此种模式下，必须将从节点的性能纳入考虑范围。所以，两个命令之间的最小时间（MIN_ST）要有明确的定义，并且命令总数限制为MAX_BS的上限。另外，主节点可以通过GET_COMM_MODE_INFO从从节点读取到通信设置。在主节点的Block Mode下则不需要遵从上述的规则。
Interleaved Mode —— 该模式的产生是因为性能原因。虽然从理论上讲存在这种模式，但是在实际的情况中却没有相关经验。
CMD
CTO的数据包结构类型如下图所示。
主节点通过CMD发送一个通用请求到从节点。PID（Packet Identifier）字段包含了命令的标识符。特定参数将在数据字段中传输。然后主节点会等待从节点的反馈（RESponse 或者 ERRor）。XCP的实现具有很强的灵活性，因此不必要局限于每一个命令的实现。在A2L文件中，所有可用的CMD均被记录在XCP的 IF_DATA数据中。如果主从节点的A2L文件存在不一致的情况，主节点可以根据从节点的响应来决定是否支持该命令。如果主节点的命令没有被从节点响应，那么从节点需使用带ERR_CMD_UNKNOWN的响应且没有更进一步的活动。这样可以让主节点快速了解到哪个命令没有被从节点响应。
CMD由Standard，Callibration，Page，Programmming 和 DAQ Measurement Commands。如果任一个内容都不需要，那么该命令则可不执行。如果某些内容是必须的，那么必须的内容在从节点中必须保证可用，剩余的内容不做强制要求。例如：在页面切换命令中，SET_CAL_PAGE 和 GET_CAL_PAGE是必选的，那么支持页面切换命令的从节点必须要支持这两个内容。对于不支持页面切换的从节点，SET_CAL_PAGE 和 GET_CAL_PAGE属于非强制要求内容。
| CMD命令组组成 | |||
|---|---|---|---|
| 组别 | 命令名 | PID | Optional |
| Standard | CONNECT | 0xFF | NO |
| DISCONNECT | 0xFE | NO | |
| GET_STATUS | 0xFD | NO | |
| SYNCH | 0xFC | NO | |
| GET_COMM_MODE_INF | 0xFB | YES | |
| GET_ID | 0xFA | YES | |
| SET_REQYEST | 0xF9 | YES | |
| GET_SEED | 0xF8 | YES | |
| UNLOCK | 0xF7 | YES | |
| SET_MTA | 0xF6 | YES | |
| UPLOAD | 0xF5 | YES | |
| SHORT_UPLOAD | 0xF4 | YES | |
| BUILD_CHECKSUM | 0xF3 | YES | |
| TRANSPORT_LAYER_CMD | 0xF2 | YES | |
| USER_CMD | 0xF1 | YES | |
| Callibration | DOWNLOAD | 0xF0 | NO |
| DOWNLOAD_NEXT | 0xEF | YES | |
| DOWNLOAD_MAX | 0xEE | YES | |
| SHORT_DOWNLOAD | 0xED | YES | |
| MODIFY_BITS | 0xEC | YES | |
| Standard | SET_CAL_PAGE | 0xEB | NO |
| GET_CAL_PAGE | 0xEA | NO | |
| GET_PAG_PROCESSOR_INFO | 0xE9 | YES | |
| GET_SEGMENT_INFO | 0xE8 | YES | |
| GET_PAGE_INFO | 0xE7 | YES | |
| SET_SEGMENT_MODE | 0xE6 | YES | |
| GET_SEGMENT_MODE | 0xE5 | YES | |
| COPY_CAL_PAGE | 0xE4 | YES | |
| Periodic data exchange – basics | SET_DAQ_PTR | 0xE2 | NO |
| WRITE_DAQ | 0xE1 | NO | |
| SET_DAQ_LIST_MODE | 0xE0 | NO | |
| START_STOP_DAQ_LIST | 0xDE | NO | |
| START_STOP_SYNCH | 0xDD | NO | |
| WRITE_DAQ_MULTIPLE | 0xC7 | YES | |
| READ_DAQ | 0xDB | YES | |
| GET_DAQ_CLOCK | 0xDC | YES | |
| GET_DAQ_PROCESSOR_INFO | 0xDA | YES | |
| GET_DAQ_RESOLUTION_INFO | 0xD9 | YES | |
| GET_DAQ_LIST_INFO | 0xD8 | YES | |
| GET_DAQ_EVENT_INFO | 0xD7 | YES | |
| Periodic data exchange – static configuration | CLEAR_DAQ_LIST | 0xE3 | No |
| GET_DAQ_LIST_INFO | 0xD8 | Yes | |
| Periodic data exchange – dynamic configuration | FREE_DAQ | 0xD6 | Yes |
| ALLOC_DAQ | 0xD5 | Yes | |
| ALLOC_ODT | 0xD4 | Yes | |
| ALLOC_ODT_ENTRY | 0xD3 | Yes | |
| Flash programming | PROGRAM_START | 0xD2 | No |
| PROGRAM_CLEAR | 0xD1 | No | |
| PROGRAM | 0xD0 | No | |
| PROGRAM_RESET | 0xCF | No | |
| GET_PGM_PROCESSOR_INFO | 0xCE | Yes | |
| GET_SECTOR_INFO | 0xCD | Yes | |
| PROGRAM_PREPARE | 0xCC | Yes | |
| PROGRAM_FORMAT | 0xCB | Yes | |
| PROGRAM_NEXT | 0xCA | Yes | |
| PROGRAM_MAX | 0xC9 | Yes | |
| PROGRAM_VERIFY | 0xC8 | Yes | |
RES
当从节点能够相应主节点的请求，那么从节点需要反馈一个正响应RES。具体的格式见上文。
ERR
当从节点检测到主节点的请求不可用时，从节点需要反馈一个负响应ERR和故障代码。具体的格式见上文。
EV
如果从服务器希望通知主服务器一个异步事件，则可以发送EV来执行此操作。具体格式如下：
| 位置 | 类型 | 描述 |
|---|---|---|
| 0 | Byte | 命令代码（0xFD） |
| 1 | Byte | Event Code |
| 2 | Byte | 事件信息数据（可选） |
| ... | ||
| MAX_CTO-1 |
SERV
从节点可以使用这种机制请求主节点执行服务。
| 位置 | 类型 | 描述 |
|---|---|---|
| 0 | Byte | 命令代码（0xFD） |
| 1 | Byte | Event Code |
| 2 | Byte | 事件信息数据（可选） |
| ... | ||
| MAX_CTO-1 |
Calibration Prameters in the Slave
要更改XCP从节点中的参数，主节点必须将参数的位置以及值发送给从节点。XCP通常使用五个字节定义地址:四个字节用于实际地址，一个字节用于地址扩展。在CAN通信中，只有7个字节可用于XCP消息。例如，如果校准器设置了一个4字节的值，并希望在一个CAN消息中发送两个信息，则没有足够的空间来执行此操作。由于总共需要9个字节来传输地址和新值，因此更改不能在一个CAN消息中传输。因此，校准请求则需要主节点发送两个message到从节点。从节点此时必须确认两条消息，并且总共交换了四条消息。下图为Master和Slave之间的通信，需要设置一个参数值。
在主节点的第一条message中(上图示例中)，主节点将SET_MTA命令发送到从节点，并将新值写入该地址。在第二条message中，从节点对SET_MTA命令的回复是OK:SET_MTA。第三条messagez中发送了DOWNLOAD命令。在此示例中，命令有效字节数是4。在第四个Message中，从节点给予了正相应OK:DOWNLOAD。到此为止，当前Calibration Process就已经完成了。为了确保Calibration的成功执行，在过程结束后可再次读取该值且可使用读取值进行更新，这样对于用户来讲就可以直接识别是否真的执行了Calibration Process.
当ECU RAM中的参数改变时，应用程序处理新值。然而，重新启动ECU将导致该值被擦除，并用闪存中的原始值覆盖RAM中的值。在此前提下，如何才能永久保存修改后的参数集呢？通常有以下两种路径:
1. 将参数保存在ECU中。例如：RAM中更改的数据可以保存在ECU的EEPROM中，此时可以通过ECU下电保存或者用户手动保存。此前提是数据可以写入到从节点的非易失性存储中。对于ECU来讲，这将占用EEPROM或Flash空间。对于ECU来讲，未必能够提供足量的空间来存储这些参数，所以这种方式并不常见。此背景下，还有另一种实现路径——将RAM参数写回到ECU的Flash中。但这种方式有点复杂，需要先擦除Flash，然后执行重写操作。那么只能将整个区域作为一个block进行处理，这就不再是单个字节的读写问题。
2. 将参数以文件的形式保存在PC中。这种方式是更易于实现和使用的方式。所有的参数或者部分参数均已文件的形式存储。最简单的情况是保存在ASCII文本文件中，其中只包含了对象及值。当然也可以使用其他的文件格式，也可以保存其他的相关信息。
这就延申出另外一个问题 —— 保存参数至hex文件及刷写。刷写ECU是另一种改变Flash参数的问题。刷写之后，ECU启动则会将参数文件作为新参数写入RAM。参数设置文件的转化到 C/H文件，且通过另外一个编译器运行，使其成为一个新的Flash文件。根据参数的编译过程，重新生成一个Flash文件的时间可能会很长。另外，校准器可能没有任何ECU软件的源代码。如果存在该情况，那么校准器将无法使用上述方案。上述方案的替代方案是将参数文件复制到现有的Flash文件中。
