CPU 时间与栈空间是嵌入式软件的两项基础资源。CPU Load描述一个核在窗口内的工作比例，Stack Measurement 则记录任务、中断和系统执行路径对栈空间的历史需求。把两类指标放在一起，可以同时观察执行预算与内存裕度。
本文从栈的基本模型讲起，介绍 Stack Painting 和 High-Water Mark，再连接边界监控、TC397/AUTOSAR 接入与开源实现。配套的 Stack Observer 已完成 Host 测试；目标平台的编译、调用权限和硬件对照分别验证。
通用测量核心与 ECU 工程之间的连接集中在平台适配层：它识别实际执行者，读取 STM 时间，形成串行事件，并把统计副本交给报告路径。
对于 TC397 与 AUTOSAR，可以按“Host 模型 → 时间源 → 调度和中断边界 → 周期采样 → 多核发布 → 目标验证”的顺序完成接入。各步骤分别建立一项明确的契约，组合后得到可解释的每核时间账本。
本文使用配套模块中的独立 Hook 模型讲解接口。C99 核心与 Mock 示例已通过 Host 验证；具体 MICROSAR/TASKING/TC397 接入处于 Experimental / Unverified，目标参数和实际 Hook 顺序由工程配置确定。
CPU 负载描述一个核在统计窗口内用于执行工作的时间比例。把任务调度与中断处理放到同一条时间线上，就能同时解释负载百分比、任务占用和 ISR 开销。
以 100 ms 为例：Task 执行 20 ms，ISR 执行 10 ms，Idle 执行 70 ms，CPU Load 为 30%。这里的关键是将每段物理时间分配给它的实际执行者，再在统一窗口内汇总。
运行时测量可以分成三个职责：平台产生执行事件，核心维护时间归属，报告路径输出统计结果。显式的分工使同一个算法可以在 PC、裸机和 RTOS 环境中运行。
embedded-runtime-observer 采用 C99 和静态内存实现这一模型。Task、Idle、ISR、调度空档和函数点共用明确的事件边界，在线统计与可选 Trace 各自保留输出状态。v0.2.0 增加独立 Stack Observer，将栈内存需求接入同一报告层。
本文承接时间模型，沿着事件进入核心后的处理过程介绍框架设计。
多核嵌入式开发里有一种容易产生误判的现象：共享变量放在 NonCached RAM，读写都是简单赋值，两边也都进入了 SchM Exclusive Area，但事件队列和业务状态仍可能不一致。
这里不需要先假设硬件缓存出错。更值得追问的是：
“事件已发布”与“事件对应的数据已就绪”，是不是同一个不可分割的状态转换？
本文以 AUTOSAR Classic COM 的一种 Deferred Rx + EventCache 实现为例，借助一个可构造的双核交错，讨论缓存可见性、原子性、内存顺序与跨核互斥之间的区别，以及事件驱动系统该怎样维护状态不变量。
文中的代码是根据实际函数关系抽象的示意性伪代码，不是 AUTOSAR 对所有 COM 实现的统一规定。具体项目还应遵循所使用组件的多核部署和并发访问约束。
在嵌入式工程里，经常会遇到两种静态库场景：
.a，交给其他团队或第三方集成；.a，再链接进自己的 ECU 工程。两种场景其实是同一条构建链的两端。
本文结合 TC397 + TASKING + AUTOSAR Classic 工程，完整梳理：
.c
│
│ Compile
▼
.o
│
│ Archive
▼
.a
│
│ Link
▼
ELF
│
▼
HEX / ECU重点不是某一个具体库，而是理解 Compile、Archive、Link 三个阶段分别做了什么，以及一个嵌入式静态库真正要能够被第三方使用，需要满足哪些条件。
C 语言没有 C++ 那样的 class、继承和虚函数，但在操作系统、驱动、AUTOSAR、Linux 内核等底层软件中，经常可以看到一种很成熟的写法：
把“基类结构体”嵌入“派生结构体”，再通过基类指针复用公共逻辑；需要具体能力时，再受控地恢复为派生类型。
这种模式可以理解为 C 语言中的组合式继承（struct embedding）+ 类型擦除（type erasure）+ 运行时类型恢复。
在 AUTOSAR BSW 调试过程中，经常需要从 C 代码定位到实际执行的汇编指令。本文以 Vector SOME/IP Service Discovery 模块中的局部变量初始化为例，说明如何分析 TriCore 汇编、栈帧以及变量地址映射。
源码：
uint8 errorId = SD_E_NO_ERROR;《炒股的智慧》读书笔记
本文主要总结设计模式这本书，并用c语言简单举例