即使没有来自 RedHawk-IDE 的请求，如何不停止 RedHawk 处理

Question

我使用Red Hawk v2.1.0实现了三组件的AM解调部分。

Platform            --> Xilinx Zynq 7035 (ARM Coretex A9*2) 
Oparating System(OS)--> embedded Linux.

将外部PC上的RedHawk-IDE与Ether连接并显示组件之间的波形时，出现异常声音。 这时，当我断开网线时，ARM 内部 Red Hawk 的 AM 解调处理将停止。 ARM 内部的 RedHawk 似乎正在等待来自外部 PC 上 RedHawk-IDE 的请求。 由此看来，当外部PC上RedHawk-IDE的请求延迟时，似乎会出现异常噪音。 如何在连接外部 PC 的 RedHawk-IDE 并监控波形的同时保持 ARM 内部的 RedHawk 的 AM 解调处理运行而不停止？ 环境如下。 CPU：Xilinx Zynq ARM CoretexA9 2cores 600MHz 操作系统：嵌入式Linux Kernel 3.14 RealTimePatch FrameLength：5.333ms（48kHz采样，256条数据）

Answer 1

在 ARM 板上运行时，我看到了类似的问题，如果不是完全相同的话。追踪确切的问题可能很困难，而且根据我的经验，这并不是特定于 redhawk 的，并且确实是 omniORB 或其配置的问题。我相信对我来说的修复之一是重新编译omniORB，而不是使用我的操作系统提供的omniORB 包。 （当时这对我来说没有任何意义，因为我使用了与包维护者相同的标志和构建过程）

首先我要确认这个问题是 ARM 特有的。如果在第二台 x86_64 主机上设置相同的组件、波形等很容易并验证问题不会发生。

其次，我会尝试使用 /etc/omniORB.cfg 文件和设置在 arm 主机上设置 omniORB 超时的“快速修复”：

clientCallTimeOutPeriod = 2000
clientConnectTimeOutPeriod = 2000

这将为连接部分和调用完成部分的 CORBA 交互设置 2 秒超时。在过去，这对我来说是一种快速解决方案，但没有解决根本问题。如果这为您“修复”了它，那么您至少已经缩小了部分问题的范围，您可以使用 traceLevel 配置选项启用omniORB 调试，以查找什么调用超时。见this sample configuration file for all options

如果您想深入了解潜在问题，您需要了解当事情锁定时 IDE 和框架在做什么。使用 IDE，这很容易；只需找到 j​​ava 进程的 PID 并运行kill -3 <pid>，就会在运行 IDE 的终端中打印完整的堆栈跟踪。这可以为您提供有关哪些呼叫被锁定的提示。对于框架，您需要使用 GDB 并连接到有问题的进程并告诉 GDB 打印堆栈跟踪。您必须提前进行一些调查以确定哪个进程被锁定。

如果最终导致 x86_64 上的 Java CORBA 实现与 ARM 上的 C++ CORBA 实现发生问题，您还可以尝试通过 x86_64 主机上的 REDHAWK python API 启动/配置/与 ARM 板交互。这可能具有更好的兼容性，因为它们都使用相同的omniORB CORBA 实现。