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

***类似***

一个奇迹、"为什么和如何"-那些"引导/影响"(但不是指示)这样的新用户"失败了"、无法传达重要(必需)的方向-您已经很好地提供了！

[引用 USER="CB1_MOBILE"]

***类似***

一个奇迹、"为什么和如何"-那些"引导/影响"(但不是指示)这样的新用户"失败了"、无法传达重要(必需)的方向-您已经很好地提供了！

[/报价]

谢谢你。

当我首次开始使用 TI MCU、尤其是 TM4C 时、我对大量可用信息感到不知所措。 有与 MCU 相关的网页；与 LaunchPad 相关的网页；超过您可以在以下网址获取的更多用户指南；应用手册；Wiki；论坛；数据表...

所以问题不在于您需要的信息是否可用、而是在于如何找到这些信息！

我所学的操作顺序如下：

(1)查找 TivaWare 代码示例；这些示例有详尽的文档记录、几乎每行代码都有注释

(2)实际上、所有 TivaWare 都有详尽的文档记录。 如果您要对外设进行编程、请找到与其相关的 driverlib 文件。 源代码包含非常好的文档。

(3)使用 LaunchPad 时、其用户指南和原理图非常有用。

(4) MCU 数据表"功能说明"和寄存器文档。

(5)如果所有其他失败、请在论坛中提问！

项目1和2需要熟悉代码在 TivaWare 目录中的组织方式。 由于目录和文件太多、这似乎让人不知所措、但我发现大部分时间我都在 driverlib 和示例中查找。

如果您可以进行快速文本搜索、这将很有帮助。 我使用 UltraEdit 作为编辑器；它具有"在文件中查找"功能、我全天都在使用。 例如、如果我查看 TivaWare 示例并遇到 如上面所示的 SysCtlClockFreqSet()之类的调用、我可以立即突出显示"SysCtlClockFreqSet"并在 C：\ti\TivaWare_C_Series-2.1.4.178\driverlib 下执行"在文件中查找"来查找函数本身。 如果在 driverlib 中找不到函数、那么我转到一个目录并在 C：\ti\TivaWare_C_Series-2.1.4.178中进行搜索。 如果您在 CCS 中工作、则有一个"转到定义"功能。 不过、我不在 CCS 中进行编辑、只进行编译和调试、因此我在这方面无能为力。 与"转到定义"相比、文本搜索的优点是、除了显示函数的定义位置外、文本搜索还可以显示函数的使用位置。 因此、您可以从其他示例中学习。

希望这对您有所帮助。

[引用 user="Danny F"]对于任何合适的想法，您都可以右键单击一个单词，然后找到它的定义和实施，从而使生活更加轻松。

我对你的措辞"体面的想法"不太确定-但是你的建议是准确和有帮助的。

是否有任何新用户 "非常不可能"会"有这样的意识？"    这是我的观点-用户已到达"不受指导和不受支持"-这是一种犯罪...

和您(和海报12_squared)的建议一样好-它很快(非常) 将"旋转到论坛中"-很少(如果有)再次被看到...

你是对的。 我回答的是相对于系统时钟的问题(因为我知道这个问题的答案)、并且希望其他人跳进并回答有关看门狗的问题。 不过、与此同时、我查看了看门狗的示例代码和数据表。 OP 询问"计算每条指令的执行时间"。 但是、我认为 OP 实际上是在询问看门狗使用什么负载值来获得所需的看门狗超时。 这里有一个示例：

C：\ti\TivaWare_C_Series-2.1.4.178\examples\boards\ek-tm4c1294xl\watchdog\watchdog.c

与我提到的另一个示例一样、系统时钟频率再次通过设置：

G_ui32SysClock = MAP_SysCtlClockFreqSet ((SYSCTL_XTAL_25MHz |
SYSCTL_OSC_MAIN |
SYSCTL_USE_PLL |
SYSCTL_CFG_VCO_480)、120000000)；

在系统时钟为120MHz 时、看门狗每秒减少1/120,000,000次计数。 因此、如果您需要1秒超时、加载值为120,000,000。 如果您需要0.5秒的超时、则为60、000、000。 等等。

示例将周期设置为1秒：

//
//将看门狗计时器的周期设置为1秒。
//
ROM_WatchdogReloadSet (WATCHDOG0_BASE、g_ui32SysClock)；

请注意参数 g_ui32SysClock 是保存在调用 SysCtlClockFreqSet()时的相同值，即120,000,000。

[引用 user="Pras p"]我需要计算每条指令的执行时间的看门狗计时器可以为我提供任何帮助。

为什么需要计算每条指令的执行时间来确定看门狗？ 这似乎是一种向后接近事物的方法？

Robert

[引用 user="BP101]\n 查找加载值的正确方法需要计算函数退出点之前要执行的指令数、并总计指令时间。 然后使用最小的时间值设置重载狗值函数在退出前可以完全执行、而不会再次送入狗、以防止其过期

否 尤其是在涉及 PID 等的控制循环中、您需要确定循环必须处理的频率、以便正确执行。 确定需要多长时间是因为加载操作不正确。 实际上、如果您需要更安全的检查、那么您也不会经常执行循环。 但没有看到很多人这么做。

有时、如果处理长操作、您可能会使用子周期监控并检查步进完成情况、而不是整个循环。 但主体仍然相同。 将看门狗时间设置为执行时间会出现低音背

Robert

[引用 user="12ve12pm"]我会担心的是错误警报/干扰性跳闸。

从定义上来说、它们基本上不会是错误的。 它们表示系统存在实际问题。 如果您的系统无法在分配的时间内响应、则表明必须解决问题。

[引用 user="12ve12pm"]如果我要设置看门狗，我会在每个主循环中馈送一次狗。

如果？

您测量的是错误的东西。 重要的不是超级循环时间。 现在是您的控制结构体运行的时候了。 超级循环的一个问题是它们混淆了控制结构。

因此、如果您有如下所示的简单项目

• 1ms 控制回路开启电流(可能是限值或 PID)。
• 以50mS 的速度运行的用户输入、收集馈送到输出的设置点(例如油门和方向)。

然后、您有两个关键控件、它们必须以一定速度运行、才能使您的控件成功。 1ms 循环尤为重要、因此您可能会在11ms 时看门狗(任何更长时间都是故障)。 用户输入循环应每50mS 运行一次、但您可能会在该循环中出现更多的波动、并在75ms 时看门狗。 在任何一种情况下、超过相关时间都是一个问题、并且超循环时间无关紧要。

另请注意、在这两种情况下、运行过快也会被视为一个问题、但通常不会引起关注。

[报价用户="12ve12PM"]，最大扫描时间的两倍[/报价]

PLC 背景可能发生什么情况？

Robert

另请参阅此处的熨平板(e2e.ti.com/.../2447636)、了解如何正确设置看门狗。

Robert

[引用用户="Robert Adsett"]

12时12分

，是最大扫描时间的两倍

PLC 背景可能发生什么情况？

Robert

[/报价]

是的。

[引用用户="Robert Adsett"]

另请参阅此处的熨平板(e2e.ti.com/.../2447636)、了解如何正确设置看门狗。  

Robert

[/报价]

感谢您在上面的链接中发帖。 非常感谢您发表该文章、我一定会对其进行一些深入的思考。

我有一种不同的方法来应对意外情况。

我不在中断中为看门狗提供数据、因为主上下文可能会卡在某个位置的无限循环中、而中断可能会继续工作。 因此、我在超级循环中进行馈送、并且只有当所有"任务"(中断和基于主上下文的状态机)报告它们都正常(与您的软件看门狗类似)、并且所有"完整性检查"都通过。

[引用用户="Robert Adsett">否 尤其是在涉及 PID 等的控制循环中、您需要确定循环必须处理的频率、以便正确执行[/QUERPILE]

否 是确定 性的、但 总 指令时间 是  确定狗 定时器 在 特定软件循环、中断或非中断的范围内应保留多长时间的正确方法。 您基本上说的是同一件事、但在 不同的叙述中、您只需在   循环执行开始时踢脚、打脚、喂狗。  

[引用 user="Robert Adsett"]实际上，如果您希望进行更安全的检查，那么循环也不会经常执行

主要思路是监视软件是否(不)在看门狗到期第一次超时内完成了正确的流程、除此之外的任何内容都只是对硬件的一个额外好处、尤其是 在第二次超时 执行 MCU POR 时。 我禁用第二个超时复位功能、因为它往往会掩盖软件设计缺陷、精确总线故障 或堆栈损坏等。  

[引用 user="Robert Adsett"]将看门狗时间设置为执行时间时将出现低音背卡声[/quot]

函数内的总指令执行时间、此时间被视为 在   看门狗 失效时间内受控硬件的故障或可能破坏。 我们 将回顾上面的爪形离合器链路 、但我描述的方法在 PWM 逆变器换向周期期间非常有效、因为在 同一 环路中发生了多个 GPTM、ADC 中断。  

[引用 user="BP101"]

Robert Adsett

实际上、如果您需要更安全的检查、那么您也不会经常执行循环

主要思路是监视软件是否(不)在看门狗到期第一次超时内完成了正确的流程、除此之外的任何内容都只是对硬件的一个额外好处、尤其是 在第二次超时 执行 MCU POR 时。 我禁用第二个超时复位功能、因为它往往会掩盖软件设计缺陷、精确总线故障 或堆栈损坏等。  

[/报价]

我同意使用绝对最少的指令将系统置于"安全状态"。 一旦发生严重的故障----无论是 CPU 停止，内存由于硬件/软件/ 太阳耀斑等原因而损坏，还是系统中的一些较大问题----您的软件中的指令可能实际执行，也可能不执行。 因此、您需要一种分层的方法来处理软件、硬件和整个系统中的这些问题；看门狗只是一个防线。

[引用 user="12ve12PM"]当然，所有内容都需要：测试、测试！

三个" 测试"的说法-"深思熟虑、专注和仔细规划-设计？"

测试-只要(两者)合适且足够广泛-(可能)发现计划和/或设计缺陷。   然而、"测试"往往是"最后/最后要考虑"、然后是"事后才考虑！"

应提前和提前准备关键/关键电路板测量-用于可靠的"仪器连接点"(或容纳"钉子床")测试平台。

但对于海报 Robert -这里的所有看门狗参考-侧重于"代码段执行"-花费"太长时间"。   反向(段执行过快)也不能证明是正确的？   那么呢？

在模拟世界中-"窗口电压比较器"可确保信号具有(两者)"低与高"界限。   不应该(某些)对"捕获关键/关键代码段-执行得太快？   (发出"过早退出"信号-出于"公平"或 (特别是)"不想要/沮丧"的原因？)   

此检查以及 Robert 建议的"监控函数的执行频率"可以提高代码的性能。   (仅)"测试"也不可能导致这两种情况。

[引用 USER="CB1_MOBILE"]

12时12分

当然、一切都需要：测试、测试！

三个" 测试"的说法-"深思熟虑、专注和仔细规划-设计？"

[/报价]

这就是设计师的工作！！！！

您不希望我破坏某人的工作安全、您会吗？ ：- p

[引用 user="12ve12PM"]破坏某人的工作安全性

"有罪方"可能"完成了这一事实"，而这一切都是靠自己的力量完成的。

这证明"检验"质量"是"罕见的"。    深入、有条不紊的"思考和规划"-在设计过程中(其本身应进入"测试")、证明了" 成功"的最佳驱动因素。

[引用 user="12ve12pm "]

Robert Adsett

12时12分

，是最大扫描时间的两倍

PLC 背景可能发生什么情况？

Robert

[/报价]

这说明了您对"扫描时间"的使用以及您对看门狗的选择。 前者是一个概念、应应用于更多的嵌入式系统、后者不应应用。

高端 PLC 使用了一个比我看到的更好的看门狗。 它们允许多个进程、因此扫描时间看门狗无法工作。 这些进程通常定期运行。 一个可能每10ms 运行一次、另一个可能每55ms 运行一次。 然后、看门狗检查每个看门狗是否在其预定时间内完成分配的工作。 这更类似于我的建议。

[引用 user="12ve12pm"]我不会在中断中向看门狗馈送内容，因为主上下文可能会卡在某个位置的无限循环中，而中断可能会继续工作。

我之所以使用字处理而不是中断、是有原因的。

但是、请注意、您在这里的投诉同样适用于超循环。 循环可能会继续幸福运行、而不会及时执行关键流程。 相反、超级循环可能在某个时间缓慢执行、但仍能轻松满足关键流程的最后期限。 执行超级循环所需的时间显然与 满足进程执行要求无关。

[引用 user="12ve12pm"]因此，我在超级循环中执行馈送，并且只有当所有"任务"(中断和基于主上下文的状态机)报告它们都正常(类似于您的软件看门狗)，并且所有"完整性检查"都通过了。

如果这些检查包括任务中的流程的及时性、那么它将按照我的建议进行分配、可能结构更少、复杂性更高。 如果没有、我认为您缺少重要的检查。

Robert

[引用 user="12ve12pm "]

CB1_MOBILE

12时12分

当然、一切都需要：测试、测试！

三个" 测试"的说法-"深思熟虑、专注和仔细规划-设计？"

您不希望我破坏某人的工作安全、您会吗？ ：- p

[/报价]

我确实希望设计人员完成他们的工作、其中包括为关键流程设置执行时间的界限。

Robert

[引用 USER="CB1_MOBIST"]但是对于海报 Robert -这里所有看门狗参考-侧重于"代码段执行"-花费"太长时间"。   反向(段执行过快)也不能证明是正确的？   然后是什么？

我自己没有足够频繁地进行检查。

当然、如果 PID 偏离可重复性等度量体、它将失败。

Robert

[引用 user="BP101"]

Robert Adsett

否 尤其是在涉及 PID 等的控制循环中、您需要确定循环必须处理的频率、以便正确执行

[/报价]

Nope、Nada、Anti-yes。

这与我所说的完全不同、甚至不是错误的。

[引用 user="BP101"]

Robert Adsett

将看门狗时间设置为执行时间会出现低音背

[/报价]

看门狗时间的现象性设置、特别是 当与禁用看门狗(并且只将它用作定时器)一起完成时 、会询问问题。 如果您对时间没有要求、则不能说您满足了这些要求。

Robert

[引用 user="12ve12PM"]这样，您就需要一种分层的方法来处理软件、硬件和整个系统中的这些问题；看门狗只是一个防线。

最后一个问题。 如果您达到看门狗触发的状态、则无法再确定任何内容。 这就是复位的目的、以尽可能快的方式进入干净状态(如果可能)。 它不是正常错误检测过程的一部分、也不是正常错误恢复的一部分、您永远不应该依赖它、它是挽救系统的最后一个艰难、绝望的尝试。

Robert

[报价用户="Robert Adsett"]如果您对时间没有要求，则不能说您满足了要求。

棒极了-正如我们所说的-"界限"-高低-提供了最大的安全性！   

关于你对"一个"的答复，这里： "不，不，不，不是"。  您能否分享您(真实)的感受？   (此处没有个性竞赛土地-尚未...)

[报价 USER="CB1_MOBILE]]您能否分享您(真实)的感受？  [/报价]

嗯...你知道、tundra 的冷库限制了情感表达。

Robert

[引用 user="Robert Adsett"]这与我所说的完全不同，甚至不是错误的。

Robert、我想您会混淆看门狗所需 的负载计数 功能、因为它是某种类型的软件看门狗。 在 上面提供的线程链接中、您 说  有一个软件看门狗、您在想什么？

 看门狗 外设所需的重新加载功能(踢脚、打脚、喂食)不是最后的麻烦、 为 SW 和 HW 故障提供一线防御。 TM4C1294数据表 确实列出了所有指令、但未能指示 与时钟节拍相关的任何时序。   我维护过的计算机系统在 主 处理器板上有一个无缝看门狗、 这是如何防止(  S100)总线架构出现其他系统处理器板故障的原因。  要么是看门狗从未启用、这就是这些业务 系统的优点、 而且价格非常昂贵。     

执行代码到 FAST 的可能引擎罩似乎表明程序 栈故障或者 在  安全装置外设重新加载计数时间窗口之外发生了一个指令指针故障。 如果    控制函数循环不再被 它监控、它无法重新加载看门狗间隔计数、那么这仍然会触发看门狗第一超时标志。

我想知道  是否可以或如何在 双狗 小组中建立第二个看门狗来观看第一个看门狗、或者通过执行该操作可以获得任何东西。

[引用 user="BP101"]

Robert Adsett

这与我所说的完全不同、甚至不是错误的。

[/报价]

不

[引用 user="BP101"]在 上面提供的线程链接中 ，您说  有一个软件看门狗，您在想什么？

如果仔细阅读、您会看到所有内容都取决于硬件看门狗。 实际上、详细说明硬件看门狗和硬件看门狗的正常运行至关重要。

[引用 user ="BP101]]看门狗  外设所需的重新加载功能(踢脚、打脚、喂食)不是最后的麻烦、 而 是针对 SW 和 HW 故障进行一线防御。 [/报价]

这种方法会导致许多与实际所需性能几乎没有关系的调试项目出现问题和无效的时间。

[引用 USER="BP101]TM4C1294数据表 确实列出了所有指令、但未能指示 与时钟节拍相关的任何时序。  [/报价]

这是有道理的、时钟周期计时是软件问题。

[引用 user="BP101]\n 我维护的计算机系统在 主 处理器板上有一个无缝看门狗、 这是如何防止(  S100)总线架构中出现其他系统处理器板故障的原因。  或者看门狗从未触发、

在正确构建的成熟系统中、看门狗应该(几乎)永远不会触发。 如果看门狗触发、那么根据定义、这是一个严重的问题。

[引用 user="BP101"]执行代码快速的可能动机似乎表明程序 栈故障或 在  看门狗外设重新加载计数时间窗口之外发生指令指针故障

以下是您唯一的建议？

[引用 user="BP101"]我想知道  是否可以或如何制作第二个看门狗  来观看双狗组中的第一个看门狗，或者是否可以通过执行该操作获得任何内容。

您可以实现单独的独立看门狗。 这样做可能会发现振荡器故障等问题。 我没有这样做、但我可以想象、有些系统需要多个看门狗。

Robert

[引用 user="Robert Adsett"] BP101 TM4C1294数据表 确实列出了所有指令，但未能指示 与时钟节拍相关的任何时序

[引用 user="Robert Adsett"]这很有意义，时钟周期计时是一个软件问题。

这是一个问题   、因为其他处理器通常会列出相对于多个系统时钟的每个指令持续时间。  了解函数指令正在执行的唯一方法是通过 debug 反汇编视图、将源代码链接到窗口。  回想一下过去的某个地方看到的 Thumb 指令时间。 也许这 是一个 Wiki 页面、因为它们不在 ARM Cortex 参考手册中、 只有少数几条指令指示周期时间。

[引用 user="Robert Adsett">您可以实现单独的独立看门狗。 这样做可能会发现振荡器故障等问题。 我没有这样做、但我可以想象、有些系统需要多个看门狗。

我 目前在 同一个函数中有两个狗失效处理程序、测试 外设 IRQ 状态 以了解哪个 狗 失效。 现在有一只狗  在执行监控多项功能的所有工作、但 两只狗 可能 比一只更好、至少 看起来是这样。 奇数部分是 在第二个超时复位 MCU 的默认设置、即 在总线故障上将 SWRST 置为有效 、但 在发生这种情况时、计数未通过 SW 函数重新加载。

        当启用时、似乎有一个 SYSCTRL 内置的狗(心跳)来检查 APB/AHB/CPU 并调用 SYSCRTL 部分中与看门狗外设默认行为相关的读取文本。  同一个看门狗(复位 MCU) 也随机导致 ICDI 获取 DAP 控制问题。  在第二个超时时禁用复位 MCU 后、DAP 行为停止。 因此、看门狗似乎 也可以是系统控制优先级、无需 重新加载 计数间隔。

看    门狗失效处理程序函数在 计时器过期但不触发 第1或第2个超时时时时、会持续被看门狗外设挤占。 智能看门狗 似乎知道  、在应用程序传输重新加载计数后、过期 IRQ 标志 在 NVIC 中有效。  这将建议 递减计数计时器 自动重新加载 系统默认计数、如果  SW 不馈送狗、则可能在总线有控制权时达到零。 另外，看着狗只死了，没有心跳。

[引用 user="BP101"] BTW：刚刚发现用于 复位看门狗重新加载值的 Tivaware SysCtlClockGet ()函数通常(过去)对 TM4C123有效、TM4C1294不支持该函数。

您的"发现"已经 "早已为人所知！"    将"辅助函数"更改为"SysCtlClockGet ()..." "SysCtlClockSet()-也在'129!     因此、您/其他129个用户-使用全新的系统时钟频率设置功能！

我们被告知 (任何) "青年喷泉"(静止)正在等待您(最新)的发现...   

这里有一些人继续认为你的"观点"是， "如上所述"： "SysCtlClockGet ()"的无效 -- --"刚刚发现"。   您之前的"发现帖子"-没有提及编译器问题-似乎"错过了"系统时钟更改的"巨大"！

如果您非常感兴趣- Amit 处理了许多此类"系统时钟问题"-由"Changed Functions"引起-由"129要求。    搜索框-顶部-等待您的"单击"栏。

BTW -您"执行"...  看起来更年轻。   您的(其他)发现是否(更好)跨越了？

[引用 user="BP101"]

BTW：刚刚发现的用于复位看门狗重新加载值的 Tivaware SysCtlClockGet ()函数仅对 TM4C123有效、TM4C1294不支持。

[/报价]

这就是我编写这样的函数的原因：

struct GlobalData｛
uint32_t SysClockFreqHz；//实际系统时钟频率、单位为 Hz

bool HaveSysClockPllVco；//如果 pllVco 包含有效值、则为 true
//如果未获得 PLL VCO、则为 false、不能为
//获得，和/或 PLL 不被使用

uint32_t SysClockPllVco；//系统前 PLL VCO 的计算值
//应用从 TivaWare 获取的分频器
// SysCtlVCOGet ()

//此处的其他全局数据
。
。
。
｝；


struct GlobalData Global；


static void SetUpSystemClock (void)
｛
#if defined (part_TM4C129ENCPDT)
map_SysCtlMOSCConfigSet (SYSCTL_MOSC_HIGHFREQ)；

Global. scClockFreqHz =
MAP_SysCtl&ClockFreqSet (
SysCtl_XSC_XCLT_SYSCL

















)| SYSC_UST_SYSCL = SYCLUST_SYSC_CLUST_SYSCL (#SYSC_CLUST_SYSCL)| SYSC_CLUST_CLUST_VCLUST_SYSC_CLUST_SYSC_CLUST_CLUST_CLUST_SYSC_CLUST_SYSCL = SYSCL = SYSCL = SYSCL = SYSCL = SYSC_CLUST_CLUST_SYSC_CLUST_SYSC_CLUST_CLUST_SYSC_CLUST_SYSC_CLUST_SYSC_CLUST_CLUST_SYSC_CLUST_SYSC_CLUST_SYSC_CLUST_SYSC_CLUST_SY



global.HaveSysClockPllVco = false；
Global. SysClockPllVco = 0；

#else
#error "未设置系统时钟！"

#endif

(Global. SysClockFreqHz =0)｛
//无法设置系统时钟！
(笑声) 处理此错误...}

｝

这封装了行为、但更重要的是、它编纂了"知识"、即 TM4C123和 TM4C129上的系统时钟设置不同。

我编写了这样的函数来处理各种不同的情况、包括在不同芯片中 UDMA 信号如何完成等

它使用编译时检查来根据项目层的 PART_*定义集选择适当的代码。

此代码可能不会按原样使用。 您需要针对您的 MCU 和电路板进行定制。 我发布它是为了说明构建此类函数的"库"的总体想法、这样您就不需要记住所有这些小细节、而是需要使用大量 ifdef 语句来整理您的程序。 只有封装功能才需要如此杂乱。

[引用 user="BP101"]

Point 是指编译器在标记错误时保持沉默、否则、具有 MCU 变体或符号向链接器指示 MCU 的点是什么。 SysCtlClockGet ()的断言也应该已经标记了 CCS 代码分析器警告、但是它仍然保持沉默。

奇怪的是、编译后的代码似乎可以工作、或者至少没有引起任何明显的问题。

[/报价]

编译器不能也不会标记任何类型的错误。 编译器工具链仅知道如何将您在 C 语言中编写的代码转换为机器代码。 当您调用一个函数时、不管该函数是否被 MCU/板"允许"、编译器都无法知道、也不在乎。 它会生成代码来调用该函数。

您*只能*获得编译器错误的方法是为每个芯片自定义构建 TivaWare 库，但不包括该芯片不允许的函数。 然后、当代码尝试进行该调用时、编译器和/或链接器将无法找到该函数、因此会标记错误。

我发现 TivaWare driverlib 函数的注释非常好。 当您调用任何 TivaWare 函数时、首先查找其定义并阅读说明非常重要！ 我不确定这是否是100%的时间、但到目前为止、只要我需要调用一个仅适用于某些 TM4C 器件而不适用于其他器件的函数、函数文档中就会显示这一点。 大多数功能都是短的、并且大多数功能分配一个或多个外设控制寄存器。 因此、您需要查看数据表、并确保存在寄存器、并实现寄存器中的特定位。 如果是、则该函数将起作用。

我可以... *** 喜欢 ***  两篇文章-非常棒。

尤其是您的措辞： "如果 PllVco 包含有效值、则为 true - 如果未获取 PLL VCO、无法获取、和/或未使用 PLL、则为 false。    最优秀的-(详细和阅读-就像法律简报)

供应商变更会给其用户带来(大量)额外的认知、在您的情况下还会付出额外的努力。    您的方法"is"是补偿此类更改的一种方法-但可能会被(进一步)供应商更改引发(某些)混乱-下游。

一般而言、您想知道如何(类似地)管理(而不是极端的) I2C 模块所要求的(扩展的)代码更改。   ("背靠背"(反转)就绪检查已确认失败-在某些情况下！    "真正的解决方案"早就"看起来很有序"了。)  

很好的工作-非常感谢-出色的内容和演示...  (我相信员工会有裂缝)

[引用 USER="CB1_MOBILE"]

我可以... *** 喜欢 ***  两篇文章-非常棒。

[/报价]

谢谢你。

[引用 USER="CB1_MOBILE"]

尤其是您的措辞： "如果 PllVco 包含有效值、则为 true - 如果未获取 PLL VCO、无法获取、和/或未使用 PLL、则为 false。    最优秀的-(详细和阅读-就像法律简报)

[/报价]

如果这是一份法律简报，它将会更像这样： "如果 PLL VCO 因任何原因不可用、包括但不限于故障和/或无法使用和/或获取 PLL VCO 和/或由于技术或法律原因、许可、侵权、疏忽、神的行为、不必要也不可用、则为 false、 和/或任何其他已知或后来形成的法律理论。"

[引用 USER="CB1_MOBILE"]

供应商变更会给其用户带来(大量)额外的认知、在您的情况下还会付出额外的努力。    您的方法"is"是补偿此类更改的一种方法-但可能会被(进一步)供应商更改引发(某些)混乱-下游。

[/报价]

这就是为什么 ifdef 逻辑仅测试我们所使用的几个部件、如果该部件是其他部件、则会生成编译器错误并停止编译。 将来、如果较新的 TM4C 系列器件添加任何必须处理的新器件、我们将需要实施其他案例。 然而，一旦实施，知识再次被编纂成文，我们不再需要记住。

[引用 USER="CB1_MOBILE"]

一般而言、您想知道如何(类似地)管理(而不是极端的) I2C 模块所要求的(扩展的)代码更改。   ("背靠背"(反转)就绪检查已确认失败-在某些情况下！    "真正的解决方案"早就"看起来很有序"了。)  

[/报价]

简而言之：我们没有。 我们尚未将 I2C 与 TM4C 搭配使用。 过去、我们在使用 I2C 硬件构建的电路板上遇到了问题、主要(我认为)源自与正在使用的 MCU (不是 TI MCU)的 I2C 外设相关的勘误表。 这方面的软件支持似乎是某种黑暗的魔法、在这种情况下 I2C 总线仍会"卡住"。 至少可以说，这是一种拉头发的运动。 我想我们最终用 SPI 部件重新制作了这些板。

[引用 user="12ve12pm"]这就是为什么 ifdef 逻辑仅测试我们使用的几个部件[/引用]

而且-对于设计和/或流程变化、"不未知"会影响那些(非常)"您正在使用的器件！"    在这些条件下、"ifdef"证明是无助的-在您的救援中...    (最近发生过这种情况@我公司发现的另一家 MCU 供应商认为您会从这种意识中获益。)    并非所有防御都能证明， "永远"成功！

[引用 user="12ve12pm "]

[引用 user="BP101"]

Point 是指编译器在标记错误时保持沉默、否则、具有 MCU 变体或符号向链接器指示 MCU 的点是什么。 SysCtlClockGet ()的断言也应该已经标记了 CCS 代码分析器警告、但是它仍然保持沉默。

奇怪的是、编译后的代码似乎可以工作、或者至少没有引起任何明显的问题。

[/报价]

编译器不能也不会标记任何类型的错误。

[/报价]

它可以而且，海事组织应该这样做。 这是正确完成库的问题。 可以说、即使是检查的必要性也是图书馆决策不当的问题、但这是另一天的问题。

一种简单的方法、如果有点难看、则遵循以下几行

#ifdef supported_processor
#define function (a、b)(function)((a)、(b)
)#else
#define function (a、b)_function_function_not _supported ()
#endif 

我可能会努力想出更干净的东西。 我可能不会、预处理器有点简陋。

第二种方法是从通过宏替换的角度重新定义原始函数。

也可以选择 PC-lint (您的线性不是您？) 提供弃用函数的机制。

不管完成了、TI 应该已经完成了。

Robert

[引用用户="Robert Adsett"]

12时12分

BP101

Point 是指编译器在标记错误时保持沉默、否则、具有 MCU 变体或符号向链接器指示 MCU 的点是什么。 SysCtlClockGet ()的断言也应该已经标记了 CCS 代码分析器警告、但是它仍然保持沉默。

奇怪的是、编译后的代码似乎可以工作、或者至少没有引起任何明显的问题。

编译器不能也不会标记任何类型的错误。

它可以而且，海事组织应该这样做。 这是正确完成库的问题。 可以说、即使是检查的必要性也是图书馆决策不当的问题、但这是另一天的问题。

一种简单的方法、如果有点难看、则遵循以下几行

#ifdef supported_processor
#define function (a、b)(function)((a)、(b)
)#else
#define function (a、b)_function_function_not _supported ()
#endif 

我可能会努力想出更干净的东西。 我可能不会、预处理器有点简陋。

第二种方法是从通过宏替换的角度重新定义原始函数。

也可以选择 PC-lint (您的线性不是您？) 提供弃用函数的机制。

不管完成了、TI 应该已经完成了。

Robert

[引用 user="12ve12pm"]但其中没有一个使您无需了解编写软件的硬件。

我不能忘记(任何人)在这里-争辩说、 "最大限度地减少硬件的掌握"。    某种程度上、最后一句似乎"打破"了您的其他回答、组织有序。

[引用 user="12ve12pm"]这是一个库设计。

是的、您也必须使您的设计功能强大、但如果库设计正确、编译器可以检测此类内容。

编译器还可以检测参数不匹配等其他内容。 但是、如果该库设计为几乎所有内容都使用单个类型(例如 uint32_t)、那么您将失去大量该功能。 这并不意味着编译器无法检测到问题、这意味着库已经使编译器的功能受阻。

[引用 user="12ve12pm"]替代方法是为每个 MCU 型号构建单独的库副本。

你可以、但我认为这里的变体不需要、甚至特别喜欢它。 当然、有一个系统会执行该操作。

[引用 user="12ve12pm"]您可以在上述函数中放置断言语句，该语句将具有在 while (1)循环中锁定代码的效果，或者转到 FaultISR ()或其他内容(如果使用 debug 进行编译)。

但这会失去编译时间(或更早版本)检测的优势。 您检测问题的时间越早、查找和修复问题就越容易。

在早期检测中更有用的是 TDD 设置、它检测到库中的块不匹配的处理器。 不过、我认为我们还不够接近拥有一个常见的 TDD 设置。

[引用 user="12ve12pm"]但其中没有一个使您无需了解编写软件的硬件。

不会、但编译器会帮助查找库是否是为了利用标准编译器用法而构建的、并且在某些情况下不会主动针对编译器工作。

Robert

实际上、如果被调用的函数包含 针对特定 MCU 类 类型的断言测试、CCS 代码分析器将/应该标记 A (警告)。  同样、编译器 应 在编译或链接期间为相同的断言测试抛出和(错误)。 如果函数被称为其他特定于类的函数   、则通常会对 MCU 类类型进行断言测试。

请注意 、此类测试位于标头区域下方、但即使 在具有 Code Analysis   的 CCS7.3中也无法发出警告/错误、请使用工作区设置并在键入 set 时运行。 这就是下面的断言的作用、并且未能为包含的工程符号 (class_is_TM4C129)标记不匹配的警告。

uint32_t SysCtlClockGet (void)｛

uint32_t ui32RCC、ui32RCC2、ui32PLL、ui32Clk、ui32Max；

uint32_t ui32PLL1；

////此函数仅在 TM4C123器件上有效。

断言(class_y_IS_TM4C123)；

断言(class_is_TM4C123)；符号丢失/不匹配也 不会通过将 Code Analyzer 设置为在编译期间运行来检查。 因此、Tivaware 库断言器件类测试无效、对于任何认为它们是安全的人来说、都是误导性的、因为怪物会在黑暗角落里发生。

[引用 user="12ve12PM">我发现 TivaWare driverlib 函数的注释非常好。 当您调用任何 TivaWare 函数时、首先查找其定义并阅读说明非常重要！ 我不确定这是否是100%的时间、但到目前为止、只要我需要调用一个仅适用于某些 TM4C 器件而不适用于其他器件的函数、函数文档中就会显示这种情况

适用于开发新项目 、但在将现有项目从一 个 MCU 类迁移到另一个 MCU 类时并不那么好。    对于 TI 从未从 TM4C123 MCU 迁移到 TM4C1294示例项目并将其放置在 TM4C129xx 名称文件夹中的所有 TM4C1294示例项目、情况如何？

这就是编译器交叉检查对 Tivaware 库的调用中的符号的原因、它充分利用 断言 来识别标头下的 MCU 类。

 编译期间没有警告/错误的一个原因可能是工程定义的库路径 是寻找 编译 的驱动程序对象 、而不是  文件夹中的实际 Tivaware 驱动程序。  Amit 在一段时间前提到 CCS 调试要求  必须编译 Tivaware 项目源驱动程序库、 我认为 这是为了对 库源 代码进行故障跟踪。  

 这个来自 SysCtlClockGet ()点的线程应该被放置在另外一个帖子中、这样我们就可以研究 Tivaware 函数断言为什么不能警告 CCS 用户。

[引用 user="BP101"]

12时12分

我发现 TivaWare driverlib 函数的注释非常好。 当您调用任何 TivaWare 函数时、首先查找其定义并阅读说明非常重要！ 我不确定这是否是100%的时间、但到目前为止、只要我需要调用一个仅适用于某些 TM4C 器件而不适用于其他器件的函数、函数文档中就会显示这一点

适用于开发新项目 、但在将现有项目从一 个 MCU 类迁移到另一个 MCU 类时并不那么好。

[/报价]

不要让我开始了解从一个 MCU 移植到另一个 MCU 的"乐趣"！

我要说、由于我们为 TM4C129和 TM4C123编写了一个代码库、是的、有一些差异导致我们遇到一些" gotchas！" 在这一过程中、使用 TivaWare API 的过程要比使用旧样式的寄存器时容易得多。 在其他项目中、当从一个 MCU 迁移到另一个 MCU 时、我通常需要从头开始重新编码主要部分、因为这实际上比两个 MCU 的数据表都打开更快、 识别填充到每个寄存器中的每个位在一个器件上意味着什么、并尝试将其转换为另一个器件。 代码重用的整体理念是实际重用您的代码！ TivaWare API 显著缓解了这一难题。

如果能够在 CCS 中运行代码分析器来识别我们正在调用的 API、我们不应该这样做、因为它们与我们的 MCU 不匹配、那就太棒了！ 但是、某些事情让我怀疑它是否能够实际工作、因为 TivaWare 断言和 MCU 类定义在运行时解析、而不是由编译器解析。

[引用 user="BP101"]

 编译期间没有警告/错误的一个原因可能是工程定义的库路径 是寻找 编译 的驱动程序对象 、而不是  文件夹中的实际 Tivaware 驱动程序。  Amit 在一段时间前提到 CCS 调试要求  必须编译 Tivaware 项目源驱动程序库、 我认为 这是为了对 库源 代码进行故障跟踪。  

[/报价]

如果、在单步执行代码时、您希望单步进入 TivaWare 代码、那么是的、您需要使用项目编译 TivaWare、以使调试器获得调试信息。 否则、您只能单步进入 asm 代码、而不会看到转换为该代码的代码。

编译 TivaWare 还有其他好处吗？

[引用 user="BP101"]

 这个来自 SysCtlClockGet ()点的线程应该被放置在另外一个帖子中、这样我们就可以研究 Tivaware 函数断言为什么不能警告 CCS 用户。

[/报价]

同意。 这肯定已经脱离了原来的话题。