F28377D硬件加速器实战：TMU/VCU-II/CLB详解-育师

做电机控制和数字电源这些年，F28377D这块片子我前前后后用过几个项目。说句实在话，很多人把它当普通C2000用，跑跑主频、调调PWM、做做ADC采样，核心的浮点运算靠CPU硬扛。但这颗芯片真正值钱的地方，其实是它在C28x内核旁边塞进来的那三把“瑞士军刀”——TMU、VCU-II和CLB。如果这三样东西你一个都没用过，那这颗芯片至少有一半的算力和硬件资源是被你白白浪费的。这篇文章我就结合自己实际调试和量产的经历，把这三个硬件加速器掰开揉碎了讲清楚：它们到底是什么、在什么场景下能帮你解决真问题、以及具体怎么在工程里把它们用起来。

先说个结论放在前面：TMU是给三角函数和数学运算“作弊”的，VCU-II是给通信解码和复数运算专用的，而CLB则是把一颗小号FPGA的核心能力塞进了MCU里。这三者解决的问题完全不同，使用方式也各有讲究。做电机控制、并网逆变器、信号处理或者工业通信协议的工程师，只要你的主控选的是F28377D（或者同系列的F28379D、F2838x），这篇文章都值得你认真看完。

1. 为什么叫“瑞士军刀”：三个硬件加速器的定位与价值

C2000系列的DSP之所以在实时控制领域站稳脚跟，靠的从来不是单纯的主频堆料。F28377D标称200MHz主频，双核C28x+FPU，这个账面数据放在今天的MCU市场里其实不算夸张。但它在电机控制、电源控制这类“每微秒都很金贵”的场景里仍然被大量选用，核心原因就是它把一些高频、重复、计算密集型的操作从CPU里剥离了出去，用专门的硬件单元去干，CPU只管发指令和拿结果。

TMU、VCU-II和CLB这三样东西，就是这种“硬件卸载”思路的具体产物。

TMU（Trigonometric Math Unit，三角函数数学单元）：专门加速三角函数、反三角函数、对数、指数、平方根倒数这类数学运算。电机控制里的PARK变换、电网锁相环里的角度计算、电源控制里的指数运算，全部能受益。
VCU-II（Viterbi/Complex Unit，维特比/复数运算单元）：听名字就知道，它最初是为了通信物理层设计的。Viterbi译码、CRC校验、复数乘法/加法/幅值计算，这些在通信基带处理里最常见的操作，它一个周期就能出结果。
CLB（Configurable Logic Block，可配置逻辑块）：这是最容易被忽略、也最“硬核”的一个。它本质上是芯片内部集成的一组可编程逻辑资源，可以让你在MCU内部搭出自定义的硬件逻辑电路，比如自定义编码器解码接口、自定义PWM保护逻辑、甚至自己实现一个串行通信协议。

一句话总结三者的关系：TMU管数学，VCU管通信，CLB管逻辑。它们共同的目标就是让F28377D在实时控制领域做到“算得快、响应快、接口灵活”。如果你只是用CPU硬算，那这颗芯片的强大之处你基本感知不到；但一旦你把这三样用起来，很多原本觉得“CPU快撑不住了”的算法，突然就变得游刃有余。

我最早接触这套东西是在一个并网逆变器的项目里。三相电网电压采样进来，要做锁相环，要做dq变换，每个开关周期都要算好几组三角函数。一开始用CPU的FPU硬算，200MHz主频下勉强能跑，但留给其他任务的时间被压得很紧。后来花了一个下午把PARK变换里的三角函数全部切到TMU，整个计算链路的耗时直接砍掉了接近60%。从那以后，我做这类项目的第一件事，就是先看哪些数学运算能往TMU上挪。

2. TMU三角函数加速：从PARK变换看硬件加速的实际收益

2.1 TMU到底能算哪些东西，和FPU有什么区别

很多初学者会把TMU和FPU搞混。FPU是浮点运算单元，只管浮点加减乘除；而TMU是在FPU基础上的扩展，它专门处理那些FPU算起来很“吃力”的超越函数。所谓超越函数，就是不能通过有限次加减乘除直接算出来的函数，比如正弦、余弦、反正切、对数、指数、平方根倒数等。

F28377D上的TMU具体支持的操作包括：

单精度浮点的sin、cos、sin/cos联合计算
反正切atan、atan2（四象限反正切，电机控制里求角度差、锁相环里求相位都靠它）
除法、平方根倒数
自然对数ln、以2为底的对数log2、指数exp
另外还有针对控制算法优化的atan2变体，比如atan2pu，能直接把结果换算成标幺值

这里有个关键点：TMU不是独立于CPU的“协处理器核心”，它更像是一条数学指令的“硬件加速通道”。你在C代码里调用sin、cos、atan2这些函数，编译器启用了TMU选项后，会自动把这些函数调用编译成TMU专用指令。也就是说，你不需要重写算法，只需要改一个编译器配置，这些数学运算就会自动跑在硬件加速器上。

这个“无感加速”的特性，对工程落地来说是最友好的。它不像CLB那样需要你用专门的图形化工具去搭硬件逻辑，也不用像VCU那样需要你关心特殊的寄存器和中断标志。TMU的使用门槛，低到让人难以置信。

2.2 工程里怎么启用TMU，编译器配置和注意事项

具体到CCS（Code Composer Studio）里的操作，其实就是在编译器选项里加一条命令：

右键工程属性，找到Build → C2000 Compiler → Processor Options
在“Specify predefine symbol”或者编译选项里添加--tmu_support=tmu0

如果你是直接改makefile或者cmd文件，对应的编译参数就是：

--tmu_support=tmu0

加上这个参数之后，编译器会把代码里对sin()、cos()、atan2()、sqrt()等标准数学库函数的调用，自动替换成TMU硬件指令。注意，这里的前提是你用的是标准库函数，而不是自己手写的泰勒展开或者查表法。如果你之前因为性能问题自己写了查表的PARK变换，切到TMU之后，完全可以抛弃查表法，用标准库函数直接算，精度和速度都会更好。

调试时有个小技巧：在CCS的Disassembly窗口里，如果你看到类似MADDF32、MPYF32、以及TMU专用的SINF32、COSF32、ATAN2F32这些指令，说明TMU编译优化已经生效了。如果看到的还是普通的CALL指令（去调用库函数），那就说明TMU选项没有正确开启，得回头检查配置。

我遇到过的一个坑是：工程里有部分文件是C语言标准库的老代码，它们内部可能直接调用了sinl()这种长双精度版本。TMU只支持单精度浮点运算，遇到double或long double版本的数学函数，编译器不会自动替换成TMU指令，反而会拉出一大段软件库去慢慢算。所以想用好TMU，代码里所有数学函数相关的变量，建议统一用float类型。尤其是在一些从STM32移植过来的工程里，习惯性用double声明变量，这类代码在F28377D上跑TMU是得不到加速效果的。

2.3 实战验证：FOC电流环PARK变换，TMU能快多少

我以FOC（磁场定向控制）里最基础的PARK变换为例，给你看一组实测数据。PARK变换的C代码如下：

// 输入：电流 Ia、Ib，电角度 theta，输出：Id、Iq void park_transform(float Ia, float Ib, float theta, float *Id, float *Iq) { float sin_t, cos_t; sin_t = sinf(theta); cos_t = cosf(theta); *Id = Ia * cos_t + Ib * sin_t; *Iq = -Ia * sin_t + Ib * cos_t; }

这段代码在200MHz的F28377D上，不开TMU、用软件数学库编译时，单次执行大约需要120~150个时钟周期（主要开销在sin和cos的软件计算上）。开启TMU优化之后，同样的C代码编译出来，单次执行大约只需要30~40个时钟周期，性能提升约3到4倍。

如果你的控制环路是20kHz的开关频率，每个PWM周期需要做一次PARK变换和一次逆PARK变换，那光这一项就能省下将近200个时钟周期。听起来不多？但对实时控制来说，省下来的CPU带宽意味着你可以做更复杂的无传感器观测器、在线参数辨识，或者把剩下的算力留给通信协议栈。

另外一个实用的地方是正交编码器或者旋变解码之后的角度处理，经常需要做atan2运算来把正余弦包络还原成角度。用软件库算一个atan2可能要几十上百个周期，TMU一条ATAN2F32指令大概5~6个周期就出结果，而且精度是硬件级的，不会出现查表法那种分段跳变。工业伺服里需要做高精度位置环的，这个特性非常值钱。

3. VCU-II：通信解码与复数运算的隐藏加速引擎

3.1 VCU-II是个什么东西，为什么它能加速Viterbi和FFT蝶形

VCU-II在F28377D的官方文档里叫“Viterbi/Complex Unit”。这个名字起得很直白：它由两部分功能组成，一部分是为了Viterbi译码准备的硬件加速逻辑，另一部分是面向复数运算的硬件加速逻辑。

Viterbi译码是卷积码最大似然译码的标准算法，广泛应用在无线通信、数字电视、深空通信这些领域。传统软件实现Viterbi，核心瓶颈是“加比选”（ACS，Add-Compare-Select）操作的循环，每个状态的每次转移都要做大量加法、比较和选择。VCU-II把这一整条ACS流水线做成了硬件指令，你只需要在正确的时间把待处理的数据准备好，一条硬件指令就能完成一次完整的ACS蝶形运算。

复数运算部分则是另一个宝藏。F28377D毕竟是个信号处理芯片，FFT、复数滤波都是常规操作。C28x内核本身是定点架构，虽然带了FPU，但复数乘法仍然需要好几条指令。VCU-II提供了专门的CMPLXMPY（复数乘法）、CMPLXADD、CMPLXSUB、以及求复数幅值的CMPLXABS指令，能在一个周期内完成复数乘法的全部实部虚部计算。

说实话，如果你做的是纯电机控制，VCU-II的Viterbi译码功能确实用不上。但如果你涉及并网逆变器里的通信协议（比如用FSK调制做孤岛检测的载波通信）、或者做工业无线通信网关、又或者需要处理来自编码器/传感器的曼彻斯特编码数据，那VCU-II就是真正的救命稻草。用软件逐比特做Viterbi译码，200MHz的CPU也会被拖垮；用VCU-II，可能只占5%~10%的CPU负载。

3.2 VCU-II的实际用法：从寄存器到中断标志

VCU-II不是靠编译器自动优化就能“无感加速”的单元。和TMU不同，VCU-II的操作需要通过操作特殊功能寄存器来完成。你需要在代码里写出类似下面这样的流程：

把待译码的数据准备好，按VCU要求的格式放到指定的数据寄存器区域。
触发VCU执行指令，比如VITERBI指令。
等待VCU完成运算（可以轮询状态位，也可以用中断通知）。
从输出寄存器中读取译码结果。

以TI官方提供的Viterbi译码库为例，初始化和调用大概长这样：

// 初始化Viterbi译码模块 VCU_viterbi_init(VCU_BASE, &viterbiParams); // 输入软判决数据，执行译码 VCU_viterbi_execute(VCU_BASE, &viterbiParams, inputData, outputData); // 检查VCU状态 while (VCU_getStatus(VCU_BASE) & VCU_STATUS_BUSY);

注意，VCU执行计算时不会阻塞CPU，它是独立的硬件流水线。你可以在启动VCU之后去干别的事，等中断来了再回来取结果。这一点和DMA的思想非常像，用得好可以达到“计算一次，中间全不占用CPU”的效果。

复数乘法部分的调用更简单一些，可以直接在C代码里通过内嵌函数或者专用的数据类型来操作。比如求两个复数a + bj和c + dj的乘积，用VCU指令基本上就是一个周期出结果，而用普通FPU指令可能需要五六个周期。

3.3 VCU在电机控制和信号处理里的应用思路

有些读者可能会问：我不做通信，VCU是不是就完全没用？其实不然。VCU的复数运算能力在很多控制场景里都能发光。

举个例子：三相电网电压的正负序分离。传统的软件实现需要用到复数滤波器或者延时信号消去法，计算量在20kHz控制频率下并不小。如果你把正负序分离里的复数旋转因子计算全部换成VCU的复数乘法指令，计算效率和精度都会有明显提升。

再举个例子：阻抗辨识或者在线参数辨识里，经常需要做复数最小二乘拟合，这些操作本质上也是一大堆复数乘加。用VCU来处理，比用CPU逐个周期去乘要高效得多。

所以我的建议是：即使你当前项目暂时用不到Viterbi译码，也值得把VCU的复数指令集好好研究一遍。等到哪天需要做并网电能质量分析或者通信协议解码时，你能比同事更快地想到用VCU来解决问题。

4. CLB可配置逻辑块：把FPGA的小型逻辑功能塞进MCU

4.1 CLB的核心构成：LUT、FSM、计数器、输出映射

如果说TMU和VCU还只是“加速计算”，那CLB就把F28377D的定位直接拉高了半个维度——它让一颗MCU具备了FPGA才有的“可编程硬件逻辑”能力。

CLB的全称是Configurable Logic Block，位于F28377D的内部控制逻辑区域。它和C28x CPU是并行运行的独立硬件，CPU可以通过寄存器把数据送给CLB，CLB也可以把自身逻辑产生的信号作为事件触发给PWM、ADC、GPIO等外设。也就是说，CLB不仅能处理输入信号，还能反过来控制芯片其他外设的行为。

一个CLB模块内部主要由这几类资源组成：

LUT（查找表）：本质是一个5输入、最大128个真值表项的查找逻辑。你可以把它理解为一个小型组合逻辑单元，类似FPGA里的LUT，但规模小很多。
FSM（有限状态机）：CLB里提供了可配置的有限状态机单元，能根据输入信号和当前状态跳转到下一个状态，最大支持4个状态。这个功能非常关键，很多时序逻辑（比如自定义解码协议）都要靠FSM来实现。
计数器：CLB内部有几个可级联的计数器，可以配置成自由计数、单次计时、带比较值的模式。这些计数器是CLB实现PWM信号测量、脉宽捕获、延时生成的基础。
输出映射：CLB的最终输出可以连接到芯片内部的多个外设，比如EPWM模块的外部触发、ADC的SOC触发、GPIO的输出等。

简单来说，CLB就是一颗“mini FPGA”，它的规模虽然和真正的FPGA没法比，但在处理编码器解码、PWM死区保护、自定义IO协议这些嵌入式高频需求时，已经绰绰有余。

4.2 SysConfig图形化配置CLB：不用手写HDL

很多搞单片机的人一听到“可编程逻辑”“硬件电路”就心里发怵，觉得自己不会Verilog。好消息是，TI提供了一套图形化的配置工具SysConfig，让你基本不用写HDL代码，也能把CLB用起来。

SysConfig里的CLB配置界面，大概的操作逻辑是这样的：

第一步，先配置CLB的输入信号源。你可以选择GPIO引脚作为输入，也可以选择EPWM模块的输出、EQEP模块的信号、或者CPU写进来的数据作为CLB的输入。

第二步，在CLB内部搭建逻辑。SysConfig提供了可视化的逻辑图编辑界面，你可以直接从元件库里拉出LUT、FSM、计数器、与门、或门、非门等逻辑元件，然后用连线把它们的输入输出接起来。这一步很像在画电路原理图，但不需要你懂Verilog。

第三步，配置CLB的输出目的地。你可以把CLB的输出接到EPWM的TZ（Trip Zone）输入，实现硬件级的过流保护；也可以接到GPIO，把CLB跑出来的逻辑结果直接输出到引脚上；还可以接到ADC的SOC触发，用CLB做出自定义的采样时序。

配置完成后，SysConfig会自动生成注册表初始化代码。你只需要在工程里调用对应的初始化函数：

CLB_init(); CLB_enable();

整个过程完全不需要手写硬件描述语言。对从传统MCU开发转过来的工程师来说，这个学习曲线其实很友好。

4.3 实操案例：用CLB实现正交编码器接口

我手里有一个实际项目，增量式编码器输出直接进F28377D。传统的做法是接EQEP模块，用EQEP的正交解码功能。但那个项目里编码器信号经过长线传输后有毛刺，EQEP的解码偶尔会出计数错误。用CLB处理之后，我在CLB内部搭了一个带毛刺滤波和方向判断的解码逻辑，相当于在硬件层面把编码器的信号质量先“洗”了一遍，再交给EQEP或者CPU去读。

具体的做法是在CLB里做一个4倍频解码器。输入是A、B两路正交信号，在CLB内部先经过LUT判断相位关系，再通过FSM记录方向状态。当A、B信号的相位关系变化时，CLB的计数器自动加1或减1。最后把这个计数值通过CLB的输出接到GPIO或者直接映射到内存总线，CPU只需要定时读一次计数结果即可。

这个方案的优势非常明显：

占用的CPU资源几乎为零，CPU不需要去轮询编码器的边沿
毛刺滤波是在硬件层做的，比软件滤波稳定可靠得多
解码器的分辨率可以做得很高（4倍频是基本，时钟够快甚至可以做8倍频）

类似的思路还可以扩展到PWM输出死区保护逻辑、自定义曼彻斯特解码器、先用逻辑门处理再让CPU介入的各类“预处理电路”。

4.4 用CLB的注意事项和调试工具

CLB的配置不是“一次性成功”的。我在实际使用中有几个深深的体会：

第一，刚开始不要贪大求全，先从一个最小的逻辑电路开始验证。比如先搭一个“输入引脚取反后输出到另一个引脚”的小逻辑，确认CLB的输入输出通路完全打通、SysConfig生成的初始化代码能正常工作，再一步步往上加功能。

第二，CLB的时钟和DSP主频不同。CLB有自己的时钟域，这个时钟和PWM模块的时钟同步，但和CPU主频不是同一个概念。在配置计数器、FSM的时候，一定要计算清楚实际的时钟周期，避免预想的延时和实际不符。

第三，调试CLB时，最好利用SysConfig提供的仿真功能，在电脑上先把逻辑配置模拟一遍。虽然这个模拟不能替代真实硬件测试，但能帮你发现很多接线错误和逻辑错误，节省大量上板调试时间。

5. 三个加速器的选用原则与工程落地建议

5.1 什么场景该用哪个，一张表帮你快速决策

很多工程师看完前面的介绍，最困惑的还是“我到底该不该用、该用哪个”。这里我根据实际经验整理了一个决策参考表：

场景	推荐加速器	理由
电机FOC里的PARK变换、角度计算	TMU	三角函数全部硬件加速，无感替换，收益最直接
电网锁相环SRF-PLL、谐波计算	TMU	atan2运算极快，锁相环带宽可以做高
无线通信Viterbi译码、卷积译码	VCU-II	自带ACS蝶形指令，一个周期完成多次加比选
复数滤波、FFT蝶形、正负序分离	VCU-II	复数乘加指令一条搞定，省时且精度高
编码器信号预处理、自定义协议解码	CLB	硬件级滤波和状态机，CPU几乎零负担
PWM死区保护、硬件过流保护逻辑	CLB	保护逻辑跑在硬件上，比软件中断快且更可靠

这三个加速器不是互斥的关系，它们可以同时使用。我做过一个比较复杂的项目，PARK变换用TMU，并网侧的复数正序分量计算用VCU，编码器信号用CLB做预处理，三个加速器各司其职，才把20kHz的完整控制算法+通信栈+保护逻辑全部塞进单核CPU。

5.2 软硬件协同设计：CPU何时等待、何时去干别的

用这三个加速器的时候，有一个很重要但是文档里很少强调的思维转变：CPU不是一切工作的执行者，它更像是一个“调度员”。

用TMU时，CPU发送完数学运算指令后，TMU和CPU是并行工作的，CPU可以继续执行后面的指令。
用VCU时，CPU把数据灌给VCU，VCU独立执行译码或复数运算，CPU可以趁机去处理中断或者准备下一批数据。
用CLB时，CPU和CLB更是完全异步的，CLB的逻辑一直在硬件层面跑着，CPU只需要在读数据的时候来看一眼。

这种“硬件卸载”的思维方式，是高性能实时控制工程师必须建立的心智模型。代码写得好不好，不仅仅看你的算法效率有多高，更要看你能不能把CPU从繁忙的重复计算中解放出来。

5.3 性能评估三板斧：怎么证明你的优化是有效的

最后分享一个非常实用的经验：做优化之前，一定要先建立性能基线。没有基线，谈不上优化。

我的习惯是，在项目一开始就加一个基准测试函数，用GPIO翻转来测量关键代码段的执行时间。比如：

GPIO_write(HARDWARE_GPIO_TEST_PIN, 1); // 代码段开始 park_transform(ia, ib, theta, &id, &iq); // 被测试代码 GPIO_write(HARDWARE_GPIO_TEST_PIN, 0); // 代码段结束

然后用示波器或者逻辑分析仪抓GPIO的高电平时间，这就是这段代码的实际执行时长。分别测“优化前”和“优化后”的波形，数据一目了然。这个方法比用计数器（比如CCS里的clock功能）更接近真实硬件运行时间，因为GPIO翻转的时间就是硬件的真实执行痕迹。

另外一个评估维度是CPU负载率。如果整个控制环路跑完，GPIO翻转之间的时间只占整个PWM周期的80%，说明CPU还有20%的余量。有了这个数字，你才能判断要不要引入更复杂的算法，还是安安稳稳保持现状。

6. 常见问题与避坑指南

6.1 使用三个加速器时容易踩的坑

我把过去调试中踩过的一些坑整理成了一张速查表，希望能帮你少走弯路：

问题	原因	解决方法
启用了TMU编译选项，但编译报错/链接报错	某些老版本编译器或库不支持TMU指令	升级到最新版CCS和C2000编译器，确认库版本配套
代码用了`double`类型，TMU没生效	TMU只支持单精度浮点指令	全局搜索`double`，改成`float`类型；注意隐式类型转换
VCU执行完译码后，读取结果时读到的是旧数据	没有等待VCU完成就读取输出寄存器	轮询VCU状态位，或者使用VCU完成中断
CLB配置后不工作	SysConfig配置生成的初始化函数没有调用	确认`CLB_init()`和`CLB_enable()`都被调用，且调用顺序正确
CLB输出接到PWM后，PWM波形异常	CLB输出与PWM模块的连接优先级配置错误	检查EPWM模块中CLB输出的映射优先级，必要时调整PWM模块的输入源配置
整个工程因为开启TMU/VCU选项而性能反而下降	可能在循环里频繁调用函数，函数调用开销大于硬件加速收益	把关键代码放到循环体外初始化，或者使用内联函数；检查是否频繁开关中断打断流水线

6.2 调试技巧：用SysConfig和仿真工具快速定位问题

CLB这类硬件逻辑资源，最大的调试难点是“看不到内部状态”。你没法像调试C代码一样打断点，去看某个中间变量。好在TI提供了一些辅助手段：

第一，SysConfig里可以打开CLB的内部信号观测功能。在调试模式下，能把CLB内部的LUT输出、FSM状态、计数器值等导出到调试接口，用CCS的Variables窗口实时查看。虽然这个功能会占用一定的调试资源，但在定位问题时候非常有用。

第二，仿真阶段尽量用ModelSim等工具做CLB的纯逻辑仿真。SysConfig生成的配置可以导出成VHDL/Verilog仿真模型，你可以先在电脑上把输入波形和输出波形对比验证一遍。等逻辑正确率高了，再烧到板子上实测。

第三，对于TMU这类无感加速的单元，调试时最有效的工具就是Disassembly窗口。编译后在反汇编里看到SINF32、COSF32这类指令，就可以确信TMU生效了。

6.3 避坑心得：先跑通最小系统再上复杂功能

最后一条经验特别想分享给刚开始接触这些硬件加速器的朋友：不要试图一次性把TMU+VCU+CLB全部用起来。很多人项目一开始就雄心勃勃，想把所有先进功能全堆上，结果调试时连问题出在哪个模块都分不清。

我自己的做法是：

第一周：只开TMU，把现有代码里所有的三角函数切换到TMU，测性能提升。
第二周：加VCU，用TI官方的示例代码先跑通Viterbi译码，再替换成自己想要的复数运算。
第三周：才开始碰CLB，先搭一个最简单的LUT逻辑验证链路，再逐步设计应用级电路。

这样分阶段推进，出了问题能快速定位是哪一层没跑通，调试效率会高很多。

7. 写在最后：硬件加速器的思维比代码本身更重要

回到开头那句话，F28377D是一把瑞士军刀。但瑞士军刀拿到手里，你得知道哪一刀是开瓶器、哪一刀是剪刀、哪一刀是螺丝刀，才不会在需要开红酒的时候，拿着刀片去锯瓶塞。TMU、VCU-II和CLB就是这把军刀上的三个关键工具，它们的定位完全不同，但它们共同的目标是同一个：把CPU从繁重的计算和逻辑处理中解脱出来，让它去做真正的决策调度。

我个人在多个项目里的体会是，硬件加速器的使用不是一个“性能优化”的选修课，而是一个成熟嵌入式工程师的必修课。尤其是当控制算法的复杂度不断上升——比如你开始做无传感器控制、做自适应参数辨识、做实时通信协议栈的时候——如果你的CPU还在为计算一个三角函数而忙得不可开交，那些所谓的“高级算法”就永远只能是纸上谈兵。

给大家一个建议：如果你现在手头有F28377D的开发板，哪怕只是跑一个最简单的LED闪烁程序，也建议花半天时间把TMU编译选项打开，把几个数学函数从软件库换成TMU，再做一次性能对比。这半小时投入，会让你意识到这颗芯片的真实潜力到底有多大。等到了真正需要极限性能的那一天，你会有底气地说一句：“没问题，我早就在用硬件加速器了。”