|
|
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-RTOS7 (SYS/BIOS), FreeRTOS, and NoRTOS with examples provided for each variant. Lastly, the drivers are supported by SysConfig to enable easy re-configuration of the drivers.
TI-Driver APIs follow a common initialization model. This model typically consists of:
Each driver documents how to initialize, open, use, and close the driver. Unless otherwise stated, the initialization function, Driver_init, may be called multiple times by the application. It is only required that the initialization is done once. For drivers which have an open function, Driver_open, it must be called per instance of the driver to be used. Each instance of the driver corresponds to a unique index in the Driver Configuration, Driver_config. Multiple software entities may use the same driver concurrently. For example, a Bluetooth or WiFi stack may utilize a driver instance. The application may concurrently use the same driver assuming it has opened a unique instance of the driver. Let's examine the ADC driver for example.
A couple observations from this code example:
For our simple example, that's all we need. However, for full details on the ADC--and other drivers, reference the Drivers and Documentation section below.
Shown below is a matrix of available drivers and documentation.
| Driver Interfaces | CC23X0 Implementations | Module Interfaces | Supported Device Wildcards |
|---|---|---|---|
| ADC.h | ADCLPF3.h | ADC | CC23X0 |
| AESCBC.h | AESCBCLPF3.h | AES | CC23X0 |
| AESCCM.h | AESCCMLPF3.h | AES | CC23X0 |
| AESCTR.h | AESCTRLPF3.h | AES | CC23X0 |
| AESCTRDRBG.h | AESCTRDRBGXX.h | AES | CC23X0 |
| AESECB.h | AESECBLPF3.h | AES | CC23X0 |
| AESGCM.h | AESGCMLPF3.h | AES | CC23X0 |
| BatteryMonitor.h | BatteryMonitorLPF3.h | Battery Monitor and Temperature Sensor (BATMON) | CC23X0 |
| CAN.h | TCAN455X.h | SPI and TCAN455X CAN Controller | CC23X0 |
| CANMCAN.h | |||
| MCAN.h | |||
| Comparator.h | ComparatorLPF3LP.h | Low power comparator | CC23X0 |
| DMA | UDMALPF3.h | µDMA | CC23X0 |
| ECDH.h | ECDHLPF3SW.h | ECDH | CC23X0 |
| ECDSA.h | ECDSALPF3SW.h | ECDSA | CC23X0 |
| GPIO.h | GPIOLPF3.h | IOC | CC23X0 |
| GPTimer | LGPTimerLPF3.h | General-Purpose Timers | CC23X0 |
| I2C.h | I2CLPF3.h | I2C | CC23X0 |
| NVS.h | NVSLPF3.h | VIMS | LPF3 |
| NVSRAM.h | |||
| NVSSPI25X.h | SSI | ||
| Power.h | PowerCC23X0.h | Power, Reset, and Clock Management | CC23X0 |
| SHA2.h | SHA2LPF3SW.h | SHA | CC23X0 |
| SD.h | SDSPI.h | SSI SPI.h | CC23X0 |
| SPI.h | SPILPF3DMA.h | SSI | CC23X0 |
| Temperature.h | TemperatureLPF3.h | Battery Monitor and Temperature Sensor (BATMON) | CC23X0 |
| RNG.h | RNGLPF3RF.h | RNG | CC23X0 |
| UART2.h | UART2LPF3.h | UART | CC23X0 |
| Watchdog.h | WatchdogLPF3.h | Watchdog Timer | CC23X0 |
The Display driver is designed to abstract operations & considerations specific to a given output method.
| Display Driver Interface | Implementations |
|---|---|
| Display.h | DisplaySharp.h DisplayHost.h DisplayExt.h DisplayUart2.h |
Logging is a lightweight framework for instrumenting target code.
| Log Interface | Sinks |
|---|---|
| Log.h | LogSinkBuf.h |
These helper apps utilize TI drivers and are available to user applications.
| Modules | Interfaces | Descriptions |
|---|---|---|
| Button.h | GPIO.h | Provides an API for button-like hardware attached to device pins. |
| LED.h | GPIO.h | Provides an API for LEDs attached to device pins. |
| PWM.h |
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.