• State TI Thinks Resolved
  • Locked Locked
  • Replies 8 replies
  • Answers 2 answers
  • Subscribers 30 subscribers
  • Views 498 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.

Original question:

AWR1642BOOST: SRR Demo - How to start the demo without Matlab GUI

AWR1642BOOST: Hardcode Cfg in SRR demo

Divya Harikumar
Expert 2020 points
Part Number: AWR1642BOOST

Hi,

I want to run the SRR demo just after switching on the sensor. Currently the sensor is waiting for the advFrameCfg command for configuration. Once the configuration is done we need to send the sensorStart for starting the sensor. 

Is there any method to bypass the CLI_Task() and hardcode AdvanceframeCfg and sensorstart ?

Regards,

Divya Harikumar

  • 0
    TI__Guru*** 147964 points

    Hi,

    There may be some delays due to local holidays. Will get back to you next week

    thank you

    Cesar

  • 0
    TI__Mastermind 21025 points

    There are several ways to do this that are already discussed on this forum.  One simple way is to call the handlers for these commands at the end of the CLI init function, as is done in the MRR demo:

     

        static char *dummy[1];

    . . .

    MRR_MSS_CLIAdvancedFrameCfg(1, dummy);
    MRR_MSS_CLISensorStart(2, dummy);

    These handler names may be different in each demo.

      -dave

     

  • 0 in reply to db_woodall
    Expert 2020 points

    Hi Dave,

    I would like to know how by adding the given piece of code, helps in bypassing the CLI?

    Regards,

    Divya Harikumar

  • 0 in reply to Divya Harikumar
    TI__Mastermind 21025 points

    This method does not bypass the CLI, it simply "sends" the commands once the CLI is initialized. The CLI obtains the program configuration and sends the necessary data and events to get the system up and running.  To bypass it entirely would entail adding function calls in the proper order with hardcoded parameters to replace what the CLI handlers are doing.  This is a simpler way to do that.

     -dave

  • 0 in reply to db_woodall
    Expert 2020 points

    Hi Dave,

    I didnt quite understand the code flow

    How does sending dummy commands help the CLI in obatining configuration parameters?

    Does it mean that we still require a configuration port?

    Regards,

    Divya Harikumar

  • 0 in reply to Divya Harikumar
    TI__Mastermind 21025 points

    >How does sending dummy commands help the CLI in obatining configuration parameters?

    Because in this case, the configuration *is* hardcoded internally. It is not sent until the advFrameCfg is received.

    >Does it mean that we still require a configuration port?

    No, if you send advFrameCfg and sensorStart as I described above, you do not need to use the configuration port at all.

     -dave

  • 0 in reply to db_woodall
    Expert 2020 points

    Hi dave,

    I do understand that configuration is not sent until the advFrameCfg is received.

    What i would like to know is what change happens when we add this piece of code?

    1
    2
    3
    4
    5
    6
    static char *dummy[1];
     
    . . .
     
    MRR_MSS_CLIAdvancedFrameCfg(1, dummy);
    MRR_MSS_CLISensorStart(2, dummy);

    Since,both ports still seem to exist in device manager.

    Regards,

    Divya Harikumar

  • 0 in reply to Divya Harikumar
    TI__Mastermind 21025 points

    Hi Divya,

    Yes, both ports still exist (and are operational) but the code simply ignores the CLI port for startup purposes.  Making these function calls simply replaces what happens when the commands are received from the UART.  If you don't think you will use the CLI UART you can disable the code that initializes it.  If you leave it running, the CLI port will still be able to receive commands (such as sensorStop) and respond to them.

       -dave