嵌入式修仙人-优快云博客

原创【EB Tresos 项目实战 09】CanTp + PduR——分段传输与路由表

一条普通 CAN 帧，最多装8 个字节。可一份诊断请求，动辄就是几十上百字节——"读取这个零件的历史故障码"这类指令，塞进 8 个字节连个开头都写不完。那差出来的那几十个字节，是谁在搬？它们在总线上长什么样？到了 ECU 这边，又是怎么一个字节不落地落到诊断模块手里的？上一篇我们讲的是"什么时候唤醒总线"；总线唤醒之后，一条超长的报文怎么被拆、拆出来的每一段又归谁。CanTp把大报文拆成小帧、再把小帧拼回大报文；PduR把拼好的报文路由到该去的模块。

2026-11-02 13:41:11 295

原创【EB Tresos 项目实战 08】CanNm _ CanSM _ ComM _ Nm——网络管理状态机

一个 ECU 什么时候该"睡"、什么时候该"醒"？一条总线上几十个节点，靠什么互相打招呼、又靠什么一起安静下来？如果各自为政——有的睡了、有的还醒着——总线上就会一直有人在说话，谁都睡不成。谁在喊睡、谁在喊醒、谁在把关；"睡"和"醒"之间，它到底走过哪几个状态；还有那个在总线上打招呼的Node ID，究竟是从哪儿来的。"名义节拍"与"实到节拍"是两回事。配置里写的主函数周期是"名义值"；真正跳到它头上多久一次，由任务周期 × 分频决定。.xdm** 里的时间是秒，生成代码里是"刻度"。

2026-11-02 10:57:06 369

原创【EB Tresos 项目实战 07】Com 信号层——94 个信号如何打包成报文

报文一路往上走，最后落到了Com手里。可 Com 接手的，只是一帧 8 个字节。“左后灯亮没亮”"刹车踏板踩没踩"这些含义，一个字节也没写着——它们藏在这 8 个字节里某几位上。一帧报文里，怎么再切出一个个信号？谁来定义"第 41 位那一小段，代表右前驻车灯"？而 8 个字节，又到底怎么装下二十几个信号？“18 条 PDU”指.xdm里的ComIPdu条目数。这份配置把左右两个变体写在同一份文件里，所以这个数是两侧合计。“13 条 PDU”（9 收 + 4 发）指单个变体生成到运行时的条目数。

2026-11-02 07:15:22 257

原创【EB Tresos 项目实战 06】CanIf 与 PDU 收发——Rx Hook 与 0x638 唤醒

上一篇里，一帧报文被硬件收进了邮箱。可到这儿，故事卡住了——邮箱只认"标准帧还是扩展帧"，它不知道这一帧叫"车身信息"还是"网络管理"。真正决定"这一帧该交给谁"的动作，发生在控制器之上那一层：CanIf。这一篇，我们先把本工程配下的 48 条收发条目一条条摊开，看清楚里面其实混着两类完全不同的东西；再逐行读通那个把整台 ECU 从睡眠里叫醒的函数。“28 收 / 20 发”指.xdm里的条目数。这份配置把左右两个变体写在同一份文件里，所以这个数是两侧合计。“21 收 / 10 发”指单个变体。

2026-11-01 15:41:04 373

原创【EB Tresos 项目实战 05】CAN 控制器配置 ——CAN FD 500k_2000k

前四篇我们都在让芯片"向内看"：配时钟、配引脚、配数字 IO、配输入捕获。这些都是芯片自己跟自己打交道的事——引脚翻不翻转，外界并不知道。这一篇开始，芯片要"开口说话"了。它说的第一句话，是往一根双绞线上说出去的。先看一个反差：同一根双绞线，同一帧报文，前半段用 500 kbps 传，后半段突然提速到 2000 kbps——中间没有任何停顿，靠一个位就完成了切换。这就是 CAN FD。它给一根总线装了"两段变速"，代价是你得给它填两套时序参数：一套管仲裁，一套管数据。

2026-10-30 11:32:25 176

原创【EB Tresos 项目实战 04】Mcu _ Port _ Dio _ Icu——从芯片引脚开始

前三篇我们一直在"看"：第 1 篇把工程解剖成五层，第 2 篇看懂"配置驱动"这套开发方式，第 3 篇把它从零编译链接跑通。可我们始终站在代码外面——知道它有McuPortDio这些模块，却没打开过任何一个。这一篇开始，我们往下钻，钻到 AUTOSAR 分层里贴着芯片的那一层。先看一个反差：一块 S32K146 焊在板子上，通电那一刻，它其实什么都做不了。没有时钟，它连"一秒"有多长都不知道；引脚没初始化，它读不出任何高低电平。让它"睁眼"的，是 MCAL 底下的四个驱动——本篇的主角。

2026-10-29 10:07:12 177

原创【EB Tresos 项目实战 03】环境搭建与首次跑通——EB Tresos + IAR + Makefile

前两篇我们都在"看"：第 1 篇把工程解剖成五层，第 2 篇看懂"配置驱动"。这一篇开始动手——把这套工程从零跑起来。先看一个反差：这份工程里，手写的.c文件总共11 个。可你按下回车之后，它吐出的是 **802 个目标文件、46 个静态库、一个约 8.6 MB 的 **.elf。从 11 个源文件到 802 个目标文件，中间那一大段，就是这一篇要讲清楚的东西。读完你会拿到这样几样东西：知道要装什么、launch.bat。

2026-10-28 11:01:20 325

原创【EB Tresos 项目实战 02】一个工程 90% 的代码你不写——配置驱动开发思维

第 1 篇我们把工程"解剖"了一遍，知道了每一层归谁管。这一篇要回答一个更扎心的问题：这份工程能编译出约 8.6 MB 的.elf，能跑 CAN 通信、能跑 UDS 诊断、能跑网络管理。可你打开源码目录会发现，**10 个任务体里只有一句 **。那剩下的代码，是谁写的？一眼看出哪部分该"配"、哪部分该"写"的判断力。这正是 AUTOSAR 开发与传统单片机开发的区别所在。手写代码source/目录下的.c.h文件，**排除 **，含空行与注释。生成代码下的.c.h文件，含空行与注释。

2026-10-27 09:39:46 232

原创【EB Tresos 项目实战 01】AUTOSAR 工程为什么长这样——五层架构与目录解剖

AUTOSAR Classic 是分层的，从上到下是「应用层 → RTE → 服务层 → ECU 抽象层 → MCAL」，每一层只能调用自己下面那层。分层不只是画在 PPT 上的，它决定了你工程里每个文件夹归谁管、每份配置放在哪个.xdm里。看懂目录，比看懂代码更快——因为 AUTOSAR 工程里绝大多数的代码不是你写的，是你"配"出来的。把你面前这个工程"解剖"开，让你知道每一块是什么、为什么在那儿。

2026-10-26 13:15:14 375

原创 AUTOSAR OS 模块详解（十四）OS-Application基础：软件组件隔离与生命周期管理

根据 AUTOSAR SWS_OS 规范，OS-Application 是功能相关的 OS 对象的可配置集合，是 AUTOSAR OS 中实现故障隔离和权限管控的基本单元。规定：操作系统模块应支持 OS-Application。任务（Tasks）中断服务程序（Category 2 ISRs）计数器（Counters）闹钟（Alarms）调度表（Schedule Tables）可信函数（Trusted Functions）应用钩子（Application Hooks）注意。

2026-02-12 09:31:45 1307

原创 AUTOSAR OS 模块详解（十三）服务保护与硬件保护：系统级安全防护机制

本文介绍了AUTOSAR多核系统中的服务保护与硬件保护机制，这是系统级安全防护的最后一道防线。服务保护通过参数校验、上下文检查和权限控制三层机制，防止非法OS服务调用破坏系统完整性。硬件保护利用特权模式与非特权模式分离，防止非可信应用直接访问关键硬件资源。文章详细阐述了服务保护的三层检查机制、特权模式原理、控制寄存器保护措施以及硬件异常处理方法，并对比了可信应用与非可信应用的区别。这些机制共同保障了多核系统中OS服务和硬件资源的安全访问。

2026-02-11 13:32:26 1129

原创 AUTOSAR OS 模块详解（十二）时序保护机制：任务执行时间监控与超时处理

多核AUTOSAR系统中的时序保护机制面临独特挑战，主要包括跨核时序故障传播、独立监控与全局协调等问题。AUTOSAR提供OS级别和应用层双重保护机制：OS级别通过执行时间、锁定时间和到达间隔监控确保任务/ISR满足时序约束；应用层通过Watchdog Manager实现程序流监护。在多核环境下，执行时间保护需考虑跨核通信时间，锁定时间保护需特别处理自旋锁问题。这些机制共同保障了系统的时序安全性和实时性。

2026-02-10 16:30:04 1120

原创 AUTOSAR OS 模块详解（十一）内存保护机制：MMU配置与内存区域隔离

本文探讨了汽车ECU项目中内存保护机制对功能安全的重要性。根据ISO 26262标准，ASIL-D级别功能需要最高级别的故障检测和隔离。在多核AUTOSAR系统中，内存保护面临共享内存访问控制、代码段部署、外设寄存器访问等挑战。AUTOSAR定义了4种内存保护缩放级别（SC1-SC4），满足不同安全需求，并比较了MMU与MPU的差异。重点介绍了MPU区域划分的基本原则（最小权限、故障隔离、核心隔离和性能优化），以及典型的多核内存区域划分方案，包括按功能域划分的具体示例，为汽车电子系统的安全设计提供参考。

2026-02-06 13:43:21 1167 1

原创 AUTOSAR OS 模块详解（十）任务定位与核心绑定：多核系统中的任务分配策略

本文系统介绍了AUTOSAR多核系统中的任务分配机制。主要内容包括：1）AUTOSAR多核调度采用独立调度策略，各核心独立执行优先级调度；2）任务采用静态绑定方式，通过OS应用间接绑定到特定核心，运行时不可迁移；3）可定位实体（如任务、ISR等）必须完全部署在单个核心上；4）任务分配需平衡负载均衡、减少跨核通信、满足实时性等目标。文章详细阐述了OS应用作为任务绑定的基本单元，并通过配置示例展示了任务和中断的核心绑定实现方式。

2026-01-24 21:54:52 1260

原创 AUTOSAR OS 模块详解（九）多核系统启动与关闭：从单核心到多核心的系统初始化

AUTOSAR多核系统启动机制解析摘要：本文详细分析了AUTOSAR多核系统的启动机制，重点探讨了主从模式、同步点设计等关键技术。多核系统启动面临硬件异步性、资源竞争和时序确定性三大挑战。AUTOSAR采用主核协调、从核激活的主从模式，通过两个同步点确保核心间协调：同步点1实现OS初始化同步，同步点2确保StartupHook执行完成。文章详细解析了主核和从核的启动流程，包括共享资源初始化、核心激活顺序等关键步骤，并介绍了同步点的实现机制。

2026-01-23 22:00:39 1380

原创 AUTOSAR OS 模块详解（八）调度表(ScheduleTables)：时间触发调度的实现

摘要：AUTOSAR调度表的时间触发机制解析本文系统阐述了AUTOSAR OS中调度表(Schedule Table)的核心机制。调度表通过静态定义的到期点序列实现精确时间触发，包含驱动计数器、持续时间、到期点等关键组件。文章详细分析了调度表的状态转换模型，包括启动/停止/同步等生命周期管理，对比了绝对启动与相对启动的特点。同时解析了到期点动作类型（任务激活/事件设置）的执行机制，并提供了工程实践中的配置检查清单，包括时间参数验证、动作约束等关键要点。

2026-01-23 21:37:33 1032

原创 AUTOSAR OS 模块详解（七）多核系统基础：AUTOSAR OS 多核架构与核间通信

摘要：AUTOSAR多核操作系统扩展了单核OSEK/VDX标准，采用"共享配置、独立执行、静态绑定"设计原则，支持多核ECU的并行计算需求。其核心机制包括可定位实体(LE)绑定、独立调度和主从启动模式，通过自旋锁实现跨核互斥。配置时需定义核心ID、绑定OS应用到特定核心，并遵循主核激活从核的启动流程。该系统解决了多核环境下的同步、资源竞争等问题，但要求设计阶段做好负载平衡，且不支持运行时任务迁移。典型应用场景包括汽车域控制器等对实时性要求高的嵌入式系统。

2026-01-22 21:34:10 2019

原创 AUTOSAR OS 模块详解（六）事件管理机制：AUTOSAR OS 中事件的注册、触发与等待策略

摘要：AUTOSAR OS 的事件机制是实现事件驱动架构的关键，通过轻量级二进制信号实现任务间异步通信。扩展任务通过事件标志位实现同步与协作，具有极小的开销和高效的实时性。本文详细解析了事件管理模型、触发机制和等待策略，包括核心API（SetEvent、WaitEvent、GetEvent、ClearEvent）的使用方法，以及多事件处理、状态机实现等典型应用场景。同时总结了工程实践中常见错误的解决方案，为汽车电子ECU开发提供重要参考。

2026-01-22 15:40:03 1316

原创 AUTOSAR OS 模块详解（五）资源管理与同步：如何避免 AUTOSAR 系统中的资源竞争与死锁

AUTOSAR Resource机制通过优先级天花板协议(PCP)解决实时系统中的并发控制问题，有效避免优先级反转和死锁。该机制提供三种资源类型：标准资源、链接资源和内部资源，通过静态配置和运行时优先级管理确保系统可靠性。关键设计包括：资源获取时立即提升任务优先级至天花板优先级、严格遵循LIFO释放顺序、ISR访问限制等。

2026-01-16 08:51:55 1110

原创 AUTOSAR OS 模块详解（四） Counter 机制的真实作用深度解析

摘要：AUTOSAR OS中的Counter机制是时间驱动架构的核心，分为Hardware和Software两种类型。Hardware Counter按需中断效率高，适用于精确时间控制；Software Counter实现简单但中断频繁。文章详细解析了Counter的设计原理、与Timer/Alarm的协作关系、JobQueue机制及Tick分辨率配置原则，并总结了多核同步、溢出处理等常见工程陷阱。通过合理配置Counter类型和Tick分辨率，可显著提升系统实时性和可靠性，为AUTOSAR时间管理奠定基础

2026-01-15 20:51:42 1106

813270556的博客