2

我在嵌入式 Linux 环境中工作，调试与 Zigbee 设备配对/绑定相关的高度时序敏感问题。

我们的架构是通过 SPI 接口从 Zigbee 前端模块读取数据，然后从内核空间传递到用户空间进行处理。处理后的数据和响应随后被传回内核空间并再次通过 SPI 接口输出。

Zigbee 802.15.4 时序要求规定我们需要在 19.5 毫秒内做出响应，并且我们经常会在此窗口之外做出响应，这会导致网络出现故障和丢包。

Linux 内核未在启用抢占的情况下运行，也可能无法启用抢占。
我的怀疑是，由于内核不可抢占，还有另一个任务/进程正在使用 ioctl() 接口，这会使 Zigbee 应用程序延迟足够长的时间，以至于超过 19.5 毫秒的窗口。

我尝试了以下工具

  • oprofile - 这里没有太大帮助，因为它分析了整个系统，并且应用程序在这段时间内实际上并不是很忙，因为它移动了如此少量的数据
  • strace - 开销太大，虽然我没有太多使用它的经验，所以也许可以改进输出。开销对性能的影响如此之大，以至于应用程序根本无法运行

有没有其他轻量级的方法来分析这样的系统？

当 ioctl 调用挂起在另一个任务/线程上时，无论如何要捕获吗？（假设这是问题的根本原因）

4

2 回答 2

1

好问题。这是一个想法。不要将其视为剖析。想想在行动中抓住它。

我将研究创建一个看门狗定时器，以在 16.5 毫秒间隔后关闭。每当你成功时，重置计时器。这样，它只会在出现故障时熄灭。那时，我会尝试获取进程的堆栈样本，或者可能是另一个可能阻塞它的进程。

这是对这种技术的改编。这将需要一些工作，但如果有任何工具可以准确地告诉你发生了什么，我会感到惊讶，而不是在线仿真器。

于 2014-08-12T19:04:17.960 回答
0

LTTng 是您正在寻找的工具。与 Oprofile 一样，它对整个系统进行概要分析，但您将能够以时间线的方式准确查看每个进程和内核线程的情况。您将能够在兴趣点周围查看线程和调度程序的交互，即当您错过 Zigbee 截止日期时。一旦检测到丢失的数据包，您可能必须变得聪明并使用某种触发（或更可能是停止）LTTng 跟踪的方法，或者您可能很幸运，只需使用命令行工具启动并立即捕获它停止追踪。

您可能需要做一些工作才能到达那里，例如，您必须投入一些时间和精力来 1) 使您的内核能够运行 LTTng（如果它还没有的话），以及 2) 学习如何使用它。它是一个强大的工具，可用于各种分析和分析任务。大多数商业嵌入式 Linux 供应商都有完整的端到端 LTTng 产品和配置，如果您有该选项的话。如果没有，您应该能够在线找到大量有用的帮助和示例。LTTng 已经存在很长时间了！狩猎愉快！

于 2014-08-14T12:44:52.737 回答