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 回答