0 引言
LFMCW(线性调频连续波雷达)具有CW雷达发射功率小的特点，更兼有脉冲雷达测距的能力，广泛应用于导航、测量等领域。基于多播机制对其组网，可以实现多台雷达扫描终端与多台显示终端同步相连。显示终端的主要功能包括控制雷达状态和显示雷达图像两个部分。采用多线程编程，可以让不同的显示终端有不同的功能，比如一部分显示终端只具有显示雷达图像的功能，而另一部分显示终端同时具有控制和显示两个功能（这部分显示终端可以提供给管理员使用）。由于显示单元是基于单播机制，为了提高显示单元的可移植性，屏蔽雷达扫描单元和显示单元通信接口的不同，可以用中间件负责两部分的通信。
DM3730是TI公司生产的双核（ARM+DSP）架构处理器。其低功耗、高性能、低价格的特点深受广大嵌入式开发者的喜爱。显示终端基于DM3730平台，扫描单元发送的雷达数据是极坐标表示，必须通过坐标转换后才能在终端上正常显示。由于坐标转换计算量过大，用ARM处理器实现坐标转换算法会大大增加系统负担，并且会产生严重的丢包现象。所以将算法实现交给DSP处理。实测发现，经过优化后的ARM处理器CPU使用率大大降低，雷达数据处理过程中再无丢包现象。
1 系统结构
1.1 物理结构
如图1所示，雷达扫描单元由雷达天线和FPGA组成。雷达天线负责采集雷达数据，FPGA负责AD采样，并实现了海杂波抑制、雨雪抑制、海浪抑制等算法。FPGA通过网线将处理好的数据发送至ARM端，ARM端负责将接收到的雷达数据作坐标转换处理并显示雷达图像。另外，ARM端还负责控制雷达状态。
1.2 系统逻辑结构
系统逻辑结构如图2所示。多播使用D类地址作为IP地址，应用程序可以通过加入一个或者多个多播组，从而仅接收所在多播组的数据。多播组1～4分别代表雷达控制信息多播组、雷达数据多播组、雷达状态反馈信息多播组、keepalive多播组。中间件与UI显示单元的连接方式是单播机制。加入雷达控制信息多播组的成员可以发送控制指令给该多播组的雷达扫描单元，从而控制其状态。加入雷达数据多播组的成员可以接收到FPGA处理好的雷达数据。加入雷达反馈信息多播组的成员可以接收到雷达自身状态的反馈信息，比如当前量程、增益等。反馈系统是为了增强雷达显示系统的实时性和健壮性。Keepalive多播组比较特殊，雷达扫描单元会定期检查该多播组有无keepalive指令，如果10 s内没有收到该指令，则自动关机。所以，中间件必须加入该多播组并不断发送keepalive指令才能保证雷达持续工作。GPS传感器和AIS传感器将采集和处理后的数据发送至串口，中间件从串口搜集这些数据，解析打包后通过socket发送至UI。可见，中间件可以选择加入这几个多播组的一个或者全部，从而拥有不同的功能组合。在这种逻辑结构下，中间件使得UI显示单元抽象了所有的数据来源，它只负责接收网络数据、显示图像以及响应鼠标键盘事件。
2 中间件功能设计与实现
中间件是连接两个独立应用程序的桥梁。两个或多个具有不同通信接口的应用程序通过中间件依然可以正常通信。所以，中间件能屏蔽不同的接口，帮助用户灵活、高效地开发应用程序，并大大提高应用程序的可移植性，这在嵌入式应用中意义重大。
基于以上分析，本中间件软件主要实现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资源，解决了由于硬件资源的限制而产生的顿卡现象。测试结果表明，加入中间件后雷达显示系统运行效果良好，达到了预期的效果。