自定义博客皮肤VIP专享

*博客头图:

格式为PNG、JPG,宽度*高度大于1920*100像素,不超过2MB,主视觉建议放在右侧,请参照线上博客头图

请上传大于1920*100像素的图片!

博客底图:

图片格式为PNG、JPG,不超过1MB,可上下左右平铺至整个背景

栏目图:

图片格式为PNG、JPG,图片宽度*高度为300*38像素,不超过0.5MB

主标题颜色:

RGB颜色,例如:#AFAFAF

Hover:

RGB颜色,例如:#AFAFAF

副标题颜色:

RGB颜色,例如:#AFAFAF

自定义博客皮肤

-+
  • 博客(78)
  • 资源 (1)
  • 收藏
  • 关注

原创 从零搭建AUTOSAR开发工程系列之—Davinci开发之应用软件开发二(15)

继续讲解SWC的Runnable如何创建、使用。

2025-06-13 15:37:05 29

原创 从零搭建AUTOSAR开发工程系列之—Davinci开发之应用软件开发一(14)

BSW开发完成后,进行应用层SWC开发。

2025-06-13 15:34:59 16

原创 从零搭建AUTOSAR开发工程系列之—Davinci开发之EcuM配置(13)

本篇介绍EcuM配置,EcuM配置分为Fix-EcuM和Flex-EcuM,本工程采用Flex-EcuM。

2025-06-13 15:06:14 16

原创 从零搭建AUTOSAR开发工程系列之—Davinci开发之BswM配置(12)

本篇介绍BswM配置,消除错误。

2025-06-13 15:04:08 14

原创 从零搭建AUTOSAR开发工程系列之—Davinci开发之OS配置三(11)

OS模块配置,这是最后一篇,在我们的工程中,创建了4个Application Task。

2025-06-13 14:51:53 7

原创 从零搭建AUTOSAR开发工程系列之—Davinci开发之OS配置二(10)

本篇开始我们继续介绍OS模块的配置。

2025-06-13 14:49:02 22

原创 从零搭建AUTOSAR开发工程系列之—Davinci开发之OS配置一(9)

目前Davinci工程已经导入了所有必备BSW模块,从本篇开始我们将一一介绍,如何配置这些BSW模块,以及问题处理。首先我们从OS模块开始介绍。

2025-06-13 14:45:49 14

原创 从零搭建AUTOSAR开发工程系列之—Davinci开发之工程导入BSW模块(8)

在上一篇,我们创建了Davinci工程,但目前这个工程还是一个“空”工程,除了具备我们MCAL配置的模块之外,BSW部分没有任何模块。本篇我们将介绍如何导入将BSW模块导入工程。

2025-06-13 14:42:28 10

原创 从零搭建AUTOSAR开发工程系列之—Davinci开发之创建Davinci工程(7)

本篇开始,进入自动动手搭建Autosar工程的第二阶段——使用Davinci工具进行软件开发。本篇我们将介绍,如何基于EB的MCAL配置信息文件,创建Davinci工程。

2025-06-13 14:36:22 18

原创 从零搭建AUTOSAR开发工程系列之—MCAL开发之导出配置文件(6)

MCAL配置开发完成以后,我们需要切换进去下一个工具链——Davinci Configurator,需要将MCAL配置信息导入到下一阶段,而在这之前,我们需要做的就是在EB中将MCAL配置信息以arxml的形式导出。

2025-06-13 14:30:08 10

原创 从零搭建AUTOSAR开发工程系列之—MCAL开发之配置MCU(5)

本篇接上篇继续MCU配置的介绍,MCU是MCAL配置中比较复杂的模块,篇幅较长因此分为两篇文章。

2025-06-13 14:26:32 9

原创 从零搭建AUTOSAR开发工程系列之—MCAL开发之配置(4)

本篇进行MCU的配置介绍。

2025-06-13 14:24:43 27

原创 从零搭建AUTOSAR开发工程系列之—MCAL开发之Dio配置(3)

本篇基于上一篇,机型进行MCAL配置开发讲解,本篇介绍如何使用EB配置Dio。

2025-06-13 14:22:27 11

原创 从零搭建AUTOSAR开发工程系列之—MCAL开发之配置Port(2)

本篇我们基于第一篇创建的EB工程,讲解如何进行Port的配置。

2025-06-13 14:19:53 11

原创 从零搭建AUTOSAR开发工程系列之—MCAL开发之EB工程的创建与使用(1)

MCAL就是嵌入式软件中的底层驱动,驱动是整个嵌入式系统功能实现的基础,在汽车电子领域,虽然代码开发不同于其他嵌入式领域,主要依赖于开发工具的使用,但各个部分所承担的角色一就是一样的,MCAL开发是从零搭建AUTOSAR工程的第一步。本篇我们将介绍如何使用汽车行业使用最广泛的MCAL开发工具EB Tresos进行MCAL工程的创建与使用。

2025-06-13 14:17:30 107

原创 BswM模块配置指导

对于BswM的配置使用,脑海里谨记四个概念即可:Rule、Expression、Action、ActionList。

2024-03-16 17:40:59 757

原创 CAN通信篇 - Com模块配置(七)

以上就是Com模块的配置,关于保持默认配置的描述,实际在应用中默认配置会根据具体配置发生改变,工具会报错,根据报错提示处理即可。关于基本Can通信的配置介绍,通信相关的配置到此就介绍完了,贴一张工具Validation的图Communication相关validation pass。当然实际工程中,信号是需要通过Rte传递到上层Appl Swc的,这个后续会介绍.

2024-03-16 17:33:51 655

原创 CAN通信篇 - ComM模块配置(六)

在不带NM功能(也不带Pnc功能)的基本CAN通信通道上,ComM的配置还是比较简单的,仅仅是定义ComMUser并引用到通道相应ComMChannel上即可。ComM通用配置使用默认即可。

2024-03-06 18:02:02 715

原创 CAN通信篇 - CanSM模块配置(五)

CanSM在Configurator配置中比较简单,但是CanSM本身的状态机并不简单。详情可以参考我在理论篇关于CanSM模块的详细介绍。

2024-03-06 17:58:39 436

原创 CAN通信篇 - PduR模块配置(四)

PduR的作用就是负责将Pdu在源和目的地之间传递;从零开始的项目需要配置定义上层和下层;注意在EcuC中创建Pdu;目的地Pdu配置中特殊的配置项需要更具具体需求具体更改;

2024-03-05 16:37:38 659

原创 CAN通信篇 - CanIf模块配置(三)

在AUTOSAR CAN通信架构下,CanIf是位于Can模块上层的模块,向下与Can模块交互。CanIf模块的配置比Can模块稍微复杂些,一级配置容器就有6个,如下图所示,下面一一详细介绍。通过CanIfCtrlDrvCfg引用到对应Can控制器;通过CanIfTrcvDrvCfg 引用到对应的Can收发器;CanIf buffer的定义、配置;CanIf Pdu的定义、配置(Tx和Rx)

2024-03-05 16:36:43 1712

原创 CAN通信篇 - CanTrcv模块配置(二)

有些Can发送器芯片是带唤醒功能的,如果启用就注意该模块配置与之相关的开关需要使能;另外就是RXD和STB的Pin角,查芯片硬件手册确定,务必要正确;

2024-03-05 16:35:38 1043

原创 CAN通信篇 - Can模块配置(一)

以上就是Davinci Configurator中关于Can模块的配置介绍。这个模块主要进行Can控制器相关参数和Can模块的Tx和Rx的MailBox配置。至于CanGeneral的配置,一般保持默认即可。另外关于轮询式Can报文处理的周期定义,仅在配置为轮询式处事方式时才需要,对于配置为中断式的,空置即可。这个模块可以理解为是AUTOSAR架构下Can通信的最低层(暂不考虑MCAL),直接与CanBus交互;

2024-03-05 16:34:44 3332

原创 AUTOSAR通信篇 -Communication(COM)

ISO 17356-4:2005 Road vehicles – Open interface for embedded automotive applications – Part 4: OSEK/VDX Communication (COM) 是AUTOSAR COM模块的功能基础。AUTOSAR COM模块以此为基础,通过不同的实现的方式,实现了全部功能和API(除去一些特殊不必要的)一个I-PDU可以归属任何一个I-PDU组;

2024-02-27 21:14:29 849

原创 AUTOSAR内存篇 -Memory Abstraction Interface(MemIf)

本文描述AUTOSAR基础软件模块“Memory Abstration Interface(MemIf)”。该模块允许NVRAM管理器访问多个内存抽象模块(FEE或EA模块),如下图所示。内存抽象接口(MemIf)从FEE或EA模块抽象出来,为上层提供在统一的线性地址空间上的虚拟分段。这里的介绍的MemIf的API都实际映射到底层的内存抽象模块(FEE/EA),对于每个API的具体行为,具体参考映射模块对应API介绍。参数DeviceIndex被用于选择内存抽象模块(也就是内存设备)。

2024-02-20 13:41:49 331

原创 AUTOSAR内存篇 -EEPROM Abstraction(EA)

EEPROM抽象(EA)一次只接受一个作业任务,即模块不提供作业任务的队列(这是NVRAM 管理器的任务)。由于NvM是EA模块唯一的调用方,为了使该EA模块尽可能小,模块函数不做校验,无论模块当前是忙还是不忙。使作业任务排队等待处理以及仅当前一个作业完成或取消才开始下一个新任务是NvM负责的任务。参数ConfigPtr需要总是保持为NULL_PTR(由于当前该参数还未被使用)。

2024-02-05 17:29:56 521

原创 AUTOSAR内存篇 -EEPROM Driver(Eep)

本文介绍EEPROM驱动,外部和内部EEPROM都适用。EEPROM驱动提供对EEPROM的读、写、擦服务。还提供EEPROM中数据块与内存中某个数据块的对比服务。这些服务都是异步的。内部EEPROM的驱动直接访问微控制器硬件,是位于微控制器抽象层。外部EEPROM驱动使用handlers(大部分情况是SPI)或驱动去访问外部EEPROM设备,位于ECU抽象层。这两种情况中的功能要求和范围是一样的,因此在语义上,API完全一致。

2024-02-05 17:25:10 593

原创 AUTOSAR内存篇 -FlashDriver(Fls)

本文介绍AUTOSAR BSW的闪存驱动(Flash Driver)模块,应用于内部和外部闪存。闪存驱动模块为闪存读、写、擦提供服务,并且如果底层硬件支持,可为设置/重置写/擦保护配置接口。在ECU的应用模式下,闪存驱动仅由Flash EEPROM模块使用,用于写数据。在应用模式,它不用于写程序代码到闪存中,但这会在boot模式下发生,不属于AUTOSAR范围。内部闪存的驱动直接访问微控制器硬件,且位于微控制器抽象层。

2024-02-01 18:29:28 692

原创 AUTOSAR内存篇 -Flash EEPROM Emulation(FEE)

本规范介绍Flash EEPROM Emulation的功能。Flash EEPROM Emulation(FEE)从设备特定寻址机制和段抽象出来,为上层提供一个虚拟的寻址机制和段,并且“虚拟地”不限制访问次数(实际上是由擦写循环次数寿命的)。FEE模块为上层提供虚拟的32位线性地址空间及统一的寻址机制。16位的块号码 – 理论上允许65536个块;16位的块偏移 – 理论上每个块最大64KB;16位块号代表一种可配置的(虚拟的)分页机制。地址对齐的值可以从底层闪存驱动器和设备中导出。

2024-02-01 18:12:04 370

原创 AUTOSAR内存篇 -内存访问(MemAcc)

MemAcc模块为不同的上层模块提供基于地址的独立的存储器访问。它根据物理分段实现所有高级功能,如Job管理、访问协调和内存驱动程序访问请求分配,因为内存驱动程序希望所有内存访问都与物理分段对齐。AUTOSAR架构下对内存的访问,被拆分为MemAcc和Mem两个模块,其中Mem依赖于硬件,属于硬件不独立模块;而MemAcc模块为硬件独立模块,使用Mem驱动的服务函数,为上层提供内存访问服务。

2024-01-30 15:24:08 635

原创 AUTOSAR内存篇 -内存驱动(Mem)

Mem驱动程序的task是基于底层内存设备技术的物理分段的低级内存访问。Mem驱动程序的API与内存设备技术无关,因此向存储器访问模块上层提供了与存储器设备无关的接口。所有高级功能(如跨段操作)都由内存访问模块处理,以尽可能降低Mem驱动器的复杂性和占用空间。Mem驱动API命名、类型定义和文件命名规则都遵循标准的AUTUSAR BSW模块实现。服务Mem_Init初始化Mem驱动的内部状态,并设置Mem驱动Job处理状态到MEM_JOB_OK。

2024-01-30 15:14:26 390

原创 AUTOSAR看门狗篇 -看门狗接口(WdgIf)

WdgIf不会为看门狗驱动添加功能,也不从看门狗属性中提取信息,如toggle或窗口模式、超时时间等。也就是说,它不隐藏底层看门狗驱动程序和看门狗硬件的任何功能,仅作为一个"管道"连接看门狗驱动和看门狗客户端。如果配置了多个看门狗驱动程序,并且为此模块启用了DET,则应检查参数DeviceIndex是否为模块服务中的现有设备。使用错误码WDGIF_E_PARAM_DEVICE向DET报告检测到的错误,且不应执行被调用的服务。

2024-01-26 14:57:20 563

原创 AUTOSAR看门狗篇 -看门狗驱动(Wdg)

Wdg模块静态(至少是在编译时)检查配置参数是否正确。Wdg模块不实现去初始化/关闭的接口。如果看门狗支持去初始化/关闭,且环境允许使用此功能,去初始化/关闭的功能通过使用OFF参数调用Wdg_SetMode实现。有些看门狗不支持去初始化/关闭功能,因为某些环境下允许使用该功能(例如在有功能安全要求系统中)。如果必须禁用中断以确保数据一致性或该模块的正确功能(例如,在切换看门狗模式时或看门狗触发程序期间),则应尽可能使用相应的BSW调度程序功能来完成此操作(这意味着独占区域的定义)。

2024-01-26 14:50:54 493

原创 AUTOSAR系统服务篇-多核OS

由于OS应用与核绑定,OS应用特定的StartupHook尽在其所绑定的核上执行。例如,如果硬件支持,在不同核上的自由运行硬件计时器使用同样的定时器(外设维护一样的计数器值),因此在不同核上提供同样的时间基准。如果核心上的任务/ 2 类ISR,其中同一个或不同的任务/2类ISR已经持有一个自旋锁,试图获取另一个未配置为最近获取的自旋锁的直接或间接后续者的自旋锁(通过OsSpinlockSuccessor配置参数),或者未配置后续者,AUTOSAR操作系统将生成错误(获取多个自旋锁时,如果不按照定义次序)。

2024-01-24 16:49:46 570

原创 AUTOSAR系统服务篇-操作系统

本文当介绍关于AUTOSAR Operating System的基本知识,满足AUTOSAR SRS文档陈述的需求。一般来说,操作系统可以根据它们的特性分成不同的组,例如静态配置和动态管理。静态配置和扩展的;旨在满足实时性能;提供基于优先级的调度策略;提供运行时保护功能(内存保护、时间保护等);可在低端控制器上运行,无需外部资源;该特性集定义了当前一代汽车ECU中常用的操作系统类型,远程信息处理/信息娱乐系统除外。

2024-01-24 16:30:04 237

原创 AUTOSAR系统服务篇-WdgM

Watchdog Manager(WdgM)模块是一个BSW模块,在标准AUTOSAR架构中,它位于服务层。WdgM能够监控从硬件看门狗实体的触发中抽象出的程序执行。WdgM监督配置数量的监督实体的执行。当它检测到程序执行中违反了对配置的时间和/或逻辑的约束时,它采取许多可配置的动作来从该故障中恢复。Alive Supervision - 用于监控周期性软件的定时Deadline Supervision - 用于监控非周期性软件的定时。

2024-01-05 18:08:21 1555

原创 AUTOSAR系统服务篇- EcuM多核

启动时主核启动从核关机时主核通知从核一句话总结:多核场景下需要主从协同完成启动、初始化、睡眠、关机等等EcuM负责的事情。详细时序图,参考本文。

2023-12-29 15:46:54 1305

原创 AUTOSAR系统服务篇- EcuM

负责上初始化负责下电和睡眠负责唤醒事件处理并通知BswM不会改变ECU状态,只负责将仲裁结果通知BswM,改变状态的事情还是由BswM执行。

2023-12-27 11:01:33 1174

原创 AUTOSAR实战篇之——NvM

本篇是对理论篇NvM理论概念描述的实际操作。使用的工具是Vector公司的Davinci。List item。

2023-12-11 17:43:52 379

原创 AUTOSAR系统服务篇 - BswM的使用

本文档是对4.0.3版及更高版本的AUTOSAR模式管理应用的介绍。其主要目的是为AUTOSAR的用户和开发人员提供基于示例的AUTOSAR模式管理不同方面的详细概述,这些示例在文中进行了解释。本文中的代码清单共同构成了示例ECU的配置。第2章解释了基础的模式管理概念,例如一般的模式、如何实现模式切换、模式管理者和模式用户的角色等。其次介绍了应用模式管理和基础软件模式管理的依赖关系,两者密切相关。基础软件模式管理器是AUTOSAR R4.0中的中央模式管理模块。它具有很高的可配置性。

2023-12-11 17:33:50 533

ASAM_MCD-2D_ODX_V2.1.0.pdf

ASAM MCD-2 D (aka ODX) allows the data-oriented specification of vehicle diagnostics. The standard defines a data model for the description of diagnostics capabilities of ECUs needed throughout the lifecycle of a vehicle from development, testing, production to after-sales and service. The standard facilitates the exchange of diagnostic information between partners in development process, e.g. between OEM and ECU supplier or between OEMs in a cooperation project. In detail, ODX covers the description of: Diagnostic communication via requests and responses, trouble codes (DTCs), parameters and other diagnostic data Communication parameters for different diagnostic protocols ECU memory programming ECU variant coding Function-oriented diagnostics

2020-03-31

空空如也

TA创建的收藏夹 TA关注的收藏夹

TA关注的人

提示
确定要删除当前文章?
取消 删除