3. RH850的XCP从站实现架构

在RH850上实现XCP从站，核心问题不是“能不能通信”，而是如何把XCP协议栈、传输层、硬件抽象和标定内存访问组织成可移植、可裁剪、可验证的分层结构。RH850通常运行在AUTOSAR或裸机/RTOS环境中，XCP从站既要响应上位机（如CANape、INCA）的命令，又要保证测量数据采集的实时性和标定RAM写入的原子性。因此，从站架构必须明确划分职责边界：协议层只关心XCP命令语义，传输层只关心报文收发，硬件抽象层只关心寄存器与内存映射，三者通过统一接口解耦。

分层设计：从命令到硬件的四层模型

推荐将RH850 XCP从站划分为四层。最上层是XCP协议核心层，负责解析命令码（如CONNECT、GET_STATUS、SET_MTA、UPLOAD、DOWNLOAD、SHORT_UPLOAD、START_STOP_DAQ_LIST等），维护从站状态机（DISCONNECTED、CONNECTED、RESUME、STORE_CAL_REQ等），并管理DAQ列表、事件通道和ODT条目。第二层是传输层适配层，它把XCP报文封装为CAN/CAN-FD帧或以太网UDP/TCP报文，并处理传输层特有的分片、流控和超时。第三层是硬件抽象层（HAL），封装RH850的CAN控制器（如RSCAN、RCAN）、以太网MAC、DMA和定时器，提供统一的发送、接收、时间戳和内存访问接口。最底层是内存与标定区，包括标定RAM、测量RAM、Flash模拟EEPROM以及页面切换机制。

这种分层的关键收益是：当项目从CAN切换到CAN-FD或以太网时，只需替换传输层适配层，协议核心层和HAL接口保持不变；当RH850型号从F1L换到F1H时，只需调整HAL中的寄存器定义和时钟配置。

传输层选择：CAN、CAN-FD与以太网的取舍

传输层选择直接决定XCP的带宽、延迟和拓扑。在RH850项目中，常见三种方案：

• 经典CAN（8字节帧）：适合低带宽标定场景，如仅上传少量测量变量（<10个）和偶尔的标定参数写入。XCP over CAN使用CTO（命令传输对象）和DTO（数据传输对象）分离，CTO走命令，DTO走DAQ数据。经典CAN下，一帧最多8字节，XCP头部占1字节，实际有效载荷7字节，因此一个32位变量需要2帧才能传完，带宽利用率低。
• CAN-FD（最高64字节帧）：RH850的RSCAN-FD控制器支持CAN-FD。XCP over CAN-FD可将一帧有效载荷提升到63字节，一个DAQ列表的多个ODT条目可打包在一帧内发送，显著降低中断频率和总线负载。适合中等规模测量（20~50个变量）和快速标定。
• 以太网UDP/TCP：RH850部分型号集成以太网MAC（如R7F7016xx系列）。XCP over Ethernet使用UDP端口（默认5555）或TCP，单帧可承载1470字节以上，适合大规模测量（数百个变量）和高频采样。但需注意以太网协议栈的内存开销和CPU负载，通常需要DMA配合。

选择依据可归纳为：测量变量数量少、总线负载敏感 → 经典CAN；需要兼顾带宽与实时性、已有CAN-FD硬件 → CAN-FD；大数据量、高频采样、有以太网PHY → 以太网。实际项目中，同一套XCP协议核心层可同时支持多种传输层，通过编译宏或运行时配置切换。

从站初始化与命令处理流程

从站初始化不是简单的“上电即用”，而是需要按顺序完成硬件、传输层和协议层的配置。以下以CAN-FD为例，给出一个可参考的初始化序列（示例参数基于RH850 F1H，实际需按芯片手册调整）：

/* 1. 时钟与端口初始化 */
R_CGC_Init();                    // 配置PLL，CAN-FD时钟源40MHz
PORT_CANFD_Init();               // 配置CAN-FD TX/RX引脚复用

/* 2. CAN-FD控制器初始化 */
canfd_config.baudrate = 500000;  // 仲裁段500kbps
canfd_config.data_baudrate = 2000000; // 数据段2Mbps
canfd_config.mode = CANFD_MODE_FD;
R_CANFD_Init(&canfd_config);

/* 3. XCP传输层绑定 */
Xcp_Transport_Register(&canfd_transport_ops);
Xcp_Transport_Init(CANFD_CH0, 0x554); // 请求ID 0x554，响应ID 0x555

/* 4. XCP协议层初始化 */
Xcp_Init(&xcp_config);
Xcp_Connect_Callback_Register(on_connect);
Xcp_Daq_Event_Register(DAQ_EVENT_1MS, 1); // 1ms事件通道

/* 5. 启动接收中断 */
R_CANFD_Start(CANFD_CH0);
Xcp_Set_State(XCP_STATE_DISCONNECTED);

初始化完成后，从站进入DISCONNECTED状态，等待上位机发送CONNECT命令。命令处理流程遵循“接收→解析→执行→响应”的循环。以SET_MTA命令为例：上位机发送SET_MTA（命令码0xF6），携带地址和地址扩展；从站解析后，将MTA指针设置为指定地址，并返回正响应0xFF。随后上位机发送UPLOAD命令，从站从MTA指向的地址读取数据并返回。若地址非法或访问越界，从站返回错误码0xFE（ERR_OUT_OF_RANGE）。

DAQ测量流程则不同：上位机通过SET_DAQ_PTR、WRITE_DAQ、SET_DAQ_LIST_MODE等命令配置DAQ列表和ODT条目，然后发送START_STOP_DAQ_LIST启动。从站根据事件通道（如1ms定时器中断）触发采样，将测量变量按ODT条目打包，通过DTO帧发送。CAN-FD下，一个DAQ列表的多个ODT可合并到一帧，减少总线占用。

关键设计约束与验证要点

RH850 XCP从站实现中，有三个容易被忽视但影响稳定性的约束。第一，标定RAM的原子性：当上位机通过DOWNLOAD命令写入标定参数时，若该参数被控制算法同时读取，可能出现撕裂。建议在HAL中提供临界区保护，或在标定页切换时暂停控制任务。第二，DAQ采样与主循环的优先级：DAQ事件通常由定时器中断触发，若中断优先级低于控制任务，采样时刻会抖动。建议将DAQ事件中断设为较高优先级，但需评估对控制周期的影响。第三，传输层超时与重连：CAN-FD或以太网可能因总线错误或网络拥塞丢帧，从站应实现命令超时计数器，超时后自动回到DISCONNECTED状态，避免上位机误判从站仍在连接。

验证时，可构造一个最小测试用例：在RH850的标定RAM中定义两个变量（如cal_gain和cal_offset），通过XCP的SHORT_UPLOAD命令读取，再用DOWNLOAD命令修改，观察控制算法输出是否按预期变化。同时用示波器或GPIO翻转测量DAQ事件的实际周期，与配置的1ms对比，偏差应小于5%。若偏差过大，检查定时器分频和中断延迟。

总结来说，RH850 XCP从站的分层架构不是学术上的“整洁”，而是工程上的“可替换”。协议核心层保持稳定，传输层和HAL按项目需求裁剪，内存与标定区按芯片特性适配。初始化流程和命令处理流程则决定了从站能否在上位机面前“一次连接成功”。把这三件事做扎实，后续的测量标定工作才有可靠的基础。