0 引言

    LFMCW(線性調頻連續波雷達)具有CW雷達發射功率小的特點，更兼有脈沖雷達測距的能力，廣泛應用于導航、測量等領域^[1]。基于多播機制對其組網，可以實現多臺雷達掃描終端與多臺顯示終端同步相連。顯示終端的主要功能包括控制雷達狀態和顯示雷達圖像兩個部分。采用多線程編程，可以讓不同的顯示終端有不同的功能，比如一部分顯示終端只具有顯示雷達圖像的功能，而另一部分顯示終端同時具有控制和顯示兩個功能（這部分顯示終端可以提供給管理員使用）。由于顯示單元是基于單播機制，為了提高顯示單元的可移植性，屏蔽雷達掃描單元和顯示單元通信接口的不同，可以用中間件負責兩部分的通信。

    DM3730是TI公司生產的雙核（ARM+DSP）架構處理器。其低功耗、高性能、低價格的特點深受廣大嵌入式開發者的喜愛。顯示終端基于DM3730平臺，掃描單元發送的雷達數據是極坐標表示，必須通過坐標轉換后才能在終端上正常顯示。由于坐標轉換計算量過大，用ARM處理器實現坐標轉換算法會大大增加系統負擔，并且會產生嚴重的丟包現象。所以將算法實現交給DSP處理。實測發現，經過優化后的ARM處理器CPU使用率大大降低，雷達數據處理過程中再無丟包現象。

1 系統結構

1.1 物理結構

    如圖1所示，雷達掃描單元由雷達天線和FPGA組成。雷達天線負責采集雷達數據，FPGA負責AD采樣，并實現了海雜波抑制、雨雪抑制、海浪抑制等算法。FPGA通過網線將處理好的數據發送至ARM端，ARM端負責將接收到的雷達數據作坐標轉換處理并顯示雷達圖像^[2]。另外，ARM端還負責控制雷達狀態。

1.2 系統邏輯結構

    系統邏輯結構如圖2所示。多播使用D類地址作為IP地址，應用程序可以通過加入一個或者多個多播組，從而僅接收所在多播組的數據^[3]。多播組1～4分別代表雷達控制信息多播組、雷達數據多播組、雷達狀態反饋信息多播組、keepalive多播組。中間件與UI顯示單元的連接方式是單播機制。加入雷達控制信息多播組的成員可以發送控制指令給該多播組的雷達掃描單元，從而控制其狀態。加入雷達數據多播組的成員可以接收到FPGA處理好的雷達數據。加入雷達反饋信息多播組的成員可以接收到雷達自身狀態的反饋信息，比如當前量程、增益等^[4]。反饋系統是為了增強雷達顯示系統的實時性和健壯性。Keepalive多播組比較特殊，雷達掃描單元會定期檢查該多播組有無keepalive指令，如果10 s內沒有收到該指令，則自動關機。所以，中間件必須加入該多播組并不斷發送keepalive指令才能保證雷達持續工作。GPS傳感器和AIS傳感器將采集和處理后的數據發送至串口，中間件從串口搜集這些數據，解析打包后通過socket發送至UI?？梢?，中間件可以選擇加入這幾個多播組的一個或者全部，從而擁有不同的功能組合。在這種邏輯結構下，中間件使得UI顯示單元抽象了所有的數據來源，它只負責接收網絡數據、顯示圖像以及響應鼠標鍵盤事件。

2 中間件功能設計與實現

    中間件是連接兩個獨立應用程序的橋梁。兩個或多個具有不同通信接口的應用程序通過中間件依然可以正常通信。所以，中間件能屏蔽不同的接口，幫助用戶靈活、高效地開發應用程序，并大大提高應用程序的可移植性^[5]，這在嵌入式應用中意義重大。

    基于以上分析，本中間件軟件主要實現5個功能：(1)控制雷達狀態；(2)接收處理雷達掃描數據；(3)接收處理雷達反饋信息；(4)發送keepalive指令；(5)提供其他功能接口，如GPS和AIS。采用多線程編程來實現這些功能。下面重點介紹雷達狀態控制和雷達數據接收處理的實現流程。

2.1 雷達狀態控制

    雷達控制流程如圖3所示。協議1是UI顯示單元和中間件控制命令協議，協議2是中間件與掃描單元控制命令協議。

    ARM端可以將雷達掃描單元視為一個通過網絡控制的移位寄存器組，通過設置這些寄存器就可以改變雷達的狀態。

    雷達控制命令包括開關機、增益調節、量程調節、海雜波抑制調節、雨雪抑制調節、掃描單元轉速等。UI顯示單元通過響應鼠標或觸摸屏事件發送命令給中間件；中間件解析并根據協議2重新合成報文發送至多播組1；掃描單元接收并解析多播組的命令，設置移位寄存器，從而改變雷達運行狀態。

2.2 數據接收處理流程

數據處理流程如圖4所示。其中，協議3為雷達與中間件的數據協議，協議4為中間件與UI顯示單元的數據協議。雷達掃描原始數據預先已經經過FPGA處理，這里的雷達數據是極坐標雷達掃描線數字信號。中間件通過加入多播組2從而接收到完整的掃描數據。由于UI顯示直角坐標數據較為通用和方便，所以中間件一個重要功能是坐標轉換。

2.3 數據處理過程中單核ARM性能的不足

    如圖5所示是FPGA發送至ARM端的雷達數據格式，ns代表線號，a代表掃描線角度。每包雷達數據由32條掃描線構成，每條線536 bit，每包數據17 160 bit，雷達掃描單元轉速V為2.4 s/rad，每一圈數據包含64個包。所以，必須在37 ms內處理完一個數據包，否則將產生丟包現象。實測發現，ARM處理每包的時間是100 ms左右，遠遠未達到要求，并且中間件CPU占有率高達40%，進行雷達控制操作時甚至出現卡頓現象。為了解決丟包問題和降低中間件CPU占有率，將坐標轉換算法實現交給DPS處理是一個非常好的選擇。

3 算法移植

    DM3730微處理器由1 GHz的ARM Cortex-A8 Core和800 MHz的TMS320C64x+ DSP Core兩部分組成，并提供了一整套完整的開發套件。

3.1 內存劃分

    如圖6所示，將物理內存的前120 MB劃分給ARM處理器用于Linux操作系統；CMEM是ARM和DSP用于數據通信的內存區域，大小為10 MB；Dsplink是用于ARM與DSP底層通信的區域，大小為1 MB；Heaps是DSP運行算法時的堆。ARM處理器和DSP處理器共享256 MB內存，ARM端運行Linux操作系統，DSP端運行實時操作系統。ARM端把這段內存通過MMU映射成虛擬內存，而DPS端直接使用物理地址。由于Linux的內存管理機制，程序員只能通過malloc()函數來為應用程序分配內存。程序員不僅不能控制這段內存在物理內存上的位置，甚至不知道這些被分成4 KB每頁的內存是否是物理連續的^[6]。相反，DPS端的實時操作系統可以直接操作物理地址。所以，為了使ARM進程（應用控制）和DSP（算法加速）的內存共享，必須從DDR3嚴格劃分出一塊內存供其共享。這塊內存的大小是可以指定并且是物理連續的，這段內存不會被Linux系統直接管理，通過指定的方法，ARM端應用程序可以訪問這段內存。

    TI公司的DVSDK開發套件提供模塊cmemk.ko為ARM和DSP通信提供連續的內存。

3.2 實現流程

    如圖7所示是ARM+DSP雙核工作原理，ARM端將DSP視為一個標準API接口，可以直接調用DSP處理數據，DSP負責實際的算法實現。實現步驟分為以下4步：

    (1)完成Codec庫的開發。將坐標轉換算法按照xDM標準封裝成Codec庫。

    (2)將Codec庫集成到Codec Engine中，使用gmake命令生成擴展名為*.X64P的庫，此庫即為DSP被調用時直接加載運行的算法庫。

    (3)調用gmake生成和*.X64P相對應的*.so庫，在中間件程序中動態加載該庫即可調用DSP進行坐標轉換。

    (4)編譯和加載CMEM模塊和Dsplink模塊，完成物理內存劃分。

4 實驗與測試

    實驗效果圖如圖8、圖9所示，圖8(a)和8(b)分別為不調用DSP核和調用DSP核的雷達顯示圖像，可以看出調用DSP核時解決了丟包現象，雷達圖像左下再無空數據。圖9(a)和9(b)分別為不調用DSP核和調用DSP核時的CPU占有率，rd_demeon即為中間件軟件。可以看出，不調用DSP核時中間件的CPU占有率高達近40%，而調用DSP核后將中間件的CPU占有率降低到20%，節約了寶貴的CPU資源。

5 結論

    本文通過設計和實現一個中間件軟件，屏蔽了基于多播機制的雷達掃描單元和基于單播機制的雷達顯示單元通信接口的不同，實現了多個掃描單元和多個顯示單元同步相連，并可以通過裁剪中間件軟件功能，讓不同的顯示單元有不同的功能。ARM端通過標準的API接口調用DSP核處理數據，不僅解決了單核ARM處理器處理數據時性能不足而產生的丟包現象，而且節約了寶貴的CPU資源，解決了由于硬件資源的限制而產生的頓卡現象。測試結果表明，加入中間件后雷達顯示系統運行效果良好，達到了預期的效果。

參考文獻

[1] 楊建宇．線性調頻連續波雷達理論與實現[D]．成都：電子科技大學，1991.

[2] 范多亮．雷達顯示終端中的死點分析[J]．信息化研究，2010，36(3)：13－15.

[3] 謝希仁．計算機網絡[M]．北京：電子工業出版社，2008.

[4] 陳筱倩，周陬，王宏遠.基于IP組播的流媒體服務器軟件設計[J].微電子學與計算機，2004(12)：76-80.

[5] 張云勇．中間件技術原理與應用[M]．北京：清華大學出版社，2010.

[6] BOVET D P，CESATI M.深入理解Linux內核[M]．陳莉君，張瓊聲，張宏偉，譯.北京：中國電力出版社，2007.