TI-Drivers is a collective of peripheral drivers for TI's SimpleLink portfolio. The drivers are centered around a portable application programming interface (API) which enables seamless migration across the SimpleLink SDK portfolio. Unless specifically stated otherwise, TI-Drivers are designed to be thread safe and work seamlessly inside of a real time operating system (RTOS) application. All TI-Driver implementations utilize the Power driver APIs to ensure low power consumption at all times. The drivers support TI-RTOS (SYS/BIOS) and NoRTOS with examples provided for each variant. Lastly, the drivers are supported by SysConfig to enable easy re-configuration of the drivers.
Shown below is a matrix of available drivers and documentation.
The Display driver is designed to abstract operations & considerations specific to a given output method.
Display Driver Interface | Implementations |
---|---|
Display.h | DisplayHost.h DisplayUart.h |
These helper apps utilize TI drivers and are available to user applications.
Module | Description |
---|---|
Button.h | Provides an API for button like hardware attached to a GPIO line. |
LED.h | Provides an API for LEDs attached to GPIO lines. |
These utilities are helper modules available to drivers.
Module | Description |
---|---|
List.h | Double linked list |
Random.h | Fast and light-weight pseudo random number generator |
RingBuf.h | Array-based ring buffer for bytes |
SDFatFS.h | Wrapper to enable the use of file systems for the SD driver. |
SPIFFSNVS.h | Enables NVS as the physical layer to read/write memory for the SPIFFS file system |
The generic driver interface defines a configuration structure using the typedef
keyword. The name of this declared type follows the naming pattern <driver>_Config
. A driver is configured by declaring an array of this configuration data structure. Each config
array index contains pointers to other data objects necessary for the driver to function at runtime. These data objects may include a hardware attributes, a function table, and object memory. Multiple indexes of the config
array should not share these data objects--with the exception of the function table. Each index of the config
array supports an independent instance of the driver.
<driver>_Config
, must have a specific C identifier. This identifies follows the case-sensitive pattern <driver>_config
.<driver>_config
. This must also have a specific C identifier following the case-sensitive pattern <driver>_count
. The data type must be a uint_least8_t
.The driver interface is joined together during the link process at build time. The <driver>_config
and <driver>_count
symbols are resolved.
The driver configuration files contain all driver configurations needed by TI-Drivers at runtime. The SysConfig tool is used to automatically generate the TI-Driver's configuration files. Two files are presently generated for TI-Drivers:
The driver objects are device specific structures that hold data for an instance of a driver. The driver objects are used exclusively by the driver and should never be accessed by the application. Device specific drivers define an object structure as a new type using the typedef
keyword. Each index in a driver's configuration will contain a pointer to a driver object.
The hardware attributes, also commonly referred to as HWAttrs
, are device specific settings that typically do not change during runtime operation of a driver. The hardware attributes also aid in abstracting the generic driver interface from the device specific hardware. Device specific drivers define a hardware attribute structure as a new type using the typedef
keyword. Each index in a driver's configuration will contain a pointer to a hardware attribute structure.
The function pointer table is a structure simply containing pointers to functions. Each index in a driver's configuration will contain a pointer to a function pointer table. The TI-Driver's interface uses function pointers to abstract a generic driver from a device specific driver. Each device specific driver declares a default function pointer table which may be referenced by default in the driver's configuration.
The NoRTOS framework module is provided to enable use of drivers without an underlying operating system. The module provides interfaces used by drivers to perform delays, block execution, register interrupts and more.