4. C2000开发环境与工程骨架

在开始写第一行电机控制代码之前，先把“工具链—库—工程”这三层关系理清楚，比急着点“新建工程”更重要。C2000的开发环境不是单一软件，而是一套协同工作的组合：CCS（Code Composer Studio）是集成开发环境，负责编辑、编译、下载和调试；C2000Ware是TI官方的基础软件包，提供器件支持文件、外设驱动库driverlib、例程和文档；SysConfig是图形化配置工具，用来生成引脚、时钟、外设的初始化代码；MotorControl SDK则是在C2000Ware之上、面向电机控制的专用软件包，包含FOC、电流采样、位置估算等模块化库和参考工程。理解它们的层次，才能知道“代码该写在哪、配置该改在哪、库该从哪来”。

一、工具链的层次与依赖关系

这五者并非平级并列，而是有明确的依赖方向。C2000Ware是根，driverlib和器件头文件都在其中；SysConfig通常随CCS或C2000Ware提供，生成的代码会调用driverlib；MotorControl SDK依赖C2000Ware和driverlib，并额外提供电机专用模块。工程创建时，如果只装了CCS而没装对应版本的C2000Ware，编译会直接报“找不到device.h”或“driverlib.h”。因此安装顺序建议是：先装CCS，再装与器件匹配的C2000Ware，最后装MotorControl SDK，并确保三者版本兼容。

二、工程创建的两种典型路径

实际工作中，从零新建工程和基于例程改造是两条最常用的路径。对于初学者和快速验证，基于C2000Ware或MotorControl SDK的例程导入更稳妥：在CCS中选择 Project → Import CCS Projects，浏览到C2000Ware安装目录下的例程文件夹，例如 C:\ti\c2000\C2000Ware_x_xx_xx_xx\driverlib\f2837xd\examples\cpu1\gpio，导入后直接编译下载，能最快确认工具链是否正常。对于正式项目，则建议用 File → New → CCS Project 新建，器件选择实际使用的型号（如TMS320F28379D），编译器版本与CCS匹配，工程模板选择“Empty Project”或带SysConfig的模板。

新建工程后，最关键的一步是把C2000Ware的路径告诉工程。在工程属性 Build → C2000 Compiler → Include Options 中添加头文件搜索路径，通常包括：${C2000WARE_ROOT}/driverlib/f2837xd/driverlib、${C2000WARE_ROOT}/device_support/f2837xd/common/include 等。链接阶段需要在 Build → C2000 Linker → File Search Path 中加入driverlib库文件，例如 driverlib.lib，并确保库的构建配置（COFF/ELF、CPU1/CPU2）与工程一致。路径尽量使用CCS变量而非绝对路径，这样工程换电脑或换安装目录时不会失效。

三、SysConfig：把“配置”变成可维护的代码

传统写法里，GPIO方向、时钟分频、EPWM周期这些初始化代码要手写寄存器，容易出错且难维护。SysConfig以图形界面方式完成这些配置，并自动生成 board.c 和 board.h。以配置EPWM1为例：在SysConfig中打开EPWM模块，设置时钟分频、时基周期、计数模式、比较值、死区等参数，保存后生成的代码会自动调用driverlib的 EPWM_setTimeBasePeriod()、EPWM_setCounterCompareValue() 等函数。工程中只需在 main() 里调用 Board_init()，外设就按配置初始化完毕。

需要特别注意的是：SysConfig生成的代码不要手动修改，因为下次保存配置时会被覆盖。所有需要定制的逻辑应写在用户自己的源文件中，通过调用生成的句柄或宏来操作外设。另外，.syscfg 文件是工程的核心配置资产，必须纳入版本管理，它与生成代码要一起提交，保证任何人拉取工程后能复现同样的外设配置。

四、编译、下载与调试的实操要点

编译前先确认三件事：器件型号与工程设置一致、编译器版本可用、库路径正确。点击 Build 后，若报“unresolved symbol”，多半是库没链接或函数名拼写错误；若报“cannot open source file”，则是头文件路径缺失。编译通过后，用XDS100v2/XDS110等仿真器连接目标板，在 Target Configuration 中选对仿真器和器件，点击 Debug 进入调试视图。

调试阶段最实用的几个操作：在EPWM中断服务函数或ADC采样完成处设置断点，观察电流采样值和PWM占空比变量；用 Expressions 窗口实时监视 gAdcResult、gDutyCycle 等全局变量；用 Graph 工具把数组变量画成波形，直观查看电流环或速度环的响应。若程序跑飞，先检查是否触发了 ILLEGAL_ISR 或 NMI，再回看时钟和外设初始化顺序。下载到Flash与RAM的配置不同，调试阶段通常先跑RAM，验证逻辑后再切换到Flash固化。

五、版本管理与工程可复现性

电机控制工程往往涉及多人协作和长期维护，版本管理不能只提交 .c 文件。建议纳入版本库的内容包括：.c / .h 源文件、.syscfg 配置文件、.projectspec 或工程描述文件、链接命令文件 .cmd、以及必要的文档。不建议提交编译产物（Debug/、Release/、*.out、*.obj），用 .gitignore 排除即可。

更重要的是记录工具版本。在工程根目录放一个 README.md 或 tools_version.txt，写明：CCS版本（如12.5.0）、C2000Ware版本（如5.02.00.00）、MotorControl SDK版本（如4.00.00.00）、编译器版本（如TI v22.6.0.LTS）。因为不同版本的driverlib API和SysConfig生成代码可能有差异，版本不一致会导致“在我电脑上能编译、在你电脑上报错”。如果团队使用Git，可以把C2000Ware和SDK作为子模块或统一放在固定路径，工程中用变量引用，避免每人路径不同。

把环境搭对、把工程骨架固定、把版本记录清楚，后面写FOC、调电流环、做多轴协同，才不会把时间浪费在“为什么编译不过”和“为什么换台电脑就跑不起来”上。工具链的稳定性，是电机控制开发效率的第一道保障。