📚 课程目录第4章 C2000开发环境与工程模板搭建

4. C2000开发环境与工程模板搭建

光伏逆变器的数字控制代码最终要落到具体芯片上运行，而 C2000 的工程不是“新建一个空工程就能编译”的简单项目。它至少涉及四层内容：集成开发环境（IDE）、芯片支持库（C2000Ware/driverlib）、链接命令文件（.cmd）以及调试配置（Flash 与 RAM）。本节以 TMS320F280049C（或同系列 F28004x）为例，把这条工具链从安装到可调试的完整过程讲清楚，并给出一个可直接复用的工程模板结构。

一、IDE 的选择与安装

目前 TI 主推两条 IDE 路线：传统的 Code Composer Studio（CCS，基于 Eclipse）和新的 CCS Theia（基于 VS Code 内核）。两者共用同一套编译器、C2000Ware 和调试探针驱动，区别主要在界面与工程管理方式。

CCS Theia：启动快、界面现代，适合新上手；对 C2000 的工程导入、编译、烧录支持已经完整，推荐作为本课程的主用环境。
Code Composer Studio 12.x/20.x：生态成熟、资料多，很多老工程和例程默认按 Eclipse 工程组织，遇到兼容性问题时更稳妥。

安装时有两个关键点必须注意。第一，安装路径不要包含中文和空格，例如使用 D:\ti\ccs，否则编译器和 make 脚本容易报路径错误。第二，安装组件中要勾选 C2000 系列器件支持（C2000 Device Support）以及对应的编译器版本（如 TI C2000 CGT 22.6.x）。如果只装了 IDE 而没装器件支持，新建工程时会找不到 F28004x 的器件选项。

安装完成后建议先不急着建工程，而是打开 CCS 的 Resource Explorer，确认能在线浏览 C2000Ware 例程。这一步能验证 IDE 与器件支持是否装全。

二、C2000Ware 与 driverlib 的导入

C2000Ware 是 TI 提供的芯片级软件包，里面包含器件头文件、外设驱动库 driverlib、位域（bit-field）支持、例程和文档。它不是通过 IDE 安装的插件，而是独立安装的软件包，默认路径类似 C:\ti\c2000\C2000Ware_5_xx_xx_xx。

安装完成后，工程需要“认识”这个路径。常见做法有两种：

引用式：工程只添加 C2000Ware 的 include 路径和 driverlib 源文件路径，不复制文件。优点是升级 C2000Ware 后所有工程自动受益，缺点是工程不能脱离本机 C2000Ware 独立分发。
拷贝式：把用到的 driverlib 源文件和头文件复制进工程目录。优点是工程自包含、便于版本管理，缺点是升级麻烦。

对于光伏逆变器这类需要长期维护、多人协作的工程，推荐拷贝式，把 driverlib 中真正用到的模块（如 adc.c、epwm.c、sci.c、gpio.c）纳入工程，避免因 C2000Ware 版本差异导致编译结果不一致。

三、新建工程与关键配置

在 CCS Theia 中新建 C2000 工程的典型流程是：File → New → CCS Project，选择器件 TMS320F280049C，工程模板选择 Empty Project (with main.c)，编译器选择已安装的 C2000 CGT 版本。建好后需要手动补齐以下配置：

Include 路径：添加 driverlib、device_support、common/include 等目录。
预定义宏：如 _FLASH（Flash 运行时定义）、CPU1、器件型号宏。
链接命令文件：指定 .cmd 文件，决定代码和数据放在 Flash 还是 RAM。
库文件：如 driverlib.lib 或直接编译 driverlib 源文件。

下面是一个最小可编译工程的目录结构示例，可作为模板直接复用：

F280049C_Inverter_Template/
├── main.c
├── device/
│   ├── F28004x_Device.h
│   ├── F28004x_GlobalVariableDefs.c
│   └── F28004x_SysCtrl.c
├── driverlib/
│   ├── adc.c / adc.h
│   ├── epwm.c / epwm.h
│   └── ...
├── include/
│   └── (工程自定义头文件)
└── cmd/
    ├── F28004x_Headers_nonBIOS.cmd
    ├── F280049C_RAM_lnk.cmd
    └── F280049C_FLASH_lnk.cmd

四、链接命令文件（.cmd）配置

链接命令文件是 C2000 工程最容易出错、也最容易被忽视的部分。它做两件事：把代码段和数据段分配到物理存储区，以及定义存储区边界。F28004x 的存储资源大致为：Flash 256KB、RAM（M0/M1/LSx/GSx）若干块、Boot ROM 等。

RAM 调试用的 F280049C_RAM_lnk.cmd 会把 .text、.cinit、.const 等段全部映射到 RAM，例如：

MEMORY
{
   RAMM0M1  : origin = 0x000002, length = 0x0003FE
   RAMLS0_3 : origin = 0x008000, length = 0x002000
   RAMGS0_3 : origin = 0x00C000, length = 0x004000
   FLASH    : origin = 0x080000, length = 0x040000
}

SECTIONS
{
   .text    : > RAMGS0_3
   .cinit   : > RAMGS0_3
   .const   : > RAMGS0_3
   .stack   : > RAMM0M1
}

Flash 调试用的 F280049C_FLASH_lnk.cmd 则把代码段放到 Flash，同时把需要高速执行的函数（如中断服务程序、PWM 更新函数）通过 ramfuncs 段搬到 RAM 运行。这是光伏逆变器控制代码的常见做法：主控制环在 RAM 中执行以保证实时性，其余代码留在 Flash。

如果 .cmd 中把 .text 分配到 Flash，但代码里又调用了 memcpy 把 ramfuncs 搬到 RAM，必须确保 ramfuncs 段在 .cmd 中有明确定义，否则链接会报 “placement fails” 错误。

五、Flash 与 RAM 调试配置

RAM 调试和 Flash 调试的区别不只是 .cmd 文件不同，还涉及启动方式和调试器配置。

RAM 调试：代码通过调试器直接下载到 RAM，复位后从 RAM 运行。优点是下载快、可反复修改、不消耗 Flash 寿命，适合开发阶段。缺点是掉电即失，且 RAM 容量有限，大工程可能放不下。

Flash 调试：代码烧写到 Flash，复位后由 Boot ROM 引导到 Flash 入口。优点是掉电保存、接近最终产品形态。缺点是每次修改都要擦写 Flash，速度慢，且需要正确配置 _FLASH 宏和 ramfuncs 搬运。

在 CCS 中切换这两种模式，通常通过不同的 Target Configuration（.ccxml）或不同的 Build Configuration 实现。建议在工程中建立 Debug_RAM 和 Release_FLASH 两个构建配置，分别关联对应的 .cmd 文件和预定义宏，避免手动改来改去。

六、工程模板的复用与检查

把上述配置固化成一个模板工程后，后续每个新项目只需复制模板、修改器件型号和 .cmd 文件即可。建议在模板中保留一份 README，记录以下检查项：

IDE 版本、C2000Ware 版本、编译器版本是否与模板一致；
Include 路径是否包含 driverlib 和 device_support；
预定义宏是否包含 _FLASH（Flash 配置时）和器件型号宏；
.cmd 文件是否与当前构建配置匹配；
ramfuncs 段是否在 .cmd 中定义，搬运代码是否在 main() 初始化阶段调用。

完成这些配置后，一个最小工程应当能够编译通过、下载到目标板、并在 main() 中点亮一个 GPIO 或翻转 PWM 输出。这一步验证通过，才说明开发环境与工程模板真正搭建完成，可以进入后续的时钟、ADC、EPWM 等外设配置。