6.1.创建和管理工程

在嵌入式系统的软件开发工程中,通常需要创建一个单独的工程,使用不同的编译选项等为不同的目标硬件/存储器配置编译应用的相关版本。在大型工程中,还需要以多个团队成员均能轻松查找和维护的结构来整理文件。

CCS IDE 是一个灵活的开发环境,允许用户(以及其他功能):

  • 以易于查找和维护的结构来整理文件。
  • 自定义工程属性。
  • 为单个工程创建多个编译配置,每个配置都有自己的一组编译选项。
  • 为每个编译配置指定不同版本的编译工具。
  • 创建一个系统级工程,从而简化对多核器件所需的多个工程进行的维护。

本节讨论了 CCS 使用的工程模型,其中涵盖了如何创建、整理和配置工程以帮助用户处理不同版本的应用。

6.1.1.工程概述

本节概述了工作区和工程,以及 CCS 支持的工程类型。

CCS 中的所有工作都基于工程,这些工程通常是文件和文件夹的集合。可在工作区中存储和整理工程。

6.1.1.1.工作区

工作区是 CCS 的主要工作文件夹,包含管理定义在工作区下的所有工程的信息。

启动 CCS 后,系统将提示用户输入工作区文件夹位置。为避免之后出现提示,用户可启用将所选文件夹用作默认文件夹的选项。

CCS 启动后,CCS Edit 透视图将默认可见。该透视图包含代码开发时较常用的一些视图,例如“Project Explorer”、“Editor”和“Problems”视图。

新工程的默认位置将在工作区文件夹中。向工作区添加一个工程后,该工程将出现在 Project Explorer 视图中。

工作区文件夹还用于存储用户信息,例如用户界面偏好选择和设置。

工作区是用户专属的,因此通常不会纳入源代码控制系统,也不会在用户之间共享。如果将工程纳入源代码控制系统,那么每位用户都会有可引用工程的专属工作区。

用户可以有多个工作区。在 Code Composer Studio 中一次只能激活一个工作区,但可以使用 File → Switch Workspace… 菜单切换工作区。

提示

建议定期清理工作区,因为工作区可能会随着时间的推移而损坏。在清理之前,如果有想要保留的工作区设置,可以保存当前的工作区设置,以便将其导入到新的工作区中。清理工作区后必须重新导入工程。

6.1.1.1.1.保存工作区

  • 若要保存工作区设置,请转至如下菜单:File → Export → General → Preferences → To preference file
  • 若要导入工作区设置,请转至如下菜单:File → Import → General → Preferences → From preference file

要观看有关如何保存/导入工作区设置的视频演示,请查看参考资料一节。

虽然推荐该方法,但并非所有设置均可使用上述方法保留。保存所有偏好设置的另一种方法是将“.metadata.plugins\org.eclipse.core.runtime.settings”文件夹复制到新工作区中。仅当使用与旧工作区相同的 CCS 版本时才建议这样做。

6.1.1.1.2.删除工作区

若要删除工作区,只需从文件系统中删除工作区文件夹。请注意,这也会删除该工作区中包含的所有工程。

删除工作区不会自动将其从 CCS 在启动期间显示的最近工作区列表中删除。若要从最近工作区列表中删除工作区,请执行以下操作:

  • 编辑可在 <install dir>\ccsv[x]\eclipse\configuration.settings 中找到的 org.eclipse.ui.ide.prefs 文件,并删除所需的工作区。OR
  • 从 CCS 菜单 Window → Preferences → General → Startup and Shutdown → Workspaces 中删除工作区。

6.1.1.2.工程

工程会存储编译单个程序或库所需的所有信息,包括:

  • 源代码和对象库的文件名和路径。
  • 编译工具选项。
  • 包含文件依赖项。
  • 用于编译工程的编译工具版本。

工程通常包含文件和文件夹。与工作区类似,工程映射到文件系统中的一个实际文件夹。创建新工程时,其默认位置在工作区文件夹的子文件夹(以工程名称命名)中。但也可以选择工作区之外的文件夹。

创建工程后,将在工作区中对其进行引用,并且该工程将在 Project Explorer 视图中可见并可使用。工作区中的每个工程都必须有唯一的名称。

工程可以打开关闭。当创建工程或将工程导入工作区时,工程会自动打开。可同时打开多个工程。

工程关闭后,仍被定义到工作区,但无法通过工作台进行修改。已关闭工程的资源将不会出现在工作台中,但仍会留在本地文件系统中。已关闭工程需要的内存较少,常规活动期间也不会进行扫描。因此,关闭不需要的工程可提升 CCS 的性能。已关闭工程在 Project Explorer 视图中仍然可见,并带有“closed”文件夹图标,可在需要时轻松打开。

image0

若要打开或关闭工程,请执行以下操作:

  • Project Explorer 视图中右键点击工程名称,然后相应选择 Open ProjectClose Project

6.1.1.3.“Project Explorer”视图

Project Explorer 视图中显示属于活动工作区的所有工程。该视图基本上是工程文件夹文件系统的展示。如果在 Project Explorer 视图中创建子文件夹,并将文件移动到该子文件夹,则实际的文件系统也会改变。与此类似,对文件系统的更改也会反映在 Project Explorer 视图中。

请注意,并非所有出现在该视图中的文件均存在于文件系统中,反之亦然。链接的文件将出现在该视图中,但由于它们是引用内容,不是真实副本,因此它们不会出现在实际文件系统中。出现在 Project Explorer 视图中的“Binaries”和“Includes”文件夹也同样是引用内容。“Binaries”文件夹指向活动编译配置子文件夹(例如,“Debug”)中的可执行文件。

下面的屏幕截图展示了 Project Explorer 视图中“c6748_sinewave”工程的内容以及该工程如何映射到 Windows Explorer 工作区中的实际工程文件夹。请注意 Windows Explorer 展示的 CCS 生成的工程文件(.ccsproject、.cproject 和 .project)和 .settings 文件夹如何在 Project Explorer 视图中隐藏以及 Project Explorer 视图中的“Binaries”和“Includes”文件夹如何在 Windows Explorer 中不展示。除此之外,其余文件夹和文件在 Project Explorer 视图和 Windows Explorer 中的结构相同。

image1

可自定义 Project Explorer 视图以展示/隐藏各种文件类型,减少视图中的混乱。

_images/proj_explorer_filter.png

6.1.1.4.工程类型

Code Composer Studio 支持几种不同类型的工程。创建新工程时,可以指定工程类型。工程类型将决定编译界面会使用和显示的工具链和设置。

  • CCS 工程 - 使用 TI 工具链或使用 ARM 和 MSP430(包含在 CCSv6 及更高版本中)的 GCC 编译器时最常使用的工程类型。在这种类型的工程中,makefile 是自动生成的。如果用户正在使用 TI 嵌入式处理器,并希望创建工程以使用 JTAG 在 TI 器件/套件上进行加载和调试,请选择此工程类型。
  • C 或 C++ 工程 - 标准 Eclipse C 或 C++ 工程,需要外部工具链,如 GCC。工程向导允许选择可自动或不自动生成 makefile 的工程类型。例如,如果用户选择“可执行工程,共享库,静态库”工程类型,默认情况下会自动创建 makefile。如果选择的工程类型为“Makefile project”,将不会自动创建 makefile。也可以创建一个“Executable”工程,然后通过修改工程属性来不自动生成 makefile。如果要创建标准 Eclipse C/C++ 工程并让工程使用 GCC 等工具链,请选择此工程类型。
  • 带有现有代码的 makefile 工程 - 不自动创建 makefile 的空工程。用于导入、修改和编译现有的基于 makefile 的代码。如果代码库有自己的 makefile,但用户希望通过 GUI 界面编译工程,请选择这种类型的工程。创建工程时,请指定代码和 makefile 所在的位置,以及用于编译的工具链。

有关标准 Eclipse C/C++ 工程和 makefile 工程的更多信息,请参阅 Eclipse 在线文档

6.1.2.使用工程

本节介绍创建、导入和使用工程的步骤。

6.1.2.1.创建新工程

下面的步骤描述了如何为 CCS 支持的不同类型的工程创建新工程。

6.1.2.1.1.创建新 CCS 工程

要创建新的 CCS 工程,请按照“入门”一章的相关小节中的步骤进行操作。

6.1.2.1.2.创建新 C/C++ 工程

Eclipse 在线文档中描述了创建新的 managed make 或 standard make C/C++ 工程的一般步骤,预知详情,请访问此链接

6.1.2.1.3.创建新 makefile 工程

此链接中的 Eclipse 在线文档描述了创建 makefile 工程的一般步骤。

6.1.2.2.向工程中添加源文件或将源文件链接到工程

CCS 支持两种将源文件和/或文件夹添加到工程的方法。可以添加链接文件。

将文件/文件夹添加到工程后,实际上该文件/文件夹会被复制到工程目录的根位置。

将文件/文件夹链接到工程后,工程会在文件系统中创建对文件/文件夹的引用,而不会将其复制到工程目录中。链接的文件显示在 CCS Project Explorer 视图中,并带有特殊图标,如下所示。

image2

除非明确排除,否则工程中包含的所有文件(复制或链接的文件)都将包含在工程编译中。若要从编译中排除文件,请参阅从编译中排除文件

若要将文件复制或链接到工程,方法是:

  • 从工程环境菜单中选择 Add Files,浏览并选择待添加的文件,或者
  • 在系统的文件资源管理器(Windows 上的 Windows Explorer、macOS 上的 Finder 等)中选择文件,然后将其拖放到 Project Explorer 视图中的工程中,或者
  • 将文件直接复制到文件系统内的工程目录中。

如果使用前两种方法中的任何一种,该对话框将提示选择 Copy filesLink to files

image3

如果选择 Copy files,文件将直接复制到工程目录中。

如果选择 Link to files,将链接文件。可以将链接位置设置为绝对路径或相对于路径变量的路径。对于将在多个用户之间共享的工程,请使用相对链接路径,如可移植工程页面中所述。

若要观看有关如何将文件添加到工程的视频演示,请查看参考资料一节。

若要将文件夹复制或链接到工程,方法是:

  • 在系统的文件资源管理器(Windows 上的 Windows Explorer、macOS 上的 Finder 等)中选择文件夹,然后将其拖放到 Project Explorer 视图内的工程中(这考虑到复制或链接),或者

  • 若要链接文件夹,请执行以下步骤:

    • 右键点击工程,然后选择 New → Folder
    • 点击 Advanced >>
    • 选择 Link to alternate location (Linked Folder)

    image4

    • 点击 Browse 浏览到要链接的文件夹(或点击 Variables 使用变量来添加路径)。

    image5

    • 该文件夹现在应链接到工程。

    image6

如果您发现 Link to files 未按预期工作(例如文件在选择后未显示在 Project Explorer 视图中),请检查您是否在“Drag and Drop Settings”中启用了 Enable linked resources

image7

image8

链接文件实际上位于工程文件夹之外的位置,因此请注意,编辑这些文件不仅会修改当前工程的文件,还会修改链接到同一文件的任何其他工程的文件。这在使用可能在多个工程之间共享源文件的 TI 软件包和 SDK 时尤为重要。

6.1.2.2.1.将资源导出到存档文件

若要将属于工程的所有源文件的副本(无论是复制的还是链接的)存档,从而将它们保存到代码存储库或与其他用户共享,可以将资源导出到存档文件。

  1. Project Explorer 视图中右键点击工程,选择 Export,展开 General,然后选择 Archive File
  2. 单击下一步 (Next)
  3. 如果想导出链接的资源,请选中复选框 Resolve and export linked resources
  4. 点击 Select All 或仅选择所需的资源。

image9

  1. To archive file: 字段中,指定归档文件的名称和位置。
  2. 单击完成 (Finish)

生成的存档文件将包含所选资源的副本。

请注意,将存档内容导入另一个工作区时,所有资源(包括链接的资源)都将被提取到根工程文件夹中,而非保留链接文件的原始目录结构。因此,该操作允许导出/共享资源,但不会在导入时完全重新创建原始编译环境。

6.1.2.3.导入工程

比起创建新工程,使用现有工程更为常见。这可以是用户自己开发的工程,也可以是 TI 提供的示例工程。在这种情况下,首先必须将工程导入 CCS。

CCS 可以导入使用相同版本或更低版本的 CCS 创建的工程,包括旧版 CCSv3 工程。但请记住,用于创建工程的 CCS 版本和用于导入工程的版本差异越大,导入过程就越容易出错。

根据工程的类型和来源,有几种不同的导入工程的方法。

使用 Resource Explorer 导入 TI 示例工程(建议尽可能使用该方法):

Resource Explorer(在 CCSv7 及更高版本中)可帮助浏览所选平台的示例、下载软件包和从单个界面导入工程。使用 Resource Explorer 导入的工程本身将复制到工作区。

有关 Resource Explorer 的更多信息,请访问此处。另请参阅入门一章中的该节。

若要从 Resource Explorer 导入工程,请执行以下操作:

  1. View 菜单打开 Resource Explorer 视图。
  2. Software 下,展开所选器件的软件包。
  3. 导航到示例工程并选择该工程。
  4. 在右侧窗格中,点击 Import to IDE

注意:如果已经下载并安装了包含示例的软件包,则将导入该工程。否则会有提示,要求先安装软件包,然后才能导入工程。

_images/project_import_rex4.png


使用 Resource Explorer Classic(旧版)导入 TI 示例工程:

如果您使用 CCS 5.2+ 至 CCSv6,您可能对该导入方法感兴趣。这些较早 CCS 版本中的 Resource Explorer 界面与 CCSv7 和更高版本中的界面不同。您无法通过该界面下载软件包,但如果您的计算机上已安装该界面,您仍然可以通过较旧的软件包(如 TI-RTOS、ControlSuite 等)浏览和导入示例工程。

该 Resource Explorer 界面(现在称为 Resource Explorer Classic)仍包含在 CCSv7 和 v8 中,但不建议与较新的软件包一起使用。另请注意,Resource Explorer Classic 在 CCSv9 和更高版本中不可用。

有关 Resource Explorer Classic 的更多信息,请访问此处

要从 Resource Explorer Classic 导入工程,请执行以下操作:

  1. View 菜单打开 Resource Explorer Classic
  2. 导航至您要导入的工程并点击 Import the example project into CCS

image11


导入 CCS 工程(CCSv3 工程以外的工程):

要使用 CCS 菜单导入 CCS 工程,请参阅入门一章中的相关小节。


导入标准 Eclipse C/C++ 工程(不建议将以下过程用于 CCS 工程):

  1. 转至菜单 File → Import → General → Existing Projects into Workspace
  2. 按照导入向导中提供的步骤进行操作。


导入旧 CCSv3 工程:

  1. 转至菜单 Project → Import Legacy CCSv3.3 Projects
  2. 点击 Select a project file 旁的 Browse,浏览至该 CCSv3.3 工程文件 (.pjt),或选择 Select search-directory 并点击 Browse 以浏览至包含该 CCSv3.3 工程文件的目录。
  3. 按照工程向导中提供的步骤进行操作。

有关更详细的参考,请点击此处

6.1.2.3.1.工程导入错误

请参阅疑难解答一节,获取有关解决常见工程导入错误的信息。

6.1.2.3.2.导入工程中的变量

默认情况下,CCS 变量 PROJECT_ROOT 设置为工程的根文件夹(包含 .*project 文件的文件夹)。导入工程时(选中“Copy project into workspace”复选框),CCS 将创建一个名为 ORIGINAL_PROJECT_ROOT 的新变量/宏,其值设置为原始工程的根目录。

如果原始工程在任何路径(例如编译器包含路径)中指定了宏 ${PROJECT_ROOT},则在导入的工程中将替换为 ${ORIGINAL_PROJECT_ROOT}。这样操作是因为工程可能仍需要引用其路径相对于原始工程位置设置的资源。

许多工程的结构是这样的:Include 文件位于一个共同的文件夹中,几个工程可以使用/引用同一组公共 Include 文件。TI 的几个软件包如 TivaWare、C2000Ware 也是这样设置的。将这些软件包中的工程导入并复制到工作区时,不必复制 Include 文件夹。因此,如果原始工程具有相对于变量 PROJECT_ROOT 设置的编译器包含路径,则这些路径将在工程导入后转换为使用 ORIGINAL_PROJECT_ROOT。因而相对于原始工程仍然正确引用了 Include 文件。

在自定义工程中,如果用户希望指定 Include 路径始终相对于“当前”工程目录而不是“原始”工程目录,请使用变量 ProjDirPath 而不是 PROJECT_ROOT。

6.1.2.4.重命名工程

若要重命名已在 Project Explorer 视图中打开的工程,请执行以下操作:

  1. 右键点击该工程,然后选择 Rename
  2. 赋予新名称并点击“OK”。

6.1.2.5.复制工程

若要生成已导入并在 Project Explorer 视图中打开的工程的副本,请执行以下操作:

  1. 右键点击该工程,然后选择 Copy
  2. Project Explorer 视图中右键点击,然后选择 Paste
  3. Copy Project 对话框中
    • 赋予新工程一个不同的名称,然后
    • 使用默认位置或指定一个不同的位置。

复制过程中,会将文件/资源从原始工程文件夹复制到目标工程文件夹中。但是,如果工程包含链接资源,它们仍将指向其原始位置。在直接编辑此类文件之前,用户需要检查工程是否引用了位于其他位置的链接文件/资源。有关更多信息,请参阅该有关链接的文件的一节。

6.1.2.6.删除工程

若要删除 Project Explorer 视图中的工程,请执行以下操作:

  1. 右键点击该工程,然后选择 Delete
  2. Delete Resources 对话框中,选择是否另外删除磁盘上的工程内容。
    如果选中该复选框,则文件系统中的工程目录将被删除。如果未选中该复选框,该工程将从 CCS 工作区中删除,但该目录仍将在文件系统中,这个工程依然可以被导入至工作区中。

6.1.2.7.共享工程

当需要与其他用户共享工程或方便多个用户同时处理同一个工程时,工程的结构很重要。此处讨论了共享工程的常见用例。

  • 共享“简单”工程或“链接文件”工程。如果想共享工程文件夹和编译工程所需的所有源文件,请使用此方法。源文件可以完全包含在工程文件夹中,也可以链接到工程。
    请参阅以下页面,了解如何共享此类工程。
    共享工程
  • 仅共享“链接文件”工程的工程文件夹。如果只想共享工程文件夹,请使用此方法。假设接收工程人员已经拥有副本或对源文件的访问权限。这是在源代码控制中进行维护的工程的常见用例。在这种情况下,工程应可移植,从而能够在多个用户之间轻松共享。可移植工程的关键是避免使用绝对路径。创建可移植工程涉及使用变量 - 链接的资源路径变量和编译变量。
    请参阅该文章,了解有关这些变量以及如何创建可移植工程的更多信息。
    便携项目

6.1.2.7.1.跨操作系统的可移植性

除了创建没有任何绝对路径的工程外,如果需要跨操作系统移植工程,还需要考虑的其他事项为:

  • 在所有设置和选项中使用正斜杠。
  • 避免在文件名中使用大写/小写字符,因为 Windows 不会区分这些字符,但 Linux 会区分。

6.1.2.8.组织工程

Eclipse 框架(以及通过扩展、CCS)让组织和导航工程资源变得十分灵活。此处描述了一些功能。

6.1.2.8.1.工作集

工作集用于对元素进行分组,以便在视图中显示或对一组元素进行操作。

您可以使用工作集来限制在 Project Explorer 视图中显示的资源集。如果用户在视图中选择工作集,则仅展示工作集中包含的资源、资源的子资源和资源的父资源。

如果在视图中有大量工程,但想在给定时间仅处理其中的一个子集,这将非常有用。

若要创建工作集,请执行以下操作:

  1. Project Explorer 视图中点击 View 菜单,然后转至 Select Working Set

image12

  1. 选择 Selected Working Sets,然后点击 New 创建新工作集。

image13

  1. 选择 C/C++ 作为工作集类型,然后点击 Next

image14

  1. 命名该工作集并为该工作集选择工程。

image15

  1. 单击完成 (Finish)
  2. 创建工作集后,选择该工作集,然后点击 OK

image16

  1. 使用 Project Explorer 视图中的 View 菜单,选择/取消选择工作集并控制工程的显示方式。
  2. 在此示例中,对“Top Level Elements”进行了设置,工作集和“其他工程”均会显示。

image17

image18

若要观看有关如何使用工作集的视频演示,请查看参考资料一节。

6.1.2.8.2.虚拟文件夹

虚拟文件夹是仅存在于 CCS 工作区树中且没有文件系统位置的文件夹。使用虚拟文件夹,可以在独立于文件系统中位置的工程层次结构中对文件和文件夹进行整理。

不能在虚拟文件夹下创建常规文件和文件夹资源。只能在虚拟文件夹下直接创建其他虚拟文件夹或链接资源。

若要创建虚拟文件夹,请执行以下操作:

  1. Project Explorer 视图中,右键点击要在其中创建虚拟文件夹的工程或文件夹。
  2. 选择 New → Folder
  3. Folder name 字段中,指定将出现在工作台中的文件夹名称。该名称可以与文件系统中的文件夹名称不同。
  4. 点击 Advanced
  5. 选择 Folder is not located in the file system (Virtual Folder)
  6. 单击完成 (Finish)

您现在可以将文件链接到虚拟文件夹。

若要观看有关如何使用虚拟文件夹的视频演示,请查看参考资料一节。

6.1.3.配置工程

CCS 在工程配置和管理方面十分灵活。

6.1.3.1.工程属性

有许多定义工程属性的设置,例如用于编译的工具集、编译器和链接器编译选项、工程依赖项和环境变量,仅举几例。可以通过工程属性查看和自定义这些设置。本节介绍了更为常用的工程设置。

6.1.3.1.1.常规属性

若要查看和自定义常规属性,右键点击工程并转至 Properties,然后点击左侧窗格中的 General

右侧窗格中的 Project 选项卡(之前在 CCS 7.3 和更低版本中称为 Main)包含以下内容:

  • 器件和连接详细信息
  • 编译器版本
  • 输出类型、输出格式和器件字节序
  • 链接器命令文件
  • 运行时支持库

image19

有关 Linker command fileRuntime support library 的更多信息,请参阅链接器命令文件运行时支持库这两篇文章。

Output format 字段决定了可执行文件 (.out) 的格式

Compiler version 字段展示了用于编译的编译器工具的版本。如果导入到 CCS 中的工程最初创建时使用的编译器工具版本与机器中安装的版本或 CCS 设置使用的版本不同,CCS 将作出告知:用于编译的版本与原始版本不同。该信息将显示在 Compiler version 字段中,如下所示。

image20

右侧窗格中的 Products 选项卡(之前在 CCS 7.3 和更低版本中称为 RTSC)包含以下内容:

  • 为工程安装和启用的产品列表

对于基于 RTSC/TI-RTOS 的工程,它还包含:

  • XDCpath 软件包存储库
  • 目标设备
  • 平台
  • 编译配置文件
_images/general_proj_properties_rtsc_3.png

Target 字段根据在 Project 选项卡中选择的 Device Variant 值自动填充。

Platform 字段可由用户根据目标板进行选择。对于示例工程,通常会自动填充。

Build-profile 字段展示了配置编译应链接到哪些 RTSC 和 SYS/BIOS 库。该选择将编译选项应用于编译 RTSC 配置 (.cfg) 时生成的 C 文件。请注意,这与适用于用户源代码的编译器属性下选择的编译选项不同。例如,如果您选择 release 式 RTSC 配置文件,则可能会在编译中添加 -O2 优化选项,如果选择 debug 式 RTSC 配置文件,就不会有 -O2 优化选项。release 式编译是个不错的选择,因为 RTSC 和 SYS/BIOS 运行时速度会更快并且使用更少的代码内存。debug 式编译会使编译速度更快,但运行时应用的效率会降低。

6.1.3.1.2.编译属性

若要查看和自定义编译属性,右键点击工程并转至 Properties,然后点击左侧窗格中的 Build。右侧窗格将显示多个选项卡。每个选项卡中的设置如下所述。有关这些设置及其使用的更多详细信息,请参见后面的小节。

Builder:定义编译命令、makefile 生成和一些其他编译设置。

大多数用户不需要调整 BuilderMakefile generation 下的默认设置。设置这些是为使用默认编译命令并自动生成 makefile。
高级用户可能希望自定义 gmake 命令,甚至使用不同的 make 实用程序。
如果您希望使用默认 gmake 以外的 make 实用程序,请参阅更改 make 实用程序

Stop on first build error 复选框用于控制编译是否应在发生第一个编译错误后立即停止。默认情况下,该复选框未被选中。这将 -k (–keep-going) 选项传递给 gmake,让其“继续运行”或在出错后尽可能继续编译。如果选中此复框,-k 选项将消失并且编译将在第一个编译错误处停止。

请注意,即使选中此复选框,仍会完成当前源文件的编译并报告在该文件中发现的所有错误。但是,不会继续编译其他源文件。此外,如果选中 Enable parallel build,多个源文件可能会同时开始编译,在这种情况下,编译将在所有文件完成后停止。如果使用自定义编译步骤,可能需要删除 -k 选项。

Enable parallel build 设置默认启用,并利用具有多核的 PC 运行并行编译,从而缩短编译时间。有关更多详细信息,请参阅并行编译一节。

Validator:设置对不同工具版本的遵守程度。

该选项卡在 CCS 7.4 及更高版本中可见。该设置配置工具版本不匹配的严重程度。如果想严格控制要用于工程编译的编译器和其他产品的版本,这将非常有用。

步骤:预编译和编译后处理步骤。

预编译步骤是在进行主工程编译之前执行的步骤。
编译后处理步骤是在进行主工程编译之后执行的步骤。
有关更多信息,请参阅预编译和编译后处理步骤

Variables:展示编译变量。

选中 Show system variables 将显示所有系统级和内置变量,否则仅显示工程级变量。
编译变量可用于编译器和链接器编译选项,例如,指定 Include 文件或库相对于编译变量的路径。
有关编译变量的更多信息,请参阅可移植工程

环境: 定义环境变量。

Link Order:定义文件传递给链接器的顺序。

如需严格控制链接顺序,可以在此处添加所需文件并控制其传递给链接器的顺序。

依赖项:定义工程之间的依赖项,允许在依赖工程之前编译引用的工程。

有关更多信息,请参阅工程依赖项

在 CCS 7.3 及更低版本中,Behavior 选项卡定义了编译设置和工作台编译行为。在 CCS 7.4 及更高版本中,这些设置移至 Builder 选项卡。

Build 类别下有几个子类别:

  • CompilerLinkerHex Utility 用于配置和设置代码生成工具的选项
  • XDCtools 用于配置 RTSC/TI-RTOS 工程
  • SysConfig 用于配置 SysConfig 工程

Compiler/Linker:编译器和链接器选项

有多个编译器和链接器选项可用于控制您的编译。选项列表太大,无法在此处详细介绍。有关编译器和链接器分别支持的选项的详细信息,请参阅编译器和汇编语言工具用户指南。在“CCS Build Properties”对话框中,这些选项分为多个组,以便于识别。您可以深入到 CCS GUI 中的“Compiler”和“Linker”部分以访问所有可用选项。

也可以直接通过 Edit Flags 按钮添加或删除编译器和链接器标志。

image22

Hex Utility:十六进制实用程序选项

十六进制实用程序可以作为 CCS 编译的一部分进行启用和调用。默认情况下,针对新 CCS 工程禁用十六进制实用程序。启用后,有多个选项可用。有关十六进制转换实用程序支持的选项的详细信息,请参阅汇编语言工具用户指南

也可以直接通过 Edit Flags 按钮添加或删除十六进制实用程序标志。

_images/project_properties_hexutility.png

有关如何将十六进制实用程序集成到 CCS 中的更多信息,请参阅 CCS 中的十六进制实用程序页面。

XDCtools:XDCtools 选项

有关支持的选项,请参阅 SYS/BIOS 用户指南

SysConfig:SysConfig 选项

XXXTODO

6.1.3.2.高级工程设置

用户可使用一些高级工程设置来控制 Code Analysis、Indexer、Code Style 等功能。

若要查看和自定义这些高级设置,请右键点击工程并转至 Properties,然后点击左侧窗格底部的 Show advanced settings。选择 C/C++ General 可以访问这些设置。

下面的小节更详细地描述了一些更常用的设置,例如 Code Analysis 和 Indexer。有关其他设置的更多信息,请参阅 Eclipse CDT 文档

6.1.3.2.1.代码分析

这是 Eclipse CDT 附带的内置静态代码分析器,用于报告编程错误、语法和语义错误等。默认设置是在工作区级别设置的,但也可以在工程级别进行配置。

可以通过 Project Properties → C/C++ General → Code Analysis 来访问这些设置。为使该设置可见,请确保点击对话框左下角的 Show advanced settings

_images/code_analysis_v9.png

默认情况下,CCS 工程在内部禁用 Code Analysis 检查。

默认情况下禁用这些检查的原因是 Eclipse 静态分析工具中定义的规则与 TI 工具中定义的规则有些不同。通常使用 TI 编译器工具针对 TI 嵌入式器件进行开发的用户对 TI 工具报告的错误(而非通用 Eclipse CDT 错误)更感兴趣。为了避免在两组错误检查之间产生混淆,系统禁用代码分析检查。

要确认是否已禁用代码分析,请转至 Project Properties → C/C++ General → Code Analysis → Launching,并观察是否已取消选中“Run with build”和“Run as you type”框。

如果在 Code Analysis 对话框中点击 ApplyApply and Close,将开启代码分析。这可能会触发语法和编程错误。如果仅在 Problems 视图和 CCS 编辑器边缘中报告错误,但不在 CCS 编译控制台中进行报告,则错误可能来自 Eclipse CDT,而不是来自 TI 编译器工具,因此不影响编译。

确认错误来源的另一种方法是在 Problems 视图中查看 Type 字段。

如果 Type 字段显示“C/C++ Problem”,则表明错误来自 TI 编译工具。

_images/code_analysis_v9_c_problem.png

如果 Type 字段显示“Semantic Error”或“Syntax Error”,则表明错误来自 Eclipse Code Analysis 工具。

_images/code_analysis_v9_semanticerror.png


如果无意中为工程打开了代码分析检查,请执行以下步骤再次将其关闭,以便不再显示编辑器中的错误:

  1. Problems 视图中,选择所有消息/错误并点击 Delete
  2. 右键点击工程并点击 Refresh
  3. 在编辑器视图中关闭源文件,然后将其重新打开。

要使代码分析保持开启状态但禁用或自定义单个设置,请选择特定的项目并点击 Customize Selected

6.1.3.2.2.Indexer

这是内置的 Eclipse 解析器。该解析器可解析工程中的源文件和头文件,从而创建可为 C/C++ 搜索、导航功能和内容辅助(代码完成)奠定基础的数据库。

若要配置或禁用索引器(在工作区级别),请转至 Window → Preferences → C/C++ → Indexer 菜单。为使该设置可见,请确保点击对话框左下角的 Show advanced settings

默认设置是在工作区级别设置的,但也可以在工程级别进行配置(方法是选中下面突出显示的复选框)。

_images/ccs_indexer_v9.png

默认情况下,索引器处于启用状态,但如果用户不使用 CCS 编辑器或不需要高级编辑器功能,则可以将其关闭。索引器不断扫描所有打开的工程以支持一些高级编辑器功能,并使用相当数量的系统资源,这有时会导致 CCS 运行缓慢。对于大型工程或工作区中有许多打开的工程(或两者)时,这通常更明显。在这些情况下,关闭索引器可能会提高性能。

在某些情况下,即使编译本身没有问题,索引器也可能会报告 Syntax 错误或 Symbol could not be resolved 错误。换而言之,Build ConsoleProblems 视图不报告错误,但是会在编辑器边缘中突出显示错误。

首先要做的(尤其是在使用者是团队中唯一一个在已知良好工程中遇到此类错误的人的情况下)是打开一个新的、干净的工作区并将工程重新导入其中。如果错误仍然存在,或者在自定义工程中遇到这些错误,可以考虑调整索引器设置甚至禁用索引器。可通过 Project Properties → C/C++ General → Indexer 实现该目的。但是,完全禁用索引器意味着无法使用代码完成和导航到声明/定义等功能。禁用索引器标记而不禁用索引器本身可能是更好的选择。为此,请转至 Window → Preferences → General → Editors → Text Editors → Annotations,并取消选中 C/C++ Indexer Markers 的全部三个复选框。

6.1.3.2.2.1.重新编译索引

如果用户发现 Code completion、Open declaration 等高级编辑器功能无法正常运作,则这可能由数据库/缓存损坏造成的。在这种情况下,重新编译索引可以解决问题。

若要为工程重新编译索引数据库,请在 Project Explorer 视图中右键点击工程,然后选择 Index → Rebuild

6.1.3.3.并行编译

启用并行编译选项可利用当今非常常见的多核计算机来加快编译。这在处理大型工程时尤其有用。

该选项在新的 CCS 工程和大多数 TI 示例工程中默认启用。

image25

若要自定义该设置,请在 Project Explorer 视图中右键点击工程,然后转至 Properties → Build → Builder 选项卡(在 CCS 7.3 及更早版本中为 Behavior 选项卡)。

可以在此处自定义要运行的并行作业数量。默认值将设置为机器上可用处理器的数量,但可通过反复试验找到更理想的数量。请注意,若设置的作业数量远高于计算机中处理器的数量或将其设置为使用没有限制的作业可能会导致系统使用更多内存并变得缓慢。

启用并行编译时,由于多个作业同时运行,CCS 编译控制台中的消息/横幅将交错显示。

要观看并行编译的视频演示,请查看参考资料一节。

6.1.3.4.预编译和编译后处理步骤

作为 CCS 编译内容,可以定义预编译和编译后处理步骤。

预编译步骤是在进行主工程编译之前执行的步骤。
即使主编译的状态及时更新,也会始终执行预编译步骤。无论执行预编译步骤是成功还是失败,都会尝试执行主编译。

编译后处理步骤是在进行主工程编译之后执行的步骤。
如果确定主编译的状态及时更新,则不会执行编译后处理步骤。只有在主编译成功执行后才会执行。

编译后处理步骤的一个常见用例是使用十六进制转换器或其他实用程序(例如,tiobj2bin)将工程创建的可执行文件 (.out) 转换为十六进制或二进制格式。十六进制转换器是编译器工具集的一部分(可以在 CCS 安装中的 \ccs\tools\compiler\<compiler_version>\bin 中找到),tiobj2bin 包含在 CCS 中(可以在 CCS 安装的 \ccs\utils\tiobj2bin 中找到)。

若要在 CCS 中设置预编译和编译后处理步骤,请在 Project Explorer 视图中右键点击工程,转至 Properties → Build → Steps 选项卡,然后在 Pre-build stepsPost-build steps 字段中输入所需的命令。

例如,要将可执行文件 (.out) 转换为二进制格式 (.bin),可以使用以下命令作为编译后处理步骤:

“${CCS_INSTALL_ROOT}/utils/tiobj2bin/tiobj2bin” “${BuildArtifactFileName}” “${BuildArtifactFileBaseName}.bin” “${CG_TOOL_ROOT}/bin/ofd2000” “${CG_TOOL_ROOT}/bin/hex2000” “${CCS_INSTALL_ROOT}/utils/tiobj2bin/mkhex4bin”

请确保将 ofd2000 和 hex2000 替换为器件的相应二进制文件,例如 ofd6x 和 hex6x(对于 C6000)或 armofd 和 armhex(对于 ARM)。

请注意,TivaWare 和 Simplelink SDK 等软件包中的一些示例工程已经执行了类似的编译后处理步骤,也可将其用作参考。

6.1.3.4.1.运行多个命令

预编译和编译后处理步骤的字段允许添加多个命令,每个命令都在一个新行上。

image26

6.1.3.4.2.添加自定义步骤

若要在编译步骤之后但在链接步骤之前添加一些自定义步骤或调用批处理文件,可以在链接器选项的命令字段中添加一个预链接步骤,如下所示。自定义步骤基本上位于现有命令之前,并用 & 符号分隔。下面的示例中,添加了一个预链接步骤,调用批处理文件。

image27

6.1.3.5.更改 make 实用程序

CCS 使用 gmake (GNU make) 来编译工程。如需使用不同的 make 实用程序或自定义编译步骤,可以执行以下操作:

  1. Project Explorer 视图中,右键点击工程并选择 Properties
  2. 在左侧窗格中选择 Build,在右侧窗格中选择 Builder 选项卡。
  3. 取消选中 Use default build command
  4. Build command 字段中输入用于编译的自定义命令。

如果想简单地修改默认编译命令以将其他选项传递给 gmake,也可以使用该方法。

使用自定义的编译步骤时,可能需要考虑启用 Stop on first build error 编译设置。如果未启用该设置,将在命令末尾添加一个 -k (-keep-going) 选项(对于 gmake,此选项要求其“继续运行”或在出错后尽可能继续编译),某些自定义编译命令可能不需要这样。

image28

必须在工程级别更改该设置。没有更改默认编译器或编译器选项的全局方法。

6.1.3.6.工程依赖项

可以构建工程,如此一来,主要工程可依赖于其他工程。一个常见的用例场景是主工程链接到库中并且库的工程被设置为引用工程。在该设置中,编译主工程时,将首先编译引用工程,然后是主工程。

创建新的 CCS 工程时或从现有工程的工程属性中可以设置工程依赖项。为了创建依赖项,所有引用的工程必须与主工程位于同一工作区中。

若要创建工程依赖项,请执行以下操作:

  1. Project Explorer 视图中,右键点击工程并选择 Properties
  2. 在左侧窗格中选择 Build,在右侧窗格中选择 Dependencies 选项卡。
  3. 点击 Add,选择要添加到引用列表的工程,然后点击 OK

image29

在编译引用工程时,可在 Referenced Build-configuration 列选择要使用的 编译配置。请注意,该设置将用于主工程的活动编译配置。在编译主工程的特定编译配置之前,用户可通过该设置来控制将编译的引用工程的编译配置。

image30

创建依赖项并不意味着由依赖工程生成的库会自动链接到主工程中。仅意味着依赖工程将在主工程之前编译,因此自上次编译以来对依赖工程所做的任何更改都将被收录。库文件仍需手动链接到主工程。这可以通过将库文件链接到主工程或通过将库名称和路径添加到主工程的链接器选项来完成。

若要观看有关如何设置工程依赖项的视频演示,请查看参考资料一节。

6.1.3.6.1.继承变量

从 CCSv7 开始,具有库工程依赖项的工程可能会在编译器中展示以下变量,即包括路径、链接器库以及搜索路径选项:

“${INHERITED_INCLUDE_PATH}”
“${INHERITED_LIBRARIES}”
“${INHERITED_LIBRARY_PATH}”

看起来这些变量是从依赖工程继承的,但实际上 CCS 目前并未使用这些变量。尽管这些变量已添加到工程中,但它们目前无法解析任何内容或用于任何目的。

一种确认方法是将鼠标悬停在变量旁边的三个点 (...) 上时显示其解析为 <none>。

_images/inherited_variables.png

6.1.3.7.特定于文件的选项

可以设置与工程级别选项不同的文件级别编译选项。例如,当特定文件需要比其他文件更高或更低的优化级别时,这将很有用。

若要设置特定于文件的选项,请在 Project Explorer 视图中右键点击文件(或文件夹),转至 Properties,然后设置所需的选项。

Project Explorer 视图中所显示带有特定于文件的选项的文件带有特殊图标(图钉)。

image31

若要恢复文件的默认设置,请执行以下操作:

  1. Project Explorer 视图中右键点击文件。
  2. 选择 Resource Configurations → Reset to Default
  3. 选择用于恢复至默认设置的资源配置,然后点击 OK

image32

当设置重置为默认值时,特殊图标将消失。

若要观看设置特定于文件的选项的视频演示,请查看参考资料一节。

添加文件特定选项时,工程元数据文件中会添加一个部分,指示存在文件特定选项以及要覆盖的默认选项。在对文件使用 Resource Configurations → Reset to Default 选项时,整个部分将被删除。因此,工程认为工程中不再有任何文件特定选项,并且该文件的特殊图标也被删除。

如果改为转至文件的 Properties → Resource 并点击 Restore Defaults,则会将选项恢复为默认值,但不会删除特殊图标。这是因为即使删除了覆盖选项,先前添加的文件的特殊部分仍然存在,因此图标仍然存在。

如果想了解为某个源文件设置了哪些文件特定选项,有以下几种方法可以找到:

  • 使用 GUI:
    右键点击源文件,选择 Properties,然后浏览选项。特定于文件的选项将以加粗的方式突出显示。
image33
  • 使用工程文件夹中的 .cproject 文件:
    添加特定于文件的选项后,会向该工程文件中添加一个部分(在 <fileInfo> 标记之间查找)。

6.1.3.8.从编译中排除文件

默认情况下,CCS 工程文件夹中的所有文件和文件夹都被认为是工程编译的一部分。

若要从 CCS 工程编译中排除文件或文件夹,请在 Project Explorer 视图中右键点击文件或文件夹,然后选择 Exclude from Build

如果工程有多个编译配置,可以指定要排除文件的编译配置。为此,请在 Project Explorer 视图中右键点击文件或文件夹,然后选择 Resource Configurations → Exclude from Build。在弹出对话框中选择要排除该文件的编译配置

在使用默认设置的情况下,从编译中排除的文件(或文件夹)将在 Project Explorer 视图中灰显。

image34

如果从编译中排除的文件在 Project Explorer 视图中根本不可见,请检查是否在视图筛选器中针对 Project Explorer 视图启用了以下选项。

image35

6.1.3.9.更改编译器版本

所有 CCS 版本都与特定版本的编译器工具捆绑在一起。在工程开发阶段,用户可能希望使用与 CCS 中包含的版本不同的编译器工具来编译工程。一个原因可能是利用较新版本编译器中的错误修复和增强功能,另一个原因可能是使较旧版本的编译器保持锁定。在这个方面,CCS 非常灵活。

若要查看用于工程编译的编译器版本,请在 Project Explorer 视图中右键点击工程,转至 Properties → General → Project 选项卡,然后查看 Compiler version 字段。如果导入到 CCS 中的工程一开始创建时使用的编译器工具版本与计算机中安装的版本或 CCS 设置使用的版本不同,则将鼠标悬停在 Compiler version 字段上时会显示该信息。

如果在 CCS 中发现/安装了多个版本,Compiler version 字段的下拉菜单将展示可供使用的不同版本。

如果想使用与现有版本不同的编译器工具版本进行编译,用户可以安装特定版本并让 CCS 发现该版本。有关详细信息,请参阅文章编译器的安装和选择

6.1.3.10.更改 SYSBIOS/XDCtools 和产品版本

与更改编译器工具版本类似,也可更改用于编译工程的 XDCtools 和 SDK 等产品的版本。

若要查看用于编译的 XDCtools 的当前版本和其他产品详细信息,请右键点击工程,然后转至 Properties → General → Products 选项卡。该选项卡显示用于编译的 XDCtools 版本,以及可用和已启用的产品和存储库等。

如果在 CCS 中发现/安装了多个版本,XDCtools version 下的下拉菜单将展示可供使用的不同版本。与此类似,Products and Repositories 视图将展示发现/安装到 CCS 中的所有产品。

如果用户希望使用与现有版本不同的 XDCtools 或 SDK 版本进行编译,则可安装特定版本并让 CCS 发现该版本(又名“Product Discovery”)。有关详细信息,请参阅文章产品的安装和选择

6.1.3.11.编译配置

在开发过程中,需要创建单个工程来编译具有不同工程选项、源文件甚至不同内存配置的可执行文件(.out 文件),这是很常见的。在 CCS 中,这是通过工程编译配置来完成的。

工程编译配置在工程级别定义了一组编译选项和资源,这些选项和资源可以通过极少步骤进行标记和轻松访问。因此,通过在单个工程中创建多个编译配置,可以在不同的选项和资源集之间进行整理和快速切换。

在 CCS 中创建新工程时,默认会创建两个编译配置:DebugRelease。Debug 编译配置通常没有优化功能但会启用完整的符号调试功能,从而实现轻松调试。Release 编译配置通常会启用优化功能并禁用符号调试功能,这样代码便会相当小或速度相当快,而无需进行源代码级调试。这些只是通常为默认编译配置设置的选项,不同的器件系列可能会有所不同,因此建议检查为每个编译配置设置的默认选项并根据需要进行调整。

创建新工程或将现有工程导入 CCS 时,第一个配置(按字母顺序)在工作区中设置为活动状态。通常这是 Debug 配置,但可能会因配置名称而异。

请注意,TI 提供的某些示例工程可能具有除 Debug 和 Release 之外的自定义配置名称。例如,C2000Ware 中的工程可能具有 RAM 和 Flash 配置,其中一个设置为从 RAM 运行,另一个设置为从 Flash 运行。根据配置,工程可能使用不同的链接器命令文件,并且可能包含或不包含某些源文件。

编译工程时,编译生成的输出文件会放置在特定于配置的子目录中。例如,如果工程位于 MyProjects 目录中,则 Debug 配置的输出文件将放置在 MyProjects\Debug 中。与此类似,Release 配置的输出文件将放置在 MyProjects\Release 中。

若要更改活动配置,请执行以下操作:

  • Project Explorer 视图中右键点击工程。
  • 转至 Build Configurations → Set Active 并选择所需的配置。
    OR
  • Project Explorer 视图中右键点击工程并转至 Properties
  • 在左侧窗格中选择 General
  • 点击 Manage Configurations
  • 选择所需的配置并点击 Set Active

若要观看有关如何更改编译配置的视频演示,请查看参考资料一节。

若要创建和管理自定义配置,请执行以下操作:

  • Project Explorer 视图中右键点击工程。
  • 转至 Build Configurations → Manage
    OR
  • Project Explorer 视图中右键点击工程并转至 Properties
  • 在左侧窗格中选择 General
  • 点击 Manage Configurations

可以在此处删除、重命名和创建新配置。创建新配置时,有几个选项可用于复制一组基本的选项/设置。

若要观看有关如何创建和管理编译配置的视频演示,请查看参考资料一节。

若要编译工程的所有编译配置,请执行以下操作:

  • Project Explorer 视图中右键点击工程。
  • 转至 Build Configurations → Build All

6.2.编译工程

有一些可用于编译工程的选项:

  1. Full Builds - 重新编译并重新链接所有源文件。
    若要重新编译当前活动工程,请执行以下操作:从工程的上下文菜单中选择 Rebuild Project
    若要在工作区中重新编译所有打开的工程,请执行以下操作:选择 Project → Clean 菜单。然后选择 Project → Build
  2. Incremental Builds - 仅编译和重新链接自上次编译以来修改过的源文件。
    若要编译当前活动工程,请执行以下操作:选择 Project → Build Project 菜单或者从工程的上下文菜单中选择 Build Project
    若要在工作区中编译所有打开的工程,请执行以下操作:选择 Project → Build All 菜单。该操作将编译工作区中所有工程的活动编译配置。
  3. Build Automatically - 每当保存任何源文件或相关头文件时,都会自动执行增量编译。
    选择 Project → Build Automatically 菜单。

在编译期间,“Console”视图显示编译工具的标准和错误输出。
编译完成后,“Problems”视图显示所有错误或警告。

如果在编译过程中遇到错误,请参考 Build errors in CCS 页面。该页面讨论了一些更为常见的编译错误和警告以及其解决方法。

6.2.1.工程文件和编译系统概述

CCS 工程使用 Eclipse 托管的 make 系统,其中 makefile 自动生成并负责管理工具链和编译详细信息。

本节概述了工程元数据文件,并描述了在工程创建和编译步骤期间发生的情况。

6.2.1.1.创建工程

创建新的 CCS 工程时,会在工程文件夹中创建以下工程元数据文件和文件夹:

  • .ccsproject:存储 TI 提供的工程设置。
    • 例如:存储用户在工程创建时输入的初始器件/工具链设置。
  • .cproject:存储由 C/C++ Development Tooling (CDT) 提供的工程设置。
    • 例如:将大部分编译属性存储在“Build”部分(大多数编译器/链接器选项)下。
  • .project:存储 Eclipse 提供的工程设置。
    • 例如:存储链接资源、链接资源变量、资源过滤器的信息。
  • .settings (folder):存储与默认 CCS 设置不同的工程特定设置。
    • 例如:工作区偏好设置
  • makefile.defs (SYS/BIOS):为 SYS/BIOS 工程生成的工程 makefile 所包含的其他 make 规则。

.ccsproject 文件包含工程创建时所做选择的快照,此后很少更改。因此,如果更改器件变体或编译器工具版本等属性,则更改不会存储在 .ccsproject 文件中,而是存储在 .cproject 文件中。

.ccsproject 文件主要是一些设置存储在工程级别(而不是编译配置级别)时的历史遗留内容。但该文件目前仍用于:

  • 使用户能够将某些设置回复到其原始值。
  • 存储一些工程范围的设置,例如用于调试的连接(以及将来可能的其他设置)。

尽管该文件似乎存储了一些不必要的信息,但在尝试调试问题时可能会有所帮助。

.ccsproject、.cproject、.project 文件是 XML 文件。通常不建议手动编辑这些文件,除非在这方面很专业并且对正在修改的内容非常了解。

6.2.1.2.编译/重新编译工程

在首次编译或重建 CCS 工程时,会执行以下步骤:

  1. 自动生成 makefile 文件
    在活动工程配置文件夹(例如 Debug 文件夹,默认情况下)中生成主 makefile 文件和几个 *.mk 头文件。
    • makefile:包含生成的 *.mk 文件的主 makefile 文件
    • 参与编译的所有源都在以下 *.mk 文件中定义
      • objects.mk
      • subdir.mk
      • subdir_vars.mk
  2. (可选)使用“gmake”清理(选择 Rebuild ProjectClean Project 时)。
    删除活动配置文件夹(例如 Debug 文件夹,默认情况下)中的 .obj、.pp 和 .out 文件。不会删除 makefile 和 .map 文件。
  3. 使用“gmake”编译主 makefile 文件
    主 make 编译依次调用预编译(如有)、主编译和编译后处理(如有)步骤。下面将进一步详细介绍这些步骤。

典型的工程编译如下所示:

image36

6.2.1.2.1.makefile

CCS 自动生成的 makefile 文件包括一些其他文件,即 makefile.init、makefile.defs 和 makefile.targets。

makefile.defs 用于为 SYS/BIOS 工程定义其他 make 规则。
TI 编译环境不使用 makefile.init 和 makefile.targets。它们由 Eclipse 组件 (CDT) 之一插入到 makefile 文件中,并可用于扩展行为。例如,可以在工程的顶层文件夹中创建这些可选的 makefile 文件:

  • makefile.init – 早期包含在编译中
  • makefile.targets – 用于为其他 make 目标添加规则

每个文件(如果存在)都包含在编译过程中的特定点处。可以通过查看活动工程配置文件夹中的 makefile 文件来了解它们包含在何处。

使用 makefile.targets 的示例:

如果用户想添加一些其他清理命令(即在默认清理之外执行一些清理操作),可以执行以下操作:

1.创建一个包含其他 make 目标规则的 makefile.targets 并将文件放在工程的顶层文件夹中。例如,一个 makefile.targets 文件执行其他清理命令(在这种情况下,删除 main.asm 文件)可能如下所示:

myclean: -$(RM) "main.asm" -@echo 'Finished my custom clean'

2.修改 CCS 中的 Build → Builder 选项卡并在默认清理之外添加“myclean”。

image37

现在,选择 Clean Project 后,将执行默认清理以及自定义的 myclean 规则,如下面的输出所示。

**** Clean-only build of configuration Debug for project test_f28377D **** "C:\\CCStudio_v6.1.1.00022\\ccsv6\\utils\\bin\\gmake" -k clean myclean DEL /F "test_f28377D.out" "test_f28377D.hex" DEL /F "main.pp" DEL /F "main.obj" 'Finished clean' ' ' DEL /F "main.asm" 'Finished my custom clean'


使用 makefile.init 的示例:

此示例说明如何挂钩已生成的 makefile 文件以编写自定义预编译步骤的脚本。这在命令不能作为 CCS 中的预编译步骤运行的情况下会很有用(例如,在预编译失败时希望主编译失败的情况下)。

  1. 创建一个包含自定义命令的 makefile.init 文件,并将该文件放在工程的顶层文件夹中。例如,makefile.init 文件可能如下所示:

    all: custom-step custom-step: @echo Custom pre-build step @mkdir a**b
  2. 转至 Project Properties → Build → Builder 选项卡,启用 Stop on first build error,并确保未启用 Enable parallel build

现在,在编译工程时,在自定义步骤中执行“@mkdir a**b”命令失败后,编译将立即停止。如果将命令更改为“@mkdir ab”,则自定义步骤将成功,编译的其余部分将继续进行。

这只是一个简单的示例,展示了如何挂钩已生成的 makefile 文件以编写自定义预编译和编译后处理步骤的脚本。与此类似,可以为单个源文件编写钩子函数脚本。

若要完全自定义 makefile 文件,可以转至 Project Properties → Build → Builder 选项卡,然后取消选中“Generate Makefiles automatically”。工程编译完成后,可以编辑(或完全重写)生成的 makefile 文件。

作为额外参考,这些外部网络文章涉及这些 makefile 文件的主题:
Eclipse 社区论坛主题
https://stackoverflow.com/questions/25575244/eclipse-cdt-generate-makefile-with-makefile-init-makefile-defs-makefile-target

6.2.1.2.2.预编译

预编译步骤是在进行主工程编译之前执行的步骤。

有关在 CCS 中设置和使用预编译步骤的详细信息,请参阅预编译和编译后处理步骤

6.2.1.2.3.主编译

在 CCS 中编译工程时,主编译是将编译命令和输入文件传递给编译器工具以及 RTSC 工具(可选)的步骤。RTSC 工具仅针对涉及 RTSC 组件(IPC、SYS/BIOS 等)的工程调用,并且在编译器工具之前调用。从 CCS 8.2 开始,还支持 SysConfig 工具,该工具可用于在 SimpleLink 器件上配置 TI 驱动程序等组件和特定于器件的组件(例如网络栈、EasyLink 和 Wi-Fi)。每个编译工具接受一组输入文件并生成一组输出文件。

下图显示了一个典型的软件开发流程,并给出了在 CCS 中编译工程时所涉及的编译工具和文件的概念。所有这些都由 makefile 文件在后台处理,但是了解编译流程有助于更好地理解出现在 CCS 编译控制台中的编译输出。

编译工具组件:蓝色突出显示,输入/输出文件:白色突出显示。RTSC 工具和 SysConfig 工具带有虚线,表明它们仅在使用 RTSC 和/或 SysConfig 时才起作用。

_images/main_build_flow_syscfg_1.png

在没有 RTSC 或 SysConfig 的情况下,较常见的软件开发流程路径是从 C/C++ 源文件通过编译器、汇编器和链接器到可执行文件的直接路径。汇编器步骤通常在后台运行并且对用户隐藏。存档器和库编译实用程序是改善过程的外围功能,根据需求运行。

如果工程是 RTSC 工程,则首先运行 XDCtools 并生成输出文件,然后将这些文件传递给编译器和链接器。

如果使用 SysConfig 工具配置组件,则 SysConfig 命令在编译器之前运行并生成输出文件(.c、.h),然后将其传递给编译器。集成到应用中的 SDK 组件决定了 SysConfig 生成的文件。随着越来越多的 SDK 组件开始与 SysConfig 集成,将会生成更多的文件。

有关图中所示每个工具的更多信息,请参阅以下参考文献:

  • 编译器:接受 C/C++ 源文件并生成汇编语言源代码。
    请参阅适用于您的特定处理器系列的编译器用户指南
  • 汇编器:将汇编语言源文件翻译成机器语言可重定位目标文件。
    请参阅适用于您的特定处理器系列的汇编语言工具用户指南
  • 链接器:将可重定位的目标文件组合成单个绝对可执行目标文件。其接受可重定位的目标文件和对象库作为输入。
    请参阅适用于您的特定处理器系列的汇编语言工具用户指南中的“链接器说明”一章。
  • 归档器:将一组文件收集到一个单独的归档文件中,该文件称为库。还可通过删除、替换、提取或添加成员来修改库。
    请参阅适用于您的特定处理器系列的汇编语言工具用户指南中的“归档器说明”一章。
  • 库编译实用程序:编译自定义运行时间支持库。
    请参阅适用于您的特定处理器系列的汇编语言工具用户指南
  • XDCtools:提供用于创建和编译作为应用一部分的静态配置的配置工具。
  • SysConfig 工具:用于创建和编译作为应用一部分的系统配置的工具。
    有关更多详细信息,请参阅 SimpleLink MCU SDK 用户指南此文章

有关典型 CCS 工程编译流程中的一些输入和输出文件的更多信息,请参阅 CCS 工程中的文件

6.2.1.2.4.编译后处理

上面讨论的主编译步骤会生成一个可执行文件 (.out)。可以使用 Code Composer Studio 直接加载该文件到目标器件和调试该文件,也可以将该文件转换为十六进制格式,并使用十六进制编程器将该文件编程到目标器件。也可以使用编译器工具附带的实用程序对 .out 文件执行其他类型的后处理。

下图显示了一些典型的编译后处理操作。

_images/post_build.png

有关图中所示每个工具的更多信息,请参阅以下参考文献:

  • 十六进制转换实用程序:将目标文件转换为其他十六进制格式。
  • 绝对列表生成器:接受链接的目标文件作为输入并创建 .abs 文件作为输出。可以对 .abs 文件进行汇编,生成包含绝对地址而不是相对地址的列表。
  • 交叉参考列表器:使用目标文件生成交叉参考列表,展示符号、其定义以及其在链接源文件中的引用。
  • 目标文件实用程序:包括目标文件显示实用程序、反汇编器、名称实用程序和符号去除实用程序等实用程序。

有关上述所有工具的详细信息,请参阅汇编语言工具用户指南

有关在 CCS 中设置和使用编译后处理步骤的详细信息,请参阅预编译和编译后处理步骤一节。

6.2.1.3.“Console”视图

在编译时,“Console”视图显示了编译工具的标准和错误输出。编译多个工程时,“Console”视图将展示在 Project Explorer 视图中所选的活动工程的输出。

该视图显示传递给各种编译工具的选项以及编译工具报告的所有诊断消息。与在“Problems”视图中报告的摘要相比,此视图中报告的信息通常更为详细,也更为有用。

_images/console_view_build.png

6.2.1.4.“Problems”视图

“Problems”视图提供了在工程编译期间遇到的错误和警告的摘要。

一些消息将有一个可点击的链接,提供有关诊断的更多详细信息。

该视图具有如下列,包含的信息如下:

  • 说明:错误说明。
  • 资源:发生错误的资源/文件。
  • Path:生成错误的资源的路径。
  • 地点: 产生错误的资源中的位置/行。
  • 类型: 错误类型。

如果 Type 列显示为 C/C++ Problem,则表明错误来自 TI 编译工具。如果显示为 Semantic ErrorSyntax Error,则错误可能来自 Eclipse Code Analysis 工具。

有关 Code Analysis 错误的更多信息,请参阅代码分析一节。

_images/problems_view_build.png

6.3.从命令行创建和编译工程

CCS 具有用于创建、编译和导入工程的终端命令。这对于夜间自动编译非常方便,或者只是在不打开 GUI 界面的情况下执行这些操作。

有关所有受支持的命令及其用法的详细信息,请参阅以下文章。

使用命令行创建和编译工程

6.4.系统工程

从 CCS 9.x 开始引入了系统工程。系统工程是一种特殊类型的工程,旨在简化对与多核器件的不同独立内核相关联的多个工程的管理。在系统工程中,在器件上的内核和工作区中的工程之间建立关联。编译系统工程将编译所有关联的工程,调试系统工程将启动器件的调试会话并从与每个内核关联的工程加载程序编译。

有关如何使用系统工程的更多详细信息,请参阅此文章

6.5.使用源代码控制

请参考以下文章,了解有关在 CCS 中使用源代码控制的信息。

使用 CCS 进行源代码控制

6.6.了解工具版本控制

Code Composer Studio 工具集由不同的组件组成,例如编译器工具和 XDCtools。了解如下内容很重要:每个组件都有自己的版本号,并且每个组件的更新可能独立于 CCS 版本的发布。

例如,CCS 10.0 包括以下内容:

  • ARM TI 编译器工具版本 20.2.0.LTS
  • XDCtools 版本 3.60.02.34

每个组件的更新都可以单独安装,同时仍然可以使用 CCS 10.0。

若要安装编译器更新,请参阅编译器的安装和选择一文。
若要具体了解编译器工具的版本控制和发布方式,请参阅此文章

若要安装 XDCtools 和其他目标内容更新,请参阅文章产品的安装和选择

可以修改 CCS 工程以使用任何可用版本的编译器工具RTSC 产品进行编译。同样可以使用不同版本的 SDK 来完成。

向 TI 报告问题时,重要的是不仅要提及 CCS 的版本,还要告知编译器工具、SYS/BIOS、XDCtools、SDK 或任何其他相关组件和软件的版本,具体视出现的问题而定。

  • 编译器版本会在 Project → Properties → General → Project (or Main) 选项卡下列出。
  • 如果是 RTSC 工程,则目标内容组件的版本将在 Project → Properties → General → Product (or RTSC) 选项卡下列出。
  • 其他相关组件(例如仿真)的版本可以在 Help → About Code Composer Studio → Installation Details 菜单下找到。

6.7.疑难解答

如果在工程导入或编译过程中遇到错误,请参阅该疑难解答页面:CCS 中的工程导入和编译错误