[参考译文] TMS320F28P550SJ：如何在 SysConfig 中处理 LS8/LS9上的 CLA 代码。

尊敬的 champs：

还有一个问题、

对于专用 CPU 使用(0x14000-0x17FFF)、可以将 LS8/LS9分配给 CPU 代码或数据使用。 对吗？

对于 CLA 使用(0x4000-0x7FFF)、是否可以将 LS8/LS9分配给 CLA 程序或数据(CPU/CLA 共享数据)使用？ 或者、它们只能用于 CLA 程序、不能用作 CLA 数据？

尊敬的 Wayne：

这看起来确实是 Sysonfig 生成的代码中的一个错误、尚未添加对此特定用例的支持。 在这种情况下、最好遵循 C2000ware 示例代码(CLA_ASIN_LS8_9)并在主文件中进行这些初始化。 我将确保在未来的 C2000ware 版本中添加此内容。  

LS8和 LS9只能选择配置为 CLA 程序存储器、而不能配置为 CLA 数据存储器、请参阅存储器映射访问：

如果 CLA 代码大于 LS8和 LS9中可容纳的代码、则需要将程序分配给存储器的非连续部分。 以下是这方面的一个示例：

• .cmd 文件

RAMLS8_LS9 : origin = 0x004000, length = 0x004000 // LS8~LS9 for CLA_PROGRAM

RAMLS0_LS1 : origin = 0x008000, length = 0x001000 // LS0~LS1 for CLA_PROGRAM

Cla1Prog : LOAD = FLASH_BANK0,
RUN = RAMLS8_LS9,
LOAD_START(Cla1ProgLoadStart_LS8_9),
RUN_START(Cla1ProgRunStart_LS8_9),
LOAD_SIZE(Cla1ProgLoadSize_LS8_9),
ALIGN(4)

Cla1Prog : LOAD = FLASH_BANK0,
RUN = RAMLS0_LS1,
LOAD_START(Cla1ProgLoadStart_LS0_1),
RUN_START(Cla1ProgRunStart_LS0_1),
LOAD_SIZE(Cla1ProgLoadSize_LS0_1),
ALIGN(4)

• 使用.c 文件执行 memcpy

memcpy((uint32_t *)&Cla1ProgRunStart_LS0_1, (uint32_t *)&Cla1ProgLoadStart_LS0_1,
(uint32_t)&Cla1ProgLoadSize_LS0_1);

memcpy((uint32_t *)((uint32_t)&Cla1ProgRunStart_LS8_9 + (0x1E000U)), (uint32_t *)&Cla1ProgLoadStart_LS8_9,
(uint32_t)&Cla1ProgLoadSize_LS8_9);

如果回答了所有客户问题、请支持此回答。 μ s

此致、

Delaney

尊敬的 Delaney：

从下面的开始、如果用户仅使用一个函数本身且大于32KB 的 CLA 任务1、该 CLA 任务1函数是否会从 LS8 (0x4000)开始放置、然后位于0x7FFF/0x8000上？ 您能否确认编译器/链接器可以将相同的函数放置在下面声明的两个 RAM 中？

顺便说一下、我们通常使用对齐(8)、这里您有目的使用对齐(4)？ 还是 align (8)也正常？

Cla1Prog : LOAD = FLASH_BANK0,
RUN = RAMLS8_LS9,
LOAD_START(Cla1ProgLoadStart_LS8_9),
RUN_START(Cla1ProgRunStart_LS8_9),
LOAD_SIZE(Cla1ProgLoadSize_LS8_9),
ALIGN(4)

Cla1Prog : LOAD = FLASH_BANK0,
RUN = RAMLS0_LS1,
LOAD_START(Cla1ProgLoadStart_LS0_1),
RUN_START(Cla1ProgRunStart_LS0_1),
LOAD_SIZE(Cla1ProgLoadSize_LS0_1),
ALIGN(4)

2. From below, the offset for LS8_9 is 0x1E000 rather than 0x10000?

memcpy((uint32_t *)((uint32_t)&Cla1ProgRunStart_LS8_9 + (0x1E000U)), (uint32_t *)&Cla1ProgLoadStart_LS8_9,
(uint32_t)&Cla1ProgLoadSize_LS8_9);

3. Is .const_cla viewed as CLA program or CLA data? Can .const_cla be placed on LS8/LS9? We are asking this because it requires memory copy. We are confused if .const_cla follows the same way as Cla1Prog if they are placed on LS8/LS9?

尊敬的 Wayne：

我明天会回复您。

此致、

Delaney

尊敬的 Wayne：

很抱歉耽误你的时间。  

Deshine Deshine 说：

从下面开始、如果用户仅使用一个函数本身大于32KB 的 CLA 任务1、该 CLA 任务1函数是否会从 LS8 (0x4000)开始放置、然后位于0x7FFF/0x8000之间？ 您能否确认编译器/链接器可以将相同的函数放在下面声明的两个 RAM 之间？

是的、如果将 LS8和 LS9组合到存储器｛｝的一个范围内(如示例所示)、则可以将大于32KB 的任务分配给存储器范围。

不过在这种情况下、如果可能、我建议将代码拆分为不同的任务(如果未使用其他任务)。 您可以在另一个任务中从软件手动触发任务(在此处查看更多信息：  4.常见问题解答—C2000 CLA 软件指南 )。

Deshine Deshine 说：

顺便 说一下、我们通常使用 align (8)、这里您使用 align (4)的目的是什么？ 还是 align (8)也可以？

我 不知道链接器如何使用 align 属性太多、 在 汇编语言工具指南中应该有更多信息。但是、C2000ware 中 CLA 的示例链接器 cmd 文件使用 align (4)、因此我建议匹配此文件是安全的。

Deshine Deshine 说：

2. 从下面开始、LS8_9的偏移是0x1E000、而不是0x10000？

抱歉、我应该提到我提供的示例是专门针对 F28P65x 的示例(由于存储器映射、该示例需要0x1E000偏移)。 对于 F28P55x、您可以像在 C2000ware 示例中一样将此值更改为0x10000。

Deshine Deshine 说：

3. const_cla 是被视为 CLA 程序还是 CLA 数据？ 可以 将.const_cla 放置在 LS8/LS9上吗？ 我们之所以问这个问题、是因为它需要存储器副本。 如果 .const_cla 与 Cla1Prog 遵循相同的方式(如果将它们放置在 LS8/LS9上？

CONST_CLA 视为 CLA 的数据存储器。 链接器 cmd 中除 Cla1Prog 之外的每个 CLA 分配都是数据存储器。 因此、不可以将 CONST_CLA 放置在 LS8/LS9中、因为无法将这些变量分配为 CLA 数据存储器。 该函数需要放置在 LS0-LS7中、并使用不需要任何偏移的 memcpy。

此致、

Delaney

尊敬的 Delaney：

"但在这种情况下、如果可能的话、如果其他任务未使用、我建议将代码拆分为不同的任务。"

您意味着用户可以通过软件调用 task2和任务1结束来将长任务1分离到任务1和任务1中？

原因是编译器可以将它们分开并单独放置、对吧？

还是其他原因？

尊敬的 Wayne：

是的、在这种情况下、编译器会制造两个不同的符号、因此链接器 在 分配存储器的方式方面具有更大的灵活性。 它也更模块化、因此是更好的编码实践。

此致、

Delaney