mmWave SDK的功能将被分解为组件，下面将进行介绍
驱动程序在系统中封装了各种硬件IPs的功能，并为更高的层提供了定义良好的API。通过使用OSAL层，驱动程序被设计成与操作系统无关。下图显示了SDK驱动程序中典型的内部软件块。在文件夹mmwave_sdk\packages\ti\drivers<ip>中有SDK驱动程序的源代码
ADCBUF TI-RTOS中的ADCBuf驱动程序在指定的频率采样模拟波形。生成的示例被传输到应用程序提供的缓冲区中。驱动程序可以一次抽取n个样本，也可以通过双缓冲和提供一个回调来处理每个完成的缓冲区来连续采样。 这个驱动程序中的api充当典型TI-PTOS应用程序的接口。特定的外设实现负责创建所有SYS/BIOS特定的原语，以支持线程安全操作。CAN CAN驱动程序可以提供驱动程序在CAN外设之间传输数据的功能。这个驱动程序不解释使用这个外设发送或接收的任何数据CANFD CANFD驱动程序提供在CANFD外围设备之间传输数据的功能。此驱动程序不解释使用此外设发送或接收的任何数据CBUFF CBUFF(Common Buffer Controller)负责从多个源(如ADCBUFF、Chrip Parameters(CP)、Chrip Quality(CQ)或任何其他源)向LVDS Tx或CSI2模块传输数据CRC CRC驱动程序允许计算指定数据上的CRCCRYPTOCSI CSI驱动程序提供了对高速接口的支持，该接口允许数据从XWR14xx传输到另一个设备。CSI驱动程序与CBUFF驱动程序协同工作DMA 直接存储器存取驱动程序提供功能来从一个内存位置复制数据到使用硬件的另一个EDMA(Enhanced DMA) 在ARxxxx SoCs的EDMA IP可以被编程在一个高级使用允许与操作系统连接的EDMA驱动软件。EDMA驱动程序暴露了由IP提供的大多数特性的编程 以下是api/特性的高层描述： 查询SoC上的EDMA实例的数目EDMA的一个特定实例初始化为已知的清除禁用状态(类似重置状态)打开EDMA的一个实例，它返回实例信息，例如该实例上的传输控制器的数量将通道配置为所需的配置，并可选择启用通道。这里包括参数集选择和参数集配置。用户可以选择提供的回调函数功能来传输完成的指示启用/禁用一个通道配置参数集。通常用于链接参数链接参数集连锁通道开始传输(手动触发)以前的配置等待传输完成(在配置中没有提供的回调的情况下使用)对于设置参数集的源或目标地址的api，用于XWR16XX(DSP)上的一些用例从CC(通道控制器)和所有TCs(传输控制器)产生的错误监视配置。相应的错误状态查询的一些设备上的处理器，其中错误中断没有连接到处理器中断映射状态查询控制性能关闭EMDA的一个实例 ESM ESM驱动程序提供了api来配置和处理来自ESM H/W模块的错误GPIOHWA HWA驱动程序提供了用于配置、触发和从硬件加速器获取结果的apiI2CMAILBOX 该邮箱驱动程序具有多种操作模式和性能，简化了对主板上外围设备的读写。这些包括阻塞、非阻塞和回调。在整个文档中，术语本地端点指的是实例化邮箱驱动程序的子系统。术语远程端点指的是通过邮箱实例与本地端点通信的子系统。应用程序通过调用Mailbox_init()初始化邮箱驱动程序，然后通过调用Mainbox_open()为远程端点打开邮箱实例。打开邮箱实例后，可以执行读和写操作OSALPINMUX pinmux驱动程序为设备上可用的各种pad提供了set/get apiQSPI QSPI驱动程序提供了通过QSPI接口访问外部SPI设备的功能QSPIFLASH QSPI闪存驱动程序提供了访问外部SPI闪存的功能SOC SOC驱动程序允许应用程序开发人员使用以下子模块： MSS RCM MSS TOP RCM DSS/DSS2 REG MSS GPCFGSPI TI-RTOS中的SPI驱动程序被设计为在SPI外围设备之间移动数据的一种方式。这个驱动程序不解释从这个外设发送或接收的任何数据 这个驱动程序中的api充当典型TI-RTOS应用程序的接口。特定的外设实现负责创建所有SYS/BIOS特定的原语，以支持线程安全操作UARTWATCHDOG在mmWave SDK中有一个OSAL层，它提供了基本组件(驱动程序、mmWaveLink、mmWaveAPI)的os无关特性。这个OSAL提供了一个抽象层为一些公共的OS服务：信号量、互斥、调试、中断、时钟、内存、循环分析器
mmWaveLink是一个控制层主要实现雷达子系统(RADARSS)与控制实体(MSS R4F)和/或DSP子系统(DSS C674x)之间的通信协议。它提供了一套底层APIs，应用程序可以调用这些api来启用/配置/控制雷达子系统。它为应用程序提供了一个定义良好的接口，以便插入正确的通信驱动程序api来与雷达通信。它作为雷达SS的驱动程序，公开雷达SS的服务，包括api来配置雷达SS的HW块，并提供MSS/DSS与雷达SS之间消息传输通信协议
在应用程序和雷达子系统之间链接处理通信错误，通知异常平台与操作系统无关能工作在单线程(非OS)的工作环境中下图显示了mmWaveLink组件各种各种的接口/APIs：
mmWaveAPI是运行在mmWaveLink和LLD API(驱动程序API)之上的一个更高级的控制层。它旨在以更简单、更少的API集的形式为执行mmWave雷达检测任务的应用提供一个抽象层。在双核的mmwave设备中，他还在IPC上提供了一个抽象层来同步和在MSS和DSS区域进行配置 下图是mmWave API内部的软件设计 在mmWave模块中提供了两种配置的模式
full configuration这个模式实现了mmWave前端的基本的线性调频脉冲/帧序列，并且是应用程序在使用基本的线性调频脉冲/帧配置时推荐使用的模式。在这种模式下，应用程序将使用mmWave控制模块提供全部服务。这些特性包括：
mmWave链路的初始化MSS和DSS之间的同步服务异步事件管理雷达的帧、高级帧和连续模式的启动和停止服务配置MSS和DSS之间的配置同步在full configuration模式中，可以使用多个线性调频脉冲创建多个配置文件，为此添加了以下的api
Chrip Management
MMwave_addChrip MMWave_delChripProfile Management
MMwave_addProfile MMWave_delProfile对于需要使用mmWave前端高级帧配置或需要在配置例程中执行额外命令序列的高级用户，建议使用最小模式。在这种模式下，应用程序只能访问mmWave控制模块提供的服务的一个子集。这些特性包括：
mmWave链路的初始化双核心设备上的MSS和DSS之间的同步服务异步事件管理启停服务在这种模式下，应用程序根据配置要求，按照正确的顺序直接调用mmWave Link API。该应用程序无法使用该配置服务，因此，在具有多个核的mmwave设备中，应用程序负责在MSS和DSS之间传递配置 下面是简单的示例调用流：
DPIF定义了检测处理链中的标准接口点，对应于上图中可伸缩链中的"蓝色"框。 这一层定义了关键接口有：
输入ADC数据(ADCbuf存储器的内容)雷达数据集检测矩阵点云及其侧面信息从一个接口点到另一个接口点的数据转换功能称为"数据处理单元"。将数据处理链拆分为处理单元可以促进多个链的某些处理块重用
距离处理(ADC data to Radar Cube)：该处理单元在活动帧时间对chrip(RF)数据进行处理(1D FFT + optional DC Range Calib)并在雷达数据集中生成处理后的数据。这个处理单元在mmWave SDK中式标准化的。给出了基于HWA和DSP的实现方案。基于HWA的实现可以在R4F或C674x上实例化静态杂波处理(Radar Cube to Radar Cube)：当启用时，该处理单元从雷达立方体读取范围FFT输出数据，并在帧间时间内将数据写回雷达数据集之前执行静态杂波滤除，这个处理单元作为参考实现提供，SDK的用户可以在他们的应用程序/处理链中重用这些处理单元，或者根据他们的特定需求创建这些单元的变体。它提供了基于S/W的实现，可以在R4F或C674x上实例化多普勒处理(Radar Cube to Detection Matrix)：该处理单元在帧间对雷达立方体进行(2D FFT + Energy Sum)处理，生成检测矩阵。这个处理单元作为参考实现提供，SDK的用户可以在他们应用程序/处理链中重用这些处理单元，或者根据他们的特定需求创建这些单元的变体。给出了基于HWA和DSP的实现方案。基于HWA的实现可以在R4F或C674x上实例化。基于DSP的实现合并静态杂波算法优化内存/mips的使用和用户可以跳过使用独立的静态杂波DPU。CFAR + AoA(Detection Matrix to Point Cloud)：他们被作为两个独立的DPUs，在帧间对检测矩阵共同运行CFAR-CA算法、峰值分组、视场滤波、多普勒补偿、最大速度增强和角度(方位角+仰角)估计，产生点云。这些处理单元作为参考实现提供，SDK的用户可以在他们的应用程序/处理链中重用这些单元，或者根据他们的特定需求创建这些单元的变体，他们提供了基于HWA和DSP的实现。基于HWA的实现可以在R4F或C674x上实例化。每个DPU呈现以下高层设计(DPU内部的软件设计)：
所有外部的DPU的api都以前缀DPU_开始。接下来是DPU唯一的名称，例如：DPU_RangeProcHWA_init标准的外部api：init，config，process，ioctl，deinit由每个DPU提供 初始化：一次初始化DPU配置：DPU的完整配置：硬件资源，静态和动态(如果DPU支持) 静态配置：在正在运行的帧中是静态的配置动态配置：只在进程不进行时，可以在帧与帧之间进行更改的配置-----理想情况下是在DPC导出帧结果后的帧间时间 流程：DPU的实际处理功能控制接口，允许高层在帧间时间切换动态配置解除初始化：解除DPU的初始化 所有I/O buffer和scratch buffer的内存分配都在DPU之外，因为mmWave应用程序依赖内存覆盖技术进行优化，并且最好在应用程序级别处理所有的H/W资源必须由应用程序分配并传递给DPU。这有助于保持DPU。这有助于保持DPU平台的不可知性，也允许应用程序在DPU处理没有及时重叠时跨DPU共享资源DPUs与操作系统无关，对所需的操作系统服务使用OSAL API下图是一个DPUs的调用流程，关于chrip/frame的配置和进程API调用的时间会根据DPU的功能、它在链中的使用、DPC实现和硬件资源的重叠而变化
DPM是支持架构的"可伸缩性"方面的基础层。这一层吸收了所有消息传递的复杂性(跨核和核内)，并为应用程序级的集成和集成任何"数据处理链"提供了标准api。应用层将能够从任何域(MSS或DSS)调用DPM api，并控制"数据处理链"的配置和执行。DPM提供的api将在MSS和DSS上都可用。它可以满足(但不限于)各种部署：
Datapath control on R4F and datapath execution is split between R4F/HWA and DSP(Distributed)Datapath control on R4F and datapath execution is on R4F using HWA(Local)Datapath control on R4F and datapath execution is on DSP(with and without HWA)(Remote)Datapath control on DSP and datapath execution is on DSP+HWA(Local)Datapath control on DSP and datapath execution is on DSP(Local)下图是DPM的内部软件设计：
参考资料：
《MMWAVE SDK User Guide》