4.1. CSL

4.1.1. Introduction

The Chip Support Library constitutes a set of well-defined APIs that abstract low-level details of the underlying SoC device so that a user can configure, control (start/stop, etc.) and have read/write access to peripherals without having to worry about register bit-field details. The CSL services are implemented as distinct modules that correspond with the underlying SoC device modules themselves. By design, CSL APIs follow a consistent style, uniformly across Processor Instruction Set Architecture and are independent of the OS. This helps in improving portability of code written using the CSL.

CSL is realized as twin-layer – a basic register-layer and a more abstracted functional-layer. The lower register layer comprises of a very basic set of macros and type definitions. The upper functional layer comprises of “C” functions that provide an increased degree of abstraction, but intended to provide “directed” control of underlying hardware.

It is important to note that CSL does not manage data-movement over underlying h/w devices. Such functionality is considered a prerogative of a device-driver and serious effort is made to not blur the boundary between device-driver and CSL services in this regard.

CSL does not model the device state machine. However, should there exist a mandatory (hardware dictated) sequence (possibly atomically executed) of register reads/writes to setup the device in chosen “operating modes” as per the device data sheet, then CSL does indeed support services for such operations.

The CSL services are decomposed into modules, each following the twin-layer of abstraction described above. The APIs of each such module are completely orthogonal (one module’s API does not internally call API of another module) and do not allocate memory dynamically from within. This is key to keeping CSL scalable to fit the specific usage scenarios and ease the effort to ROM a CSL based application.

In general for application recommended interfaces to be used will be driver API. CSL Functional layer APIs could be used for low-level access when required. CSL Register layer memory map is available for being used under rare cases in application when required.

The source code of the CSL is located under $(PDK_BASE_DIR)\packages\ti\csl directory.

4.1.2. User Interface

4.1.2.1. Application Integration

CSL is common package supporting multiple devices.Software layer using CSL source would need to pass compile time define -DSOC_XXX. Refer ticslsoc.h for list of devices/SOC’s

Refer list of APIs/interfaces available under <PDK_INSTALL_DIR\packages\ti\csl> directory.

Chip Support Library Summary
Component Type	Library
Install Package	PDK
Install Directory	PDK_INSTALL_DIR\packages\ti\csl
Endian Support	Little
Linker Path	PDK_INSTALL_DIR\packages\ti\csl
Include Paths	PDK_INSTALL_DIR\packages\
Reference Guides	See docs under Install Directory

4.1.3. Application

4.1.3.1. Examples

These are example projects to test the functionality of API in CSL-FL layers. The following is the list of CSL-FL test examples which are supported with the CSL library:

CSL-FL examples are mostly baremetal examples. Refer the following links for further information about the CSL Examples.

ADC	CSL ADC Singleshot Example
CRC	CSL CRC CPU Example
DCC	CSL DCC Example
ECC	CSL ECC Example
ESM	CSL ESM Example
MAILBOX	CSL MAILBOX Example
MCAN	CSL MCAN Example
MCSPI	CSL MCSPI Example
OSPI	CSL OSPI Example
R5F MPU	CSL R5F MPU Example
RTI	CSL RTI Example
SPINLOCK	CSL SPINLOCK Example
UART	CSL UART Example
VTM (Voltage and Thermal Management)	CSL VTM Sensor Read Example
	CSL VTM Temperature Alert Example
	CSL VTM Max Out of range Example

• All the output binary files will be generated in common location i.e. PDK_INSTALL_DIR\packages\ti\binary\[EXAMPLE]\bin\[BOARD]\