AUTOSAR架构的CANDriver_新能源技术.docVIP

AUTOSAR架构的CANDriver 1 文档说明 考虑到这几篇AUTOSAR文档的结构完全一样，在此先对将涉及的文档做一个概括性说明。以CAN Driver规范为例，如下图1所示。 图1 CAN Driver规范的内容 总的来说，文档一般有10个章节，前5章相当于先做一个详细的背景知识介绍，只有了解好这个背景与前提，才能更好地解读后面章节的内容。然后列出了底层软件需求与详细软件设计的追溯关系，比如图2所示。 图2 底层系统需求与软件需求追溯示意，引自[1] 再描述了该模块的功能规范说明，接口与函数定义，以及功能执行时序图等内容，可理解为介绍如何用详细软件设计去实现需求的过程。就如图2所示内容，有一条底层软件需求是 CAN Driver模块必须提供一个接收通知服务，然后分解成2条详细软件设计去实现。类似于通过这种形式，即根据某模块一系列的软件需求，定义了一系列的软件详细设计，最终决定了该模块的软件架构和内容。 最后，配置规范。从配置工具角度来理解，这部分内容相当于定义好了配置工具的项目与内容。比如前面文章讲到的位速率，如果要配置它，那么配置工具应该在这个项目的配置页面设计位速率，SEG1，SEG2和SJW等配置内容。 图3 配置规范示意，引自[1] 关于AUTOSAR文档的一点感受：当阅读和研究部分AUTOSAR文档后，会有很多方面的收获，比如需求方面，软件方面，项目方面和技术方面。当然如果仅仅基于文档的话，也许会枯燥乏味，去结合实际项目，应该有助于更深入地理解以上提及的这些方面。 好了，关于文档大致说明到这，下面开始进入CAN Driver模块。 2 CAN Driver 为了与文档描述保持一致，下文将使用CAN模块来表示CAN Driver。简单地说，CAN模块属于一部分的最底层内容，其作用是执行硬件访问和为上层提供独立的硬件接口（这里能访问CAN模块的上层只有Can Interface模块）。说到访问硬件，先了解几个概念，如图4所示： 图4 CAN硬件单元示意 对图4内容的解释如下： 一个CAN 硬件单元（CAN Hardware Unit）就相当于某个ECU的CAN硬件部分，它可以包括一个或多个CAN控制器（Controller）。 一个CAN控制器就是一个CAN节点或一条CAN，即对应连接一条物理通道。它有很多个报文邮箱（message object）。 一个报文邮箱又有多个寄存器，用来存储报文信息，如下图5所示。 图5 报文邮箱的寄存器，引自[2] 所以关于CAN接收和发送，由上可知CAN模块访问的是CAN硬件单元的某个CAN控制器的某些寄存器。那么CAN模块在怎样的条件才能访问到呢？下面需要再介绍几个概念： 2.1 ?驱动状态机（Driver state machine） CAN模块驱动状态机有两个状态，在上电或重置后，CAN模块进入CAN_UNINIT状态(未初始化状态)，初始化后，CAN模块进入CAN_READY状态，这时可执行一些与读、写、总线关闭、唤醒和控制器状态设置相关的功能。也就是说CAN接收和发送必须在驱动状态机处于CAN_READY才能执行。 图6 CAN驱动状态机，引自[1] 2.2? 控制器状态机（Controller state machine） 在驱动状态机处于CAN_READY状态前提下，还需要考虑CAN控制器状态。因为在硬件层面，CAN控制器会执行很复杂的状态机，去实现不同的硬件行为。有时是需要在相应的状态才会去实现某些功能，比如初始化，波特率设置等；有时是外部事件（总线关闭，唤醒事件）会触发状态变化，导致是否能执行某些功能。 出于简化目的，这里将CAN控制器的状态分为4个。 图7 CAN控制器状态机，引自[1] CAN控制器未初始化- UNINIT属于CAN模块的所有寄存器都处于复位状态，不使能CAN中断。CAN控制器不参与CAN总线。CAN控制器状态已停止- STOPPED在这种状态下，CAN控制器已初始化，但不参与总线。另外也不得发送错误帧和确认。CAN控制器状态已启动- STARTED控制器处于正常运行模式，具有完整的功能，这意味着它已加入网络。对于许多控制器而言，离开“初始化”模式会使控制器启动。CAN控制器状态为睡眠- SLEEP与STOPPED仅有的不同是：CAN的硬件设置支持睡眠模式（由CAN硬件支持唤醒的CAN总线直接唤醒）关于CAN硬件支不支持SLEEP，其对应的处理方法有：支持-- the CAN hardware is triggered to transition into SLEEP state, the Can module shall set the controller to the SLEEP state from wh