即使沒有來自RedHawk-IDE的請求，如何不停止RedHawk處理

我使用Red Hawk v2.1.0來實現具有三個組件的AM解調部分。即使沒有來自RedHawk-IDE的請求，如何不停止RedHawk處理

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

當與以太外部PC上連接紅鷹-IDE和顯示部件之間的波形，異常聲音發生。此時，當我斷開LAN電纜時，ARM內紅鷹的AM解調處理將停止。 ARM內部的RedHawk似乎在等待來自外部PC上RedHawk-IDE的請求。由此看來，當來自外部PC的RedHawk-IDE的請求延遲時，會出現異常噪音。在連接外部PC的RedHawk-IDE和監控波形時，如何保持ARM內部RedHawk的AM解調處理不停止運行？環境在下面。 CPU：賽靈思ZYNQ ARM CoretexA9 2cores 600MHz的 OS：嵌入式Linux內核3.14 RealTimePatch 幀長：5.333ms（48kHz的採樣，256個數據）

來源

2017-08-10 H.Yoshida

在ARM板上運行時我看到類似的但不相同的問題，。追蹤確切的問題可能是困難的，根據我的經驗，這並不是redhawk的具體問題，而且確實是omniORB或其配置的問題。我相信我的一個修補程序是重新編譯omniORB，而不是使用我的操作系統提供的omniORB軟件包。（當時對我來說沒有任何意義，因爲我用&構建過程作爲包維護者）

首先我會確認這個問題是特定於ARM的。如果在第二臺x86_64主機上安裝相同的組件，波形等並且不會出現問題，則不會發生問題。

其次，我會嘗試設置omniORB的「速戰速決」超時使用/etc/omniORB.cfg文件和設置手臂主機上：

clientCallTimeOutPeriod = 2000 
clientConnectTimeOutPeriod = 2000

這將設置CORBA的交互2秒的超時在connect部分和呼叫完成部分。在過去，這對我來說是一個快速解決方案，但沒有解決潛在的問題。如果這爲您「修復」了它，那麼您至少已經縮小了部分問題的範圍，並且可以使用traceLevel配置選項啓用omniORB調試，以查找哪些調用超時。請參閱this sample configuration file for all options

如果您想深入瞭解潛在問題，您需要查看在鎖定事件時IDE和框架正在執行的操作。使用IDE這很容易;只需找到java進程的PID並運行kill -3 <pid>，並且將在運行IDE的終端中打印完整的堆棧跟蹤。這可以給你提示哪些呼叫被鎖定。對於框架，您需要使用GDB並連接到有問題的進程，並告訴GDB打印堆棧跟蹤。您必須提前做一些調查，以確定哪個進程處於鎖定狀態。

如果它最終成爲x86_64上的Java CORBA實現與ARM上的C++ CORBA實現交談的問題，您還可以嘗試通過x86_64主機上的REDHAWK python API啓動/配置/與ARM板進行交互。這可能會有更好的兼容性，因爲它們都使用相同的omniORB CORBA實現。

來源

2017-08-10 13:43:51

我嘗試更改omniORG.cfg，然後重新啓動omniNames和omniEvents。我們的無線電幀是5.33毫秒，所以我設置了下面的元素。 clientCallTimeOutPeriod = 2 clientConnectTimeOutPeriod = 2 由於調製解調處理已在Radio Frame內完成。但是設備管理器不會啓動。 DomainManager和DeviceManager之間似乎沒有通信。 –

將呼叫超時設置爲2ms太小。按照建議嘗試2000，看看是否有幫助 –

我嘗試更改值2000（2秒）。但是，設置值0（無超時）時沒有變化。我仍然聽到奇怪的聲音。當我用Ftrace檢查進程移動時，它正在等待來自IDE的請求。來自IDE的以太網中斷保持大約5幀，並且它不執行5.33 ms * 5 = 26.6 ms的調制解調器處理。它是在IDE端設置的嗎？ –

即使沒有來自RedHawk-IDE的請求，如何不停止RedHawk處理

回答

相關問題