TI的mmWave的软件架构非常复杂,附加价值很高。要想搞懂,得先死磕官方的mmWave SDK user guide。这篇文章的意义就在于让你可以快速读懂这篇UG。
UG分为6个部分:
- 开箱体验;
- 系统概况;
- 开搞;
- 如何开搞;
- 深度开发;
- 附录。
第1部分就是我们上一篇示例工程文章中提到的要准备的东西。
第2部分说SDK这个开发包分为Suite和Demo两大部分。Suite中包含了以下这些内容:
至于每个里有什么内容,起什么功能,UG这里没有给出解释。不过把本系列文章看完你就知道了。第2部分还给出了几个名词的解释:
第3部分上来先告诉你,demo工程放在了mmwave_sdk_03_03_00_03\packages\ti\demo这个路径下面,整个软件的详细说明文档(包括demo的说明文档)为mmwave_sdk_ 03_03_00_03\docs路径下的mmwave_sdk_module_documentation.html,这个文档写的非常详尽,非常好!所有关于软件架构、软件设计、驱动、算法库的详细说明都在这里面。
然后在demo工程路径下找到xwr16xx_mmw_demo.bin文件烧写到Flash中,这个在我们上一篇文章中描述过。下面是连接示例,没有DCA1000开发板(用于抓取原始回波数据)也可以。
接下来配置上位机mmWave Demo Visualizer发送配置文件,接收目标信息。当然也对DCA1000配套的上位机的使用方法进行了详细说明。
最后,也是第3部分占篇幅最多的内容:.cfg的格式说明。要配置雷达前端就要通过mmWave Link。而.cfg就是上位机发送的配置文件。mmWave Link的说明文档可以从mmwave_sdk_module_documentation.html中打开。需要配置的参数如下图所示(不局限于下图)。
第4部分先详细讲解了怎么连接串口、怎么烧写擦除Flash、如何连接JTAG调试DSP。然后说明了几个.bat文件,感觉没什么用。。。
第5部分进行深度开发,这部分才是重点。下面详细介绍。
=====================华丽的分割线=================================================
目录
5.3 RF control path and data path
5.1 软件系统部署
一个典型的毫米波雷达应用一般都有以下操作:
- 通过mmWave Link来控制和监视RF前端;
- 通过标准总线与外部通信;
- 使用DSP进行雷达信号与信息处理。
软件系统架构分为3层,如下图所示。最下面灰色的是芯片内的硬件层;往上是驱动层(包括硬件驱动、操作系统、信号处理算法模块、连接链路等);再往上是API层(包括API接口、数据传输管理、EDMA、数据处理算法模块(DPU)等);最上面一层是系统应用层(包括计算结果传输、远端配置等)。
图5.1 软件架构
对软件各层进行部署(把软件架构拍扁放到一张图里),可以看出大致的数据流向,如下图所示。绿色箭头表示控制路径,红色箭头表示数据路径。蓝色的块是mmWave SDK组件,黄色的块是自定义应用程序代码。
5.2 典型的FMCW雷达处理链
典型的毫米波雷达处理接收到来自RF前端的ADC数据后,开始进行距离和多普勒FFT,然后使用CFAR进行非相参检测(这里感觉图中写错了,如果是非相参的空间维FFT怎么做,后续看代码确认),最后利用空间维FFT估计角度。得到点云数据后可以使用更高层次的算法对点云数据进行后处理,如聚类、跟踪、分类,以表示真实世界的目标。
将上图中的处理流程放到软件架构中,如下图所示。图中DPM、Higher Processing Chain在ARM中实现;Detection Processing Chain在DSP或硬件加速ASIC中实现;RF control既可以在ARM也可以在DSP中,还可以ARM、DSP一起控。
Detection Processing Chain这部分是主要的雷达信号与数据处理过程,我们把这部分展开,如下图所示。这里的内容需要结合代码来看,在下一篇文章中再介绍。本文先把UG过一遍。
5.3 RF control path and data path
5.3.1 RF control path
看上面这个图,要像剥洋葱,从外面一层层剥进去。
由ARM或DSP单独控制RF前端步骤大致分为3步:init、config、start。下面的这些图是梯形图,纵轴是时间,横轴是各个软件模块。
- Init
- Config
- Start
DSP和ARM联合控制RF前端感觉没有应用场景,还很麻烦,这里就跳过了。
5.3.2 Data path
我们把雷达数据的主处理流程单独摘出来看,其层次结构如下图所示,主要位于整个软件架构(图5.1)的第二层(API层)。
DPM为应用程序提供了一个简化的API结构,同时隐藏了任务间和处理器间通信的复杂性。从下面的图中可以看出,应用程序只需要调用各种DPM APls来控制处理链(在下面的梯形图中的“蓝色”中看到的函数调用),并在报告回调中对这些APls的结果进行重新操作。数DPCs也通过DPM向应用程序提供了一个标准化的API结构,并使用DPUs封装了数据流的实现,同时提供了简单的基于IOCTL的接口来配置和触发数据流。
将此处理流程层次实现时,有3种不同的部署。这其实是一个多核间部署的问题。
- DPC与DPM在一个核里;
- DPC与DPM不在一个核里,DPC在DSP中,DPM在ARM中;
- DPC分布在两个核里;
以上这三种情况,都可以通过DPM来控制DPC。
部署问题说完,还有初始化问题,软件的运行顺序如下:
- mmWave初始化、DPM初始化;
- mmWave配置、DPM通过IOCTL接口配置DPC;
- DPM启动;
- mmWave启动;
- mmWave停止;
- DPM停止;
5.3.2.1 DPC与DPM在一个核里
mmWave(即RF前端控制)的流程不在下图中展示,5.3.1节已介绍过。下面的图单独摘出了Data path的软件流程。
5.3.2.2 DPC与DPM不在一个核里
比较发现,不在一个核中时,多了IPC1链路,多了同步的一个步骤。DPC分布在不同的核中的情况比较鸡肋(应当是有硬件加速时才会考虑)也比较复杂,这里就略过了。
注1:IPC(Inter-Process Communication,进程间通信)。
本次就先更新到这里,下一篇软件架构的文章直接从5.4开始。
《TI单芯片毫米波雷达软件架构研究(二)》在专栏 “TI单芯片毫米波雷达代码走读” 中。