不断debug，优化中……

Autosar网络管理的休眠唤醒功能，Can收发器起到比较大的作用，充当唤醒源以及最终执行网络休眠。Autosar--Can收发器通俗讲解唤醒/休眠请求进入normolComM_EcuM_WakeUpIndication 有唤醒源事件CanSM_RequestComMode 有通信请求CanSM_NetworkStatemachine() 更新CANSM状态CanIf_SetTrcvMode() 进入normal。

PORT Driver就是对微控制器（MCU）的整个PORT模块进行初始化配置。很多端口和管脚被分配有多种不同的功能，即可以进行引脚功能复用，比如通用I/O、adc、pwm、spi等功能。因此，对PORT必须有一个整体的配置和初始化，对各管脚的具体配置和使用取决于微控制器和ECU的引脚功能分配。PORT初始化数据应当尽可能高效地写到每个端口。DIO驱动中所用到的端口的配置和初始化都是在PORT驱动模块中完成的。因此，在使用DIO功能之前，应先进行PORT的初始化。1、PortContainer说明。

ADC主要是作为模拟量转换为数字量使用，在汽车的控制器中具有广泛的用途。AutoSAR中ADC模块用于初始化并控制微控制器的内部模数转换单元，提供启动和停止转换的服务用来启用和禁用ADC转换的触发源。此外，ADC模块还提供了启用和禁用通知机制服务来决定是否将ADC转换完的结果通知给上层应用，同时ADC模块提供了用于查询转换状态和读取转换结果的功能。目标：设置PTC14引脚为ADC信号采集功能。2、Port模块，将引脚复用成ADC。1、在Mcu模块，使能ADC时钟。依赖Mcu、Port。

Can邮箱，顾名思义，收到制定的报文，才会放到邮箱，并触发中断，来处理报文数据，所以可以通过邮箱接收的方式，接收制定报文ID才进入中断，避免频繁进入中断，增加CPU的负载。当接收报文ID，CAN硬件过滤器receiverID & MASK == CODE&MASK 进行对比。BASIC:可以存放多个ID的报文，依赖硬件滤波器CanFilterMasks。当CAN邮箱配置成BASIC时，需要配置硬件滤波器。FULL:只能存放一个ID的报文。，就位于相位缓冲段2开始的地方，CAN控制器和CAN邮箱。

AutoSAR中MCU Driver主要提供了用于基本的控制器初始化、下电、复位功能的服务，同时也为其它MCAL层需要的功能提供对应的服务函数。通常来说在AutoSAR的架构中MCU主要支持以下几个功能:1.初始化控制器的外设时钟、系统时钟、PLL等，对所有控制器内各个外设模块用到的时钟提供配置服务。2.初始化定义的RAM Section。3.为MCU的运行提供省电功能，支持MCU运行相关模式转化配置，支持整个系统复位，以及获取系统复位的原因。4.支持通用的模块的配置，比如DMA、GTM等。

中央处理单元，处理通信请求并管理数据流。核心职责包括信号处理、通信模式管理和网络管理。它是一个资源管理器，封装了对底层通信服务的控制。ComM 模块控制与通信相关的基础软件模块，而不是软件组件或可运行实体。ComM 模块从通信请求方收集总线通信访问请求，并协调总线通信访问请求。ComM作用：1、简化用户对总线通信栈的使用。这包括简化的网络管理处理。2、协调一个 ECU 上多个独立软件组件的总线通信栈的可用性（允许发送和接收信号）。用户不应了解硬件（例如在哪个通道进行通信）。

根据event Validation之后的结果选择进入不同的阶段，一种是验证有效，进入RUN 11阶段，另外一种是验证无效，进入Go Sleep阶段；若在该阶段存在RUN Request，那么就会立刻跳回到RUN 11阶段；RUN阶段可以划分为以下两个阶段，一个是RUN II，表示正常工作状态，另一个是RUN III，表示为进入到ShutDown所作的前提准备，顶层设计如下图所示：在RUN 1阶段则表明已完成了所有BSW模块（包括OS及RTE）的初始化，开始运行SW-C程序。

介绍EcuM模块，管理ECU运行状态，上电工作流程，规定上电时 Startup需要做什么操作，正常运行Run需要做什么操作，休眠Sleep时需要做什么操作，关机下电ShutDown做什么操作,唤醒Wakeup需要做什么操作，这五大流程管理。EcuM的初始化，在main函数里。

BswM就是一个基于Rules的服务模块，主要工作就是上面讲到的根据制定的Rules，执行相应的Action。下图之前我们放过一次，这里多讲讲：可以看到这里有三个Auto Configuration，那都是DaVinci自动配置的部分，然后下面的Miscellaneous就是我们用户自己定义的部分（当然其实一般来说都不必自己定义对Rules的评估可以有两种形式的：立即 和 延迟立即：当然就是被call了之后立马开始了。

用的是Qspi0SpiDriver要配置 4个选项SpichannelSpiJobMcu 模块配置dma配置。

网管报文btye设置：1、重复消息请求位设置 2、ECU地址。接收到主动唤醒源，网管报文快发周期，次数；wait bus-sleep 定时设置以及网管报文超时设置。repeat message time 超时时间。为保证ECU起来首发的报文是网管报文，网管报文范围0x600~0x6FF。ComM 要放在CanNm前执行。CAN网络管理filter。

被动唤醒源是网管报文。进入RepeatMessageState，会做两个动作，StartNM-TimeoutTimer网管报文监听定时器开启，StartRepeatMessageTimer定时器开启，发送网管报文，如果是主动唤醒源，会快发一段时间的网管报文。跳转条件：当RepeatMessageTimerhasexpired，StartRepeatMessageTimer定时器超时并且没有网络请求（有主动唤醒源，被动唤醒），会跳到ReadySheepState。

在 AUTOSAR 中，我们在配置期间在 SWC 中创建 Runnable，并且 在 SWC 的相应源文件中生成Runnable 或函数骨架。这样的条件可以在配置时定义，条件可以是：初始化时调用的Init Runnable、定期调用runnable可用于发送一些周期性数据、基于不同RTE事件的触发等。我们知道，对于 ECU 中的每个功能，SWC 都可以是专用的，但其行为或功能的实现是使用 Runnable 完成的。数据接收事件：顾名思义，每当端口接收到数据时，此类事件就会触发一个可运行的事件。

由于 AUTOSAR 的目标是标准化，因此需要在配置时了解实体之间传输的数据，因此端口也不例外。端口接口是定义两个端口之间传输或接收的信息类型的接口。端口接口就像端口的蓝图，它定义了 SWC 端口遵循的“协议”。端口接口配置是在系统配置时完成的，并且该接口应遵守的端口被分配给这些端口。当实体之间传输的数据是异步类型时，使用这种类型的接口。标准化 AUTOSAR 接口：标准化 AUTOSAR 接口由 AUTOSAR 预定义，应用程序 SWC 在与 ECU 管理器等 BSW 服务交互时使用该接口。

由于 AUTOSAR 软件架构的分层性质不允许上层直接访问硬件，因此需要一个额外的概念来绕过此限制，特别是对于资源关键型和/或不符合 AUTOSAR 的软件组件。正是在这里，复杂设备驱动程序出现了。复杂设备驱动程序基本上为应用程序层提供了 AUTOSAR 接口，从而可以直接访问物理层上的值。复杂驱动程序的概念对于需要直接访问 ECU 上的硬件设备的应用程序组件非常有用。喷射控制或电子阀门控制应用是需要直接访问硬件的此类应用的很好的例子。

AUTOSAR架构中的应用层AUTOSAR 应用层构成AUTOSAR 架构中的最顶层，被认为对所有车辆应用至关重要。AUTOSAR 标准使用“组件”概念指定应用层实现。这些软件组件通过明确定义的端口进行连接。这些端口有助于软件组件之间以及与AUTOSAR BSW之间的通信。在应用程序软件组件的上下文中，有一些称为 Runnable 的实体，它们基本上是包含软件组件实际实现的过程。可运行或可运行实体在 VFB 规范中定义，并且是原子软件组件的一部分（在后面的部分中描述）。

Mcal篇 配置Dio模块输出

AUTOSAR（Automotive Open System Architecture）是一个跨汽车行业的标准化软件架构，旨在促进汽车电子系统的开发和部署。下面是AUTOSAR发展的一些关键点：起源和背景： AUTOSAR最初于2003年由汽车制造商宝马、戴姆勒克莱斯勒、福特和供应商博世联合发起，旨在应对汽车电子系统日益复杂的挑战。这些挑战包括不断增长的软件代码量、硬件和软件之间的紧密耦合，以及不同汽车制造商之间的差异化。标准化软件架构： AUTOSAR致力于建立一个标准化的汽车软件架构，以便不同汽车制造商