4. SystemView实时系统可视化
SystemView 是 SEGGER 提供的实时系统行为可视化工具，它通过目标端的一小段记录代码（RTT 通道）把 RTOS 内核事件、中断进入/退出、API 调用等带时间戳地送到主机端，再由 PC 端软件还原成时间轴。与单纯看串口打印日志不同，SystemView 的价值在于“时间关系”：任务何时被唤醒、何时被抢占、中断打断了谁、谁在等谁、CPU 到底忙在什么地方。本节围绕事件记录、任务切换与中断时序、CPU 负载与堆栈使用率四条主线展开。
一、事件记录：SystemView 的数据来源
SystemView 的记录能力来自两部分：一是 RTOS 适配层（如 FreeRTOS 的 SEGGER_SYSVIEW_FreeRTOS.c），它把内核的调度、队列、信号量、定时器等 API 挂钩到 SystemView 事件；二是用户自定义事件，通过 SEGGER_SYSVIEW_RecordXXX 系列 API 手动埋点。记录通道默认走 RTT，因此不需要额外串口，也不明显影响实时性。
关键配置项包括：SEGGER_SYSVIEW_Conf.h 中的 SEGGER_SYSVIEW_RTT_CHANNEL（RTT 通道号，需与 RTT 控制块一致）、SEGGER_SYSVIEW_CPU_FREQ（CPU 主频，用于把时间戳换算成微秒）、SEGGER_SYSVIEW_TIMESTAMP_FREQ（时间戳计数频率，通常等于 CPU 频率或 SysTick 频率）。若时间戳频率填错，时间轴会被整体拉伸或压缩，任务周期看起来“不对”，这是最常见的配置错误之一。
记录缓冲区大小由 SEGGER_SYSVIEW_RTT_BUFFER_SIZE 决定，默认 1024 字节。事件密集时（例如高频中断 + 多任务切换）缓冲区会溢出，SystemView 会显示 “Event buffer overflow” 或时间轴出现断档。此时应增大缓冲区，或降低记录粒度（关闭部分内核对象记录）。
二、任务切换与中断时序图
SystemView 的时间轴以“行”组织：每个任务一行，中断一行，空闲任务一行。任务处于 Running 时该行显示为实心色块，Ready 为浅色，Blocked/Suspended 为空白。中断行在 ISR 执行期间显示为窄色块，并叠加在被它打断的任务行之上，从而直观看出“中断打断了哪个任务、持续多久、返回后调度器是否切换”。
下面这张图给出一个典型的三任务 + 一个定时器中断的时序关系示意：任务 A 运行中被 SysTick 中断打断，ISR 中释放信号量唤醒了任务 B，退出中断后调度器发现 B 优先级更高，于是发生抢占切换。
读图要点：t1 时刻 SysTick 进入，任务 A 被打断；t2 时刻 ISR 内释放信号量，任务 B 由 Blocked 变为 Ready；ISR 退出后，调度器比较优先级，B 高于 A，于是 t2 之后 B 立即运行，A 退回 Ready。若图中出现“A 在 B 就绪后仍继续运行”，说明优先级配置或临界区屏蔽了调度，是典型的实时性缺陷。
三、CPU 负载分析
SystemView 的 CPU Load 视图基于“空闲任务运行时间占比”反推：CPU 负载 ≈ 1 − 空闲时间 / 统计窗口。它给出的是平均值，窗口可调（例如 100 ms）。判断标准不是“越低越好”，而是看是否留有余量：若峰值负载长期高于 80%，一旦出现突发中断或高优先级任务抖动，就可能错过截止时间。
更实用的做法是结合时间轴看“负载来自哪里”。例如负载 65%，但其中 40% 来自一个 1 kHz 的定时器中断，那么优化方向就是降低该中断频率或把 ISR 中的耗时处理搬到任务里。SystemView 还能显示每个任务的累计运行时间，便于定位“谁吃掉了 CPU”。
四、堆栈使用率分析
堆栈溢出是嵌入式系统最隐蔽的故障之一。SystemView 本身不直接测量堆栈，但 SEGGER 提供了配套的 SEGGER_SYSVIEW_EnableStackCheck() 与 RTOS 的堆栈填充机制（如 FreeRTOS 的 configCHECK_FOR_STACK_OVERFLOW 配合 uxTaskGetStackHighWaterMark()）。常见做法是在任务创建时用固定模式（如 0xA5）填充堆栈，运行一段时间后统计未被覆盖的字节数，得到“高水位线”。
使用率 = (分配栈大小 − 剩余未用字节) / 分配栈大小。工程上建议保留 20%～30% 余量，因为最坏路径（深层嵌套中断 + 递归 + 浮点保存）往往在压力测试时才出现。若某任务使用率超过 85%，应优先增大其栈，而不是简单调大全局堆。
五、一次典型排查流程
假设现象是“设备偶发响应延迟”。可按以下顺序使用 SystemView：
- 先看 CPU Load 曲线，确认延迟发生时负载是否飙升；
- 再看时间轴，定位延迟区间内哪个中断或任务在运行；
- 检查该中断的 ISR 时长，若超过预期，说明 ISR 内做了耗时操作；
- 检查被延迟任务的优先级与就绪时间，确认是否存在优先级反转；
- 最后核对相关任务的堆栈高水位，排除栈溢出导致的异常跳转。
整个过程的关键是“用时间轴对齐现象”。SystemView 允许在时间轴上打标记（Marker），把外部事件（如 GPIO 翻转、串口收到命令）与内部调度对齐，从而把“偶发”变成“可复现的时间关系”。
综上，SystemView 不是“看日志”的工具，而是把 RTOS 的调度决策、中断行为和资源占用放到同一时间轴上对照。掌握事件记录配置、时序图读法、CPU 负载与堆栈高水位四项技能，就能把多数实时性问题从“猜”变成“看”。