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.

Compiler/LAUNCHXL-CC1312R1: Is there a resource to determine what files to include to use a given peripheral?

Part Number: LAUNCHXL-CC1312R1
Other Parts Discussed in Thread: SYSCONFIG, MSP430FR2355, CC2650

Tool/software: TI C/C++ Compiler

  I was able to compile and load the uartecho.c demo program. I then took the core code from the uart task and added it into the rfEchoRx.c demo program. I add the various .h files that were in the uartecho.c demo. I had undefined errors on the macro constant CONFIG_UART_0  , and some undefined symbol problems:

undefined first referenced
symbol in file
--------- ----------------
UART_config C:/ti/simplelink_cc13x2_26x2_sdk_3_40_00_02/source/ti/drivers/lib/drivers_cc13x2.aem4f<UART.oem4f>
UART_count C:/ti/simplelink_cc13x2_26x2_sdk_3_40_00_02/source/ti/drivers/lib/drivers_cc13x2.aem4f<UART.oem4f>

So my question is when you want to use a peripheral in TI-RTOS, is where a reference where you can see what you have to include ? 

Enclosed is the file that won't compile, the main_tirtos.c I modifed from the "stock" rfEchoRx.c example.

Windows 10, latest versions of everything downloaded 3/22/2020. CCS  Version: 10.0.0.00010   LAUNCHSL-CC1312R has 'E' version chip on it (latest vesrion)

 - pete

3240.main_tirtos.c
/*
 * Copyright (c) 2016-2017, Texas Instruments Incorporated
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 *
 * *  Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer.
 *
 * *  Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in the
 *    documentation and/or other materials provided with the distribution.
 *
 * *  Neither the name of Texas Instruments Incorporated nor the names of
 *    its contributors may be used to endorse or promote products derived
 *    from this software without specific prior written permission.
 *
 * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
 * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
 * THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
 * PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
 * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
 * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
 * PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
 * OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,

 * WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
 * OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE,
 * EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
 */

/*
 *  ======== main_tirtos.c ========
 */
#include <stdint.h>
#include <stddef.h>

/* POSIX Header files */
#include <pthread.h>

/* RTOS header files */
#include <ti/sysbios/BIOS.h>

/* Driver configuration */
#include <ti/drivers/Board.h>

/*// PDH UART head file */
#include <ti/drivers/GPIO.h>
#include <ti/drivers/UART.h>

// include this so can do System_printf
#include <xdc/runtime/System.h>

/* Driver configuration */
#include "ti_drivers_config.h"

extern void *mainThread(void *arg0);

/* Stack size in bytes */
#define THREADSTACKSIZE    1024

/*
 *  ======== main ========
 */
int main(void)
{
    pthread_t           thread;
    pthread_attr_t      attrs;
    struct sched_param  priParam;
    int                 retc;
    int                 detachState;

    /* Call driver init functions */
    Board_init();
    Board_initGeneral();

    /* Set priority and stack size attributes */
    pthread_attr_init(&attrs);
    priParam.sched_priority = 1;

    detachState = PTHREAD_CREATE_DETACHED;
    retc = pthread_attr_setdetachstate(&attrs, detachState);
    if (retc != 0) {
        /* pthread_attr_setdetachstate() failed */
        while (1);
    }

    pthread_attr_setschedparam(&attrs, &priParam);

    retc |= pthread_attr_setstacksize(&attrs, THREADSTACKSIZE);
    if (retc != 0) {
        /* pthread_attr_setstacksize() failed */
        while (1);
    }

    retc = pthread_create(&thread, &attrs, mainThread, NULL);
    if (retc != 0) {
        /* pthread_create() failed */
        while (1);
    }

    BIOS_start();

    //// Uart Code from the uartecho.c demo
    UART_Handle      uart;
    UART_Params      uartParams;
    const unsigned char uartBootMessage[] = "Hello World\n";

    /* Call driver init functions */
    GPIO_init();
    UART_init();

    /* Create a UART with data processing off. */
    UART_Params_init(&uartParams);
    uartParams.writeDataMode = UART_DATA_BINARY;
    uartParams.readDataMode = UART_DATA_BINARY;
    uartParams.readReturnMode = UART_RETURN_FULL;
    uartParams.readEcho = UART_ECHO_OFF;
    uartParams.baudRate = 115200;

    // uart = UART_open(CONFIG_UART_0, &uartParams);     // got undefined on CONFIG_UART_0
    uart = UART_open(0, &uartParams);

    if (uart == NULL) {
        /* UART_open() failed */
        while (1);
    }

    // Print a boot message
    retc = UART_write(uart, uartBootMessage, sizeof(uartBootMessage));
    System_printf("The UART wrote %d bytes\n", retc);

    return (0);
}

  • Hi Peter, 

    I would assume your project has a ".syscfg" file which means you need to configure this to match your device setup. In short, you would open this file (should bring up a GUI) and add in a UART to your project. This will then be used to generate the board files for the project that includes the missing structures.

  •   this worked.  I was (and still am a bit) confused with the difference between the .syscfg file and the board.h

  • Hi Peter, 

    The "board.h" file is typically not used anymore when SysConfig is present, did you find this used in any of the drivers examples you look at? 

  • All of the examples I look at using the Resource Explorer have a Board.h in the main_tirtos.c files.

    And there is a Board.h in all the source trees.

     - pete

  •  today I remover all TI software from my Windows 10 machine. I re-loaded CSS with the minimal amount of options. The version is 10.0.0.00010. When I look at the only "Demo" program for the CC1312, in main_tirtos.c   I see #include <ti/drivers/Board.h>

    If I go to the "drivers" and look at the uartecho main_tirtos.c I also see the same include.

    Importing the demo uartecho, I see the include in main_tirtos.c    I also see the .syscfg

    So I now understand how I must use the .syscfg tool to make sure all the drivers and their include files are in a project. I am however at a loss to understand your statement that "The "board.h" file is typically not used anymore when SysConfig is present". Would I be correct in assuming that you mean there is no distinct board.h file, however there is an include file <ti/drivers/Board.h>  ?

    While the loaded version of the uartecho has no board.h file I still see the file Board.h in the "Includes" just as I saw it in the screen shot I previously provided. This is consistent with what you have said. Note that there is much confusion here with the subtle difference between "board.h" and "Board.h" (the capital letter B).

    So I think we are good. I would love to have a better description of the structure of where all these things "live" in the directory. I am also curious as to if there is a more recent version of the TI-RTOS reference manual than the 2016 version. I want to have a way to see all the system calls/subroutines and their parameters for all the "pieces" that one might use (i.e. RTOS, UART, RF, Timers, etc). Having that would make it easier to look at the various examples in the drivers section and learn how things work.

    So mark this resolved, Advise on the best reference guide for the TI-RTOS or any "live"/web based tools to look at these. A lot of the documentation out there is very dated.

     - pete

  • Hi Pete,

    It is true that CCS sees the "Board.h" file as it list all the files it can reach based on the project setup. The Board.h file itself is not really used by the demo applications anymore when SysConfig is in used. In this particular case it seems they simply left the "Board.h" hanging in the main_tirtos.c file to be able to share this in between legacy projects and new SysConfig projects.

    Before SysConfig, "Board.h" was the header file used to pull in all the driver structures needed. The file itself is basically just a bunch of re-defines (so that these align across devices) and a link to the board specific file (in your case, this would have been CC1312R1_LAUNCHXL.h).

    Now when we instead use SysConfig to generate these files (the output of SysConfig is similar to that of the old CC1312R1_LAUNCHXL.c/h and Board.h files), we instead include "ti_drivers_config.h" as you can see in the uartecho.c file. If you want, you could view the SysConfig "ti_drivers_config.h" file as the "Board.h" equivalent.

    The most up to date documentation is what you find in the resource explorer:

    http://dev.ti.com/tirex/explore/node?node=AOSQDVXMohlV5LElLx5wxA__pTTHBmu__LATEST

    Note that TI-RTOS and TI Drivers do not share documentation as they are different components in the SDK. The drivers typically have dependency graphs when looking at the device specific documentation (that would be the files that got "CC26X*" in the name). 

  •   Thank you for that detailed explanation, it helps a lot.

      The desire to have a simple way to move between different chips, many of which have minor differences, is often hard to achieve. As such, users will at some point have to dig down into the process and understand what all the files are, what the hierarchy is and understand the build and link process. This is particularly daunting for new users of the SDK/IDE like myself even if we've been doing this since the early 8-bit uP days. This is the first time I've trusted an RTOS other than one I wrote. I've been burned before.

      I'll read the documentation and hopefully things will become clearer, and any support I need will be more focused. The board I'm working on uses the 900 MHz CC1312, the Bluetooth LE CC2650 MOD, the TRF796x RFID chip, the MSP430FR2355 as an SPI to dual serial device. All of the temperature, pressure, humidity and light sensors are TI, as are the two switching regulators for +5 and +3 and the logic "glue" chips. The next board in the series adds the CC3220MODx WiFi part and and the MSP432P401 as the system controller that replaces a Raspberry Pi to finally get the final product. I'm counting on TI to not let me down !

     - pete

  • Hi Pete,

    We are constantly working on the documentation but there is so many things that should really be covered which means that some gets more or less covered. The SysConfig is a rather new component but there exists some documentation for it within the User's Guides of the SDK components. This is typically the best place to find this kind of information (for future notice). For what ever information you can't find, you can always reach out to us here on E2E for a clarification :)

    Thanks for sharing information about your design! Have you considered the CC1352 device instead of the CC1312 and CC2650MOD? This is a dual band device which means you can run both Sub1GHz and BLE on it "at the same time".

    We (TI) got the Dynamic Multi-Protocol Manager which allows you to quite easily setup an application that can run two protocols at the same time. They do however share the same radio so there is a theoretical loss in radio time as there could be resource conflicts but for many use-cases, this is not really an issue.

    What you can get out of considering such a solution is not only a smaller design (as you only need one IC) but also you will have a single SDK for both the Sub1GHz and BLE application. The CC2650 device is "stuck" on an older SDK and is not supported in the simplelink family, this means that it does receive very (very) limited number of updates. The BLE stack available for this device is rather old and it would not have gotten all potential bug-fixes that the newer stacks has.

    As the CC3220 devices is also inside the Simplelink family, it would really only be the CC2650 that would have a total different SDK solution (the CC3220 do has its own SDK but it follows the "SimpleLink" structure) which from a development point of view could be bothersome as it will not share the same structure in terms of work flow as for example the CC1312 and CC3220.