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.

TI-RTOS GUI for TM4C129x

Hi there,

I am planning to use TM4C129 with TI-RTOS. And I have a few questions so far:

1. The latest TI-RTOS version for TIVA MCU is 2.16.01.14, right?

2. In TI-RTOS examples all Tasks, SWIs and so on are defined statically in the code and NOT in cfg-file. Is the any particular reason for that?

3. Reading RTOS WIKI you can find this note: 

You can use the graphical configuration tool in CCS to easily configure which drivers are used by an application. 

What is it about? As far as I know there is no GUI to configure drivers for TIVA, right?

Thank you 

  • Hi Stan,

    Stan Sidorov said:
    1. The latest TI-RTOS version for TIVA MCU is 2.16.01.14, right?

    Correct

    Stan Sidorov said:
    2. In TI-RTOS examples all Tasks, SWIs and so on are defined statically in the code and NOT in cfg-file. Is the any particular reason for that?

    I think you meant dynamically created? (via Task_create() at runtime?)

    No particular reason.  You can create Tasks statically via the *.cfg file if you prefer.

    Stan Sidorov said:

    3. Reading RTOS WIKI you can find this note: 

    You can use the graphical configuration tool in CCS to easily configure which drivers are used by an application. 

    Let me double check on this.  The driver modules may have changed; if so, then the wiki may be out of date.  Let me get back to you on this.

    Steve

  • Hi Steve, thank you.

    Will look forward to get more info about the 3-rd question.

    Steven Connell said:
    I think you meant dynamically created? (via Task_create() at runtime?)

    I would think so. Whatever we do in cfg-file it is considered to be created statically and at run-time - dynamically. However, if you look at the TI-RTOS driver examples for TivaC you can find opposite. spiloopback_EK_TM4C129EXL_TI:

    /* *  ======== slaveTaskFxn ========
     *  Task function for slave task.
     *
     *  This task runs on a higher priority, since slave
     *  has to be ready for master. Slave SPI sends a
     *  message to master and also receives message from
     *  master. Task for this function is created
     *  statically. See the project's .cfg file.
     */
    Void slaveTaskFxn (UArg arg0, UArg arg1)
    {
    ...
    }
    
    int main(void)
    {
    ...
        /* Construct master/slave Task threads */
        Task_Params_init(&taskParams);
        taskParams.priority = 1;
        taskParams.stackSize = TASKSTACKSIZE;
        taskParams.stack = &task0Stack;
        Task_construct(&task0Struct, (Task_FuncPtr)masterTaskFxn, &taskParams, NULL);
    
        taskParams.stack = &task1Stack;
        taskParams.priority = 2;
        Task_construct(&task1Struct, (Task_FuncPtr)slaveTaskFxn, &taskParams, NULL);
    ...
    }
    

    So that is why I got confused. 

    Thanks

  • Hi Stan,

    Stan Sidorov said:
    Will look forward to get more info about the 3-rd question.

    I can confirm.  The drivers used to be selectable via the *.cfg file in the TI-RTOS "overview" page of XGCONF.  Now, the drivers are always included automatically.

    Stan Sidorov said:
    I would think so. Whatever we do in cfg-file it is considered to be created statically and at run-time - dynamically. However, if you look at the TI-RTOS driver examples for TivaC you can find opposite. spiloopback_EK_TM4C129EXL_TI:

    Stan Sidorov said:
    Task_construct(&task0Struct, (Task_FuncPtr)masterTaskFxn, &taskParams, NULL);

    Ah yes, the example is using "construct."  It does look misleading; this actually isn't dynamically allocating memory, the storage is actually statically allocated and the construct call initializes it.

    You can see an example explaining the differences in the RTSC Module Primer:

    http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/rtsc/3_15_03_67/exports/docs/rtscpedia/RTSC_Module_Primer/RTSC_Module_Primer__Lesson_4.html

    From the example there:

    "Put another way, RandGen_create allocates and initializes storage for a new instance object; RandGen_construct just initializes storage already allocated in a variable of type RandGen_Struct."

    Steve

  • Hi Steve,

    Thanks. Now all make sense.

    Stan