[参考译文] TM4C1294NCPDT：ROM 与闪存 SSI/SPI Tivaware API#39；s - shouldn#39；t ROM 版本是否更快？

admin

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/601560/tm4c1294ncpdt-comparison-of-rom-vs-flash-ssi-spi-tivaware-api-s---shouldn-t-rom-version-be-faster

器件型号：TM4C1294NCPDT
主题中讨论的其他器件：冲击

研究员，

下面的代码通过 SPI 端口读取两组连续的32位、其中 CSB 由 GPIO 控制、时钟设置为7.5MHz。需要11.44us。 Tivaware 函数编译到闪存、无优化。

IntMasterDisable()；
GPIOPinWrite (gyroHW->GPIOFSSPort、gyroHW->GPIOFSSPin、0)；//降低 CSB
SSIDataPut (gyroHW->SSIBase、frameHigh)；//仅发送高16位
while (SSIBusy (gyroHW->SSIBase))；//清零前16位
SSIDataGet (gyrohw->SSIBase、readCrap)；//读取无用数据
SSIDataPut (gyroHW->SSIBase、(frameLow))；//这会发送其他16位
while (SSIBusy (gyroHW->SSIBase))；//刷新第二个16位
GPIOPinWrite (gyroHW->GPIOFSSPort、gyroHW->GPIOFSSPin、gyroHW->GPIOFSSPin)；//提升 CSB
SSIDataGet (gyrohw->SSIBase、readCrap)；//读取无用数据
GPIOPinWrite (gyroHW->GPIOFSSPort、gyroHW->GPIOFSSPin、0)；//降低 CSB
SSIDataPut (gyroHW->SSIBase、frameHigh)；//刷新第三个16位
while (SSIBusy (gyroHW->SSIBase))；//等待位被清空
SSIDataGet (gyroHW->SSIBase、read16High)；//读取16位
SSIDataPut (gyroHW->SSIBase、frameLow)；//刷新最后16位
while (SSIBusy (gyroHW->SSIBase))；//等待位被清空
SSIDataGet (gyrohw->SSIBase、read16Low)；//读取更多数据
GPIOPinWrite (gyroHW->GPIOFSSPort、gyroHW->GPIOFSSPin、gyroHW->GPIOFSSPin)；//提升 CSB
IntMasterEnable()；

而具有直接从 ROM 调用的所有 API 的确切版本需要12.22us。

IntMasterDisable()；
ROM_GPIOPinWrite (gyroHW->GPIOFSSPort、gyroHW->GPIOFSSPin、0)；//降低 CSB
ROM_SSIDataPut (gyroHW->SSIBase、frameHigh)；//仅发送高16位
while (ROM_SSIBusy (gyroHW->SSIBase))；//刷新前16位
ROM_SSIDataGet (gyroHW->SSIBase、readCrap)；//读取无用数据
ROM_SSIDataPut (gyroHW->SSIBase、(frameLow))；//这会发送其他16位
while (ROM_SSIBusy (gyroHW->SSIBase))；//刷新第二个16位
ROM_GPIOPinWrite (gyroHW->GPIOFSSPort、gyroHW->GPIOFSSPin、gyroHW->GPIOFSSPin)；//提升 CSB
ROM_SSIDataGet (gyroHW->SSIBase、readCrap)；//读取无用数据
ROM_GPIOPinWrite (gyroHW->GPIOFSSPort、gyroHW->GPIOFSSPin、0)；//降低 CSB
ROM_SSIDataPut (gyroHW->SSIBase、frameHigh)；//刷新第三个16位
while (ROM_SSIBusy (gyroHW->SSIBase))；//等待位被清空
ROM_SSIDataGet (gyroHW->SSIBase、&read16High)；//读取16位
ROM_SSIDataPut (gyroHW->SSIBase、frameLow)；//刷新最后16位
while (ROM_SSIBusy (gyroHW->SSIBase))；//等待位被清空
ROM_SSIDataGet (gyroHW->SSIBase、read16Low)；//读取更多数据
ROM_GPIOPinWrite (gyroHW->GPIOFSSPort、gyroHW->GPIOFSSPin、gyroHW->GPIOFSSPin)；//提升 CSB
IntMasterEnable()；

不是这样会使任何人丧生、而是所有迄今为止的讨论和文档都意味着 ROM 调用速度更快。是否有任何想法作为上述结果的原因？

此致

布鲁诺

8 年多前

0 admin 8 年多前

TI__Guru**** 2333840 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您的"ROM 与闪存"列表似乎已被撤销！ (顶部代码列表被描述为、"闪存"-然而所有调用都是 ROM！)

使用"绝对"时要小心(即"所有讨论和文档...") 这显然是不真实的！ (您真的没有搜索-然后查看 "全部"-所以评论是毫无根据的、不正确！) Amit 撰写了几篇文章、描述了通过 ROM 调用体验到的"限制"(有时)...

有人指出、存在 ROM 函数要求的"开销"、这些开销不存在闪存调用！和、"类型、大小、甚至是代码/函数"放置"(位于 ROM 中)-所有这些都被证明会影响代码执行。 (对讨论/文档进行更彻底的审查可能会揭示(如何/何时/何地) ROM 调用的"最佳"性能。)

它证明了"好"、即"运行此类比较测试"-但"不好"、您得出的结论可能依赖于"绝对" (全部) 、并且可能存在事实错误... (信贷 UCLA 法律)

并进一步详细说明 SPI 从器件的"谋杀"-通过8+MHz SPI 时钟-(通过 PM 进行通信)。

0 admin 8 年多前

TI__Guru**** 2333840 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

[报价 USER="CB1_MOBILE "]您的"ROM 与闪存"列表似乎已被撤销！ [/报价]

对。固定的！

我们找到了有关该主题的讨论、从中有一些很好的见解。

e2e.ti.com/.../1010015

[引用 user="CB1_mobile "]"所有讨论和文档...") 这显然是不真实的！[/引述]

注意到。这就是校对、修订和 cb1s 的作用！我的发言是基于两个思路。首先、从 Tivaware UG 复制以下文本：

"为了获得更好的精度、可以使用此函数的 ROM 版本。该版本不会受到与闪存和完美缓冲器相关的时序变化的影响、但仍会因中断服务例程而延迟。"

接下来，我本人根据上述情况多次在这里的文章中为空间和速度使用基于 ROM_的函数辩护。到目前为止，没有人纠正过，以至于我把它作为一个坚实的事实。感谢您指出这一点、CB1。

结论是 ROM 调用可能会更小、但不一定更快(我看到、第二个函数在很大程度上取决于我们所讨论的函数以及系统上的其他"不可预测变量")。作为一篇文章、实际上是为了发起讨论和学习、我要说、目的是实现的！

布鲁诺

0 admin 8 年多前

TI__Guru**** 2333840 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您好 Bruno - et、"Merci Beago"。

对于那些想要 (进一步)"在技术(如果不是热的)时罢工的邪恶者(即追求利润的小技术公司)，不要休息，至少要“暖”。 (04：00 -在"联合"中-设置和准备"周末迷"(观看时钟)裂缝 crüe。)

我相信你基于多个变量(一些变量并非总是很容易预测)的"扩大结论"(承认"性能差值"的可能性)最能为你服务。而且-您已经了解(并且很好地接受)、"证据的可接受性和接受性规则"可能会在审判室之外"接触"。 (只有这些"事实"(经过早期筛选和批准)可用作"证据"。)

如果您有兴趣-可能会证明您具有深刻见解：

重复测试-但首先放大代码列表("复制/粘贴"您的代码10x)-然后测量/比较/对比度
重复您的测试(多次)、但(现在)针对不同的 MCU 外设-注意潜在的变化(如果有) (在过去-我们测试并注意到这种情况...)
为了防止"其他"(影响)程序元素(在原始代码环境中运行此类测试)受到(不受"外部"影响)的(不受此类影响)入侵。 (即中断、RTOS 等)
不同的系统时钟会改变性能(即4C123为40MHz 及以下)-可能会证明对"运行-测量-和记录"很有用

是否存在"通用真理"(即 ROM 函数始终优于闪存-在执行速度和存储器占用空间方面)、这样的"特性"和提升不能更好？ (许多用户都是工程师-比较表(以某种方式)"请记住"。然而，由于认识到所产生的"可变性"，也许"很少"(也许没有)。 (不明智地使用"绝对"！)

BTW -您提供的"MCU 手册部分"未特别说明通过 ROM 调用实现的"执行速度"优势。 (改为使用(套头)"时间可变性") 您的结论(可能)证明是有效的、但并非"确定的"、并且在"每种/每种"操作条件下"有效"。

所以-结论是至关重要的-作为伟大的"指南柱"-并且可能(甚至)受益于"在(其他、更严格)学科中常用的方法！" (特别是那些：享有法律地位/规则、且在(真实)工程诞生之前已经发展过！)

基于 Arm 的微控制器（参考译文帖）

基于 Arm 的微控制器（参考译文帖）(Read Only)

[参考译文] TM4C1294NCPDT：ROM 与闪存 SSI/SPI Tivaware API#39；s - shouldn#39；t ROM 版本是否更快？