Software Overview¶

The SimpleLink Wi-Fi SDK delivers components that enable engineers to develop applications on the Texas Instruments SimpleLink CC35xx family of wireless microcontroller (MCUs). This powerful software toolkit provides a cohesive and consistent software experience for all SimpleLink CC35xx wireless MCU users by packaging essential software components, such as a Bluetooth® Low Energy (Bluetooth LE) protocol stack supporting Bluetooth 5.4, and Wi-Fi 6 networking stack based on LwIP (https://savannah.nongnu.org/projects/lwip/), as well as the FreeRTOS kernel and TI Drivers in one easy-to-use software package along with example applications and exhaustive documentation.

The SimpleLink MCU portfolio offers a single development environment that delivers flexible hardware, software and tool options for customers developing wired and wireless applications. With 100 percent code reuse across host MCUs, Wi-Fi™, Bluetooth Low Energy, Sub-1GHz devices and more, choose the MCU or connectivity standard that fits your design. A one-time investment with the SimpleLink software development kit (SDK) allows you to reuse often, opening the door to create unlimited applications. For more information, visit www.ti.com/simplelink.

SDK Components¶

The SDK components are used together to build applications. The SDK components relate to each other as shown in the following diagram.

Starting from the bottom of this architecture diagram, the components are as follows:

Hardware Abstraction Layer (HAL): C functions that abstract writes to hardware registers. This is the layer the drivers and OS kernel use to access hardware features. Certain hardware settings can be configured using the Sysconfig tool.
OS/Kernel : The kernel provides services such as timing and scheduling of tasks. TI SimpleLink SDKs come with the FreeRTOS kernel. Using a kernel is optional;
- The Driver Porting Layer (DPL) abstracts driver interfaces. Drivers use RTOS features such as clocks, interrupts, mutexes, and semaphores. By abstracting this functionality, applications that use TI Drivers can use the FreeRTOS kernel.
- The POSIX layer abstracts the RTOS kernel functionality used by applications. The POSIX layer allows examples and user applications to be easily ported to use a different kernel. Using this layer is optional.

TI Drivers API: Exposes functionality of the hardware-specific drivers in the same way across all TI SimpleLink devices. Though the hardware implementation of the UART may be different on different chipsets, the TI Drivers API used to access its common functionality is the same. TI Drivers can be configured manually or using the Sysconfig tool.
Middleware: Add functionality on top of drivers. Communications stacks and graphics libraries are examples of middleware.
Examples: The SDK provides a wide range of examples. Their purpose is to make it easy to start writing applications. Each example comes with its own documentation and project files. Examples are provided that use the supported RTOS kernels. For certain SDKs, examples that do not use an RTOS are also provided.

Directory Structure¶

The SDK is installed in /ti or c:ti by default. This is also the installation location for any plug-ins that are installed alongside the SDK. This is the top-level directory structure of the SDK installation:

The “docs” directory contains all the documentation files for the various SDK components.
The “examples” directory contains a number of example applications for each supported board.
The “kernel” directory contains the files required to use the FreeRTOS kernel. The kernels implement the DPL and POSIX layers, which allow an SDK application to switch between the supported kernels.
The “source” directory contains source code, libraries, and linker files used when building applications. This includes files for drivers, boards, devices, middleware, and more. For example, the source code for all the TI Drivers is provided here. See the following figure for more about the contents of this directory tree.

Since the same directory structure is used across the different SDKs in the TI SimpleLink family, it is possible to move application code between the different devices without making significant changes to the file structure or include paths.

The following figure shows a high-level view of the “source” directories that are common to all device types. The SDK provides additional features for specific device families.

../../_images/packageStructure_narrow.png

The following figure similarly provides an overview of the “examples” directory contents that are common to all device types.

Tools and Utilities Included¶

The SDK does not contain an IDE or code generation tools such as a compiler and linker. You should have one of the supported code generation tool suites available. The supported suites are Code Composer Studio with TI’s Code Generation Tools, and the GNU Compiler Collection (gcc).

Some versions of the SDK also offer functionality-specific tools, such as the WiFi Toolbox.

The CC35xx utilizes the Wi-Fi toolbox to assist in signing images and flashing them into the device, allowing for maximum security and prevention of malicious people from programming the device. To achieve this, customers must “activate” the device, or install a root of trust (and configuring other settings), which will be used to validate any images that are to be programmed to the device.

For more information read Activation and Fuses

TI Drivers¶

The SDK includes drivers for a number of peripherals. These drivers are provided in the <SDK_INSTALL_DIR>/source/ti/drivers directory. The driver examples show how to use these drivers.

Some of the drivers are available only for certain target families. Some examples of drivers supported on several target families include GPIO, I2C, Power, SPI, UART, and Watchdog. There are many more. See the [detailed reference information](../drivers/doxygen/html/index.html) for the complete list of TI Drivers for your target family along with full information about the APIs and configuration structures.

Driver Framework¶

TI drivers have a common framework for configuration and a set of APIs that all drivers implement. Applications interface with a TI driver using a top-level driver interface. This interface is configured via a set of data structures that specify one or more specific lower-level driver implementations. TI Drivers can be configured manually or using the SysConfig tool.

TI drivers can be split into two categories: instance-based drivers and singleton drivers.

Singleton drivers such as GPIO and Power only have a single instance for the entire application. They only need to be initialized with Driver_init() once and can then be called without the need for a handle.

Instance based drivers support multiple instances of the same driver coexisting in the same application. These might each target their own hardware peripheral on the device such as UART or allow time-division multiplexed access to a single hardware peripheral by the driver. Such instance-based drivers support all the standard APIs given below.

void Driver_init(void) - Initializes the driver. This function must be called only once and before any calls to the other driver APIs. Generally, this is done before the RTOS Kernel is started.
void Driver_Params_init(Driver_Params *params) - Initializes the driver’s parameter structure to default values. All instance-based drivers implement the Params structure. The Params structure is empty for some drivers.
Driver_Handle Driver_open(uint_least8_t index, Driver_Params *params) - Opens the driver instance specified by the index with the params provided. If the params field is NULL, the driver uses default values. This function returns a handle that will be used by other driver APIs and should be saved. If there is an error opening the driver or the driver has already been opened, Driver_open() returns NULL.
void Driver_close(Driver_Handle handle) - Closes the driver instance that was opened, specified by the driver handle returned during open. This function closes the driver immediately, without checking to see if the driver is currently in use. It is up to the application to determine when to call Driver_close() and to ensure it doesn’t disrupt on-going driver activity.

Drivers Porting Layer (DPL)¶

The Drivers Porting Layer allows the TI drivers to work with any supported RTOS kernel.

The TI Drivers use DPL APIs provided by various RTOS Kernels for clock, interrupt, mutex, semaphore, and other services. However, the DPL abstracts the RTOS kernel functionality used by the drivers so that the application is not dependent on any particular RTOS.

Board Files¶

Unless you are using SysConfig, TI Driver examples contain a board-specific C file (and its companion header file). The filenames are board.c and board.h, where board is the name of the launchpad. All the TI Driver examples for a specific board use the same board files. These files are considered part of the example application, and you can modify them as needed.

The board files perform board-specific configuration of the drivers provided by the SDK. For example, they typically configure the GPIO ports and pins and configure use of the board LEDs.

SysConfig¶

The SysConfig tool makes it easy to configure components like TI Drivers and device-specific components (such as the networking stack, EasyLink, and WiFi).

For this release, SysConfig is used in the majority of the examples and is the recommended mechanism for configuring TI Drivers and device-specific components. Please note that SysConfig is not required though. A project can still use the previous board file approach. Please refer to the rtos/<board>/drivers/empty_legacy example to see this approach.

You can choose to use SysConfig no matter what your choice is for the following:

Device: Supported for a range of SimpleLink devices and boards.
IDE: Supported for CCS Desktop, CCS Cloud, and as a standalone desktop tool
Compiler Toolchain: Supported for the TI and GCC toolchains.
RTOS: Supported for FreeRTOS

This section focuses on configuring TI Drivers, since all devices support TI Drivers using a common configuration framework. For TI Drivers, the SysConfig tool generates source files–ti_drivers_config.c and ti_drivers_config.h–to be compiled and linked with the application during builds. Additional components, such as networking stacks, may be configurable using SysConfig for certain targets, and will cause additional source files to be generated. See the device-specific documentation for information about any additional components that SysConfig can be used to configure.

As shown above, SysConfig provides descriptions and links to access reference documentation for the drivers and other modules you can configure.

Besides the ease-of-use provided by SysConfig, the tool resolves conflicts on the fly. This ensures that you create a valid pin and TI Driver configuration. In addition, you can view diagrams of the pin configuration as you make changes.

SysConfig settings are stored in a file called <project>.syscfg. Its output files are stored in a syscfg folder within the build folder.

You open (with a simple double click) the <project>.syscfg file in SysConfig and modify it as needed. You can view the ti_drivers_config.c and ti_drivers_config.h file contents within SysConfig and see how configuration changes affect the generated code.

When you save the <project>.syscfg file and build the project, the following actions occur:

The ti_drivers_config.c and ti_drivers_config.h are generated from the <project>.syscfg file.
The ti_drivers_config.c and ti_drivers_config.h are compiled to create a ti_drivers_config.o object file.
The ti_drivers_config.o object is linked with the rest of the libraries to create the application.

Some users may choose to use SysConfig initially to generate the ti_drivers_config.c, ti_drivers_config.h (and other component configuration files) and then exclude the *.syscfg file from the build so that manual changes made to these files are not overwritten. Additionally user may want to add their custom board setup into SysConfig.

Additional information for SysConfig can be found on http://www.ti.com/tool/sysconfig.

Using FreeRTOS with CCS¶

The FreeRTOS Kernel is configured through the SysConfig tool. This is used to enable and disable modules as well as configure device-specific settings. SysConfig will generate three files, and contribute to one more as part of the application project:

ti_freertos_config.c : Contains the source code that is to be compiled for FreeRTOS. This is done by inserting preprocessor statements to #include the C files of all selected modules. The file also contains several hooks used to enable and disable FreeRTOS features such as Queue registration in TI code.
ti_freertos_portable_config.c : This file contains all C code for the application’s architecture and toolchain specific port.
ti_utils_build_linker.cmd.genlibs : The ports of some architecture and toolchain combinations use assembly files. We compile these into prebuilt libraries. This is because we cannot #include assembly files safely. These libraries are then added to the linker invocation through an entry in the ti_utils_build_linker.cmd.genlibs file.

#. FreeRTOSConfig.h : This is the standard FreeRTOS configuration header file that your application will typically #include. The entries in this file will change depending on the device and settings selected in SysConfig. You no longer need to edit FreeRTOSConfig.h yourself. SysConfig will maintain it for you. If you would like to change a FreeRTOS feature or setting that is not exposed in SysConfig, you can remove this file from SysConfig and maintain it yourself.

Changing the FreeRTOS Configuration¶

As with all SysConfig modules, you can either edit their configuration via the SysConfig GUI or by editing the .syscfg file directly in a text editor.

Since the FreeRTOS configuration is stored in a project’s .syscfg file, each project has its own FreeRTOS configuration. Changing one project’s configuration will not impact another project’s configuration.

Why might you want to change the default FreeRTOS configuration?

Reduce the code footprint. For example, you might decrease the heap size or disable Software Timers.

Enable debug options. For example, you might add Assert checking to the configuration.