专用工具为调试基于RTOS的系统设计

死锁：

死锁（又名致命拥抱）是一种情况，其中（至少）两个任务都在不知不觉中等待另一个拥有的资源。死锁可能不会立即发生，因为很大程度上取决于两个任务何时需要彼此的资源。如下图所示，μC/Probe 的内核感知屏幕有一列显示每个任务执行的频率（即任务由 RTOS 切换的频率）。您可以通过监视此列来检测死锁，并注意您期望运行的任何任务是否实际上正在运行。换句话说，如果计数停止（μC/Probe 在 CPU 运行时更新这些计数器），那么您可能检测到死锁。但是，对于这种情况，您还会注意到至少有两个任务停止计数。您可能不需要使用像 μC/Probe 这样的工具来检测死锁，因为在任何情况下，您都应该注意应用程序中这些任务的锁定行为。但是，该工具使其更加明显。

您可以通过以下方式避免死锁：

总是获取所有需要的资源，总是以相同的顺序获取它们并以相反的顺序释放它们。

在 RTOS API 调用上使用超时以避免永远等待资源可用。确保检查来自 RTOS API 的返回错误代码，以确保您对所需资源的请求确实成功。

饥饿：

当高优先级任务消耗所有 CPU 的带宽时，就会发生饥饿，为低优先级任务留下很少或没有 CPU 时间。饥饿的影响的特点是响应能力和产品功能的下降，例如嵌入式目标的显示更新缓慢、通信堆栈中的数据包丢失、操作员界面迟缓等。除了解决这些问题之外，您几乎无能为力至：

优化占用大部分 CPU 带宽的代码。

提高 CPU 的时钟速度。由于其他系统考虑，这很少是一种选择。

选择另一个 CPU。这也很少是一种选择，尤其是在开发周期的后期。

监控任务和 ISR 执行时间

了解任务和 ISR 的执行时间对于帮助基于 RTOS 的系统分析（例如速率单调分析 （RMA））通常很有用。具体来说，通过这些信息，您可以确定是否所有时间紧迫的任务都可以按时完成，并帮助您为任务分配优先级。不幸的是，这些信息只有在系统设计和运行后才真正准确和可用。换句话说，代码的实际执行时间通常要在实际目标上执行时才能准确知道。然而，一旦可用，任务和 ISR 执行时间对于确认系统设计期间所做的假设非常有用。

SystemView 提供任务和 ISR 的最小/最大执行时间，如下面的屏幕截图所示。

1 -上下文窗格中 的Max Run Time列显示所有任务和 ISR 的最大执行时间。在SysTick（即tick ISR）的情况下，最长的执行时间是0.5488 ms。我们可以通过搜索事件 #4016155 来确定何时（及时）发生了这个较长的执行时间。您只需从 Go 菜单中选择 Go to event 。.. 并键入 4016155，然后按 Enter。

2 - 事件窗口显示这对应于 ISR 出口。事实上，这是有道理的，因为只有在 ISR 退出时才知道 ISR 的最大执行时间。

3 - 双击事件窗口中显示事件 #4016155 的行会强制时间轴窗口显示该事件。可以看出，SysTick 的执行时间比其他执行时间要宽。

在大多数情况下，您不需要找到（及时）任务或 ISR 的最大执行时间发生在哪里，尤其是当您仅将该信息用于 RMA 时。但是，在某些情况下，您可能需要找出执行时间比预期或预期长得多的原因。不幸的是，SystemView 可能无法提供关于发生这种情况的原因的额外线索。您可能希望在此处使用代码执行跟踪工具（例如 Segger 的 J-Trace）并检查 ISR 在事件 #4016155 之前执行的代码。

测量用户代码的执行时间

有很多方法可以测量代码执行时间。一种方法是使用具有跟踪功能的调试探针。您只需运行代码、查看跟踪、计算增量时间（通常是手动）并将 CPU 周期转换为微秒。不幸的是，跟踪为您提供了一个执行实例，您可能需要进一步查看跟踪捕获以找到最坏情况下的执行时间。这可能是一个乏味的过程。另一种方法是检测您的代码并在代码的不同位置拍摄可用的自由运行计数器的快照，并计算快照读数之间的差异。这实际上在嵌入式计算设计［7］上发表的一篇论文中有所描述对于 Cortex-M MCU，但该概念同样适用于其他目标。该论文提供了 API 来测量经过的时间。您只需将要测量的代码包装如下：

elapsed_time_start（n）;

// 测量代码

elapsed_time_stop（n）;

其中“n”指定“n”个 bin（0 到 n-1）之一，其中最小和最大执行时间保存如下：

elapsed_time_tbl［n］.min

elapsed_time_tbl［n］.max

在 Cortex-M 的情况下，执行时间以 CPU 时钟频率单位保存。

如下图所示，您可以使用 Micrium 的 μC/Probe 轻松显示以微秒为单位的结果。μC/Probe 允许对数字进行缩放，在这种情况下，需要根据所用评估板的 CPU 时钟频率进行调整。

概括

IDE 中内置的调试器通常不足以调试基于 RTOS 的实时系统。

幸运的是，有专门为调试基于 RTOS 的系统而设计的专用工具，但开发人员通常不知道这些工具。这些工具之一是 Segger 的 SystemView ，它在时间线上显示 ISR 和任务，并收集运行时统计信息，例如最小和最大执行时间、ISR 和任务之间的关系、CPU 负载等等。

另一个可以补充 SystemView 的工具是 Micrium 的 μC/Probe ，它是一种通用工具，允许开发人员在不干扰 CPU 的情况下可视化和更改正在运行的嵌入式目标的行为。μC/Probe 在裸机或基于 RTOS 的应用中同样适用。对于基于 RTOS 的应用程序，μC/Probe 包括非侵入式实时内核感知以及 TCP/IP 堆栈感知。两种类型的工具（SystemView 和 μC/Probe）都应该在早期和整个开发周期中使用，以提供有关嵌入式目标运行时行为的反馈。

审核编辑：郭婷