【TI毫米波雷達】MMwave毫米波雷達API配置及驅(qū)動（以IWR6843AOP為例）

導(dǎo)入庫

MMWave API（位置處于BSS）可以被DSS和MSS調(diào)用
通過Mailbox進行數(shù)據(jù)通信
毫米波雷達接口

#include < ti/control/mmwave/mmwave.h>
#include <ti/drivers/mailbox/mailbox.h>

MMWave工作原理

首先搞清楚 mmwave時雷達射頻整體 每秒發(fā)送很多frame（幀）
frame下面有chirp 比如96個chirp
所以當發(fā)送開始時 會連續(xù)發(fā)送96個chirps 然后接收數(shù)據(jù) 再處理
如圖為chirp的時序圖

雷達工作原理是上電-發(fā)送chirps-幀結(jié)束-處理-上電循環(huán)
一個Frame，首先是信號發(fā)送，比如96個chirp就順次發(fā)出去，然后接收回來，混頻濾波，ADC采樣，這些都是射頻模塊的東西。射頻完成之后，F(xiàn)FT，CFAR，DOA這些就是信號處理的東西。然后輸出給那個結(jié)構(gòu)體，就是當前幀獲得的點云了。

在射頻發(fā)送階段 一個frame發(fā)送若干個chirp 也就是上圖左上角
第一個綠色點為frame start 第二個綠色點為frame end
其中發(fā)送若干chirps（小三角形）
chirps的個數(shù)稱為numLoops（代碼中 rlFrameCfg_t結(jié)構(gòu)體）
在mmwave studio上位機中 則稱為 no of chirp loops

frame end 到 周期結(jié)束的時間為計算時間 稱為inter frame period

frame start到循環(huán)結(jié)束的時間稱為framePeriodicity（代碼中 rlFrameCfg_t結(jié)構(gòu)體）
在mmwave studio上位機中 則稱為 Periodicity

如下圖frame配置部分

在inter frame Periodicity時間內(nèi)（比如這里整個周期是55ms）
就是用于計算和處理的時間 一定比55ms要小
如果chirps很多的話 那么計算時間就會減小

如果是處理點云數(shù)據(jù) 則只需要每一幀計算一次點云即可
計算出當前幀的xyz坐標和速度 以及保存時間戳

雷達上電

 /* Wait for BSS powerup */
if (SOC_waitBSSPowerUp(socHandle, &errCode) < 0)
{
    /* Debug Message: */
    System_printf ("Debug: SOC_waitBSSPowerUp failed with Error [%d]\n", errCode);
    return 0;
}

Mailbox_init(MAILBOX_TYPE_MSS);

除了初始化SOC外 還需要調(diào)用SOC_waitBSSPowerUp和Mailbox_init

配置流程

1. 初始化模塊：MMWave_init

配置結(jié)構(gòu)體 MMWave_InitCfg
domain指定運行位置

MMWave_InitCfg      initCfg;
initCfg.domain                  = MMWave_Domain_MSS;
initCfg.socHandle               = MMWave_Global_Params.handle.socHandle;
initCfg.eventFxn                = MMWave_eventFxnCallback;  //事件回調(diào)
initCfg.linkCRCCfg.useCRCDriver = 0U;           //1開啟CRC 0關(guān)閉CRC
initCfg.linkCRCCfg.crcChannel   = CRC_Channel_CH1;      //CRC通道1
initCfg.cfgMode                 = MMWave_ConfigurationMode_FULL;  //全部模式 也可以設(shè)置成最小全部模式
initCfg.executionMode           = MMWave_ExecutionMode_ISOLATION;  //MSS和DSS不通訊 如果需要 則換個模式

//以下全是回調(diào)
initCfg.cooperativeModeCfg.cfgFxn   = MMWave_cfgFxnCallback;
initCfg.cooperativeModeCfg.closeFxn = MMWave_closeFxnCallback;
initCfg.cooperativeModeCfg.openFxn  = MMWave_openFxnCallback;
initCfg.cooperativeModeCfg.startFxn = MMWave_startFxnCallback;
initCfg.cooperativeModeCfg.stopFxn  = MMWave_stopFxnCallback;

/* Initialize and setup the MMWave Control module */
MMWave_Global_Params.handle.MMWave_handle = MMWave_init (&initCfg, &errCode);
if (MMWave_Global_Params.handle.MMWave_handle == NULL)
{
    /* Error: Unable to initialize the MMWave control module */
    MMWave_decodeError (errCode, &errorLevel, &mmWaveErrorCode, &subsysErrorCode);
    System_printf ("Error: MMWave Control Initialization failed [Error Level: %d Error code: %d Subsystem: %d]\n",errorLevel,mmWaveErrorCode, subsysErrorCode);
    return;
}

在MSS+DSS協(xié)作模式下工作時，毫米波同時在MSS和DSS上執(zhí)行。每個域都注冊一個回調(diào)函數(shù)，如果對等域執(zhí)行等效操作，則由毫米波模塊調(diào)用該函數(shù)。

這樣在配置時 會自動進行傳參 使兩個部分同步

2. 同步模塊：MMWave_sync

/* Synchronization: This will synchronize the execution of the control module
     * between the domains. This is a prerequiste and always needs to be invoked. */
    //同步
    if (MMWave_sync (MMWave_Global_Params.handle.MMWave_handle, &errCode) < 0)
    {
        /* Error: Unable to synchronize the MMWave control module */
        MMWave_decodeError (errCode, &errorLevel, &mmWaveErrorCode, &subsysErrorCode);
        System_printf ("Error: MMWave Control Synchronization failed [Error Level: %d Error code: %d Subsystem: %d]\n",errorLevel,mmWaveErrorCode, subsysErrorCode);
        return;
    }

直接調(diào)用MMWave_sync

3. 執(zhí)行毫米波模塊：MMWave_execute

在執(zhí)行上面兩步以后需要調(diào)用MMWave_execute
這個函數(shù)需要在上下文一直調(diào)用 所以建立一個死循環(huán)線程

這里priority 越大 優(yōu)先級越高 越先響應(yīng)

/*****************************************************************************
    * Launch the MMWave control execution task
    * - This should have a higher priroity than any other task which uses the
    *   MMWave control API
    *****************************************************************************/
    //這里是開了一個線程循環(huán)調(diào)用
    Task_Params_init(&taskParams);
    taskParams.priority  = 5;
    taskParams.stackSize = 3*1024;
    MMWave_Global_Params.task.MMWaveCtrl = Task_create(Ctrl_MMWave, &taskParams, NULL);

void Ctrl_MMWave(UArg arg0, UArg arg1)
{
    int32_t errCode;
    MMWave_ErrorLevel   errorLevel;
    int16_t             mmWaveErrorCode;
    int16_t             subsysErrorCode;

    while (1)
    {
        /* Execute the MMWave control module: */
        if (MMWave_execute (MMWave_Global_Params.handle.MMWave_handle, &errCode) < 0)
        {
            MMWave_decodeError (errCode, &errorLevel, &mmWaveErrorCode, &subsysErrorCode);
            System_printf ("Error: MMWave control execution failed [Error Level: %d Error code: %d Subsystem: %d]\n",errorLevel,mmWaveErrorCode, subsysErrorCode);
        }
    }
}

4. 打開模塊：MMWave_open

MMWave_OpenCfg      openCfg;

openCfg.freqLimitLow  = 600U;   //低頻限制
openCfg.freqLimitHigh = 640U;   //高頻限制

openCfg.chCfg.rxChannelEn = 0x000F;  //開啟四個RX
openCfg.chCfg.txChannelEn = 0x0007;  //開啟四個TX
openCfg.chCfg.cascading   = 0x0000;  //不開啟級聯(lián)
openCfg.chCfg.cascadingPinoutCfg = 0;  //直接給0

openCfg.lowPowerMode.lpAdcMode = 0x0000; //Regular ADC mode

openCfg.adcOutCfg.fmt.b2AdcBits = 2; //16bit
openCfg.adcOutCfg.fmt.b8FullScaleReducFctr = 0; //16bit只能為0
openCfg.adcOutCfg.fmt.b2AdcOutFmt = 2;  //Complex with Image band

openCfg.defaultAsyncEventHandler    = MMWave_DefaultAsyncEventHandler_MSS;

openCfg.disableFrameStartAsyncEvent = false;
openCfg.disableFrameStopAsyncEvent  = false;

openCfg.useCustomCalibration        = false;  // 無自定義校準 false表示默認啟用所有校準
openCfg.customCalibrationEnableMask = 0x0;

openCfg.calibMonTimeUnit            = 1;   //一幀一次校準

/*
MMWave_CalibrationData      calibrationData;
memset ((void*)&calibrationCfg, 0 , sizeof(MMWave_CalibrationCfg));

calibrationData.ptrCalibData->calibChunk
calibrationData.ptrPhaseShiftCalibData->PhShiftcalibChunk
*/

/* Open the mmWave module: */
if (MMWave_open (MMWave_Global_Params.handle.MMWave_handle, &openCfg, NULL, &errCode) < 0)
{
    /* Error: decode and Report the error */
    MMWave_decodeError (errCode, &errorLevel, &mmWaveErrorCode, &subsysErrorCode);
    System_printf ("Error: mmWave Open failed [Error Level: %d Error code: %d Subsystem: %d]\n",errorLevel,mmWaveErrorCode, subsysErrorCode);
}

這里是配置頻段 RX、TX使能個數(shù)、采樣位數(shù)等
對應(yīng)mmwave studio：

5. 模塊的配置：MMWave_config

這里是配置frame

MMWave_CtrlCfg      ctrlCfg;

ctrlCfg.dfeDataOutputMode = MMWave_DFEDataOutputMode_FRAME;

ctrlCfg.u.frameCfg.profileHandle[0]=MMWave_Global_Params.handle.profileHandle[0];
ctrlCfg.u.frameCfg.profileHandle[1]=NULL;
ctrlCfg.u.frameCfg.profileHandle[2]=NULL;
ctrlCfg.u.frameCfg.profileHandle[3]=NULL;

ctrlCfg.u.frameCfg.frameCfg.chirpStartIdx = 0;
ctrlCfg.u.frameCfg.frameCfg.chirpEndIdx = 2;
ctrlCfg.u.frameCfg.frameCfg.numLoops = 96;
ctrlCfg.u.frameCfg.frameCfg.numFrames = 0;
ctrlCfg.u.frameCfg.frameCfg.numAdcSamples = 96;
ctrlCfg.u.frameCfg.frameCfg.framePeriodicity = 11000000;  //55ms
ctrlCfg.u.frameCfg.frameCfg.triggerSelect = 0x0001; //軟件API觸發(fā)

ctrlCfg.u.frameCfg.frameCfg.numDummyChirpsAtEnd = 0;
ctrlCfg.u.frameCfg.frameCfg.frameTriggerDelay = 0;

/*
//frame模式不用配
ctrlCfg.u.continuousModeCfg.cfg.startFreqConst
ctrlCfg.u.continuousModeCfg.cfg.txOutPowerBackoffCode
ctrlCfg.u.continuousModeCfg.cfg.txPhaseShifter
ctrlCfg.u.continuousModeCfg.cfg.digOutSampleRate
ctrlCfg.u.continuousModeCfg.cfg.hpfCornerFreq1
ctrlCfg.u.continuousModeCfg.cfg.hpfCornerFreq2
ctrlCfg.u.continuousModeCfg.cfg.rxGain
ctrlCfg.u.continuousModeCfg.cfg.vcoSelect
ctrlCfg.u.continuousModeCfg.dataTransSize
*/
//ctrlCfg.u.advancedFrameCfg.profileHandle = //NULL;  //frame模式不用配

/* Configure the mmWave module: */
if (MMWave_config (MMWave_Global_Params.handle.MMWave_handle, &ctrlCfg, &errCode) < 0)
{
    /* Error: Report the error */
    MMWave_decodeError (errCode, &errorLevel, &mmWaveErrorCode, &subsysErrorCode);
    System_printf ("Error: mmWave Config failed [Error Level: %d Error code: %d Subsystem: %d]\n",errorLevel,mmWaveErrorCode, subsysErrorCode);
}

對應(yīng)：

配置profile和chirp

如果需要配置profile和chirp 則需要調(diào)用MMWave_addProfile和MMWave_addChirp

注意 chirp是在profile之下的 而profile是在mmwave之下的（就像mmwave的句柄在soc之下）

所以配置frame時：

ctrlCfg.u.frameCfg.profileHandle[0]=MMWave_Global_Params.handle.profileHandle[0];

這里的profile句柄就是MMWave_addProfile返回的 而chirp的句柄在MMWave_addChirp的返回中
并且MMWave_addChirp的第一個參數(shù)就是MMWave_addProfile的返回值（profile的句柄）
MMWave_addProfile的第一個參數(shù)則為MMWave_init的返回值（mmwave的句柄）
那么配置的先后關(guān)系就可以列出來了（其實不用在意 只要配了就行 另外 句柄要用全局變量 但是按順序配置可以方便從上往下讀代碼）

rlProfileCfg_t  profileCfg;
rlChirpCfg_t    chirpCfg;
memset ((void*)&profileCfg, 0 , sizeof(rlProfileCfg_t));
memset ((void*)&chirpCfg, 0 , sizeof(rlChirpCfg_t));

profileCfg.profileId = 0;
profileCfg.pfVcoSelect = 0x02;  //內(nèi)置 VCO2 選擇60-64GHz
profileCfg.pfCalLutUpdate = 0x00;  //校準
profileCfg.startFreqConst = 0x58E3A1CD;  //60GHz
profileCfg.idleTimeConst = 0x2710;  //100us
profileCfg.adcStartTimeConst = 0x258;  //6us
profileCfg.rampEndTime = 0x1770;  //60us
profileCfg.txOutPowerBackoffCode = 0;  //全為0
profileCfg.txPhaseShifter = 0;  //全為0
profileCfg.freqSlopeConst = 0x05E7;  //54.713 MHz/us
profileCfg.txStartTime = 0;  //0us
profileCfg.numAdcSamples = 96;  //96
profileCfg.digOutSampleRate = 0x0B86;  //2950ksps
profileCfg.hpfCornerFreq1 = 0;  //175K
profileCfg.hpfCornerFreq2 = 0;  //350K
profileCfg.txCalibEnCfg = 0xFFFF;  //不適用于IWR6843 ES 1.0
profileCfg.rxGain = 0x68; //40dB/34dB

MMWave_Global_Params.handle.profileHandle[0] = MMWave_addProfile(MMWave_Global_Params.handle.MMWave_handle,&profileCfg,&errCode);
if(MMWave_Global_Params.handle.profileHandle[0] == NULL)
{
    MMWave_decodeError (errCode, &errorLevel, &mmWaveErrorCode, &subsysErrorCode);
    System_printf ("Error: mmWave profileCfg failed [Error Level: %d Error code: %d Subsystem: %d]\n",errorLevel,mmWaveErrorCode, subsysErrorCode);
}

chirpCfg.chirpStartIdx=0;
chirpCfg.chirpEndIdx=0;
chirpCfg.profileId=0;
chirpCfg.startFreqVar=0;
chirpCfg.freqSlopeVar=0;
chirpCfg.idleTimeVar=0;
chirpCfg.adcStartTimeVar=0;
chirpCfg.txEnable=(1<<0);

//TDM模式 用for循環(huán)配置三次 每次的chirpStartIdx chirpEndIdx均不同 分別為00 11 22 另外 打開的TX也不同 分別為TX0 TX1 TX2
//這三個chirp配置都屬于同一個profileHandle下
for(i=0;i<3;i++)
{
    chirpCfg.chirpStartIdx=i;
    chirpCfg.chirpEndIdx=i;
    chirpCfg.txEnable=(1<<i);
    MMWave_Global_Params.handle.chirpHandle[i] = MMWave_addChirp(MMWave_Global_Params.handle.profileHandle[0],&chirpCfg,&errCode);
    if(MMWave_Global_Params.handle.chirpHandle[i] == NULL)
    {
        MMWave_decodeError (errCode, &errorLevel, &mmWaveErrorCode, &subsysErrorCode);
        System_printf ("Error: mmWave chirpCfg %d failed [Error Level: %d Error code: %d Subsystem: %d]\n",errorLevel,mmWaveErrorCode, subsysErrorCode);
    }
}

//然后下面再是MMWave_config 函數(shù)和配置

然后下面再是MMWave_config 函數(shù)和配置

對應(yīng)的就是這一大塊

6. 啟動毫米波：MMWave_start

這里就是開啟測量了 同時定義了校準和運行模式

MMWave_CalibrationCfg       calibrationCfg;
memset ((void *)&calibrationCfg, 0, sizeof(MMWave_CalibrationCfg));

calibrationCfg.dfeDataOutputMode = MMWave_DFEDataOutputMode_FRAME;

calibrationCfg.u.chirpCalibrationCfg.enableCalibration = true;
calibrationCfg.u.chirpCalibrationCfg.enablePeriodicity = true;
calibrationCfg.u.chirpCalibrationCfg.periodicTimeInFrames = 10;  //每10幀一次校準

//calibrationCfg.u.contCalibrationCfg.enableOneShotCalibration  //frame模式不用配

/* Start the mmWave module: The configuration has been applied successfully. */
if (MMWave_start(MMWave_Global_Params.handle.MMWave_handle, &calibrationCfg, &errCode) < 0)
{
    /* Error/Warning: Unable to start the mmWave module */
    MMWave_decodeError (errCode, &errorLevel, &mmWaveErrorCode, &subsysErrorCode);
    System_printf ("Error: mmWave Start failed [Error Level: %d Error code: %d Subsystem: %d]\n",errorLevel,mmWaveErrorCode, subsysErrorCode);
    /* datapath has already been moved to start state; so either we initiate a cleanup of start sequence or
       assert here and re-start from the beginning. For now, choosing the latter path */
}

錯誤代碼

毫米波雷達錯誤代碼可以用MMWave_decodeError函數(shù)來獲取
傳入的第一個參數(shù)為errCode 而后面三個其實都是返回值
比如：

int32_t         errCode;
MMWave_ErrorLevel   errorLevel;
int16_t             mmWaveErrorCode;
int16_t             subsysErrorCode;
if (MMWave_start(MMWave_Global_Params.handle.MMWave_handle, &calibrationCfg, &errCode) < 0)
{
    /* Error/Warning: Unable to start the mmWave module */
    MMWave_decodeError (errCode, &errorLevel, &mmWaveErrorCode, &subsysErrorCode);
    System_printf ("Error: mmWave Start failed [Error Level: %d Error code: %d Subsystem: %d]\n",errorLevel,mmWaveErrorCode, subsysErrorCode);
    /* datapath has already been moved to start state; so either we initiate a cleanup of start sequence or
       assert here and re-start from the beginning. For now, choosing the latter path */
}

最后皆可以通過mmWaveErrorCode來獲取調(diào)用函數(shù)的問題

其他模塊的錯誤代碼基本地址不一樣 但是也大同小異 查其他模塊的手冊就可以了

附錄：結(jié)構(gòu)框架

雷達基本原理敘述

雷達工作原理是上電-發(fā)送chirps-幀結(jié)束-處理-上電循環(huán)
一個Frame，首先是信號發(fā)送，比如96個chirp就順次發(fā)出去，然后接收回來，混頻濾波，ADC采樣，這些都是射頻模塊的東西。射頻完成之后，F(xiàn)FT，CFAR，DOA這些就是信號處理的東西。然后輸出給那個結(jié)構(gòu)體，就是當前幀獲得的點云了。

在射頻發(fā)送階段 一個frame發(fā)送若干個chirp 也就是上圖左上角
第一個綠色點為frame start 第二個綠色點為frame end
其中發(fā)送若干chirps（小三角形）
chirps的個數(shù)稱為numLoops（代碼中 rlFrameCfg_t結(jié)構(gòu)體）
在mmwave studio上位機中 則稱為 no of chirp loops

frame end 到 周期結(jié)束的時間為計算時間 稱為inter frame period

frame start到循環(huán)結(jié)束的時間稱為framePeriodicity（代碼中 rlFrameCfg_t結(jié)構(gòu)體）
在mmwave studio上位機中 則稱為 Periodicity

如下圖frame配置部分

在inter frame Periodicity時間內(nèi)（比如這里整個周期是55ms）
就是用于計算和處理的時間 一定比55ms要小
如果chirps很多的話 那么計算時間就會減小

如果是處理點云數(shù)據(jù) 則只需要每一幀計算一次點云即可
計算出當前幀的xyz坐標和速度 以及保存時間戳

雷達天線排列位置

在工業(yè)雷達包：

C:\ti\mmwave_industrial_toolbox_4_12_0\antennas\ant_rad_patterns

路徑下 有各個EVM開發(fā)板的天線排列說明
同樣的 EVM手冊中也有
如IWR6843AOPEVM：


其天線的間距等等位于數(shù)據(jù)手冊：

芯片框架

IWR6843AOP可以分成三個主要部分及多個外設(shè)
BSS：雷達前端部分
MSS：cortex-rf4內(nèi)核 主要用于控制
DSS： DSP C674內(nèi)核 主要用于信號處理
外設(shè)：UART GPIO DPM HWA等

其中 大部分外設(shè)可以被MSS或DSS調(diào)用
另外 雷達前端BSS部分在SDK里由MMWave API調(diào)用

代碼框架上 可以分成兩個代碼 MSS和DSS 兩個代碼同時運行 通過某些外設(shè)進行同步 協(xié)同運作

但也可以只跑一個內(nèi)核 在僅MSS模式下 依舊可以調(diào)用某些用于信號處理的外設(shè) demo代碼就是如此

如下圖為demo代碼流程

Demo工程功能

IWR6843AOP的開箱工程是根據(jù)IWR6843AOPEVM開發(fā)板來的
該工程可以將IWR6843AOP的兩個串口利用起來 實現(xiàn)的功能主要是兩個方面：
通過115200波特率的串口配置參數(shù) 建立握手協(xié)議
通過115200*8的串口輸出雷達數(shù)據(jù)
此工程需要匹配TI官方的上位機：mmWave_Demo_Visualizer_3.6.0來使用
該上位機可以在連接串口后自動化操作 并且對雷達數(shù)據(jù)可視化



關(guān)于雷達參數(shù)配置 則在SDK的mmw\profiles目錄下
言簡意賅 可以直接更改該目錄下的文件參數(shù)來達到配置雷達參數(shù)的目的

但這種方法不利于直接更改 每次用上位機運行后的參數(shù)是固定的（上位機運行需要SDK環(huán)境） 所以也可以在代碼中寫死 本文探討的就是這個方向

CCS工程導(dǎo)入

首先 在工業(yè)雷達包目錄下找到該工程設(shè)置

C:\ti\mmwave_industrial_toolbox_4_12_0\labs\Out_Of_Box_Demo\src\xwr6843AOP

使用CCS的import project功能導(dǎo)入工程后 即可完成環(huán)境搭建

這里用到的SDK最新版為3.6版本

工程敘述

以下來自官方文檔 可以直接跳過

Software Tasks

The demo consists of the following (SYSBIOS) tasks:

MmwDemo_initTask. This task is created/launched by main and is a one-time active task whose main functionality is to initialize drivers (<driver>_init), MMWave module (MMWave_init), DPM module (DPM_init), open UART and data path related drivers (EDMA, HWA), and create/launch the following tasks (the CLI_task is launched indirectly by calling CLI_open).
CLI_task. This command line interface task provides a simplified 'shell' interface which allows the configuration of the BSS via the mmWave interface (MMWave_config). It parses input CLI configuration commands like chirp profile and GUI configuration. When sensor start CLI command is parsed, all actions related to starting sensor and starting the processing the data path are taken. When sensor stop CLI command is parsed, all actions related to stopping the sensor and stopping the processing of the data path are taken
MmwDemo_mmWaveCtrlTask. This task is used to provide an execution context for the mmWave control, it calls in an endless loop the MMWave_execute API.
MmwDemo_DPC_ObjectDetection_dpmTask. This task is used to provide an execution context for DPM (Data Path Manager) execution, it calls in an endless loop the DPM_execute API. In this context, all of the registered object detection DPC (Data Path Chain) APIs like configuration, control and execute will take place. In this task. When the DPC's execute API produces the detected objects and other results, they are transmitted out of the UART port for display using the visualizer.

Data Path

Top Level Data Path Processing Chain

Top Level Data Path Timing

The data path processing consists of taking ADC samples as input and producing detected objects (point-cloud and other information) to be shipped out of UART port to the PC. The algorithm processing is realized using the DPM registered Object Detection DPC. The details of the processing in DPC can be seen from the following doxygen documentation:

ti/datapath/dpc/objectdetection/objdethwa/docs/doxygen/html/index.html

Output information sent to host

Output packets with the detection information are sent out every frame through the UART. Each packet consists of the header MmwDemo_output_message_header_t and the number of TLV items containing various data information with types enumerated in MmwDemo_output_message_type_e. The numerical values of the types can be found in mmw_output.h. Each TLV item consists of type, length (MmwDemo_output_message_tl_t) and payload information. The structure of the output packet is illustrated in the following figure. Since the length of the packet depends on the number of detected objects it can vary from frame to frame. The end of the packet is padded so that the total packet length is always multiple of 32 Bytes.

Output packet structure sent to UART
The following subsections describe the structure of each TLV.

List of detected objects

Type: (MMWDEMO_OUTPUT_MSG_DETECTED_POINTS)

Length: (Number of detected objects) x (size of DPIF_PointCloudCartesian_t)

Value: Array of detected objects. The information of each detected object is as per the structure DPIF_PointCloudCartesian_t. When the number of detected objects is zero, this TLV item is not sent. The maximum number of objects that can be detected in a sub-frame/frame is DPC_OBJDET_MAX_NUM_OBJECTS.

The orientation of x,y and z axes relative to the sensor is as per the following figure. (Note: The antenna arrangement in the figure is shown for standard EVM (see gAntDef_default) as an example but the figure is applicable for any antenna arrangement.)

Coordinate Geometry
The whole detected objects TLV structure is illustrated in figure below.

Detected objects TLV

Range profile

Type: (MMWDEMO_OUTPUT_MSG_RANGE_PROFILE)

Length: (Range FFT size) x (size of uint16_t)

Value: Array of profile points at 0th Doppler (stationary objects). The points represent the sum of log2 magnitudes of received antennas expressed in Q9 format.

Noise floor profile
Type: (MMWDEMO_OUTPUT_MSG_NOISE_PROFILE)

Length: (Range FFT size) x (size of uint16_t)

Value: This is the same format as range profile but the profile is at the maximum Doppler bin (maximum speed objects). In general for stationary scene, there would be no objects or clutter at maximum speed so the range profile at such speed represents the receiver noise floor.

Azimuth static heatmap

Type: (MMWDEMO_OUTPUT_MSG_AZIMUT_STATIC_HEAT_MAP)

Length: (Range FFT size) x (Number of "azimuth" virtual antennas) (size of cmplx16ImRe_t_)

Value: Array DPU_AoAProcHWA_HW_Resources::azimuthStaticHeatMap. The antenna data are complex symbols, with imaginary first and real second in the following order:

Imag(ant 0, range 0), Real(ant 0, range 0),...,Imag(ant N-1, range 0),Real(ant N-1, range 0)
         ...
         Imag(ant 0, range R-1), Real(ant 0, range R-1),...,Imag(ant N-1, range R-1),Real(ant N-1, range R-1)

Note that the number of virtual antennas is equal to the number of “azimuth” virtual antennas. The antenna symbols are arranged in the order as they occur at the input to azimuth FFT. Based on this data the static azimuth heat map could be constructed by the GUI running on the host.

Azimuth/Elevation static heatmap

Type: (MMWDEMO_OUTPUT_MSG_AZIMUT_ELEVATION_STATIC_HEAT_MAP)

Length: (Range FFT size) x (Number of all virtual antennas) (size of cmplx16ImRe_t_)

Value: Array DPU_AoAProcHWA_HW_Resources::azimuthStaticHeatMap. The antenna data are complex symbols, with imaginary first and real second in the following order:

 Imag(ant 0, range 0), Real(ant 0, range 0),...,Imag(ant N-1, range 0),Real(ant N-1, range 0)
         ...
         Imag(ant 0, range R-1), Real(ant 0, range R-1),...,Imag(ant N-1, range R-1),Real(ant N-1, range R-1)

Note that the number of virtual antennas is equal to the total number of active virtual antennas. The antenna symbols are arranged in the order as they occur in the radar cube matrix. This TLV is sent by AOP version of MMW demo, that uses AOA2D DPU. Based on this data the static azimuth or elevation heat map could be constructed by the GUI running on the host.

Range/Doppler heatmap

Type: (MMWDEMO_OUTPUT_MSG_RANGE_DOPPLER_HEAT_MAP)

Length: (Range FFT size) x (Doppler FFT size) (size of uint16_t)

Value: Detection matrix DPIF_DetMatrix::data. The order is :

 X(range bin 0, Doppler bin 0),...,X(range bin 0, Doppler bin D-1),
        ...
        X(range bin R-1, Doppler bin 0),...,X(range bin R-1, Doppler bin D-1)

Stats information

Type: (MMWDEMO_OUTPUT_MSG_STATS )

Length: (size of MmwDemo_output_message_stats_t)

Value: Timing information as per MmwDemo_output_message_stats_t. See timing diagram below related to the stats.

Processing timing

Note:

The MmwDemo_output_message_stats_t::interChirpProcessingMargin is not computed (it is always set to 0). This is because there is no CPU involvement in the 1D processing (only HWA and EDMA are involved), and it is not possible to know how much margin is there in chirp processing without CPU being notified at every chirp when processing begins (chirp event) and when the HWA-EDMA computation ends. The CPU is intentionally kept free during 1D processing because a real application may use this time for doing some post-processing algorithm execution.
While the MmwDemo_output_message_stats_t::interFrameProcessingTime reported will be of the current sub-frame/frame, the MmwDemo_output_message_stats_t::interFrameProcessingMargin and MmwDemo_output_message_stats_t::transmitOutputTime will be of the previous sub-frame (of the same MmwDemo_output_message_header_t::subFrameNumber as that of the current sub-frame) or of the previous frame.
The MmwDemo_output_message_stats_t::interFrameProcessingMargin excludes the UART transmission time (available as MmwDemo_output_message_stats_t::transmitOutputTime). This is done intentionally to inform the user of a genuine inter-frame processing margin without being influenced by a slow transport like UART, this transport time can be significantly longer for example when streaming out debug information like heat maps. Also, in a real product deployment, higher speed interfaces (e.g LVDS) are likely to be used instead of UART. User can calculate the margin that includes transport overhead (say to determine the max frame rate that a particular demo configuration will allow) using the stats because they also contain the UART transmission time.

The CLI command “guMonitor” specifies which TLV element will be sent out within the output packet. The arguments of the CLI command are stored in the structure MmwDemo_GuiMonSel_t.

Side information of detected objects

Type: (MMWDEMO_OUTPUT_MSG_DETECTED_POINTS_SIDE_INFO)

Length: (Number of detected objects) x (size of DPIF_PointCloudSideInfo_t)

Value: Array of detected objects side information. The side information of each detected object is as per the structure DPIF_PointCloudSideInfo_t). When the number of detected objects is zero, this TLV item is not sent.

Temperature Stats

Type: (MMWDEMO_OUTPUT_MSG_TEMPERATURE_STATS)

Length: (size of MmwDemo_temperatureStats_t)

Value: Structure of detailed temperature report as obtained from Radar front end. MmwDemo_temperatureStats_t::tempReportValid is set to return value of rlRfGetTemperatureReport. If MmwDemo_temperatureStats_t::tempReportValid is 0, values in MmwDemo_temperatureStats_t::temperatureReport are valid else they should be ignored. This TLV is sent along with Stats TLV described in Stats information

Range Bias and Rx Channel Gain/Phase Measurement and Compensation

Because of imperfections in antenna layouts on the board, RF delays in SOC, etc, there is need to calibrate the sensor to compensate for bias in the range estimation and receive channel gain and phase imperfections. The following figure illustrates the calibration procedure.

Calibration procedure ladder diagram

The calibration procedure includes the following steps:

Set a strong target like corner reflector at the distance of X meter (X less than 50 cm is not recommended) at boresight.
Set the following command in the configuration profile in .../profiles/profile_calibration.cfg, to reflect the position X as follows: where D (in meters) is the distance of window around X where the peak will be searched. The purpose of the search window is to allow the test environment from not being overly constrained say because it may not be possible to clear it of all reflectors that may be stronger than the one used for calibration. The window size is recommended to be at least the distance equivalent of a few range bins. One range bin for the calibration profile (profile_calibration.cfg) is about 5 cm. The first argument "1" is to enable the measurement. The stated configuration profile (.cfg) must be used otherwise the calibration may not work as expected (this profile ensures all transmit and receive antennas are engaged among other things needed for calibration).
   measureRangeBiasAndRxChanPhase 1 X D
Start the sensor with the configuration file.
In the configuration file, the measurement is enabled because of which the DPC will be configured to perform the measurement and generate the measurement result (DPU_AoAProc_compRxChannelBiasCfg_t) in its result structure (DPC_ObjectDetection_ExecuteResult_t::compRxChanBiasMeasurement), the measurement results are written out on the CLI port (MmwDemo_measurementResultOutput) in the format below: For details of how DPC performs the measurement, see the DPC documentation.
   compRangeBiasAndRxChanPhase <rangeBias> <Re(0,0)> <Im(0,0)> <Re(0,1)> <Im(0,1)> ... <Re(0,R-1)> <Im(0,R-1)> <Re(1,0)> <Im(1,0)> ... <Re(T-1,R-1)> <Im(T-1,R-1)>
The command printed out on the CLI now can be copied and pasted in any configuration file for correction purposes. This configuration will be passed to the DPC for the purpose of applying compensation during angle computation, the details of this can be seen in the DPC documentation. If compensation is not desired, the following command should be given (depending on the EVM and antenna arrangement) Above sets the range bias to 0 and the phase coefficients to unity so that there is no correction. Note the two commands must always be given in any configuration file, typically the measure commmand will be disabled when the correction command is the desired one.
   For ISK EVM:
   compRangeBiasAndRxChanPhase 0.0   1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 
   For AOP EVM
   compRangeBiasAndRxChanPhase 0.0   1 0 -1 0 1 0 -1 0 1 0 -1 0 1 0 -1 0 1 0 -1 0 1 0 -1 0 

Streaming data over LVDS

The LVDS streaming feature enables the streaming of HW data (a combination of ADC/CP/CQ data) and/or user specific SW data through LVDS interface. The streaming is done mostly by the CBUFF and EDMA peripherals with minimal CPU intervention. The streaming is configured through the MmwDemo_LvdsStreamCfg_t CLI command which allows control of HSI header, enable/disable of HW and SW data and data format choice for the HW data. The choices for data formats for HW data are:

MMW_DEMO_LVDS_STREAM_CFG_DATAFMT_DISABLED
MMW_DEMO_LVDS_STREAM_CFG_DATAFMT_ADC
MMW_DEMO_LVDS_STREAM_CFG_DATAFMT_CP_ADC_CQ
In order to see the high-level data format details corresponding to the above data format configurations, refer to the corresponding slides in ti\drivers\cbuff\docs\CBUFF_Transfers.pptx

When HW data LVDS streaming is enabled, the ADC/CP/CQ data is streamed per chirp on every chirp event. When SW data streaming is enabled, it is streamed during inter-frame period after the list of detected objects for that frame is computed. The SW data streamed every frame/sub-frame is composed of the following in time:

HSI header (HSIHeader_t): refer to HSI module for details.
User data header: MmwDemo_LVDSUserDataHeader
User data payloads:
Point-cloud information as a list : DPIF_PointCloudCartesian_t x number of detected objects
Point-cloud side information as a list : DPIF_PointCloudSideInfo_t x number of detected objects

The format of the SW data streamed is shown in the following figure:

LVDS SW Data format

Note:

Only single-chirp formats are allowed, multi-chirp is not supported.
When number of objects detected in frame/sub-frame is 0, there is no transmission beyond the user data header.
For HW data, the inter-chirp duration should be sufficient to stream out the desired amount of data. For example, if the HW data-format is ADC and HSI header is enabled, then the total amount of data generated per chirp is:
(numAdcSamples * numRxChannels * 4 (size of complex sample) + 52 [sizeof(HSIDataCardHeader_t) + sizeof(HSISDKHeader_t)] ) rounded up to multiples of 256 [=sizeof(HSIHeader_t)] bytes.
The chirp time Tc in us = idle time + ramp end time in the profile configuration. For n-lane LVDS with each lane at a maximum of B Mbps,
maximum number of bytes that can be send per chirp = Tc * n * B / 8 which should be greater than the total amount of data generated per chirp i.e
Tc * n * B / 8 >= round-up(numAdcSamples * numRxChannels * 4 + 52, 256).
E.g if n = 2, B = 600 Mbps, idle time = 7 us, ramp end time = 44 us, numAdcSamples = 512, numRxChannels = 4, then 7650 >= 8448 is violated so this configuration will not work. If the idle-time is doubled in the above example, then we have 8700 > 8448, so this configuration will work.
For SW data, the number of bytes to transmit each sub-frame/frame is:
52 [sizeof(HSIDataCardHeader_t) + sizeof(HSISDKHeader_t)] + sizeof(MmwDemo_LVDSUserDataHeader_t) [=8] +
number of detected objects (Nd) * { sizeof(DPIF_PointCloudCartesian_t) [=16] + sizeof(DPIF_PointCloudSideInfo_t) [=4] } rounded up to multiples of 256 [=sizeof(HSIHeader_t)] bytes.
or X = round-up(60 + Nd * 20, 256). So the time to transmit this data will be
X * 8 / (n*B) us. The maximum number of objects (Ndmax) that can be detected is defined in the DPC (DPC_OBJDET_MAX_NUM_OBJECTS). So if Ndmax = 500, then time to transmit SW data is 68 us. Because we parallelize this transmission with the much slower UART transmission, and because UART transmission is also sending at least the same amount of information as the LVDS, the LVDS transmission time will not add any burdens on the processing budget beyond the overhead of reconfiguring and activating the CBUFF session (this overhead is likely bigger than the time to transmit).
The total amount of data to be transmitted in a HW or SW packet must be greater than the minimum required by CBUFF, which is 64 bytes or 32 CBUFF Units (this is the definition CBUFF_MIN_TRANSFER_SIZE_CBUFF_UNITS in the CBUFF driver implementation). If this threshold condition is violated, the CBUFF driver will return an error during configuration and the demo will generate a fatal exception as a result. When HSI header is enabled, the total transfer size is ensured to be at least 256 bytes, which satisfies the minimum. If HSI header is disabled, for the HW session, this means that numAdcSamples * numRxChannels * 4 >= 64. Although mmwavelink allows minimum number of ADC samples to be 2, the demo is supported for numAdcSamples >= 64. So HSI header is not required to be enabled for HW only case. But if SW session is enabled, without the HSI header, the bytes in each packet will be 8 + Nd * 20. So for frames/sub-frames where Nd < 3, the demo will generate exception. Therefore HSI header must be enabled if SW is enabled, this is checked in the CLI command validation.

Implementation Notes

The LVDS implementation is mostly present in mmw_lvds_stream.h and mmw_lvds_stream.c with calls in mss_main.c. Additionally HSI clock initialization is done at first time sensor start using MmwDemo_mssSetHsiClk.
EDMA channel resources for CBUFF/LVDS are in the global resource file (mmw_res.h, see Hardware Resource Allocation) along with other EDMA resource allocation. The user data header and two user payloads are configured as three user buffers in the CBUFF driver. Hence SW allocation for EDMA provides for three sets of EDMA resources as seen in the SW part (swSessionEDMAChannelTable[.]) of MmwDemo_LVDSStream_EDMAInit. The maximum number of HW EDMA resources are needed for the data-format MMW_DEMO_LVDS_STREAM_CFG_DATAFMT_CP_ADC_CQ, which as seen in the corresponding slide in ti\drivers\cbuff\docs\CBUFF_Transfers.pptx is 12 channels (+ shadows) including the 1st special CBUFF EDMA event channel which CBUFF IP generates to the EDMA, hence the HW part (hwwSessionEDMAChannelTable[.]) of MmwDemo_LVDSStream_EDMAInit has 11 table entries.
Although the CBUFF driver is configured for two sessions (hw and sw), at any time only one can be active. So depending on the LVDS CLI configuration and whether advanced frame or not, there is logic to activate/deactivate HW and SW sessions as necessary.
The CBUFF session (HW/SW) configure-create and delete depends on whether or not re-configuration is required after the first time configuration.
For HW session, re-configuration is done during sub-frame switching to re-configure for the next sub-frame but when there is no advanced frame (number of sub-frames = 1), the HW configuration does not need to change so HW session does not need to be re-created.
For SW session, even though the user buffer start addresses and sizes of headers remains same, the number of detected objects which determines the sizes of some user buffers changes from one sub-frame/frame to another sub-frame/frame. Therefore SW session needs to be recreated every sub-frame/frame.
User may modify the application software to transmit different information than point-cloud in the SW data e.g radar cube data (output of range DPU). However the CBUFF also has a maximum link list entry size limit of 0x3FFF CBUFF units or 32766 bytes. This means it is the limit for each user buffer entry [there are maximum of 3 entries -1st used for user data header, 2nd for point-cloud and 3rd for point-cloud side information]. During session creation, if this limit is exceeded, the CBUFF will return an error (and demo will in turn generate an exception). A single physical buffer of say size 50000 bytes may be split across two user buffers by providing one user buffer with (address, size) = (start address, 25000) and 2nd user buffer with (address, size) = (start address + 25000, 25000), beyond this two (or three if user data header is also replaced) limit, the user will need to create and activate (and wait for completion) the SW session multiple times to accomplish the transmission.

The following figure shows a timing diagram for the LVDS streaming (the figure is not to scale as actual durations will vary based on configuration).

How to bypass CLI

Re-implement the file mmw_cli.c as follows:

MmwDemo_CLIInit should just create a task with input taskPriority. Lets say the task is called "MmwDemo_sensorConfig_task".
All other functions are not needed
Implement the MmwDemo_sensorConfig_task as follows:
Fill gMmwMCB.cfg.openCfg
Fill gMmwMCB.cfg.ctrlCfg
Add profiles and chirps using MMWave_addProfile and MMWave_addChirp functions
Call MmwDemo_CfgUpdate for every offset in Offsets for storing CLI configuration (MMWDEMO_xxx_OFFSET in mmw.h)
Fill gMmwMCB.dataPathObj.objDetCommonCfg.preStartCommonCfg
Call MmwDemo_openSensor
Call MmwDemo_startSensor (One can use helper function MmwDemo_isAllCfgInPendingState to know if all dynamic config was provided)

Hardware Resource Allocation

The Object Detection DPC needs to configure the DPUs hardware resources (HWA, EDMA). Even though the hardware resources currently are only required to be allocated for this one and only DPC in the system, the resource partitioning is shown to be in the ownership of the demo. This is to illustrate the general case of resource allocation across more than one DPCs and/or demo's own processing that is post-DPC processing. This partitioning can be seen in the mmw_res.h file. This file is passed as a compiler command line define

"--define=APP_RESOURCE_FILE="<ti/demo/xwr64xx/mmw/mmw_res.h>" 

in mmw.mak when building the DPC sources as part of building the demo application and is referred in object detection DPC sources where needed as文章來源地址http://www.zghlxwxcb.cn/news/detail-704669.html

#include APP_RESOURCE_FILE 

到了這里，關(guān)于【TI毫米波雷達筆記】MMwave毫米波雷達API配置及驅(qū)動（以IWR6843AOP為例）的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！