[参考译文] 编译器/SW-EK-TM4C1294XL：如何将系统时钟频率设置为120MHz、以及 TM4C1294xl 中指令的计算执行时间

预制测试：
1.更改了 Tivaware 驱动程序库变量 TM4C1294NCPDT、项目符号(class_y_TM4C129)、然后清理了编译的驱动程序库。

SysCtlClkGet ()的运行时断言在编译期间不会发出警告、因为在找不到运行时符号(class_is_TM4C123)时可能会遇到这种警告。 它也没有发出运行时调试消息、而是在应用中定义了调试。

其他非 Tivaware 模块置为有效、仍可通过 UART0打印消息。 也许、写入 Tivaware 驱动程序断言的方式是不正确的？

(现在)在-中的52个帖子以及在 O..p.(有限)主题中的"如此远的传播"：(即设置系统时钟和计算。 exe 中。 时间)-"在这里关上大门"是不明智的-并启动一个"主题贴有正确标签"主题-重点关注这些新的(更有趣的)主题-不太可能、"永远会被注意到"-一旦这个主题"旋转到论坛中？"

如果寻求"供应商注释/注释"-一个正确命名的新线程-显示最佳...

[引用 user="BP101]preformed a test：
1.更改了 Tivaware 驱动程序库变量 TM4C1294NCPDT、项目符号(class_y_TM4C129)、然后清理了编译的驱动程序库。

SysCtlClkGet ()的运行时断言在编译期间不会发出警告、因为在找不到运行时符号(class_is_TM4C123)时可能会遇到这种警告。 它也没有发出运行时调试消息、而是在应用中定义了调试。

其他非 Tivaware 模块置为有效、仍可通过 UART0打印消息。 也许、写入 Tivaware 驱动程序断言的方式是不正确的？

[/报价]

它不会产生编译时警告或错误。 这些断言只能在运行时产生一些结果。 为了说明原因、让我们看看 Class_IS_TM4C123和 Class_IS_TM4C129的定义。 如果 TivaWare 已安装到默认位置、则会从 C：\ti\TivaWare_C_Series-2.1.4.178\inc\hw_types.h 中获得：

//
//
//帮助程序宏用于确定芯片版本等
//
// Driverlib 将在"run-time"时使用这些宏来创建必要
的//条件代码块，这些代码块将允许单个版本的 Driverlib
//“二进制”代码支持多个(所有) Tiva 芯片修订版。
//
//预计这些宏将在标准'C'//
条件代码块中使用，例如
//
//// if (class_in_TM4C123)
// ｛
// 在此处执行一些 TM4C123类特定代码。
//｝
//
//默认情况

下，这些宏将被定义为//适当寄存器的运行时检查，以便为整个 Tiva 系列中的通用 DriverLib 创建运行时条件代码//块。
//
//但是、如果需要优化代码空间、这些宏可以针对
特定版本的 Tiva 芯片进行"硬编码"/"。 然后、许多编译

器会//检测"硬编码"条件、并适当地优化代码//块、从而消除任何"不可访问"的代码。 这将导致一个较小
的// Driverlib、从而生成较小的最终应用程序大小、但代价
是//将 Driverlib 二进制文件限制在一个特定的 Tiva 芯片修订版本上。
////
*****************
#ifndef class_in_TM4C123
#define class_in_TM4C123 \
(((HWREG (SYSCTL_DID0)&(SYSCTL_DID0_VER_M | SYSCTL_DID0_CLASS_M))=\
(SYSCTL_DID0_VER_1 | SYSCTL_DID0_Class_TM4C123)
#endif

#ifndef CLASS_IS_TM4C129
#define CLASS_IS_TM4C129 \
(((HWREG (SYSCTL_DID0)&(SYSCTL_DID0_VER_M | SYSCTL_DID0_CLASS_M))=\
(SYSCTL_DID0_VER_1 | SYSCTL_DID0_Class_TM4C129)
)#endif

#ifndef REVIS_A0
#define REVISE_A0 \
(((HWREG (SYSCTL_DID0)&(SYSCTL_DID0_MAJ_M | SYSCTL_DID0_MIN_M))=\
(SYSCTL_DID0_MAJ_REVA | SYSCTL_DID0_MIN_0)
)#endif

#ifndef REVIS_A1
#define REVISE_AS_A1 \
(((HWREG (SYSCTL_DID0)&(SYSCTL_DID0_MAJ_M | SYSCTL_DID0_MIN_M))=\
(SYSCTL_DID0_MAJ_REVA | SYSCTL_DID0_MIN_0)
)#endif

#ifndef REVIS_A2
#define REVISE_AS_A2 \
(((HWREG (SYSCTL_DID0)&(SYSCTL_DID0_MAJ_M | SYSCTL_DID0_MIN_M))=\
(SYSCTL_DID0_MAJ_REVA | SYSCTL_DID0_MIN_2)
)#endif

#ifndef REVIS_B0
#define REVISION_ITH_B0 \
(((HWREG (SYSCTL_DID0)&(SYSCTL_DID0_MAJ_M | SYSCTL_DID0_MIN_M))=\
(SYSCTL_DID0_MAJ_RevB | SYSCTL_DID0_MIN_0)
)#endif

#ifndef REVISE_B1
#define REVISE_B1 \
(((HWREG (SYSCTL_DID0)&(SYSCTL_DID0_MAJ_M | SYSCTL_DID0_MIN_M))=\
(SYSCTL_DID0_MAJ_RevB | SYSCTL_DID0_MIN_1)
#endif 

请注意、HWREG 是一个读取特定地址的宏。 它直接在上面的同一文件中定义：

//
//
//用于硬件访问的宏，包括直接访问和通过位带区访问。
////
*****************
#define HWREG (x) \
(*((volatile uint32_t *)(x)))

这是在运行时必须发生的事情。 class_is_TM4C123和 class_is_TM4C129上面的注释解释了这些将在 if ()语句的运行时使用。

请注意、如果您的应用程序代码包含以下内容：

#ifdef class_in_TM4C129...
执行只能在 TM4C129上完成的操作...
#endif

那么这是一个编程错误！！！ 这是因为无论您编译的是哪种 TM4C 变体、都会定义 Class_IS_TM4C123和 Class_IS_TM4C129！

我重申编译器无法在编译时发出有关此问题的警告。 至少编译器现在不存在。 据我所知、TI ARM 编译器和由 TM4C 供应商提供的 GCC ARM 编译器基本上都是 ARM 编译器、而 TM4C 系列没有任何特定知识或特殊功能。 如果您希望编译器提供此类编译时检查、则需要编译器包含有关 TM4C 系列的特殊知识。 您需要将命令行参数传递给编译器、以告诉编译器您目前正在编译的确切变体。 在该编译器中、HWREG 和类似的内容需要是编译器内在函数、而不是代码中的普通定义。 如果编译器具有有关目标芯片的这种类型的知识并且 HWREG 是可在编译时解析的内在函数，则可能会发出编译时警告，指出断言将失败--这也会附带警告。 如果您的代码将参数传递给 TivaWare 函数、而该函数在编译时无法解析(因为它们依赖于运行时之前未知的值)、则编译器可能不会警告断言会失败。

底线是、只要编译器不知道目标芯片的详细信息、例如 SYSCTL_DID0等特定寄存器中将找到的值、就不会得到所需的编译时警告。

[引用 user="12ve12pm">据我所知、TM4C 供应商提供的 TI ARM 编译器和 GCC ARM 编译器基本上都是 ARM 编译器、而 TM4C 系列没有任何特定知识或特殊功能。 如果您希望编译器提供编译时检查、例如这样的检查、则需要编译器包含有关 TM4C 系列的特殊知识。

这是我的观点、即 CCS 代码分析器会抱怨未明确定义或 索引中的所有其他符号、但让 123gClass fly by 保持无任何警告。 请注意 SysCtrlClockSet()有一个(如果 129Class assert return) ，但 SysCtrlClkGet ()中的运行时断言是留给事后剖析的。 Tivaware 本应使程序员在跟踪导致 MCU 故障的库问题时避免浪费时间。 它做得很好、但在一些早期的驱动程序库中失败的原因很明显、以确保 CSS 代码分析器可以看到这些 MCU 特定类调用。  

CCS 代码分析 器警告(预编译/编译后) 监视已定义的宏 (#ifdef 断言)是否被错误启用。  CCS 编译器不会完全编译 启用了错误 Assert 定义的工程、如果启用了错误、则会抛出错误。 因此、编译器会在运行前检查库的断言、尽管 会尽力进行其他验证。   LWIP 1.4.1具有许多此类(#ifdef assert)检查、以确保工程不会在启用错误协议的情况下编译。

问题是  SysCtlClkGet()中的断言123Class 是否已在 Tivaware 库的后续版本中修复？

[引用 user="BP101"]

因此、编译器会在运行前检查库的断言、尽管 会尽力进行其他验证。   LWIP 1.4.1具有许多此类(#ifdef assert)检查、以确保工程不会在启用错误协议的情况下编译。

[/报价]

您能向我展示在编译时捕获的这种断言的具体示例吗？ 无论是 TivaWare 还是 lwIP 断言、都无关紧要。 我想弄清楚这是如何工作的。 谢谢。