1. 课程导入与SystemView定位

在嵌入式系统开发中，功能正确只是最低要求。一个电机控制任务能否在 100 μs 内完成电流环计算、一个蓝牙协议栈是否会在中断密集时丢包、一段音频处理代码有没有因为优先级反转而出现爆音——这些问题往往不会在单步调试中暴露，却会在真实运行时集中出现。实时性能分析要回答的，正是这类问题：系统在真实时间约束下，究竟把时间花在了哪里，又是谁在什么时候抢占了谁。

传统调试手段各有边界。断点会暂停整个系统，破坏时序关系；printf 通过串口输出，本身耗时可达几十微秒到毫秒级，足以掩盖被观测的抖动；示波器擅长看引脚电平、PWM 占空比、SPI 时钟等物理信号，但无法直接告诉你"当前运行的是哪个任务"；逻辑分析仪能抓取多路数字信号并做协议解码，却看不到 RTOS 内部的调度决策和任务状态迁移。SystemView 补上的正是这块空白：它以软件事件为记录对象，把任务切换、中断进入/退出、API 调用、用户自定义事件按时间轴还原出来，形成一张可缩放的系统行为时间线。

从图中可以看出，SystemView 的观测链路是"目标系统 → RTT 上行 → 调试探针 → 上位机"。它不占用 UART，不需要额外引脚，通过 J-Link 的 RTT（Real Time Transfer）通道把事件数据送到 PC 端。这意味着它可以在不停止 CPU、不改变任务时序的前提下持续记录，这是它区别于断点和 printf 的根本优势。

SystemView 在嵌入式开发中的角色

SystemView 的定位可以概括为"RTOS 级的时间显微镜"。它不替代示波器，也不替代调试器，而是与它们形成互补：示波器看"电信号在引脚上怎么变"，SystemView 看"软件在 CPU 上怎么跑"。两者结合，才能同时掌握物理层和调度层的完整信息。

具体来说，SystemView 能回答以下几类问题：

• 任务调度是否合理：哪个任务占用了最多 CPU 时间？是否存在低优先级任务长期得不到调度的情况？
• 中断响应是否及时：从中断触发到 ISR 第一条指令执行，延迟是多少？ISR 执行时间是否超出预期？
• 阻塞与唤醒是否符合设计：任务在等待信号量、队列、延时时的状态迁移是否与预期一致？
• CPU 负载是否安全：系统在峰值负载下是否还有余量？是否存在周期性抖动？

以一个典型的电机控制场景为例：FOC 电流环运行在 20 kHz PWM 中断中，速度环运行在 1 kHz 任务中，通信任务负责 CAN 报文收发。如果电流环偶尔超时，用示波器只能看到 PWM 输出异常，但无法判断是 ISR 本身太长，还是被更高优先级中断抢占。SystemView 的时间线会直接显示：电流环 ISR 被 CAN 接收中断打断，且 CAN ISR 执行了 8 μs，导致电流环实际执行时间从 5 μs 拉长到 13 μs，超过了 10 μs 的预算。这就是从"现象"到"根因"的定位过程。

典型应用场景

SystemView 适用于以下场景：RTOS 任务调度优化、中断延迟与抖动分析、CPU 负载评估、任务间同步机制验证、低功耗模式唤醒时序检查、协议栈实时性验证。它尤其适合那些"功能正常但实时性不达标"的问题——这类问题最难用传统手段定位，因为系统在大部分时间里表现正常，只在特定条件下出现偶发超时。

学习路径

本课程的学习路径按"先建立观测能力，再解读数据，最后优化系统"的顺序展开。首先理解 SystemView 的架构与数据通路，掌握目标端集成与上位机连接方法；然后学会配置事件记录范围、设置时间戳精度、使用过滤与缩放功能；接着通过时间线视图识别任务切换、中断嵌套、阻塞唤醒等关键模式；最后结合 CPU 负载统计和实际案例，完成从数据到决策的闭环。

需要强调的是，SystemView 的价值不在于"看到很多事件"，而在于把事件还原成可解释的系统行为。一条任务切换记录本身没有意义，但当它和中断到达时刻、信号量释放时刻放在同一时间轴上时，就能判断调度是否及时、优先级分配是否合理。这也是本课程后续章节要反复训练的核心能力。