- 博客(209)
- 资源 (4)
- 收藏
- 关注
RSS订阅原创 87.ADC、PWM、ICU——模拟与波形三件套怎么配
本文详解S32K144上ADC、PWM、ICU三类模拟与波形外设：ADC基于SAR结构，支持多通道分组及PDB硬件触发；PWM由FTM生成，可配置占空比、极性与故障关断；ICU用于测量信号周期、占空比，仅偶数通道可用。三者均通过AUTOSAR接口统一管理，关键点包括时钟配置联动、通道约束（如ICU限偶数）、硬件触发同步及安全机制（如FLT）。
2026-11-15 00:16:05
4
原创 86.引脚复用怎么配——Port 管结构、Dio 管读写
S32K144引脚复用由PORT与DIO驱动协同管理：PORT负责配置引脚功能（通过PCR编号，公式为端口×32+引脚号），DIO仅用于运行时读写。PCR号需准确计算，错位将导致功能错配。配置须依据官方IO信号表，未使用引脚应统一设为输入上拉/下拉。注意：输出口回读仅在配置为输入时有效，否则读取的是输出寄存器值。关键点：先初始化PORT，再使用DIO，二者必须配对。
2026-11-15 00:14:51
3
原创 85.时钟是地基——SCG 四源三分频与 GPT 定时器
S32K144时钟由SCG统一管理，支持SOSC、SIRC、FIRC、SPLL四源选一，经三级分频输出CORE、SYS、BUS、FLASH四路时钟。核心概念为“四源选一、三级分频出四路”。运行模式（RUN/HSRUN/VLPR）对应不同配置，VLPR下频率受限。GPT定时器共38通道，分布于FTM、LPIT、LPTMR、SRTC，OStick常用LPIT/LPTMR。关键点：外设时钟门控（PCC）需开启，PLL须锁定后方可使用；双时钟模式支持低功耗下动态切换时钟；注意Flash时钟不宜过低，避免增加等待周期
2026-11-15 00:13:37
3
原创 84.上电到 BSW 跑起来——启动序列谁先谁后
本文详解MCU上电启动流程：从复位后启动代码初始化栈、数据段，到EcuM接管并按序初始化MCAL驱动。核心为“Mcu必须最先初始化”，因其控制时钟门控（PCC），决定外设能否工作。关键步骤包括：Mcu_Init载入配置 → Mcu_InitClock配时钟 → 等待PLL锁定 → 分发时钟 → 切换至RUN模式。顺序不可颠倒，否则导致外设失效或系统卡死。强调配置要点：Mcu在DriverInitList中优先、时钟配置正确、避免手动改寄存器。常见错误如未锁PLL即分发时钟，引发MCU_E_PLL_NOT_L
2026-11-15 00:12:11
3
原创 83.NXP MCAL 包里到底有啥——23 个模块怎么读
本文详解NXPS32K1MCAL模块包结构与集成流程，基于AUTOSAR 4.3.1/S32K1XX R1.0.5标准，涵盖23个驱动模块、46份中英文手册。核心为BASE模块，作为所有模块依赖基础，包含关键头文件与stub配置项。强调“UM教配置、IM教集成”的阅读路径，提示需关注版本、封装、勘误表及NXP官方release。重点提醒：stub由集成商替换，配置前锁定芯片封装，避免引脚错配；问题上报应通过NXP官方渠道，不依赖Vector支持。
2026-11-15 00:10:54
3
原创 82.S32K1 接入实操——版本红线与两个必踩坑
S32K144采用Mixed混工具模式，遵循“tresos初配、CFG接管”流程。需确保版本匹配：MSR4用CFG5.15+，MSR3 MixedASR用4.2.3.2+。关键顺序为先打HotFix再运行脚本。配置时添加Base、Resource、Dem、EcuM等占位组件，导出ECUC后导入DaVinciCFG进行后续开发。常见问题包括McuNoPll导致链接错误（需设为STD_OFF）及CSEC包缺plugins目录（需手动创建）。MCAL问题应联系NXP，而非Vector。
2026-11-15 00:09:42
4
原创 81.第三方 MCAL 怎么搬进 Vector 家——三种工作流选哪个
本文详解S32K144平台中NXP第三方MCAL集成至Vector BSW工程的流程。核心是通过MCALIntegrationPackage实现适配，使DaVinciConfigurator能识别NXP驱动模块。采用Mixed工作流（推荐），先用EB tresos初配MCAL，再导入CFG进行后续配置。关键步骤为运行Script_MCAL_Prepare.bat完成环境准备，注意避免使用generateall，按需逐个-n指定模块。强调责任边界：Vector仅负责接口适配，不承担MCAL功能缺陷。注意事项包
2026-11-15 00:08:40
4
原创 80.诊断与存储常见问题——收官排查清单收好
S32K144诊断与存储栈高频问题聚焦于诊断超时、DTC丢失及NvM写失败。排查遵循“自顶向下、分层查状态”原则：先验应用层API，再查Dcm/Dem/NvM状态机，最后验证驱动与硬件。关键点包括：确认CAN报文收发、会话/安全等级匹配、NvM_WriteAll完成、Fee扇区不重叠、Debounce阈值合理。优先使用GetStatus类接口，避免加打印破坏实时性。量产前须做Flash寿命评估、版本管理及关闭DevErrorDetect。CANoe是定位核心，九成问题可从报文时序中发现。
2026-11-15 00:07:21
6
原创 79.IoHwAb——把 MCU 外设封装成 RTE 端口的“翻译官“
IoHwAb（I/O硬件抽象层）位于MCAL与RTE之间，将ADC、DIO、PWM等外设通道封装为RTE可调用的S/R或C/S端口，实现应用层（SWC）与底层驱动的解耦。它支持芯片迁移时仅重配映射，无需修改SWC代码，并完成工程单位换算（如原始码转毫伏）。典型流程：先配置MCAL通道，再在IoHwAb中创建Runnable与Schedulable，映射至Task，通过函数模板读取底层数据并转换后写入RTE信号。注意端口类型匹配、周期对齐、引脚复用一致及GlobalSuspend/Restore配对使用。复杂
2026-11-15 00:04:56
4
原创 78.RamTst——CPU 闲下来时给 RAM 做“背景体检“
RamTst是ISO26262要求的运行期RAM自检机制，利用OS空闲时间片分步检测内存故障。通过MarchMATS等算法在低优先级任务中逐单元测试，覆盖stuck-at、耦合等缺陷，避免影响实时性。关键点：配置时排除栈与关键变量区，正确调用Allow启动，绑定IdleTask，合理设置测试单元数。与上电自检互补，实现全周期内存健康监控。
2026-11-15 00:03:28
5
原创 77.Eep 驱动——S32K144 把 FlexNVM 仿真成 EEPROM 用
S32K144上Eep驱动主要操作FlexNVM的EEPROM仿真分区，由FTFC控制器管理，支持字节级读写，适用于高频写入场景（如标定数据）。需在启动代码中通过DEVDIV寄存器划分EEPROMPartition，否则Eep_Init将失败。Eep与Fls共享FTFC但分区不同，应用应通过NvM调用，避免直接调用API导致资源冲突。配置时注意分区大小与块地址匹配，量产前需核对NXP勘误0N57U。API风格统一，遵循AUTOSAR MCAL规范。
2026-11-14 23:23:18
3
原创 76.Ea 基础——外部 EEPROM 的“块级翻译官“
Ea（EEPROM抽象层）位于Eep驱动与NvM之间，将线性地址访问转换为块级操作，实现对EEPROM芯片的逻辑块管理。它解决硬件页写限制问题，自动拆分跨页写请求，使NvM可统一使用块接口。与Fee功能相似但针对外部EEPROM，二者不可共存。配置时需定义逻辑块号、长度及虚拟页大小，支持立即擦除块（ImmediateBlock）以满足实时需求。注意：无外挂EEPROM时无需配置Ea，初始化顺序为Eep_Init→Ea_Init，且块号必须与NvM一致。错误通过Job结果上报，非自动触发Dem。
2026-11-14 23:22:02
6
原创 75.MemIf——NvM 与 Fee/Ea 之间那层“统一门面“
MemIf是NvM与Flash/EERPOM间的统一抽象接口，通过设备句柄分发读写请求，实现对Fee（内部仿真EEPROM）和Ea（外部EEPROM）的统一调用。其“薄皮”特性表现为无状态、无需Init/MainFunction，仅依赖编译宏配置设备数（如S32K144通常仅用Device0）。关键操作包括通过MemIf_Read/Write分发请求，设置MemIf_SetMode切换SLOW/FAST模式以优化时序。虽看似可省，但因AUTOSAR规范要求必须存在，且共享状态/结果枚举，便于统一排错。实际使
2026-11-14 23:21:01
3
原创 74.NvM 基础——非易失存储的“块总管“怎么当
NvM是AUTOSAR存储栈的“总管”，统一管理应用与非易失存储（Flash/EEPROM）的交互。它通过RAM镜像实现异步写入，避免阻塞应用；支持CRC校验与冗余备份，保障数据可靠性。核心API包括ReadAll/WriteAll、ReadBlock/WriteBlock及GetErrorStatus。配置时需注意块长度、CRC、冗余、优先级等参数，合理设置ReadAll自动读取范围以优化启动时间。关键点：确保RAM镜像与块长度一致，避免CRC失败；慎用Immediate优先级；禁止频繁写入以防闪存损耗。
2026-11-14 23:19:56
4
原创 73.诊断栈 S32K144 集成实战——DTC 是怎么落到内部 Flash 的
本文详解S32K144上诊断帧与DTC数据流的集成实现：诊断帧经FlexCAN0进入，经CanIf、PduR、CanTp至Dcm处理，查询DTC时从NvM RAM镜像读取；写DTC则先存入内存，下电或周期写入Fee（Flash仿真EEPROM），再由Fls写入CodeFlash。关键在于通过Fee实现小数据高效、耐擦写的存储管理，避免直接操作扇区级Flash。配置需严格划分扇区，初始化顺序不可颠倒，下电时必须轮询NvM_WriteAll确保数据持久化。强调了地址不重叠、禁止在编程扇区取指等注意事项，揭示“读
2026-11-14 23:18:57
3
原创 72.DiagA2lGen——给诊断内部符号补一张“地图“
DiagA2lGen是Microchip提供的命令行工具，用于从Dem、Dcm、Fim模块的生成代码中提取内部状态变量（如DTC状态、会话、安全等级），生成A2L片段，使CANape等工具可测量诊断状态。需扫描包含生成代码的源码目录，输出.a2l片段并合并至主A2L文件。关键点：输入目录必须完整，片段需正确include，避免因遗漏或手动修改导致失效。常见问题为未包含生成文件或未合并片段。
2026-11-14 23:17:51
5
原创 71.vDem——PC 上跑的那个“虚拟病历本“
vDem42是Vector提供的虚拟诊断事件管理模块，运行于PC仿真环境，替代真实ECU上的Dem，支持SWC在无硬件条件下完成诊断逻辑测试。其接口与真实Dem一致，状态存储于RAM，断电丢失，适用于单元测试与联调。关键点：仅用于PC侧，不可部署至ECU；事件ID必须与ECU工程严格一致；通过RTE正确连接PPort/RPort，启用回调监控状态变化。可动态增删用户事件，提升调试效率。下一集将介绍DiagA2lGen工具。
2026-11-14 23:16:53
3
原创 70.Dem 基础与配置——事件、去抖和 DTC 的“病历本“
Dem（诊断事件管理）是ECU后台核心模块，负责监控故障事件、通过去抖机制避免误报，按配置管理DTC状态（如Confirmed/Pending），并记录冻结帧与扩展数据。其核心流程为：事件上报→去抖计数→置位/清除DTC→预存快照→持久化至NvM。关键点包括：Debounce阈值≥3、正确配置FreezeFrame与ExtendedData、初始化顺序合规、避免未注册DID导致数据丢失。Dem_SetEventStatus为应用层唯一入口，需配合PrestoreFreezeFrame实现“先存后确认”。下一
2026-11-14 23:15:47
3
原创 69.Dcm 配置实战——七类服务、三张会话、一道门禁
本文详解S32K144上基于Vector Dcm模块配置最小可用UDS诊断服务集的实战流程。通过四大配置组（General/Dsl/Dsd/Dsp）实现7类核心服务：会话控制（10）、读/写DID（22/2E）、安全访问（27）、读DTC（19）、ECU复位（11）、例程控制（31）。重点解析协议通道、服务表、会话矩阵、安全等级与DID映射配置，强调数据来源（RTE端口或回调函数）及权限控制逻辑。附带关键代码示例与常见坑点提醒，如长度不匹配、安全等级未关联、任务映射缺失等。最终达成诊断仪在ExtendedS
2026-11-14 23:14:34
4
原创 68.Dcm 基础——会话和安全等级这两张“门禁表“
本文详解Dcm（诊断通信管理器）的内部结构与配置逻辑，其核心为三部分：服务分发（Dsd）、服务处理（Dsp）与传输层适配（Dsl）。通过正交设计的会话与安全等级状态，实现精细化权限控制。重点讲解了UDS服务注册、会话管理、安全访问、DID配置及关键定时参数（P2/P2*），并结合实例说明常见NRC响应与排错要点。强调服务表配置优先原则，指出会话超时机制与任务调度对诊断响应的影响，为下一集完整配置奠定基础。
2026-11-14 23:13:26
3
原创 67.诊断栈总览——Dcm 坐前台、Dem 管病历、NvM 存记忆
本集概述AUTOSAR Classic诊断栈架构：Dcm（诊断通信管理）为前台，负责UDS协议解析与会话控制；Dem（诊断事件管理）为后台，管理故障事件与DTC生成；NvM实现故障数据掉电保存。三者协同通过PduR/CanTp经CAN总线通信，诊断采用点对点问答模式，长报文需分段传输。配置关键在Dcm、Dem、NvM模块联动及Task调度匹配，确保诊断响应及时、数据持久。下一集将深入Dcm会话与安全等级配置。
2026-11-13 21:14:29
3
原创 66.通信栈常见问题——一张分层排查地图收好
本文梳理通信栈常见问题排查路径，提出“自底向上、分层隔离”原则，构建从应用到总线的完整报文链路图（应用→Com→PduR→CanIf→FlexCAN→引脚→收发器→总线）。针对无报文、错误帧、信号错、BusOff等现象，明确关键排查点：时钟使能、引脚复用、波特率匹配、终端电阻、初始化顺序及工具分工。强调先定位断点再调参，避免盲目修改。建议将排查地图存为团队Wiki，持续迭代经验，提升故障处理效率。
2026-11-13 21:12:53
5
原创 65.GenTool——把 DBC 变成 ARXML 的那台控制台翻译机
GenTool（VLC）是将DBC/LDF/Fibex等遗留通信数据库转换为AUTOSAR ARXML SystemDescription的核心工具，实现信号、帧、节点等对象的自动映射。它通过命令行参数（如-e、-r、-o）配置，生成符合Vector私有规则的ARXML及ECUExtract，常由DPA自动调用。转换依赖DbcRules_Vector规范，无行业标准，命名前缀（如DT_、CM_）不可通用。关键点：转换结果取决于DBC质量，属性映射需验证，部分属性（如ILTxTimeout）被忽略。适用于大项
2026-11-13 21:11:44
5
原创 64.CAN 通信调试——按“发没发、对不对、健不健康“三层查
本文详解CAN通信调试核心思路：以Vector CANoe为工具，结合AUTOSAR架构，按“发没发、对不对、健不健康”三层逻辑排查问题。重点包括通道参数对齐、DBC同步、报文周期验证、错误帧分析及BusOff处理。通过Trace、Graphics、Statistics窗口与Com/CanIf/CanSM状态联动，实现软硬件协同诊断。强调先验检查MCAL四链路（时钟/引脚/波特率/收发器），避免误判配置问题。常见故障如无报文、错误帧、BusOff均有明确根因与应对策略，确保调试高效准确。
2026-11-13 21:10:30
4
原创 63.通信栈 S32K144 集成实战——从空白 MCU 到总线报文的四条“接线“
本文详解S32K144上实现CAN通信的四大关键链路：时钟使能、引脚复用、波特率匹配与收发器模式配置，强调从芯片空白到总线出现周期报文需打通四道“阀门”。基于Vector 3rdPartyMCAL工作流，通过EBtresos与DaVinci协同配置，确保MCAL（时钟/引脚）与BSW（PDU/信号）联动。实操中需严格对齐时钟80MHz、500kbit/s波特率、引脚复用设置及收发器TJA1043切换至NORMAL模式，并按正确顺序初始化Can_Init→CanTrcv_Init→Com_Init等模块。常见
2026-11-13 21:09:21
5
原创 62.FlexCAN3 驱动——邮箱、位时序和那个“少一个“的保留位
本集详解S32K144上FlexCAN3的AUTOSAR CAN驱动，核心为FullCAN（固定ID）与BasicCAN（动态ID）邮箱区分设计，支持RxFIFO与RxQueue优化接收。采用三段式初始化，配置需关注时钟、波特率、邮箱布局及ERR005829硬件缺陷导致的预留邮箱。中断与轮询可独立配置，ISR需正确映射。强调时钟一致性与符号名动态获取，避免常见配置陷阱。下一集将完成芯片级集成。
2026-11-13 21:07:04
6
原创 61.DBC 规则——DBC 属性这本“翻译字典“怎么写
DbcRules_Vector 就是 DBC/LDF/Fibex 遗留数据库进 AUTOSAR 的"属性字典"，属性名、枚举顺序、取值范围都照规范写。导入前重点查：网络级属性、Com 发送属性、NM 属性、诊断属性，以及导出时那个 GENy 勾选项。
2026-11-13 21:05:10
8
原创 60.CanTrcv 基础与配置——DIO 引脚背后的收发器抽象
CanTrcv_30_Tja1043是AUTOSAR中用于抽象CAN收发器的驱动模块，通过DIO引脚控制TJA1043、TCAN1043等芯片，屏蔽硬件差异。支持正常、待机、睡眠三种模式，遵循特定迁移规则，通过轮询或中断检测总线唤醒，并上报至EcuM。配置需正确映射引脚，初始化顺序为先清内存再初始化，且不支持SPI控制。该模块实现极简，核心功能仅为引脚操作封装，旨在实现芯片更换时上层代码零修改，提升系统可移植性。
2026-11-13 21:03:00
5
原创 59.Cdd_Communication 基础与配置——把私有协议接进 AUTOSAR 通信栈
本文介绍如何使用Vector提供的Cdd_Communication模板，将自定义通信模块（如私有协议、非标总线）接入AUTOSAR通信栈。CDD作为“毛坯改造间”，通过预定义接口与PduR协同，支持上层（如Com/Dcm）或下层（如CanIf）角色，实现I-PDU收发与传输层功能。核心步骤包括：选定贡献类型、关联全局PDU、生成并实现回调函数（如RxIndication、TxConfirmation）、替换内存映射占位符。强调CDD为模板而非成品，需集成方自行实现逻辑，且回调签名、中断安全、命名规范需严格
2026-11-13 21:01:27
5
原创 58.Nm 基础与配置——ComM 与各 BusNm 之间的总线无关适配层
Nm（Network Management Interface）是AUTOSAR中承上启下的适配层，向上为ComM提供统一接口，向下对接各类总线专用的BusNm（如CanNm、LinNm、FrNm等），实现总线无关的网络管理。其核心价值在于：提供统一接口，支持GenericBusNm接入旧有或自定义NM（如NmOsek），并可选启用协调器（NMCoordinator）实现多网络同步休眠。配置重点包括通道绑定、协调器与超时设置、回调转发及MacroLayer优化。在单总线场景下可降级为宏层以节省资源。图58-
2026-11-13 21:00:02
3
原创 57.NmOsek 基础与配置——老 OSEK 逻辑环的 AUTOSAR 入口
NmOsek是Vector基于OSEK NM 2.5.3实现的CDD模块，作为GenericBusNm挂载于AUTOSAR Nm之下，兼容老车型逻辑环网络管理。它通过ALIVE、RING、LimpHome报文维护环状通信，支持被动模式与动态控制，配置需注意初始化顺序、主函数周期调度及DBC属性设置。虽不支持部分AUTOSAR特性，但为旧项目迁移提供无缝接口，体现工程实用性。
2026-11-12 19:45:04
7
原创 56.CanNM——整车一起醒来、一起睡着的网络管理
本文详解CAN网络管理（CanNm）的协同睡眠/唤醒机制，核心解决多ECU间通信协调问题。通过Repeat/Normal/ReadySleep三子状态实现“一人想睡，全网等”的协同逻辑：本地需通信则快速发送NM帧（Repeat），无需时进入ReadySleep并依赖他人帧续时；全网无报文后，经PrepareBusSleep最终进入睡眠。关键配置包括周期参数、被动模式与固定NMID，强调NMPDU控制位（如WakeUp、SleepReady）的作用。结合状态机与实际配置示例，阐明如何通过ComM/Nm接口实现
2026-11-12 19:43:45
8
原创 55.CanTp——ISO 15765-2 多帧分段与流控
CanTp 按 ISO 1576-2 把长数据切成 SF/FF/CF，用 FC 流控。BlockSize 管"几块停一次"，STmin 管"两帧间隔"，两者共同决定传输速度。数据搬运靠 PduR GenericTp 回调，超时由 CanTp_MainFunction 处理。下一集收官通信栈前段，讲 CanNM：整车怎么一起醒来、一起睡着。
2026-11-12 19:42:40
7
原创 54.CanIf——PDU 到 CAN ID 的映射与收发路径
CanIf是AUTOSAR中直接对接CAN硬件的接口模块，负责将上层PDU映射为具体CANID、DLC及控制器通道。其核心功能为“查号台”：通过配置表实现PduId到CANID与硬件句柄（HRH）的转换。初始化需严格按六步顺序执行，收发路径对称，依赖CanDriver中断回调。关键点包括：接收先按HRH分组再匹配CANID，避免错位；动态发送需启用DYNAMIC类型；唤醒链路须正确配置WakeupSource；TxConfirmation不可执行重操作，以免阻塞中断。最终，CanIf以60为ModuleID
2026-11-12 19:41:26
230
原创 53.CanSM——把通信模式翻译成控制器动作
CanSM作为CAN模式管理核心，协调ComM与CanIf，实现三态模式（NO/SILENT/FULL）到控制器/收发器状态的转换。启动时按“收发器Normal→控制器STARTED→PduOnline”顺序执行，确保通信可靠。支持BusOff自动恢复，分L1/L2两级延时，结合Dem上报故障。关键配置包括恢复时间、重试机制及波特率切换参数。强调顺序不可乱，硬件异常需优先排查。下一集将深入CanIf映射与收发路径。
2026-11-12 19:40:14
9
原创 52.PduR——PDU 路由器的路由表、FIFO 与网关
PduR是数据面的“交接点”，仅依据路由表原封转发PDU，不拆包、不改内容。它支持IF（直传）、TP（流式传输）和Gateway（跨总线转发）三类路径，实现网关功能。通过FIFO缓冲接收帧、TxBuffer应对发送背压，由BswM控制路由开关。关键配置需确保引用一致，避免断链；网关1:N注意带宽，TP路径禁用FIFO，N:1合流需保留源ID。路由表编译期定死，不可动态增删，强调“专责转发”以兼容多协议。
2026-11-12 19:39:06
107
原创 51.ComStackLib——配置之外的“代码瘦身“引擎
ComStackLib是Vector AUTOSAR BSW共用的代码生成与数据优化层，直接影响ROM/RAM占用。通过预编译压缩（如#define、位域打包）、数据去重、类型最小化、枚举紧凑化及运行时配置选择等四类优化，显著减少常量表体积，尤其在S32K144等资源受限芯片上意义重大。但优化需权衡可调试性与多变体支持，改动后须全栈重新生成与验证。其核心价值在于以极小代价实现配置数据的极致压缩，让同一代码适配更小芯片。
2026-11-12 19:37:53
7
原创 50.ComM——通信模式仲裁者
ComM 在每个通道上维护 NO / SILENT / FULL 三态，是所有"用网请求"的仲裁点。用户请求 ComM_RequestComMode，模式结果经 ComM_BusSM_ModeIndication 下 CanSM、经 BswM_ComM_CurrentMode 上报 BswM。报文不发先看 ComM 停在哪一态，而不是先翻 Com 参数。下一集跳出"功能模块"视角，讲贯穿所有 MICROSAR 模块的 ComStackLib 代码生成优化
2026-11-12 19:36:46
8
原创 49.从 DBC 导入 Com 配置——S32K144 单通道实战
DBC文件可一键导入Com配置，自动映射报文ID、信号位置、周期等属性，大幅提升效率。但关键字段如I-PDUGroup归属、信号处理模式、回调函数名等需人工补全，否则导致通信异常。导入前须勾选“ExportGENycompatiblemessageattributes”，确保属性完整；注意ECU名一致、格式（Motorola/Intel）正确，避免位序错乱。建议用CANoe验证导入结果，确保信号对齐。后续需配合ComM管理发送权限。
2026-11-12 19:35:10
8
原创 48.Com 模块——信号打包、I-PDU 组与收发上下文
本文详解AUTOSAR Com模块核心功能，揭示信号从应用层到CAN报文的打包机制。以“装箱车间”比喻Com工作流程，强调Signal、I-PDU、I-PDUGroup三要素及Tx/Rx MainFunction的作用。重点解析关键参数：ComBitPosition/Size、TxMode模式、IMMEDIATE/DEFERRED上下文差异、超时监控与I-PDUGroup启停逻辑。指出常见陷阱：误用IMMEDIATE、OnChange位宽限制、初始值非零、超时配置过短及I-PDUGroup漏配。最后阐明按组
2026-11-12 19:33:38
8
ISO26262培训 开发模板
2022-05-31
PEAK CAN 资源包
2020-10-26
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人