📚 课程目录第3章 Stellar硬件抽象层与诊断接口开发

3. Stellar硬件抽象层与诊断接口开发

Stellar作为面向汽车域集中式电子电气架构的MCU/SoC系列，其硬件抽象层（HAL）并不是简单的寄存器封装，而是把GPIO、CAN控制器、以太网MAC、Flash控制器这些异构外设统一成一套可被诊断协议栈调用的服务接口。诊断接口开发的核心矛盾在于：上层UDS/OBD协议栈只关心“收到什么请求、返回什么响应”，而底层硬件只提供寄存器位、邮箱、DMA描述符和中断标志。HAL的职责就是在这两者之间建立稳定的映射，并把时序、并发和错误处理收敛在驱动内部。

一、HAL分层与诊断接口的调用关系

建议把Stellar的HAL划分为三层：最底层是寄存器访问层（RAL），直接操作外设基地址与位域；中间是外设驱动层，负责GPIO通道、CAN邮箱、以太网DMA环、Flash命令序列的状态机管理；最上层是诊断服务适配层，把CAN帧、以太网DoIP报文、Flash读写请求翻译成统一的服务原语。诊断请求接收与响应本质上是一次“事件—解析—执行—回写”的闭环，HAL需要保证这个闭环在中断上下文与任务上下文之间安全切换。

二、GPIO的HAL配置与诊断用途

在诊断场景中，GPIO通常承担三类职责：诊断使能引脚（如DoIP激活线）、故障指示输出、以及外部看门狗或复位控制。HAL配置需要明确方向、上下拉、驱动能力和中断触发方式。以Stellar常见的端口寄存器为例，配置一个诊断使能输入引脚可抽象为：

typedef struct {
    uint8_t  port;        /* GPIOA..GPIOH */
    uint8_t  pin;         /* 0..15 */
    uint8_t  mode;        /* INPUT / OUTPUT / AF */
    uint8_t  pull;        /* NONE / UP / DOWN */
    uint8_t  irq_edge;    /* NONE / RISING / FALLING / BOTH */
} hal_gpio_cfg_t;

int hal_gpio_init(const hal_gpio_cfg_t *cfg);
int hal_gpio_read(uint8_t port, uint8_t pin, uint8_t *level);
int hal_gpio_write(uint8_t port, uint8_t pin, uint8_t level);

关键点在于：诊断使能引脚的中断服务程序只做“置位事件标志”，真正的诊断会话切换放到任务上下文执行，避免在ISR中调用可能阻塞的协议栈函数。若该引脚用于唤醒，还需在HAL中配置唤醒源并使能对应的低功耗退出路径。

三、CAN控制器的HAL与诊断报文收发

CAN是经典诊断（UDS on CAN）的主要承载。Stellar的CAN控制器通常提供多个发送邮箱和接收FIFO，HAL需要完成位时序计算、过滤器配置和邮箱管理。位时序由波特率、采样点和时钟分频决定，例如系统时钟80 MHz、目标500 kbps、采样点80%时，可先取时间份额tq=1/(500k×10)=200 ns，再分配同步段、传播段、相位段。HAL应把这类计算封装成参数结构，而不是让诊断层直接写寄存器。

诊断请求接收的典型流程是：接收FIFO中断触发→HAL读取邮箱并组装成can_frame_t→按CAN ID过滤出诊断请求（如0x7DF功能寻址、0x7E0物理寻址）→投递到诊断接收队列。响应发送则相反，HAL根据诊断层给出的响应ID和长度，选择空闲发送邮箱并写入数据长度码（DLC）与数据场。

typedef struct {
    uint32_t id;        /* 11-bit or 29-bit */
    uint8_t  dlc;       /* 0..8 */
    uint8_t  data[8];
    uint8_t  is_ext;
} can_frame_t;

int hal_can_send(uint8_t ctrl, const can_frame_t *frm);
int hal_can_recv(uint8_t ctrl, can_frame_t *frm, uint32_t timeout_ms);

需要特别注意的是多帧诊断响应的流控处理。当响应长度超过8字节时，诊断层会拆分为首帧、连续帧，并依赖流控帧控制发送节奏。HAL在这里不解析ISO-TP，但必须保证发送邮箱的“发送完成”中断能及时释放，否则连续帧会因邮箱耗尽而丢帧。

四、以太网MAC与DoIP诊断通道

面向DoIP的诊断需要以太网MAC提供稳定的收发通道。HAL配置包括MAC地址、PHY接口模式（RGMII/RMII）、DMA描述符环的基地址与长度、以及接收过滤。诊断报文通常走UDP或TCP，HAL只负责以太网帧的收发，IP与DoIP由协议栈处理。一个常见的实现是维护两个描述符环：发送环由诊断层填充，接收环由DMA自动回写，HAL在接收中断中检查描述符的“拥有位”并交给上层。

以太网诊断的难点在于缓冲区管理。若接收环过小，突发DoIP报文会导致溢出；若过大，则占用宝贵的内存。建议根据诊断并发量估算：假设单条诊断请求平均200字节、峰值每秒50条，则接收环至少应能容纳2～3倍突发量，并配合中断合并减少CPU占用。

五、Flash控制器的HAL与诊断刷写支撑

诊断刷写（如UDS 0x34/0x36/0x37）最终要落到Flash控制器的擦除与编程。Stellar的Flash通常按扇区或页组织，HAL需要提供擦除、编程、校验三个原语，并处理等待周期、写保护解锁和ECC状态。编程前必须确保目标区域已擦除，编程后建议回读校验，只有校验通过才向诊断层返回肯定响应。

int hal_flash_erase(uint32_t addr, uint32_t len);
int hal_flash_program(uint32_t addr, const uint8_t *buf, uint32_t len);
int hal_flash_verify(uint32_t addr, const uint8_t *buf, uint32_t len);

一个实用的判断依据是：擦除后读取应为全0xFF，编程后回读应与源数据逐字节一致。若ECC报错或校验失败，HAL应返回明确错误码，诊断层据此回复0x72或0x73等否定响应，而不是笼统地报“内部错误”。

六、诊断请求接收与响应的底层驱动闭环

把上述外设串起来，诊断请求的底层闭环可以概括为：CAN或以太网中断触发→HAL读取原始帧→适配层识别诊断通道并投递到接收队列→诊断任务解析服务并执行（可能调用Flash HAL）→生成响应→HAL通过对应通道发送→等待发送完成并释放资源。整个过程中，HAL要保证同一诊断通道的请求与响应顺序一致，避免多帧响应与后续请求交叉。

建议在HAL中为每个诊断通道维护独立的发送完成信号量和接收队列深度计数，便于定位“请求已收到但响应未发出”这类问题。

Flash编程期间通常不能从同一Flash区域取指执行，若诊断刷写涉及运行区，必须把关键代码或跳转逻辑放到RAM中执行，否则会出现取指失败或总线异常。

综上，Stellar的HAL与诊断接口开发，重点不在于把寄存器逐个封装，而在于为诊断协议栈提供稳定、可预期、可诊断的底层服务。GPIO负责状态与使能，CAN与以太网负责报文通道，Flash负责数据落地，四者通过统一的适配层与诊断任务衔接，才能支撑后续的刷写、维护与故障诊断功能。