多线程RTOS应用程序的五个最佳实践

多线程 RTOS 应用程序的一个更被低估的方面是您不能只查看代码来完全了解应用程序的工作原理。

你需要知道它的各个部分是如何相互通信的，并且你需要很多其他信息：任务执行需要多长时间，是否有任何潜在的竞争条件或死锁，你是否满足你的时间要求等等。

您希望代码做什么和它实际做什么可能在许多方面有所不同，这些方面既难以在代码中看到，也难以测试。这对所有使用多线程代码的开发人员来说都是一个挑战，无论他们使用的是 RTOS 还是 Linux，最好使用可视化跟踪诊断工具进行管理，让您深入了解我所说的代码的“黑暗面”——您可以从字面上理解看看它在执行时的行为。

视觉时间线是一个很好的起点。在许多情况下，查看随时间分布的软件事件、消息和任务执行很重要，例如当错误的精确位置从症状中不明显时——计算机可能在数字处理和文本日志中搜索方面表现出色，但通常你不知道要搜索什么。在视觉模式识别方面，人脑表现出色。

显示软件事件的可视化时间线可以让您大致了解嵌入式应用程序的内部工作原理，如果您需要深入挖掘以查找错误，这是一个很好的起点。

调试时更好的洞察力意味着将有更少的猜测，并且更有可能找到根本原因。在无法使用传统方法（如在断点处暂停系统）的情况下，它也是一个很大的帮助。

你说 printf 调试怎么样？是的，printf 很容易部署，有时它确实是你所需要的，但它的价格很高。将调试打印输出放在对时间敏感的应用程序代码中是有风险的，并且不能很好地扩展到更复杂的应用程序和更快的处理器。此外， printf 通常非常慢，每次打印输出大约为几毫秒。相比之下，针对软件事件跟踪的优化解决方案可以比这快大约 100 倍，允许您在同一时期收集更多信息。

确保在整个开发项目中测量时间和性能。做得对，这可以确保您可以在开发过程中发现并解决任何问题，而不是在承诺的交付日期之前与时间赛跑。

满足时序规范对于具有严格要求的实时系统至关重要，但对于几乎所有嵌入式系统的用户体验也很重要。没有人喜欢迟缓的触摸屏或无法提供承诺吞吐量的慢速 wifi 路由器。同样，根本原因从源代码中可能并不明显，如果真正的问题是糟糕的软件设计，那么简单地切换到更快的处理器可能没有任何好处。

如果你发现自己在一个项目中“调试地狱”，大量的调试会消耗房间里的所有能量并阻止项目向前推进，那么视觉跟踪诊断可以帮助你。在基于 RTOS 的应用程序的软件设计中未能遵循最佳实践通常是一个主要的促成因素，并且它可能以例如性能差、处理器负载高或瞬态错误的形式出现。任务之间的大量依赖是另一个可以改进设计的常见信号。

即使是架构糟糕的系统也可能在今天运行，但它们将具有复杂和混乱的行为以及较差的可测试性，这增加了泄漏到生产设备中的难以捉摸的错误的风险。而且它们几乎肯定会很脆弱，因此代码或环境中的微小变化都会导致它们失败。

可视化跟踪诊断帮助开发人员分析和改进他们的软件设计，确保系统行为稳定可靠。当您可以更早地发现软件设计缺陷时，修复它们所需的更改就会更少。设计改进还可以带来更好的系统性能和响应能力，这反过来又可以让您选择更具成本效益的处理器来降低 BoM 成本或使用更低的时钟频率来延长电池寿命。

使用您的跟踪工具将跟踪数据连续流式传输到主机，如果需要，您可以在其中存储很长的记录，甚至在屏幕上实时显示数据。跟踪流使您能够监控系统测试或寻找难以重现的罕见错误。视觉跟踪诊断允许在高级视觉概览中发现异常并深入到特定事件以准确找出发生了什么。

最后，可视化跟踪诊断可以实现为纯软件解决方案，不需要额外的硬件，甚至不需要调试探针。在内存和处理器使用方面存在成本，但通常不会超过您可以在整个开发、测试甚至部署过程中将其保留在系统中（如果您愿意）。在所有阶段都能获得这些信息意味着每个人每天都能从中受益。

这种方法允许记录来自应用程序的任何相关信息，包括在运行时未公开的内部数据和状态。数据可以与可视化执行时间线并行绘制，以便在运行时深入了解您的应用程序。这样，您就可以制作出能够击败竞争对手的出色产品。

遵循这五个最佳实践，在系统级别获得对实时行为所需的可见性，以提高产品质量并加快开发速度，从而更快地进入市场。

审核编辑：郭婷