我在嵌入式Linux环境中工作,调试与Zigbee设备的配对/绑定相关的高度时序敏感问题。
我们的架构是通过SPI接口从Zigbee前端模块读取数据,然后从内核空间传递到用户空间进行处理。然后,处理后的数据和响应将传回内核空间,并再次通过SPI接口进行计时。
Zigbee 802.15.4时序要求规定我们需要在19.5ms内做出响应,并且我们经常遇到这样的情况,即我们在此窗口之外做出响应,导致网络出现故障和数据包丢失。
Linux内核没有启用抢先运行,也可能无法启用抢占。
我怀疑是因为内核不可抢占,所以还有另一个任务/进程正在使用ioctl()接口,这使Zigbee应用程序保持足够长的时间,超过了19.5ms的窗口。
我尝试过以下工具
是否还有其他轻量级方法来分析这样的系统?
当ioctl调用挂在另一个任务/线程上时,无论如何都要捕获? (假设这是问题的根本原因)
答案 0 :(得分:1)
好问题。 这是一个想法。不要把它想象为剖析。 想想在行动中抓住它。
我会调查创建一个看门狗定时器,在16.5ms间隔后关闭。 只要成功,请重置计时器。 这样,它只会在出现故障时才会消失。 那时,我会尝试获取进程的堆栈样本,或者可能阻止它的另一个进程。
这是this technique的改编。 这需要一些工作,但是如果有任何工具可以告诉你究竟发生了什么,那么我会感到惊讶。缺少在线模拟器。
答案 1 :(得分:0)
LTTng是您正在寻找的工具。与Oprofile一样,它描述整个系统,但您将能够以时间轴的方式查看每个进程和内核线程的具体内容。您将能够在感兴趣的点周围查看线程和调度程序的交互,也就是说,当您错过Zigbee截止日期时。一旦检测到丢失的数据包,您可能必须聪明并使用一些触发(或更可能停止)LTTng跟踪的方法,或者您可能会很幸运并立即使用命令行工具启动并立即捕获它停止追踪。
你可能需要做一些工作才能到达那里,例如你必须投入一些时间和精力1)使你的内核能够运行LTTng,如果它还没有它,2)学习如何用它。它是一个功能强大的工具,适用于各种分析和分析任务。如果您有这种选择,大多数商业嵌入式Linux供应商都有完整的端到端LTTng产品和配置。如果没有,您应该能够在线找到大量有用的帮助和示例。 LTTng已经存在了很长时间!快乐狩猎!