• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 30 subscribers
  • Views 1233 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

IWR6843AOP: What is mmWaveLink useful for?

Abram Early
Prodigy 130 points
Part Number: IWR6843AOP
Other Parts Discussed in Thread: AWR1243

We've got an application where we need to configure the IWR6843AOP as a slave device that will receive commands and send data over its SPI interface. At first glance, mmWaveLink looked like a perfect way to accomplish this using existing and well tested libraries/drivers that I can just plug into our existing application. However, as I understand it, implementing mmWaveLink on our host MCU wouldn't leverage the application core of the IWR6843AOP, and we wouldn't be able to extend or add extra modules to the datapath. This feels massively wasteful, and extremely limiting. That, and it looks like mmWaveLink is effectively used by the mmWave SDK when you are programming the application core anyway. The host MCU is very constrained, so doing large amounts of data processing off of the radar chip is out of the question.

So, my questions are thus: What is the point of implementing mmWaveLink on a separate MCU? Does this only make sense for the less feature complete radar chips? Would mmWaveLink make sense for our application? Can I still extend/modify the data path with extra processing steps that are run locally on the IWR6843AOP?

I'm happy to answer any further questions.

  • 0
    TI__Mastermind 30405 points

    Hi Abram,

    The RF front-end, including chirp generation, timing, calibration and monitoring etc, on TI mmWave chips is controlled by the RadarSS. The RadarSS runs the TI provided radarss firmware (C:\ti\mmwave_sdk_03_05_00_04\firmware\radarss\xwr6xxx_radarss_rprc.bin). The API interface exposed by this firmware is mmwavelink and it is the only way to interface with the RadarSS/Front-end.

    For Front-end only i.e. less featured devices (e.g. AWR1243 - 77GHz frequency range), mmwavelink is the only way to communicate with the sensor and the application on the external processor can port the mmwavelink API implementation provided in the SDK. In such cases the external processor is expected to be capable of handling the raw ADC data from the Radar sensor over LVDS or CSI-2 and performing the required FMCW digital processing.

    For devices such as IWR6843AOP, which have digital processing capability to generate point cloud and tracking information, you should generally use the higher level software examples provided in the SDK and Industrial Toolbox to leverage the full capabilities of the device. You can extend/modify the data-path software chain according to your requirements. We can comment more if you provide some specific details about your use case.

    Regards

    -Nitin

  • 0 in reply to Nitin Sakhuja
    Prodigy 130 points

    That pretty much confirms my suspicions and clears up my concerns. Thank you for such a detailed and clear answer!

    Since mmWaveLink doesn't look like an option for my application, I'll need a sturdy and reliable method to communicate with the device over SPI (UART is also available since I need access to the bootloader). This interface would be used to change/modify the configuration of the datapath chain (Such as changing environment parameters, and possibly changing the chirp profile for development units), starting/stopping the sensor, and retrieving the processed data from the device. There is also the possibility that I will need to provide additional data for processing over this interface, but that isn't clear at this point.

    So I guess where I'm getting stuck is that I'm unsure how to use the hardware interfaces available to me to accomplish this. I was hoping that mmWaveLink would eliminate a lot of guesswork and give a relatively standard interface. Just as a quick summary, we have hooked up the SPI interface (MOSI, MISO, SCK, CS, and the interrupt line), as well as the UART used for the bootloader (RX, TX).

    From what I've seen in the examples you've provided, the datapath strongly favors a synchronous approach to data transfer. As in, when you receive the results from the datapath, you are expected to transmit/use that data before returning from that function. That in mind, it would seem that the preferable approach would be to have the IWR6843AOP act as the SPI master to transfer datapath results to the host MCU, and use the UART for command/configuration commands from the host. This way the IWR6843AOP can transmit it's datapath results immediately upon receiving them.

    The opposite approach, where the IWR6843AOP acts as the SPI slave, is what I've been doing up until now, but this requires the datapath results to be accessed asynchronously. Though I haven't done so at this point, this will need mutexes/semaphores or data copying to keep the data clean and consistent.

    At this point, I'm just unclear on what approach will be the most reliable and "kosher" way to setup this interface to mesh well with how the datapath functions, and how data is moved between the cores of the IWR6843AOP. Do you have any thoughts on this? If not, I'll just go ahead and close out this inquiry as resolved. I'll also be looking for documentation and tutorials on how the datapath functions and how to use it.

  • 0 in reply to Abram Early
    TI__Mastermind 30405 points

    Hi Abram,

    As you noticed, our UART based demos work on a synchronous data output approach.

    In my opinion, the similar approach you mentioned above using SPI as master for data transport instead of UART would be preferable to minimize delays arising from slave mode operation (where the slave needs to wait for clock from the master before it can start sending data out) and achieve maximum SPI throughput.

    Regards

    -Nitin