C2000 CLA 控制率加速器：独立于 CPU 的高频控制环路实现与踩坑实录

这篇算是把系列学习笔记往前推了一步。前面几篇我陆续整理了GPIO、ADC、ePWM、PIE中断这些基础外设，到了这一篇，终于要碰 F280049C 上最有意思的一个模块——控制率加速器 CLA（Control Law Accelerator）。坦白说，刚接触 CLA 的时候，我以为它不过是个能帮忙算数学的硬件加速器，跟那些 DSP 里的协处理器差不多。等到自己动手跑例程才发现，CLA 完全是一个可以独立取指、独立跑控制代码的“第二处理器”，有自己的编译器支持、自己的寄存器组，甚至有自己的调试方式。这篇笔记我就把从零配置 CLA、跑通一个带 ADC 采样和 PWM 输出的小闭环例程的过程记录下来，重点说清楚每一步为什么要这么做，以及那些文档里不会写但实际一定会踩的坑。

这篇文章适合正在学 C2000 系列、准备做数字电源、电机控制或者任何需要高频控制环路的同学。如果你手里恰好是 LaunchXL-F280049C 开发板，那可以直接跟着复现。即使不用同款芯片，CLA 的基本思路在 TMS320F28379D、F28002x 这些带 CLA 的型号上也是通用的，差别主要在外设访问权限和触发源映射上。

1. 先搞清楚 CLA 是什么，CPU 为什么需要它帮忙

1.1 两个“处理器”的分工

很多第一次接触 CLA 的人会把它理解成一个类似 FPU 的浮点运算单元，这个理解其实不准确。FPU 是在 C28x CPU 流水线里的一个运算部件，它还是要等 CPU 取指、译码、送数据，本质上不减轻 CPU 的调度负担。CLA 不一样，它是一个独立的可编程协处理器，有自己的程序计数器、自己的指令流水线、自己的寄存器组，可以不依赖 C28x 主核，直接从内存里取指令并执行代码。

我打一个比方：CPU 像餐厅里的主厨，负责整体节奏、接单、摆盘、协调各个岗位。FPU 相当于主厨手里的那把好刀，刀快了但活还是主厨自己干。CLA 则是另一个熟练的二厨，你告诉他菜谱（程序），再告诉他什么时候开工（触发源），他就能自己完成切配、炖煮这些环节，主厨只需要最后尝一下味道、调整出品。放到嵌入式控制里，CPU 可以把电流环、电压环、滤波算法这些高频、确定性要求高的运算交给 CLA，自己腾出手去跑通信协议栈、人机交互、故障诊断、系统调度，整机性能会明显上一个台阶。

具体到 F280049C，这颗芯片的定位是 Piccolo 系列里的控制型 MCU，主频 100MHz，自带 FPU、TMU（三角函数加速单元）和 VCRC（循环冗余校验单元）。CLA 在时钟配置上跟随 SYSCLK，可以按系统时钟或半速运行，默认常见配置是让它跟 SYSCLK 同频。CLA 的指令集中包含单精度浮点运算指令，所以控制算法里常用的 float 类型计算可以直接编译到 CLA 上跑，不需要手动转成定点或者拆成整数运算。

这里“为什么需要 CLA”这个问题其实值得细想。单纯追求算力的话，C28x CPU + FPU + TMU 跑浮点 PI 控制器已经很快了，但控制环路的问题往往不只是峰值算力，而是实时性、确定性和 CPU 资源的分配。PWM 周期可能是 10kHz 甚至更高，也就是说每 100 微秒就要完成一次采样、一次控制算法计算、一次寄存器更新。如果这个中断服务函数里塞了太多浮点运算，CPU 大部分时间都在进中断、出中断，主循环里的通信、显示和逻辑处理就会变得卡顿。CLA 最大的价值，是把这些时间关键任务从 CPU 中断中剥离出来，让控制环路的执行不再挤占主程序。

在动手写代码之前还有一个观念要转过来：CLA 不是一个“函数库”，而是一台可以运行 C 代码的独立处理器。它的编程模型和 CPU 有区别，代码要放到专门的 RAM 区域，入口函数由硬件事件触发，任务之间还有优先级抢占的关系。把这些机制理解透了，后面配置才不会一头雾水。

1.2 CLA 能直接访问的外设和内存

CLA 能够独立运行控制算法，前提是它能自己拿到输入、自己写出结果，否则还是得靠 CPU 帮忙搬数据。F280049C 的 CLA 在总线设计上专门开放了一批对外设和内存的访问通路，常见可访问对象包括：

• ADC 结果寄存器（ADCRESULT0~15），这是控制环路的输入来源。
• CMPSS 比较器子系统的滤波输出，常用于过流保护等快速逻辑。
• ePWM 的一部分控制寄存器，比如比较值 CMPA、CMPB，以及部分时基配置，可以直接由 CLA 更新。
• GPIO 数据寄存器，可以翻转引脚来输出状态或测量时序。
• 共享 RAM 区，包括 LSx、MSx 这些内存段，CPU 和 CLA 可以共用。
• 部分系统控制寄存器和中断标志，不过每个型号的访问范围差异很大。

这句“差异很大”不是客套话。F28379D 的 CLA 能访问的外设范围，和 F280049C 就不完全相同；F28004x 内部不同型号之间也可能有细微差别。所以最靠谱的做法，是打开对应型号的 Technical Reference Manual（TRM），翻到 CLA 章节看“Memory Map”和“Peripheral Access”的表格，确认你要用的外设寄存器在不在 CLA 的总线访问列表里。我早期在 F28379D 上写过一个 CLA 程序，想直接在 CLA 里访问某个寄存器，结果编译能过，运行起来就是非法访问，查了半天才发现那个寄存器根本不在 CLA 可访问范围内。

有了这些访问通路，一个典型的闭环数据链路就可以完全不经过 CPU：

ePWM 时基触发 ADC 采样 → ADC 转换结束产生 ADCINT → ADCINT 触发 CLA 任务 → CLA 读取 ADC 结果寄存器 → 运行控制算法 → 更新 ePWM 比较值寄存器 → 下个 PWM 周期自动生效。

这条链路里 CPU 要做的事情只是初始化配置，运行阶段完全旁路掉了。这也是数字电源、电机控制里最常见的一种 CLA 使用方式。理解了这个通路，再去看 C2000Ware 里的 CLA 例程，就会觉得代码结构非常清晰。

2. 从零配置 CLA：时钟、内存、任务触发

2.1 开启时钟并把代码放进 RAM

配置 CLA 的第一步，是在系统初始化阶段打开 CLA 模块和它相关 RAM 的时钟。F280049C 上外设时钟默认不全部打开，所以这个步骤漏了，后面大概率会跑飞或进异常。

// 使能 CLA1 模块时钟 SysCtrlRegs.PCLKCR0.bit.CLA1 = 1; // 使能 CLA 要用的 RAM 时钟，具体看型号，LSx/MSx 都要确认 SysCtrlRegs.PCLKCR2.bit.LS0 = 1; SysCtrlRegs.PCLKCR2.bit.LS1 = 1;

这里有个容易忽略的点：CLA 程序不能放在 Flash 里执行。CLA 有自己的取指总线，它访问不了片内 Flash 阵列，所以 CLA 要跑的代码必须放在 RAM 里。F280049C 里的 LSx（Local Shared）RAM 和 MSx（Master Shared）RAM 都可以被 CPU 和 CLA1 访问，常见做法就是把 CLA 程序段加载到 Flash，启动时拷贝到 LSx RAM，然后让 CLA 从 RAM 取指运行。

听起来有点绕，其实就是链接器里的一件常规操作。工程里的 cmd 文件会定义一个用于 CLA 代码的段，比如叫Cla1Prog，它在 Flash 里保存原始内容，运行地址定位到 LSx RAM：

Cla1Prog : LOAD = FLASH, RUN = LS0RAM, LOAD_START(_Cla1funcsLoadStart), LOAD_END(_Cla1funcsLoadEnd), RUN_START(_Cla1funcsRunStart)

boot 阶段再用memcpy把这个段从 Flash 拷贝到 LSx RAM，然后才能让 CLA 跑。TI 的 C2000Ware 例程里都会有一段类似这样的代码：

extern uint16_t Cla1funcsLoadStart, Cla1funcsLoadEnd, Cla1funcsRunStart; memcpy((void *)&Cla1funcsRunStart, (void *)&Cla1funcsLoadStart, (size_t)&Cla1funcsLoadEnd - (size_t)&Cla1funcsLoadStart);

很多初学者拷贝忘了，结果 CLA 一启动就进非法指令。调试时如果发现 CLA 任务开始地址不对，先查这段拷贝有没有真正执行。

再补充一个容易踩的细节：定义 CLA 任务函数时，要确保函数被分配到Cla1Prog这个段，比如在函数声明处加上：

#pragma CODE_SECTION(Cla1Task1_ISR, "Cla1Prog");

或者直接在源文件里统一配置。如果函数没被放进正确的段，链接器会把它默认放 Flash，CLA 又取不了 Flash，运行结果一定是异常的。

2.2 配置任务触发和 PIE 中断

CLA 的任务机制和 CPU 中断有点类似，但更简单直接。F280049C 的 CLA1 支持 8 个任务，编号从 Task1 到 Task8，编号越小优先级越高。每个任务都可以独立指定触发源，触发源可以是：

• ADCINT1~4，即 ADC 转换完成中断。
• ePWM1~4 的 SOCA/SOCB 信号，可以在 PWM 时基的特定点触发。
• CPU Timer 0。
• 软件强制触发。
• I2C、SPI 等外设事件，具体看 TRM 的触发源映射表。

任务一旦被触发，CLA 会停下当前正在执行的低优先级任务，转去执行高优先级任务。这种抢占是硬件层面的，被抢占任务的状态有专门机制保护，不需要像 CPU 中断那样在软件里反复关中断、开中断。

配置触发源的寄存器是 MCTL，以任务来自 ADCINT1 为例：

// 将 CLA1 的 Task1 触发源设置为 ADCINT1，具体字段值参看 TRM Cla1Regs.MCTL.bit.TASK1_SEL = 1; // 使能 CLA1 运行 Cla1Regs.MCTL.bit.RUN = 1;

CLA 任务执行完毕后，会向 PIE 控制器发一个完成中断。F280049C 上 CLA1 的中断位于 PIE 第 11 组（具体组号以头文件里PIE_Group11的宏定义为准），CPU 可以在中断服务函数里读取 CLA 计算出来的结果，或者仅仅做一个标志位通知主循环。

// 使能 PIE 组11，CLA1_TASK1 完成中断 PieCtrlRegs.PIEIER11.bit.INTx1 = 1; IER |= M_INT11; EINT;

这里我想强调一个原则：CLA 任务完成中断不是必须的。如果 CPU 完全不需要关心 CLA 的计算结果，或者只在主循环里轮询共享变量，那么可以不使能这个 PIE 中断，减少 CPU 的中断开销。控制环路最理想的状态，就是“CLA 自己闭环，CPU 偶尔看一眼”。

3. 例程实战：CLA 跑一个低通滤波和 PWM 控制

3.1 例程目标与整体链路

纸上谈兵说完了，我们跑一个实际可行的例程。目标如下：ePWM1 产生 10kHz 的 PWM 波，同时作为 ADC 的触发源，ADC 在 PWM 周期中点完成一次采样。采样完成后，ADCINT1 自动触发 CLA Task1，CLA 读取 ADC 结果、执行一个一阶低通滤波器，然后把滤波后的结果换算成占空比，直接写回 ePWM1 的比较值寄存器。整个过程 CPU 只负责初始化，运行阶段完全不参与。

这个例程虽然简单，但它包含了一个控制应用的最小闭环链路：采样、滤波、调制输出、周期性触发。扩展到电机控制或者数字电源时，只需要把低通滤波换成 PID 控制器，把输出目标从 CMPA 换成其他控制对象，框架是一样的。

开发板我用的是 TMS320F280049C LaunchPad，内部 ADC 输入接到板上的可调电位器，PWM 输出用示波器观察占空比。这样调起来直观，改电位器能看到 PWM 脉宽跟着变化。

链路时序可以这么理解：ePWM1 的周期计数器在 10kHz 频率下递增递减，到达指定的 SOCA 比较点后产生 ADC 触发信号；ADC 完成转换后产生 ADCINT1；ADCINT1 作为 CLA Task1 的触发源，让 CLA 在下一个 PWM 周期到来前完成滤波和 CMPA 更新。整个过程像一条流水线，每个 PWM 周期执行一次，周期性和确定性都由硬件保证。

3.2 关键代码逐段解读

先定义共享变量。这里必须用volatile修饰，否则编译器可能把变量优化到寄存器里，CPU 主循环循环读取时拿到的永远是旧值。

volatile float gAdcFiltered = 0.0f; // CLA 滤波结果，供 CPU 读取 volatile float gDutyCmp = 0.0f; // CLA 计算的占空比比较值

然后写 CLA 任务中断服务函数。注意这个函数不是普通 CPU ISR，它的分配段和书写方式有专门要求，我用__interrupt关键字加上指令来标记 CLA 任务函数。

// 告诉编译器这个函数放到 CLA 可执行段里 #pragma CODE_SECTION(Cla1Task1_ISR, "Cla1Prog") __interrupt void Cla1Task1_ISR(void) { uint16_t rawAdc; float vAdc; float filtered; uint16_t period; uint16_t cmpVal; // 1. 读取 ADC 结果寄存器 rawAdc = AdcaResultRegs.ADCRESULT0; // 2. 换算成实际电压，粗略按 12 位 ADC、满量程 3.3V // 实际项目中 adcofftrim 带来的偏移要单独处理，后面细说 vAdc = (float)rawAdc * 3.3f / 4095.0f; // 3. 一阶低通滤波：y[n] = y[n-1] + alpha * (x[n] - y[n-1]) filtered = gAdcFiltered + 0.1f * (vAdc - gAdcFiltered); gAdcFiltered = filtered; // 4. 把电压换算成 PWM 比较值，并写回 ePWM1 period = EPwm1Regs.TBPRD; cmpVal = (uint16_t)(filtered / 3.3f * (float)period); EPwm1Regs.CMPA.bit.CMPA = cmpVal; }

代码逻辑并不复杂，几个细节值得展开。

首先，ADC 结果寄存器的读取索引要和 ADC 的 SOC 对应。比如 ADC 转换是由 SOC0 完成的，结果放在 ADCRESULT0；如果由 SOC1 完成，对应 ADCRESULT1。很多人查了半天滤波结果不对，最后发现读错了结果寄存器。

其次，周期值period从TBPRD读取，这个方法比较通用。在递增递减计数模式下，比较值和占空比的关系是周期内先高后低还是先低后高，取决于计数方向和输出极性，所以换到自己的板子上要先确认 PWM 极性，免得占空比看起来反了。

再说 CPU 端，主循环里读取gAdcFiltered即可：

while(1) { // 主循环做通信、显示、按键处理 // 需要 CLA 滤波结果时直接读取共享变量 float currentFilter = gAdcFiltered; ... }

如果你想验证 CLA 任务是不是真的没占 CPU 时间，可以写一个计数变量放在主循环里递增，同时用一个 GPIO 翻转观察 CPU 负载。CLA 跑起来以后，主循环计数频率几乎不受影响，这就是 CLA 卸载 CPU 的直观证据。

还有一个很实用的调试验证方法：在 CLA 任务里翻转一个 GPIO。比如任务开头置高、结尾置低，用示波器测量这个 GPIO 的高电平时间，就能测出 CLA 执行一次算法花了多少时间。在 100MHz 主频下，一个几十行的浮点滤波任务通常只需要几百纳秒到一两微秒，完全可以塞进 10kHz 控制周期里。

4. 写 CLA 代码绕不开的坑和优化技巧

4.1 ADC 结果寄存器与 adcofftrim 的坑

这句“CLA 读取 ADC 结果寄存器时，可能读到的是尚未应用 adcofftrim 的原始值”是我在某个交流群里看到的，自己也踩过一模一样的坑。刚开始我总觉得自己从 ADC 读到的电压值比万用表量到的偏大或者偏小，以为是参考电压不稳，后来才发现问题出在 ADC 的偏移校准上。

C2000 系列 ADC 内部有一个偏移校准机制，用 ADCOFFTRIM 寄存器记录校准值，正常转换结果经过了内部修正后才被 CPU 访问。但 CLA 在访问部分 ADC 结果寄存器时，走的总线路径和 CPU 不完全一样，某些情况下可能直接读到未叠加修正量的原始结果。这意味着同一个 ADC 通道，CPU 读到的值和 CLA 读到的值可能会相差几个 LSB。控制环路里如果对精度要求高，这个误差不能忽略。

我用的解决办法是在系统初始化阶段把修正值读出来，放到一个 CLA 也能访问的共享变量里，CLA 任务处理时手动叠加。

// 系统初始化时，CPU 读取校准寄存器并保存到共享变量 volatile int16_t gAdcOffTrim = 0; gAdcOffTrim = (int16_t)AdcaOffsetTrimReg.ADCOFFTRIM;

CLA 端读取原始值后再加上偏移：

rawAdc = AdcaResultRegs.ADCRESULT0; rawAdc = (uint16_t)((int32_t)rawAdc + (int32_t)gAdcOffTrim);

注意处理符号和范围，别让数据溢出。不过这个做法是否必需，还是要以具体芯片 TRM 为准。有些型号的 CLA 访问路径已经做了修正，就没必要再多此一举。我的建议是：拿到一块新板子，先用 CPU 读一次、CLA 读一次同一通道比较结果，确定差异再决定要不要处理。

4.2 volatile、共享数据与 RAM 仲裁

CPU 和 CLA 共享变量是这个架构的基本通信方式，但共享带来的问题也很现实。

第一就是volatile。不夸张地说，很多 CLA 例程“跑起来没反应”的故障，最后都落在变量上没有加 volatile。编译器在开优化后，如果发现代码里反复读取同一个变量但变量似乎没有变化，就可能把读操作优化掉，直接沿用第一次读取的值。对 CPU 和 CLA 来说，对方修改共享变量相当于一个异步事件，所以在所有跨内核共享的变量上，volatile不是选项，而是必须。

第二是原子性。F280049C 上不管是 C28x CPU 还是 CLA，都是 32 位架构，32 位以内的读写操作通常是原子的，比如int32_t、float这类变量，一侧在读、另一侧在写，最多读到旧值，不会读到一个撕裂后的中间值。但如果是 64 位类型，或者结构体、数组这类多内存访问的数据类型，就需要额外做同步。常见的做法是用一个标志位表示“数据已经更新”，另一侧先读标志位再读数据；读完数据后可能需要清除标志位。

第三是共享内存仲裁。CPU 和 CLA 都能访问 LSx、MSx RAM，但如果它们同时访问同一个内存段，硬件会在两者之间插入一个等待周期。这种冲突在低频调试时看不出来，等控制频率提高、且 CLA 和 CPU 频繁访问同一段 RAM 时，会表现为指令执行时间抖动。优化思路是尽量把 CLA 经常访问的数据放到独立段里，CPU 频繁访问的数据放到另一段，减少总线冲突。

我习惯的布局是：CLA 跑控制算法时，把 ADC 原始数据、滤波结果这类高频访问变量放在 MSx RAM，把 CPU 的通信缓冲区放在另一段内存，让两个内核各管各的地盘，交集越小越好。

4.3 调试 CLA 的独有方式

CLA 程序不能直接在 CPU 的调试窗口里像普通 C 代码那样逐步查看，因为它是独立运行的。但 CCS 提供了对应的 CLA 调试视图，可以查看 CLA 的程序计数器、任务状态、寄存器组和内存窗口。切换到 CLA 视图后，可以像调试普通代码一样断点、单步运行 CLA 代码，只是断点类型要选 CLA Breakpoint，不能和 CPU 断点混用。

调试 CLA 时有一个限制要提前知道：CLA 代码里不能随便调用系统库函数，比如printf、memcpy这类。这倒不是语法不支持，而是 CLA 的库支持很受限，调用链一复杂就容易出问题。实际调试时，我更习惯把中间结果写到共享变量里，然后在 CCS 的变量窗口里观察；或者直接翻转 GPIO，用示波器看时序。这两种方法比任何打印都可靠。

还有一个工程习惯，我在调 CLA 时会先把系统优化级别调低，等逻辑没问题了再开优化。CLA 代码经过编译器优化后，单步执行的行号和指令对应关系有时候会变得很飘，调试体验很差。先把正确性验证完，再追求性能。

4.4 任务优先级和实时性

CLA 的任务抢占机制可以理解为一个简化版的中断系统。高优先级任务能抢占低优先级任务，但低优先级任务永远等不到高优先级任务让路。这个设计有一个微妙的坑：如果你把一个耗时很长的任务放在高优先级，它会反复抢占其他任务，导致低优先级任务饿死或者执行周期不稳定。

建议把时间关键的任务放在高优先级，比如电流环、过流保护逻辑；把滤波、参数标定这类对时间不那么敏感的任务放在低优先级。任务里避免写while循环等待某个条件，CLA 是事件驱动的，出现循环通常意味着设计思路有问题。

另外，CLA 代码里不要用delay或者空转等待。控制任务本身就有严格的时间预算，如果因为等待导致任务执行时间超过 PWM 周期，下一轮触发到来时上一轮任务还没跑完，任务会一直被抢占，整个控制周期就乱了。

5. 常见问题排查实录与速查表

5.1 三个我踩过的典型问题

第一个问题，CLA 任务完全不触发。我当时的配置是 Task1 挂在 ADCINT1 后面，ADC 也确实在出中断，但任务就是不跑。查到最后，发现 ADCINT1 在 PIE 里被 CPU 禁用了。这里有个容易绕晕的点：ADCINT1 既要作为 CLA 的触发源，也要作为 PIE 中断源，而 CLA 触发链路上 ADCINT 信号在送往 CLA 之前，是否受 PIE 的启用位影响，不同芯片有不同的设计。很多型号上，如果 PIE 里对应的 ADCINT 中断没使能，CLA 也收不到触发。所以排查任务不触发时，先把 PIE 中断使能补上再说。

第二个问题，一进 CLA 就跳到非法中断。这个基本没有悬念，绝大多数是 CLA 代码没有正确拷贝到 RAM，或者任务入口地址配置错误，指向了一个 CLABoot ROM 区域或者没有数据的地址。处理办法是检查 cmd 文件里Cla1Prog的 LOAD/RUN 地址，确认启动时memcpy真的执行了，再确认 CLA 任务入口地址寄存器指向的是函数所在的 RAM 地址。

第三个问题，变量读到旧值。我在主循环里读 CLA 的计算结果，发现数据永远不更新。排查之后原因有两点：一是共享变量没加volatile，编译器把读取操作优化掉了；二是 PIE 中断标志位没有清，或者 CLA 任务完成中断没有正确触发，导致 CPU 根本不知道有新结果。后来我调整了机制，不再依赖中断通知，而是在主循环里直接轮询共享变量，反而更简单可靠。

5.2 排查速查表

这个表是我自己排查问题时的参考模板，不一定覆盖所有情况，但覆盖的是 CLA 入门阶段最常碰到的几类问题。每次报错先看“环境问题”再看“逻辑问题”，能少走很多弯路。

最后再分享一个个人经验。CLA 这个外设，刚上手时最容易让人不适应的地方在于：你在写的其实是一套“旁路系统”，它有自己的代码段、自己的触发源、自己的中断号，任何一个环节没配置到位，表现出来的都是莫名其妙的异常。所以我建议初学者不要急着直接改造现有工程，先把 C2000Ware 里自带的 CLA 例程完整跑一遍，从代码结构、cmd 文件、启动拷贝到中断配置，通盘过一遍，再回到自己的项目里套用，效率会高很多。跑通一次之后，CLA 的收益是肉眼可见的——CPU 占用率大幅下降，控制环路的确定性却比之前更稳。