[参考译文] CCS/PROCESSOR-SDK-AM335X：仍然... SYS_BIOS_path 或 BIOS_CG_ROOT 集在哪里？

嗯、__TMS470__(无论它是什么)显示为正在定义(它不是灰色的)。 但是、在任何文件中的任何搜索都不能指示它是如何定义的。

它与 TI ARM 编译器一起包含  __TMS470__的定义：

其中 TMS470是 TI 用于 ARM 系列器件的历史名称。

CCS IDE 提取预定义的编译器宏、以用于突出显示条件编译块的语法。

[引用用户="Christopher Weber"]

失败的是什么？  嗯、我得到了以下结果：

该错误显示使用 的是 TI 编译器的 ti/targets/std.h。 对于 GNU 编译器、应为 GNU/targets/std.h

在 CCS 工程属性中的"CCS General -> Products -> XDCtools Settings"下、"Target："设置为什么？

对于与 GNU 编译器一起使用的 XDCtools、Target：应该以 GNU.targets 开头

根据 XDCtools 的错误、假设您的 Target：仍然是 ti.targets 设置、该设置适用于 TI 编译器。

切斯特、

感谢您的快速回复。

任何地方都没有__TMS470__设置。  以下是适用于 TI 编译器的"调试"：

没有_TMS470__

它确实命名了那些来自-define 的其他目标

但是...  没有任何内容定义_TMS470__

所以，我又回到了“方形一个”，在这个“黑盒”中，我不知道它来自哪里。

接下来、对于"目标"、 没有一个。  它是一个静态库、不会为我提供任何选项。

但是、正如您看到的、有-defines、我找不到它的相关文档。

我更改了它们、将"ti"替换为"GNU"、现在它已编译。

AM335x
XDC_TARGET_Types__=GNU/Targets/std.h
XDC_TARGET_NAME___=GNU/Targets/ARM/A8F 

我不知道这背后的架构是什么、所以下次它不能正常工作时、我也会同样感到沮丧。

(std.h 的 GNU 风格没有这些#ifdefs...  因此、我想这仅适用于 TI 版本。。。)

但它仍在使用 BIOS 6_46进行编译...   它来自哪里？  我想将其更改为 BIOS_6_76...

切斯特、

哦，看！！   突然、在调试中定义了大量内容。  以前没有。

(请注意、滚动条现在指示数十个或更多以前没有的内容。)

我真的很不知道在这个环境中、如何在盖子下进行神奇的操作、现在甚至没有物体、突然...  

Scott、

我可以帮助回答动态变量问题。  动态变量由 CCS 根据您在项目中选择使用的"产品"以及它们在 PC 上的位置进行填充。

该项目将使用产品 X 版本 Y。 然后、CCS 会提供其在您的计算机上了解的产品和版本列表。  然后、它将使用适当的路径填充该变量。  这样做是为了避免项目中存在可能因用户而异的绝对路径。  团队成员 A 的安装位置可能不同于团队成员 B

在此项目设置为使用4.30版本的 cc13x2 SDK。

CCS 知道我安装的 SDK 的不同版本、并将使用4.30版本的路径。

编译器的变量的工作方式与工程将存储要使用的编译器和版本的方式相同。

遗憾的是、AM335x 的 SDK 非常复杂、因为 SDK 本身不是作为产品封装的、而是作为产品集合的：EDMA 驱动程序、SYS/BIOS、NDK、PDK。

如果您想更改项目所使用的 BIOS 版本、请不要更改这些变量。  而是在项目选项中更改产品选择。  这是我和您的第一次屏幕截图。  您可能希望选择 Debug 作为编译配置。  之后、您应该能够  

您可以在此处展开 SYS/BIOS 并选择要使用的版本。  如果未列出您要使用的版本、则 CCS 不知道它的位置。  可以通过转至 CCS 中的 Preferences 对话框(上面我的第二个屏幕截图)并在对话框顶部指定其安装路径、然后单击 Refresh 来解决该问题。   

此致、

John

John、

(我正在使用大字体、因此图像之间的文本会引起您的注意...  不要“大喊大叫 ”，有些内部值变得模糊了...)

感谢您的回复。

但是...  我知道所有这些。  这里是我不理解的。  (当你看到这种情况时、你就会知道我对这种情况有何仇恨...)

是... 我有这些产品 、可以查看它们的安装位置。

这是一个静态库、在项目设置中未启用它们。

但它包括$｛BIOS_CG_ROOT｝、它在我可以找到的任何位置都没有定义、您可以看到上下文气泡中是一个"动态变量"且为空。

G

然而...  进行编译时、它会以磁力的方式插入搜索路径。

所以...  当我被问及"更新到新 SYSBIOS 的工作量是多少？"时、 在这个静态库中.... 到目前为止，我的答案是“我不知道！！  我不知道旧款是如何被包括在内的！！"

如果我看不出旧的那个是如何被包括的，我应该把它更改为新的那个？？？？

好的、有几个问题

1) 1)正在填充的变量的值。

2) 2)搜索路径中存在的变量

1是奇数。  我不希望该变量具有值。 项目选项对话框不认为它有值、但它确实看起来像是在构建时填充的。  有几个想法。  是否为此项目选择了另一个 BIOS 版本？  它可能会从另一个配置中获取值。  我无法在较新的 CCS 版本中重现该行为。  当我尝试时、我收到一条警告、指出"build-variable 'XXXXX' cannot be resolved"。  这可能是使用的 CCS 版本中的一个错误。

#2变量已添加到 include 搜索路径中。  如果此构建配置是基于另一个构建配置创建的、则会复制包含路径。  如果您不想在此处删除它、只需将其删除即可。  变量的值由 CCS 控制、但包含路径列表由您控制。

如果您在产品选择中选择 BIOS 6.76、它是否会将变量的值更改为6.76路径？

此致、

John

John、

BIOS 6_76不适用于 Sitara 中的 TI 编译器。  他们说他们不会支持它。  这是一个迁移到更新软件包、不同编译器等的项目...

在我继续挖掘时、Frank Livingston 告诉我检查 Window | Preferences | Code Composer Studio | Build | Variables 并选中"show system variables"。  嗯、就在这里。

现在、转到 BIOS 6_76、并尝试迁移到 GNU 编译器。

TI 已经放弃了这个东西中的"SYS_BIOS_path"、现在有一个$｛COM_TI_BIOS_include_path｝。

猜猜猜会怎么样...？  它是空的。  不仅仅是"尚未填充" 、它实际上是空的。  而不是在我上面描述的首选项中的任何位置定义。

给定以下一组内容：

$｛COM_TI_BIOS_include_path｝
$｛PROJECT_ROOT｝
$｛CG_TOOL_INCLUDE_PATH｝
$｛PROJECT_ROOT｝/ti

(是的、项目中有一个"TI"文件夹) 我的构建命令如下：

C：/ti/gcc-arm-none-eabi-7-2018-q2-update/bin/arm-none-eabi-gcc-7.3.1.exe
-c
-mcpu=cortex-A8
-March =armv7-a
-mtun=cortex-A8
-marm
-mfloat-abi=hard
-i"C：/Source/projects/DnsTest
-i"C：/ti/gcc-arm-none-eabi-7-2018-q2-update/arm-none-eabi/include
-i"C：/Source/projects/DnsTest/ti

这会被截断、但请注意项目中有4个目录、但命令行有3个目录。  第一个问题：$｛COM_TI_BIOS_include_path｝ 甚至未列出！！

接下来、我创建了一个快速测试项目、其中包括：

$｛COM_TI_BIOS_include_path｝
$｛PROJECT_ROOT｝
$｛XDC_FIND：GNU/目标/ARM/libs/install-native/arm-no-eabi/include/newlib-nano：$｛ProjName｝｝
$｛XDC_find：ti/posix/gcc：$｛ProjName｝｝$
｛Proj_path｝工具

真不知道｛XDC_FIND…… ？？   

显然、调用的是某种搜索、但会发生什么情况？  是否在某处记录？  以及为什么在其后面附加项目名称？

有什么想法吗？

$｛COM_TI_｝的情况并不少见 _include_path｝为空。  这是一种功能、产品可以提供构建路径、但在许多情况下不提供。   

我看到的 SimpleLink 项目也是如此。  如果我单击[...] 项目选项中的框、它向我显示路径将解析的内容、在本例中、它是空白的。

查看实际传递给编译器的包含路径。  您可以看到、$｛COM_TI_SIMPLELINK_CC13X2_26X2_SDK_include_path｝和$｛SYSCONFIG 工具_include_path｝均未传递、因为产品实际上不为它们提供任何内容。  传递的第一条路径是$｛PROJECT_ROOT｝生成的路径

-i"/Users/a0792138/workspace_v10112/clock_CC26X2R1_LAUNCHXL_tirtos_gcc -i"/Users/a0792138/workspace_v10112/clock_CC26X2R1_LAUNCHXL_tirtos_gcc/Debug -i"/Users/a0792138/ti/simplelink_cc13x2_26x2_sdk_4_30_00_54/source -i"/Users/a0792138/ti/simplelink_cc13x2_26x2_sdk_4_30_00_54/source/ti/posix/gcc -i"/Users/a0792138/ti/simplelink_cc13x2_26x2_sdk_4_30_00_54/kernel/tirtos/packages/gnu/targets/arm/libs/install-native/arm-none-eabi/include/newlib-nano -i"/Users/a0792138/ti/simplelink_cc13x2_26x2_sdk_4_30_00_54/kernel/tirtos/packages/gnu/targets/arm/libs/install-native/arm-none-eabi/include -i"/Applications/ti/ccs1011/ccs/tools/compiler/gcc-arm-none-eabi-7-2017-q4-major/arm-none-eabi

因此、您在$｛COM_TI_BIOS_include_path｝为空时看到的结果是可以的。

$｛XDC_FIND｝是我的新产品。

我向我的项目添加了相同的路径、以查看它的功能。

即、我添加了以下内容：

$｛XDC_FIND：GNU/Targets/ARM/libs/install-native/ARM-none-eabi/include/newlib-nano：$｛ProjName｝｝

当我构建时、我看到它解决了以下问题：

-i"/Users/a0792138/ti/simplelink_cc13x2_26x2_sdk_4_30_00_54/kernel/tirtos/packages/gnu/targets/arm/libs/install-native/arm-none-eabi/include/newlib-nano

基本上、它看起来像是在使用 XDC 工具来定位子路径"GNU/Targets/ARM/libs/install-native/arm-no-eabi/include/newlib-nano "。  在本例中、它会在我的 SDK 安装文件夹中找到它。  然后、它会将该路径的完整路径添加到 include 路径。

至于项目名称变量在最后使用的原因、我想它用于定义搜索范围。  在本例中、使用该项目的 XDC 封装路径。

我将要求我们的一位构建人员确认。

此致、

John

好的。  我与构建专家一起检查了 XDC_FIND 宏的工作方式、就像我描述的那样。

如果在末尾未指定 ProjectName、则会使用 Preferences -> Code Composer Studio -> Products -> RTSC 中的全局产品列表。  通过指定工程、它使用为工程定义的包路径。

还有一个 CCS_find_file 宏以相同的方式工作、但也适用于 XDC 以外的软件产品。

这对我来说都是新的。

此致、

John