TI C2000 CLA Software Development Guide

C2000 CLA Complete Guide

Core Technology Analysis and Development Practice

In real-time control systems, computational performance often determines the response speed and control accuracy of the system. The Control Law Accelerator (CLA) integrated into the Texas Instruments (TI) C2000 series microcontroller is a revolutionary hardware acceleration technology. It is a fully programmable, independently running 32-bit floating-point coprocessor designed specifically for math intensive computations. CLA can execute real-time control algorithms in parallel with the C28x main CPU, theoretically doubling the overall computing performance. It is particularly suitable for handling low latency control loops, filtering algorithms, and complex mathematical operations.

This article is aimed at embedded engineers, providing a systematic technical guide from multiple dimensions such as CLA's independent operation mechanism, programming model, data sharing, task triggering, debugging techniques, and common difficult problems, to help developers quickly grasp the development points of CLA and avoid engineering pitfalls.

Independence and synchronization mechanism of CLA

CLA is a computing unit independent of C28x CPU. Once configured by the main CPU, CLA can autonomously execute algorithms without the need for intervention from the main CPU. It has its own independent bus structure, register group, pipeline, and processing unit. More importantly, CLA can directly access a large number of peripheral registers, such as ePWM, HRPWM, eCAP, eQEP, ADC, DAC, comparator subsystems, etc., making it very suitable for handling time sensitive control tasks.

The synchronization between C28x and CLA mainly relies on triggering mechanisms. The main CPU can start CLA tasks by writing specific registers or using peripheral interrupts. At the same time, CLA can also send interrupts to the main CPU to notify task completion or occurrence of floating-point overflow/underflow and other abnormal events. This bidirectional interrupt mechanism allows two processors to work in coordination, for example, C28x is responsible for system level communication and diagnostics, while CLA focuses on the underlying fast control loop.

CLA programming essentials: C compiler and data type restrictions

CLA fully supports C programming language, and TI's TMS320C28x code generation toolchain integrates the CLA C compiler. Developers can write CLA programs just like writing regular C code, but due to the constraints of the CLA architecture, there are several limitations to C language support. For more information, please refer to the "CLA Compiler" chapter in the compiler user guide.

Differences in key data types

There is a significant difference in data type interpretation between C28x and CLA, which is one of the most easily overlooked issues in development.

Integer type: On CLA, int is 32-bit; On C28x, int is 16 bits.

Pointer type: C28x treats pointers as 32-bit data types (address bus width is 22 bits, must be represented by 32 bits); The address bus width of CLA is only 16 bits, so pointers are interpreted as 16 bits.

If a structure is defined in the shared header file and contains pointer members, the interpretation of memory layout by C28x and CLA will be inconsistent, resulting in pointer dereference errors. For example:

c struct {float a;float *b;float *c;} X;

In C28x, b and c each occupy 32 bits (two 16 bit words); In CLA, b and c each occupy 16 bits (one word). If an attempt is made to access * (X.c) in the CLA task, the actual accessed address will be offset incorrectly.

Solution: Use a union to align the pointer with a 32-bit integer, forcing the CLA compiler to allocate the pointer to the lower 16 bits while occupying 32-bit space. For example:

c typedef union {float *ptr;uint32_t pad;} CLA_FPTR;

A more general suggestion is to always use fixed width types defined in std int. h, such as int16_t and uint322-t, to avoid directly using fuzzy types such as int and unsigned int. In addition, shared global variables must be defined in the. c file of C28x, and can only be declared as external variables in CLA code. This is because the data page mechanism of C28x has stricter restrictions, and CLA can access the data defined on the C28x side, otherwise it cannot.

Task triggering and nesting support

The tasks of CLA are similar to interrupt service routines (ISR), with each task initiated by a trigger source. The trigger source can be:

Peripheral interrupts (such as ePWM cycle matching, ADC conversion completion, etc.). To determine which peripheral can trigger which task, please refer to the Device Technical Reference Manual (TRM).

Software forced triggering: C28x can start tasks through IACK instructions or by writing bits to CLA's forced register (MIFRC). For example, IACK # 0x0003 triggers both Task 1 and Task 2 simultaneously.

Another CLA task (with limitations): On some devices, CLA cannot directly force another task, but it can be triggered by interrupting C28x and then triggered by C28x software, or indirectly by writing ePWM registers.

Task nesting

Type 0 and Type 1 CLA: do not support task nesting, only one task can be executed at a time.