• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 54 subscribers
  • Views 599 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC1352R: RF_postCmd and RF_pendCmd explanations

Vincenzo Cristiano
Intellectual 710 points
Part Number: CC1352R


Hello, 

I am working on a project that uses Proprietary Radio Driver. In particular, I would like to understand better the meaning of RF_postCmd and RF_pendCmd. 

Questions are:

    1. what does post mean and what does pend mean in this specific case? 
    2. If I use an RF_postCmd to receive data from another board is it mandatory touse also an RF_pendCmd? 
    3. Looking at resource explorer demos I see that there are just examples with RF_runCmd, this includes both RF_postCmd and RF_pendCmd. Receiving doesn't mean an asynchronous behavior? In other words, I don't know if there is someone who sends me data over RF so is not "correct" to block until receiving, right?

    Best regards,

    Vincenzo 

    • 0
      TI__Genius 10580 points

      Vincenzo,

      I'd recommend the SimpleLink Academy Training "Basic RX and TX" which is a part of the Proprietary RF Training.

      https://dev.ti.com/tirex/explore/node?node=AJ1y3Qt11VwjrCSQsRfxXw__pTTHBmu__LATEST 

      In that lab, the commands you are asking about are described as follows:

      RF_postCmd(): Execute a radio operation command asynchronously or append it to the command queue if another command is already running

      RF_pendCmd(): Wait for previously posted command to complete

      RF_runCmd(): Execute a radio operation command synchronously and wait for its completion

      Regards,

      Daniel

    • 0 in reply to daniel_o
      Intellectual 710 points

      Daniel,

      Thank you for your reply.

      I still don't understand the combination of postCmd and pendCmd.
      In my case, I have a command read from UART that I send through RF_runCmd. I have another launchpad that sniffs the data so I detect the send. On the other hand, the receiver sees this command and replies with another packet that I detect through the sniffer but I don't see it on the first board.

      Should I add a pendCmd to postCmd? Is it not possible to receive only through postCmd?
      I always use a runCmd for TX and a postCmd for RX, is it correct?

      best regards,
      Vincenzo

    • 0 in reply to Vincenzo Cristiano
      TI__Genius 10580 points

      Vincenzo,

      I'd recommended looking at the RF driver .h file <cc26x2_cc13x2 sdk install location>/source/ti/drivers/rf/RFCC26X2.h (excerpt below from lines 168-226)

      rf_postCmd() and rf_pendCmd() are asynchronous. rf_runCmd() is synchronous.

      The RF core supports 3 different kinds of commands:

      1. Direct commands
      2. Immediate commands
      3. Radio operation commands

      Direct and immediate commands are dispatched via #RF_runDirectCmd() and
      #RF_runImmediateCmd() respectively. These functions block until the command
      has completed and return a status code of the type #RF_Stat when done.

      @code
      #include <ti/devices/${DEVICE_FAMILY}/driverlib/rf_common_cmd.h>

      RF_Stat status = RF_runDirectCmd(rfHandle, CMD_ABORT);
      assert(status == RF_StatCmdDoneSuccess);
      @endcode

      Radio operation commands are potentially long-running commands and support
      different triggers as well as conditional execution. Only one command can be
      executed at a time, but the RF driver provides an internal queue that stores
      commands until the RF core is free. Two interfaces are provided for radio
      operation commands:

      1. Asynchronous: #RF_postCmd() and #RF_pendCmd()
      2. Synchronous: #RF_runCmd()

      The asynchronous function #RF_postCmd() posts a radio operation into the
      driver's internal command queue and returns a command handle of the type
      #RF_CmdHandle which is an index in the command queue. The command is
      dispatched as soon as the RF core has completed any previous radio operation
      command.

      @code
      #include <ti/devices/${DEVICE_FAMILY}/driverlib/rf_common_cmd.h>

      RF_Callback callback = NULL;
      RF_EventMask subscribedEvents = 0;
      RF_CmdHandle rxCommandHandle = RF_postCmd(rfHandle, (RF_Op*)&RF_cmdRx,
      RF_PriorityNormal, callback, subscribedEvents);

      assert(rxCommandHandle != RF_ALLOC_ERROR); // The command queue is full.
      @endcode

      Command execution happens in background. The calling task may proceed with
      other work or execute direct and immediate commands to interact with the
      posted radio operation. But beware that the posted command might not have
      started, yet. By calling the function #RF_pendCmd() and subscribing events of
      the type #RF_EventMask, it is possible to re-synchronize to a posted command:

      @code
      // RF_EventRxEntryDone must have been subscribed in RF_postCmd().
      RF_EventMask events = RF_pendCmd(rfHandle, rxCommandHandle,
      RF_EventRxEntryDone);

      // Program proceeds after RF_EventRxEntryDone or after a termination event.
      @endcode

      The function #RF_runCmd() is a combination of both, #RF_postCmd() and
      #RF_pendCmd() and allows synchronous execution.

      -Daniel