[参考译文] 针对 C7x 器件的 CCS 12.5问题和编译 C7x SYS-BIOS 工程失败

您好、George、

您希望将此 SDK 用于什么用途、或者持续的动机是什么？

  自8.0 SDK 起、无论处理器目标如何、TI SDK 均不再支持 SYS/BIOS。  

此致

苏曼

Suman、

要移植到 C7x 的现有 C6x 工程使用 SYS/BIOS、我认为该工程与 TI-RTOS 相同。

我希望从 SYS/BIOS 到 SDK TI-RTOS 的过渡将非常 简单。

无论如何、对于 C7x、我需要正式迁移至使用 SDK 中包含的 TI-RTOS？

您能否向我介绍从 SYS/BIOS 转换为基于 SDK 的 TI-RTOS 的文档？

我看到可下载"ti-processor-sdk-rtos-j721e-evm-09_01_00_06"。

我下载了此 SDK、并将其解压到目录 C：\TI

我已将路径 C：\TI 添加到 CCS\Window\Preferences\Code Composer Studio\Products "Product discover path"

已选择" Code Composer Studio 每次启动时搜索产品..."

已重新启动 CCS、并且在下载内容内找到这些附加产品。。

DSPLIB C66x

MATHLIB C66x

它未找到"pdk_jacinto_09_01_00_22"、也未找到下载文件夹中包含的任何其他产品。

对于针对 C7x 的 SDK 和 TI-RTOS 支持、下载"ti-processor-sdk-rtos-j721e-evm-09_01_00_06.tar.gz"是否正确？

如果没有、我需要什么下载？

对于 CCS 安装、我应该将下载解压到哪个路径？

我还尝试通过 CCS\Help\Install New Software... 但我在该更新机制方面尚未取得任何成功。

 非常感谢在 J721EXSOMG01EVM 上使用 DRA829为 C7x 项目提供 SDK/TI-RTOS 的任何方向。

谢谢。

-乔治

您好、George、

guiquan wu 说：

我移植到 C7x 的现有 C6x 项目使用 SYS/BIOS，我认为这与 TI-RTOS 相同。

是的、SYS/BIOS 和 TI-RTOS 是相关的、后者是一个更广义的术语、包括一些 BSP 驱动程序、但底层 RTOS 是相同的。 这些术语有点同义词。

guiquan wu 说：

无关，对于 C7x，我需要正式改用 SDK 中包含的 TI-RTOS？

最后一个支持 TI-RTOS (或 SYS/BIOS)的 SDK 为7.3 SDK。 从 SDK 8.0开始、FreeRTOS 是受支持的默认 RTOS。

您不能将最新的 CCS 与旧版 SYS/BIOS、XDC 等配合使用。 如果您想继续使用 SYS/BIOS 或 TI-RTOS 作为操作系统、最好坚持使用该 SDK 支持的最后一个 SDK 和/或 CCS 版本。 不过、对此的支持非常有限。

guiquan wu 说：

下载"ti-processor-sdk-rtos-j721e-evm-09_01_00_06.tar.gz"是否正确针对 C7x 的 SDK 和 TI-RTOS 支持？

此 SDK 仅支持 FreeRTOS (或 SafeRTOS)。

此致

苏曼

Suman、

哪些最新的 CCS 支持 SDK 7.3？

J721EXSOMG01EVM 上的 DRA829中是否存在针对 C71x 的 SDK 7.3支持？

是否有将项目代码从 SYS/BIOS 迁移到 FreeRTOS 的相关文档？

RTSC 对 C7x 器件和最新 CCS 的支持是否可行？

如果 C7x 器件 SDK 不再支持 XDCtools、未来将如何替代 XDCtools？

您好、George、

guiquan wu 说：

最新的 CCS 支持 SDK 7.3是什么？

SDK 7.3在CCS 版本 9.3上正式受支持、但是 SDK 7.3仍应在更高版本的 CCS 上运行。

guiquan wu 说：

J721EXSOMG01EVM 上的 DRA829中是否存在针对 C71x 的 SDK 7.3支持？

是的、C71x 支持 SDK 7.3。

guiquan wu 说：

是否有将项目代码从 SYS/BIOS 迁移到 FreeRTOS 的文档？

如果您有任何后续问题、请参阅此文档并随时与我们联系。

guiquan wu 说：

RTSC 支持对于 C7x 器件和最新 CCS 是否可行？

我将与团队沟通、并就此问题与您联系。

此致、

内哈尔

Neehar,

我希望您进一步了解 RTSC 对 C7x 的支持会包括对 C7x 器件 SDK 的相关 XDCtools 支持？

如前所述、我的目标是将现有的 C6x SYS/BIOS 工程及其工具生态系统按如下方式迁移到最新 CCS 上的 C71x SYS/BIOS 工程。

我现有的 C6x SYS/BIOS 项目环境和工具生态系统...

CCS 6.1.3

器件系列：C6000、型号：AM5726

编译器版本：TI v8.2.0

输出类型/格式：RTSC 应用程序(可执行文件)、eabi (ELF)

器件字节序：小端

RTSC……

XDCtools 版本3.31.43_CORE

SYS/BIOS 版本6.45.1.29

am57xx PDK 版本1.0.3

RTSC 平台软件包- DRA7XX/C6000、定义了共享资源内存映射、1个用于单核、2个用于双核配置/构建。

RTSC 平台配置-唯一的 config/build .cfg 文件-可参考相关 RTSC 平台包的单核/双核构建配置

向前利用 SYS/BIOS (TI-RTOS)和 RTSC 生态系统以便在新的 C7x 项目中使用将会有很大帮助。

现在您已经确认针对 C71x 器件提供了 SDK 7.3支持、并且更新的 CCS 版本*应该支持该支持...

我的期望是、该 SDK 7.3对 C71x 器件 的支持意味着、 J721EXSOMG01EVM 上的 DRA829中存在类似的 C71x 器件 SYS/BIOS 支持、这也是我先前问题的一部分。

我的预期是、用于 C71x 器件的此 SDK 7.3支持应在未来的最新 CCS 12.5、12.6等协议中可行。

CCS 12.5帮助/检查更新显示未找到更新。

CCS 12.5帮助/安装器件支持... 由于 Windows 7上的 CCS 错误而无法工作(请参阅我的最新主题、CCS 12.5 "安装器件支持"失败)

CCS 12.5帮助/安装新软件... 似乎未提供 C7000站点以供参考进行更新。

如何将此 SDK 7.3下载到 CCS 12.5上？

我将继续手动将 SDK 7.3下载到 CCS 12.5。

这个下载在 Windows 上的什么位置(什么路径)应该被放置在 CCS 12.5中才能识别它？

谢谢。

-乔治

Neehar,

我希望您进一步了解 RTSC 对 C7x 的支持会包括对 C7x 器件 SDK 的相关 XDCtools 支持？

如前所述、我的目标是将现有的 C6x SYS/BIOS 工程及其工具生态系统按如下方式迁移到最新 CCS 上的 C71x SYS/BIOS 工程。

我现有的 C6x SYS/BIOS 项目环境和工具生态系统...

CCS 6.1.3

器件系列：C6000、型号：AM5726

编译器版本：TI v8.2.0

输出类型/格式：RTSC 应用程序(可执行文件)、eabi (ELF)

器件字节序：小端

RTSC……

XDCtools 版本3.31.43_CORE

SYS/BIOS 版本6.45.1.29

am57xx PDK 版本1.0.3

RTSC 平台软件包- DRA7XX/C6000、定义了共享资源内存映射、1个用于单核、2个用于双核配置/构建。

RTSC 平台配置-唯一的 config/build .cfg 文件-可参考相关 RTSC 平台包的单核/双核构建配置

向前利用 SYS/BIOS (TI-RTOS)和 RTSC 生态系统以便在新的 C7x 项目中使用将会有很大帮助。

现在您已经确认针对 C71x 器件提供了 SDK 7.3支持、并且更新的 CCS 版本*应该支持该支持...

我的期望是、该 SDK 7.3对 C71x 器件 的支持意味着、 J721EXSOMG01EVM 上的 DRA829中存在类似的 C71x 器件 SYS/BIOS 支持、这也是我先前问题的一部分。

我的预期是、用于 C71x 器件的此 SDK 7.3支持应在未来的最新 CCS 12.5、12.6等协议中可行。

CCS 12.5帮助/检查更新显示未找到更新。

CCS 12.5帮助/安装器件支持... 由于 Windows 7上的 CCS 错误而无法工作(请参阅我的最新主题、CCS 12.5 "安装器件支持"失败)

CCS 12.5帮助/安装新软件... 似乎未提供 C7000站点以供参考进行更新。

如何将此 SDK 7.3下载到 CCS 12.5上？

我将继续手动将 SDK 7.3下载到 CCS 12.5。

这个下载在 Windows 上的什么位置(什么路径)应该被放置在 CCS 12.5中才能识别它？

谢谢。

-乔治

Neehar,

很抱歉我的上一篇文章重新发布。

我不知道这是怎么发生的,除了我回复了额外的信息,当我选择"回复" E2E 说有一个问题,我没有登录,并蒸发了我的详细更新,这花了一个小时制作.  我现在学到的教训是在按"回复"之前复制回复的内容。

这里是一个简短的总结丢失的回复没有分享的多个组合故障的具体细节尝试使其工作...

我手动下载并安装 SDK 7.3。

将 BIOS_6_83_02_07、 PDK_Jacinto_07_03_00_29、 xdctools_3_61_04_40_CORE 安装到 C：\TI\ccs1250中。

路径 C：\TI\ccs1250是安装产品以替代更新版本的 CCS 12.6 (2024年1月12日发布)的最佳位置、是否会迁移到 C：\TI\ccs1260中、这意味着要使用 CCS 12.6、必须复制或将这些安装的产品移至新路径？

更新了 Project_C7x 以使用这些新产品(请参阅原始帖子)。

在我的原始帖子中、Project_C7x 仍失败。

使用 xdctools_3_61_04_40_core 只是简单地说"失败"、而没有详细输出。

我将 Project_C7x 恢复为使用 xdctools_3_62_01_16_core (CCS 12.5的已安装产品)、可提供更详细的故障信息(请参阅原始发布)。

TMS320C7100器件当前不受支持。
C71目标支持以下器件：
C71
J7ES
J721E

很明显、此错误是由 Project_C7x 包含我的定制 RTSC 平台包文件"myC7x"引起的(请参阅原始帖子详情)

在创建 RTSC 平台包文件"myC7x"期间、 "器件名称"的*仅* c7000系列选项为 TMS320C7100。

xdctools 显然不支持 TMS320C7100器件。

如何更新或以其他方式获取 RTSC 平台包文件向导/创建器以允许 C7000器件以 TMS320C7100以外的其他目标、例如 C71、J7ES、J721E、 等等？

非常感谢为解决该 RTSC 平台封装问题提供帮助。

谢谢。

-乔治

Neehar,

为了查看安装了新版本 CCS 12.5的 xdctools_3_62_01_16_core 后抛出的错误、我找到了检测到错误的构建支持文件、即 TMS320C7100不受支持。

该文件为 C：\TI\ti-processor-sdk-rtos-j721e-evm-07_03_00_07\BIOS_6_83_02_07\packages\ti\sysbios\family\c7x\Settings.xs

作为一种权变措施黑客...

我按如下方式修改了设置表、以包括从 C71复制的 TMS320C7100 -注意 C71、J7ES、J721E 都等效...

这是修改后的表的一个片段、显示了添加的 TMS320C7100...

VAR 设置=｛
设备：｛
/*
* GEL：20240118 -已添加 TMS320C7100以解决构建问题
*/
"TMS320C7100"：｛
hwiDelegate："ti.sysbios.family.c7x.hwi"、
timerDelegate："ti.sysbios.timers.dmtimer.Timer"、
clockTimerDelegate："ti.sysbios.timers.dmtimer.Timer"、
timerSupportDelegate："ti.sysbios.family.c64p.tci6488.TimerSupport"、
timestampDelegate："ti.sysbios.family.c7x.TimestampProvider"、
taskSupportDelegate："ti.sysbios.family.c7x.taskSupport"、
intrinsicsSupportDelegate："ti.sysbios.family.c7x.IntrinsicsSupport"、
cacheDelegate："ti.sysbios.family.c7x.cache"、
clockTickPeriod : 1000,
目标：["ti.targets.elf.c71"]
｝、
"C71"：｛
hwiDelegate："ti.sysbios.family.c7x.hwi"、
timerDelegate："ti.sysbios.timers.dmtimer.Timer"、
clockTimerDelegate："ti.sysbios.timers.dmtimer.Timer"、
timerSupportDelegate："ti.sysbios.family.c64p.tci6488.TimerSupport"、
timestampDelegate："ti.sysbios.family.c7x.TimestampProvider"、
taskSupportDelegate："ti.sysbios.family.c7x.taskSupport"、
intrinsicsSupportDelegate："ti.sysbios.family.c7x.IntrinsicsSupport"、
cacheDelegate："ti.sysbios.family.c7x.cache"、
clockTickPeriod : 1000,
目标：["ti.targets.elf.c71"]
｝、

现在、当我使用较新的"CCS 12.5已安装" xdctools_3_62_01_16_core 在 Project_C7x 中运行 main.c 的编译时 、SDK 7.3的 BIOS_6_83_02_07会生成所有与自动生成的工程相关的文件、 成功 。

我知道这不是正确的前进路径、但我无法弄清楚如何获取 RTSC 平台包向导以允许我选择 TMS320C7100以外的 C7000器件。

我仍然想要一个更强大的 TI 推荐的 RTSC 平台软件包向导解决方案、该解决方案允许选择 SYS/BIOS 和 XDCtools 生态系统支持的 C7000器件。

至少与此同时、我可以继续研究我以"应用"为中心的构建错误。

我期待更正式的 TI 解决方案。

谢谢。

-乔治

您好、George、

guiquan wu 说：

RTSC 支持对于 C7x 器件和最新 CCS 是否可行？

最新的 CCS 12.5不再支持 RTSC 和 XDCtools。 它们应该仍能与 CCS 9.3上的 SDK 7.3搭配使用。

guiquan wu 说：

如何将此 SDK 7.3下载到 CCS 12.5？

我认为、如果您使用的是 SDK 7.3、最好的选择是继续使用 CCS 9.3、因为后者是经过测试和验证的 SDK 版本。 我们不再在最新版本的 CCS 上支持 SYS/BIOS、也不支持 XDCtools。  如果您在 CCS 9.3上看到相同的问题、请随时提出任何问题

您可能希望确保当前的 C6x 项目能够首先在 CCS 9.3环境上编译、然后迁移到 C7x。

但是、如前所述、SYS/BIOS 支持有限 、因此您可能需要考虑 切换到 FreeRTOS。

此致、

内哈尔

Neehar,

我明白、但我上一篇文章清楚地显示了带有 SDK 7.3的 SYS/BIOS 6.83.02.07以及最新的"CCS 12.5"的 XDCtools 3.62.01.16通过"次要"黑客"解决 RTSC 平台包向导中的限制问题、可以成功生成自动生成的 Project_C7x 支持文件。

我想保留最新的 CCS 12.5、并在 SDK 7.3的 BIOS_6_83_02_07中使用最后一个 C7x SYS/BIOS、然后查看是否有 RTSC 平台包向导的可用解决方案。

我不理解您的意见...

最新的 CCS 12.5不再支持 RTSC 和 XDCtools。

我认为情况不完全是这样、因为 CCS 12.5明确允许创建自定义 RTSC 平台包文件(尽管 C7000器件受限)、而项目创建向导同样允许使用 XDCtools 支持 RTSC。

当  CCS 12.5上明确提供 RTSC 和 XDCtools 生态系统时、我需要了解您声明的正确性。

请详细说明您对 RTSC 和 XDCtools 的 CCS 12.5声明。

我认为此 RTSC 平台包向导 C7000器件限制将出现在 CCS 9.3上、但可能不存在。

我可以访问并安装 CCS 9.3、查看 RTSC 平台软件包向导是否允许以 TMS320C7100以外的 C7000器件为目标。

您是否知道 CCS 9.3的 RTSC 平台封装向导是否修复了我在 CCS 12.5上看到的 C7000器件限制？

至少在近期继续使用 SYS/BIOS、我可以专注于将 C6x 图像处理代码迁移到 C7x 并进行评估。

我们必须快速了解可以改进哪些性能、这一点至关重要。   我们需要确定 C7x 在替换多个 C6x 器件方面的效果。

从 SYS/BIOS (TI-RTOS)转向 FreeRTOS 并继续尝试 CCS 和替代工具生态系统评估需要付出很大的努力、从而推迟和分散人们对非常重要的 C7x 图像处理评估工作的注意力。

期待您的评论。

谢谢。

-乔治

您好、George、

我正在查看您的原始帖子、鉴于此处的信息以及您的团队与我们的电话、我对 C66迁移至 C7x 有一些问题。  

1) 1)您当前正在尝试迁移什么？ 最终、我知道将尝试迁移您的整个代码库、使其不再依赖于 C66、而是使用您现有的简单自定义函数或 C66函数库开始迁移？ 换句话说、它是您在 C66上运行且想要在 C7x 上运行的独立程序/函数吗？

2)如果上述问题的答案是肯定的,那么在裸机环境中开始迁移是否对您有效?

[quote userid="41338" url="~/support/tools/code-composer-studio-group/ccs/f/code-composer-studio-forum/1313234/ccs-12-5-issues-targeting-c7x-device-and-building-c7x-sys-bios-project-fails 当下、我的目标是通读 C6000到 C7000迁移用户指南(SPRUIG5e.pdf)、解决了在我们现有的 C6x 代码库、基础设施、数据类型、算法、内联函数中需要进行的大量更改 等[/报价]

如果这仍然是您的当前目标、那么如果您专注于将代码从 C66转换到在 C7x 上运行的矢量可编程版本、那么在裸机环境中工作的设置就会更少。 使用此方法、您将以"无启动"模式启动 EVM、并将 C7x 编译器生成的输出二进制文件加载到 C7x 内核上。 我们的开发团队目前在开发 DSPLIB 等库时使用这种方法。 如果您感兴趣、我可以提供相关设置说明。 但这意味着、就目前而言、您无需处理 SYSBIOS/TI-RTOS/FreeRTOS SDK 相关设置。  

此致！

阿莎

Asha：

很抱歉响应延迟。

我非常欢迎获取有关 TI 裸机设置环境/以"无引导模式"定位输出二进制文件/将其加载到 EVM 的指令的信息。  在对我们的各种功能进行有限/有针对性的"Blackbox"IP 测试时、这种方法非常有用。

请转发此裸机设置环境/说明、以"无引导模式"将输出二进制文件加载到 EVM 中。

在后台、我们现有的 Project_C6x 是一个应用、它利用大量图像链管理复杂的 IP 架构、即捕获、分析、渲染、 和"输出"。

我最初尽力从我们现有的 Project_C6x 中分割出 C6x 图像处理相关函数、并将它们放在 Project_C7x 中以执行 C7x 软件流水线周期时序分析、 但在这样做时发现、这只是为了比较 C6x 和 C7x 迁移的 IP 而进行的巨大努力、最终结果很难用于验证测试、最终无法用于产品中。

除了在产品内实时管理图像链外、我们现有的 Project_C6x 还具有相应的基础设施和功能、能够在仿真模式下播放具有相关控制/参数设置的数字图像激励、以评估请求/执行的 IP 的准确性和性能。  通过剥离这个基础设施功能、即通过 SYS/BIOS、乒乓数据移动到 L2-SRAM 等来移除所需的进程及其通信/控制。仅仅获取针对 C7x 进行编译的 C6x 代码最终将用处不大。

因此、我决定不采用该方法、而是积极迁移整个 Project_C6x 基础架构(通过 SYS/BIOS 进行的过程/通信、通过 UDMA 进行的 DataMover 等)、图像链和 IP、因为现在该方法存在、可以解决整个过程中的任何问题。

到目前为止、我已经 使用 SDK 7.3、RTSC 和 CCS 12.6上的 SYS/BIOS 成功地将整个旧工程_C6x 构建为新工程_C7x。

这一切都完成了相当小的改动和适应。

具有在 C7000编译器上编译的固有函数的 C6x C/C++ IP 代码、无需进行任何必要的返工。

阅读了《C6000到 C7000迁移用户指南》(SPRUIG5E.PDF)之后、我希望至少在编译之前对我们的代码进行一些更改、但我感到很惊喜、事实并非如此。  我基本上在全球范围内包括了 c7x.h 和 c6x_migration.h、而且在 C7000编译期间还包括了 Viola All。

在这条路上有一些障碍需要克服...

-RTSC 平台软件包向导不允许我选择受支持的 C71器件，而只允许选择 TMS320C7100 -请参阅先前的解决方法。

-缺乏对 TSC 64位自由运行计时器的 CSL 支持,即 CSL_tscEnable, CSL_tscRead 不在库 ti.csl.ae71中-变通办法是直接引用 C7x 计时器寄存器__tsc -这是在我们的映像链中的运行时用于捕获用于各种 IP 步骤的周期。

-在我们的图像链中替换当前不支持/缺失的 C7x IMGLIB 调用-等待 TI 正式交付所需的 C7x IMGLIB 调用。

-将 DataMover 从 C6x 上的 EDMA3修改为 C7x 上的 UDMA -正在进行中。

-将通信修改为其他 SOC CPU 的 A72等, DRA829上的设备-正在进行的工作-推迟到特定的 C7x 设备选择

因此、我们现在可以查看编译器.asm 输出以比较/对比软件流水线循环和 C6x 和 C7x 之间的预测周期。

将 Project_C7x 加载到 J721E_DRA829_TDA4VM 的 C71X_0上后、我们可以着手实际运行仿真、并获取每个软件流水线循环的实际 C7x 周期时间、以便与之前的 C66x DSP 上的相同周期进行比较。

目前、在使用"无引导模式"加载 EVM C71X_0时遇到问题。

我可以使用"SD Boot Mode"加载 EVM C71X_0、但使用板载 XDS110调试探针将我的 Project_C7x.out 加载到 EVM 上需要耗费许多小时。

有关这些详细信息、请参阅我最近的文章...  

J21EXSOMG01EVM：CCS 12.6 -通过 EVM 板载 XDS110调试探针使用无引导模式连接 SoC 内核时出现 JTAG 故障  

短期内不必决定是否继续使用 SYS/BIOS 而不是迁移到 FreeRTOS。  说实话、我并不是很有兴趣在没有显著优势或理由的情况下迁移到一个新的 RTOS。  我对 SYS/BIOS 很满意、因为它对我来说已经有很多年的良好使用了。  继续使用 SDK 7.3的 SYS/BIOS 产品可能是非常可行的选择。

需要快速做出的最重要决定是、只需编译具有和不具有内在函数的 C6x IP C/C++代码、C7x 器件是否能够符合预期以显著超越 C66x；最终是否可以替换大量 C66x DSP 而无需在针对 C7x 方面进行重大编码/专业化认证。

我希望这有助于理解我关于评估从 C6x 迁移到 C7x 的迁移工作量和可行性的思考过程。

谢谢。

-乔治

您好、George、

感谢您的详细回答！ 我在下面讲了几个要点：

guiquan wu 说：

请转发此裸机设置环境/说明以"无引导模式"将输出二进制文件加载到 EVM 中。

对于构建环境、除了使用 CCS 加载二进制文件之外、我们在很大程度上也独立于 CCS。 我们将使用 CMake 作为跨平台构建系统生成器。 对于 Ubuntu 平台、我们使用的是 GNU make + C7x 编译器(用于目标)或 GCC (用于主机仿真)。 对于 Windows、我们使用 Ninja + C7x 编译器(用于目标)和 Visual Studio + MS Visual Studio 代码工具(用于主机仿真)。 本质上、我们是从命令行进行编译、并为 C7x 编译器提供 C/C++文件和链接器文件(不设置数据移动等功能)。 然后、使用 EVM 在 No Boot Mode (无引导模式)通过 CCS 将输出二进制文件加载到特定的 C7x 内核(SDK 中的指令)。

guiquan wu 说：

迄今为止，我已成功 使用 SDK 7.3、RTSC 和 XDCtools 在 CCS 12.6上的 SYS/BIOS 将整个旧 Project_C6x 作为新的 Project_C7x 构建完整无损。

听起来不错！ 您在该主题中的初始问题是否得到了解决？ 我们将继续支持在您提到的线程中调试您最近的 CCS 问题。  

guiquan wu 说：

最需要快速确定的是 C7x 器件是否能够满足其计费需求以显著超越 C66x、这只需简单地编译带有/不带有内在函数的 C6x IP C/C++代码即可、最终是否可以替换大量 C66x DSP、无需在以 C7x 为目标时进行重要编码/专业化认证。

您能否解释一下您试图进行的 C66和 C7x 比较？ 是否要将 C66项目与使用现有 C66项目代码且包含 c7x.h 和 c6x_migration.h 头文件的 C7x 项目进行编译的项目进行比较？ 如果是、请注意、包含迁移头文件不会利用 C7x 的矢量处理功能、因此性能比 C66有一些重大改进。

此致！

阿莎

Asha：

感谢提供裸机设置环境和说明。

我将 C6x 工程迁移到在 C7x 上使用 SYS/BIOS、RTSC 和 XDCtools 的 Project_C7的原始问题已在以下注意事项中得到基本解决。

我已经能够使用以下方法针对 J721E 上的 C71X_0成功构建该 Project_C7x 等效项...

Windows 7 64位 SP1上的 CCS 12.5、12.6

XDCtools ... CCS 12.5已安装 xdctools_3_62_01_16_core

用于创建面向 C7000、TMS320C7100的"myC7x"平台软件包的 RTSC 平台软件包

需要对 C：\TI\ti-processor-sdk-rtos-j721e-evm-07_03_00_07\BIOS_6_83_02_07\packages/ti\sysbios\family\c7x\Settings.xs 进行变通办法修改

修改了设置表、增强了以包括从 C71复制的 TMS320C7100 -注意到 C71、J7ES、J721E 都等效...

SDK 7.3 ... BIOS_6_83_02_07、 PDK_Jacinto_07_03_00_29

有待解答的 TI 开放性问题...

1. Needar 声明..."最新的 CCS 12.5不再支持 RTSC 和 XDCtools。"

我认为情况不完全是这样、因为 CCS 12.5明确允许创建自定义 RTSC 平台包文件(尽管 C7000器件受限)、而项目创建向导同样允许使用 XDCtools 支持 RTSC。

我想了解为什么当  CCS 12.5/12.6上清楚提供 RTSC 和 XDCtools 生态系统时、此声明才是准确的。

请详细说明关于不支持 RTSC 和 XDCtools 的这个 CCS 12.5声明。

2.唯一用于 C7000的 RTSC 平台软件包目标是 TMS320C7100器件，所提供的 xdctools 显然不支持该器件。

我想删除我已经对 C：\TI\ti-processor-sdk-rtos-j721e-evm-07_03_00_07\BIOS_6_83_02_07\packages/ti\sysbios\family\c7x\Settings.xs 所做的"权变措施"

如何更新或以其他方式获取 CCS RTSC 平台包文件向导/创建器、以便允许以 TMS320C7100以外的其他 C7000器件寻址、例如 C71、J7ES、J721E、 等等？

在回答这些向 TI 提出的未决问题后、 我们可以"解决"此主题并在另一主题上跟踪我提到的其他"无引导模式"EVM 问题。

关于...

您能否解释一下您试图进行的 C66和 C7x 比较？ 是否要将 C66项目与使用现有 C66项目代码且包含 c7x.h 和 c6x_migration.h 头文件的 C7x 项目进行编译的项目进行比较？ 如果是、请注意、包含迁移头文件不会利用 C7x 的矢量处理功能、因此性能比 C66有一些重大改进。

回复...

是的、我的目的实际上是比较 C7x C7000编译器在现有原生 C6x 图像处理代码上的性能、而不对带和不带 C6x 内在函数的 C/C++代码进行任何更改。  它是否对所有相同的循环进行软件流水线处理？ 它是否会对其他循环进行软件流水线处理？ 展开因子是什么？  周期/循环是什么？  这就是包含 c7x.h 和 c6x_migration.h 头文件的目的。  我们需要进行此练习、以获得将 C6x 代码行迁移 到 C7x 上的基准结果。  我们的期望是 C7x 应该超越 C6x 而不是 C7x 专业化。

我们需要评估 C7x 在不进行修改的情况下支持和运行我们现有的 C6x 代码库的能力。  我们再次希望、也不会抱任何期望、C7x 应该表现更好。  是不是更好,多少?  更糟糕吗？  我们在继续之前需要知道这一点。

我们的 C6x 图像处理代码库相当广泛、在过去20年中经过了~100人工年的开发工作。

重新编写和重构该 C6x 代码库(甚至是子集)以支持 C7x 的完整矢量处理的投资将是一项微不足道的工作和费用。  接下来进入专门的 C7x 矢量处理实施的下一阶段、需要 与正在研究的其他非 TI DSP 处理器选项进行权衡。

谢谢。

-乔治

您好、George、

让我澄清一下有关支持的问题。

SYS/BIOS 6.83.00.18 和 XDC 3.61.02.27  分别是 SYS/BIOS 和 XDC 产品的最后一个版本、它们分别于2020年8月/6月发布。

https://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/bios/sysbios/

这些示例至少经过了 CCS 10.1的验证、发布时可用的最新 CCS 版本分别为 CCS 10.4或 CCS 10.3.1。  

https://www.ti.com/tool/download/CCSTUDIO

SYS/BIOS 和 XDC 产品已达到 EOL、并且 TI 内部没有团队对照从较新 Ubuntu 计算机上开始发布的绝对最新 CCS 版本来开发或验证这些版本。  

最后一个使用 SYS/BIOS 的 Jacinto Processor SDK 版本为7.3 (2021年4月发布)、早在两年多以前、且  从那时起就没有在使用 SYS/BIOS 的 Jacinto 处理器中进行开发。 最新 SDK 支持的唯一 RTOS 主要是 FreeRTOS、及其安全型号 SAFERTOS。

我很高兴看到您能够使用这些与最新 CCS 协同工作。 我想说你很幸运、因为这些工具确实具有一些元数据插件等、可能需要更改才能与最新的 Eclipse 插件等搭配使用(正如某些较旧 SYS/BIOS 版本的最低 CCS 版本所示)。

此致

苏曼