[参考译文] F28377D-SEP：syscfg 文件的 CPU 使用情况

你好、Reshma  

对于空工程、实际的 RAM 影响是最小的、并且它完全随您在 SysConfig 中配置的内容而扩展。
衡量特定编译情况的最佳方法是在编译后查看.map 文件、CCS 会与.out 一起生成该文件。 检查 board.obj 和 c2000ware_libraries.obj 部分以了解确切的图。

此类文件c2000ware_libraries.cmd.genlibs为可选特征的脚手架/占位符。 它们的存在使建立系统能够无条件地引用它们而不会出现错误。  空文件占用零内存、编译器和链接器只会将其作为 no-ops 进行处理。 它们不会影响您的闪存或 RAM 占用空间。

您是正确的、Device_init()默认情况下为所有外设启用时钟并Device_initGPIO()解锁所有 GPIO 端口、这会消耗比启动时严格必要的 CPU 周期数更多的 CPU 周期数。 但是、这是一次性启动成本、而不是持续的运行时损失。

如果您仍想优化,下面是需要从 Device_init () 中选择性地保留的内容。   

// 1。 禁用看门狗（或配置看门狗）
sysctl_disableWatchdog ();

// 2. 设置系统时钟（必需）
SysCtl_setclock (device_setclock_CFG)；//您的 PLL 配置

// 3. 闪存等待状态（如果从闪存运行）
FLASH_initModule (FLASH0CTRL_BASE、FLASH0ECC_BASE、DEVICE_FLASH_WAITSTAT)；

// 4. 而不是 Device_enableAllPeripherals()、只调用您需要的内容。 例如：
SysCtl_enablePeripheral (SYSCTL_PERIPH_CLK_TIMER0)；//（如果使用 CPU 计时器 0）
SysCtl_enablePeripheral (SYSCTL_PERIPH_CLK_EPWM1)；//如果使用 ePWM1
SysCtl_enablePeripheral (SYSCTL_PERIPH_CLK_SCIA)；//（如果使用 SCI-A）
//...只添加您的应用程序所需的内容

对于 Device_initGPIO()、它只需调用 GPIO_unlockPortConfig (GPIO_PORT_A、0xFFFFFFFF)（以及 B、C 等）即可删除所有 GPIO 配置寄存器的写锁定。 如果您仅使用端口 A 和 B、则可以调用：

GPIO_unlockPortConfig (GPIO_PORT_A、0xFFFFFFFF)；
GPIO_unlockPortConfig (GPIO_PORT_B、0xFFFFFFFF)；
//如果未使用、则跳过 C、D、E、F

如果您手动编辑device.c、SysConfig 将在下次重新生成文件时覆盖您的更改。 保留优化：
将相关的初始化代码复制到您自己的main.c或自定义的 init 文件中
device.c从构建中删除 SysConfig 生成的

或

接受默认的Device_init()“原样 “、额外的 CPU 周期为一次性启动 总线电压 以微秒为单位进行测量、除非您有严格的引导时间要求、否则可以忽略不计

您应该查看 映射文件的模块摘要部分。


在运行时零差。 SysConfig 完全是一个代码生成工具。 它在构建时写入 board.c / board.h。 编译后、生成的目标代码在功能上与用户手动编写的代码相同。 编译器不知道也不关心源代码是来自 SysConfig 还是手写的。 没有 SysConfig“运行时“、它根本不存在于您的最终二进制文件中。

.syscfg 文件本身是否会增加 RAM 开销？
编号 在预编译步骤中、SYSCONFIG 工具完全使用.syscfg 文件。 它会生成.c/.h 文件、然后完成。 syscfg 文件中的任何内容都不会到达您的二进制文件中。

您是否可以使用独立的 SysConfig 工具并仅复制生成的文件？
是的、您可以这样做。 使用 sysconfig 生成文件、 然后从主目录中其他 c 文件所在的 sysconfig 文件夹复制这些文件。
然后、您可以从 generation 中禁用 sysconfig、当您下次编译时它不会生成代码。



RAM 使用方式将相同、生成的 board.c、board.h、device.c 和 device.h 都是相同的文件、无论 SysConfig 是在 CCS 内运行还是作为独立的 CLI 工具运行。 二进制输出 应相同。

我们建议使用 CCS 中集成的 SysConfig 作为主工作流程、因为在修改.syscfg 时、它会在每次构建中自动重新生成板级配置文件。 独立方法有效、但需要您手动重新运行该工具、并在配置更改时重新复制文件、这很容易出错。 对于生产工程、集成的 SysConfig 更简洁。 独立复制方法对于固定的、最终确定的配置或在 CCS 之外工作时是合理的。