• 状态 Resolved
  • 已锁定 已锁定
  • 回复 17 回复
  • 订户 0 订户
  • 视图 815 视图
  • 用户 0 会员在此处
选项
选项
相关

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] EK-TM4C1294XL：异常大的中断延迟

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

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/605340/ek-tm4c1294xl-unusually-large-interrupt-latency

器件型号：EK-TM4C1294XL

大家好、

我一直在尝试从 ADS1274EVM 接收 SPI 信号到 TM4C1294XL。 为此、我已将来自 ADC 的/DRDY 信号的下降沿配置为微控制器的中断(GPIO 端口 F)。 在执行此操作时、我发现延迟非常大、即6-7us、而它应该在1us 附近(120MHz 系统时钟的12个周期)。 我还将中断优先级设置为最高、尽管它不应产生影响、因为 GPIOF 中断是我定义的唯一 ISR。 我的代码如下所示、如果有人有任何建议、我将不胜感激。 下面给出了我的逻辑分析仪的一些代码片段和输出。

为中断设置 GPIOF： 

// DRDY 反转的引脚 F4设置
SysCtlPeripheralEnable (SYSCTL_Periph_GPIOF)； //启用端口 F
GPIOPinTypeGPIOInput (GPIO_PORTF_BASE、GPIO_PIN_0)；//初始化 PF0作为输入

//中断设置
GPIOIntDisable (GPIO_PORTF_BASE、GPIO_PIN_0)； //为 PF0禁用中断(如果已启用)
GPIOIntTypeSet (GPIO_PORTF_BASE、GPIO_PIN_0、GPIO_FALLING_EDGE)； //为下降沿触发配置 PF0
GPIOIntClear (GPIO_PORTF_BASE、GPIO_PIN_0)； //清除 PF0的挂起中断
GPIOIntRegister (GPIO_PORTF_BASE、GPIOPortFIntHandler)； //为端口 F 注册 ISR
IntPrioritySet (INT_GPIOF、0)； //设置中断优先级
GPIOIntEnable (GPIO_PORTF_BASE、GPIO_PIN_0)； //为 PF0启用中断

我的 GPIOF 中断服务例程 

//中断服务例程(ISR)或中断处理
程序 void GPIOPortFIntHandler (void)
｛

//清除 GPIO 中断
GPIOIntClear (GPIO_PORTF_BASE、GPIO_INT_PIN_0)；


//逐个填充缓冲区元素；收集64位
SSIDataPut (SSI1_base、DummyData)；
SSIDataGet (SSI1_base、&pui32DataRxBuffer[0])； //获取前16位[111：96]
SSIDataPut (SSI1_base、DummyData)；
SSIDataGet (SSI1_base、&pui32DataRxBuffer[1])； //获取第二个16位[95：80]

//为2个通道添加下面的块
SSIDataPut (SSI1_base、DummyData)；
SSIDataGet (SSI1_base、&pui32DataRxBuffer[2])； //get 第三个16位[79：64]
SSIDataPut (SSI1_base、DummyData)；
SSIDataGet (SSI1_base、&pui32DataRxBuffer[3])； //获取第四个16位[63：48]

//为3个通道添加下面的块
SSIDataPut (SSI1_base、DummyData)；
SSIDataGet (SSI1_base、&pui32DataRxBuffer[4])； //get 第五个16位[47：32]

//为4个通道添加下面的块
SSIDataPut (SSI1_base、DummyData)；
SSIDataGet (SSI1_base、&pui32DataRxBuffer[5])； //获取第六个16位[31：16]
SSIDataPut (SSI1_base、DummyData)；
SSIDataGet (SSI1_base、&pui32DataRxBuffer[6])； //get 第七个16位[15：0]

//合并和连接元素以获取通道1和2
pui16DataRx0[计数器]=((uint16_t)(pui32DataRxBuffer[0])<< 1)|((uint16_t)(pui32DataRxBuffer[1])>> 15)；

//pui16DataRX1[计数器]=((uint16_t)(pui32DataRxBuffer[1])<< 9)|((uint16_t)(pui32DataRxBuffer[2])>> 7)；
//pui16DataRX2[计数器]=((uint16_t)(pui32DataRxBuffer[3])<< 1)|((uint16_t)(pui32DataRxBuffer[4])>> 15)；
//pui16DataRx3[计数器]=((uint16_t)(pui32DataRxBuffer[4])<< 9)|((uint16_t)(pui32DataRxBuffer[5])>> 7)；

//计数器更新
if (counter < input_vector_size - 1)｛counter++；｝ //递增计数器，只要它低于4999
否则｛COUNTER = 0；｝ //如果计数器为4999、则将计数器重置为零
while (SSIBusy (SSI1_base))｛｝

｝

逻辑分析仪输出


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

    我是否可以注意到以下几点？

    • 您在 D_RDY 的下降沿中断-但如果切换到上升沿-中断将更快发生！  (通过 D_RDY 的脉冲宽度) 目标是响应、而不是真正的延迟度量！
    • 您"注册"中断-而不是将其放在 MCU 的"矢量表"中-我认为-可以实现更快的响应
    • 您将中断的时间设置为"清除"-加上函数的执行时间"SSIDataPut ()"-并将"这两个延迟"分类为中断延迟！    GPIO 切换不会像前面提到的处理程序中的第一条指令那样提供中断延迟的"真实情况"？

    当运行速度超过特定速度时- MCU 是否会遭受更多 的"等待状态"和/或其他"严重影响？"

    除了上述内容之外、我会(理想情况下)切换到另一个端口、并确定所选端口和引脚是否会产生"延迟损失"。

    我同意您的计算结果、并认为您可以改进结果...

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

    CB1的答案很好！

    其他一些指针：

    -在清除特定中断时要小心、例如 GPIOIntClear (GPIO_PORTF_BASE、GPIO_INT_PIN_0)；-最好先读取中断屏蔽、然后清除所有中断。 如果代码增长并添加其他引脚作为中断源、即使噪声触发中断、您也会陷入 ISR 重新进入循环中。

    -不仅整个 SSI 命令集不是延迟、而且将所有这些内容保留在中断中也是不好的。 最好在 ISR 内部设置一个控制标志、然后在主执行期间处理 SSI 通信。

    [引用 user="Stefan Manoharan"]在1us 附近(120MHz 系统时钟的12个周期)[/quot]

    实际上、该时间量与120个周期相关。

    (Saleae 在这里获得了大量免费广告...)

    PS：如果由于某种原因，您试图在值可用并由/DR 线路发出信号后“尽快”读取转换器，也许您应该考虑轮询。 不过、该"浪涌"可能对整个系统没有影响、因为 AD 转换器的最大速率为每秒144K 样本。 还有其他阶段会影响您的测量(包括您将对所有这些样本执行的任何数字处理、如果有)。

    布鲁诺

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

    [引用 USER="CB1_MOBILE "]通过查看 TivaWare_C_Series-2.1.4.178源代码、可以看到 GPIOIntRegister ()函数确实将中断处理程序放置在 Cortex-M4的"矢量表"中、可以"注册"中断、而不是将其放置在 MCU 的"矢量表"中； GPIOIntRegister()更新 RAM 中的向量表。 其中、对 IntRegister 函数的第一次调用会将矢量表从闪存复制到 RAM。 因此、使用 GPIOIntRegister()不会考虑观察到的大中断延迟。

    我自己还没有测量中断延迟、但发现之前的线程 TM4C129的最小 GPIO 中断延迟 、其中代码使用 了 GPIOIntRegister ()、在 CPU 时钟为120MHz 的 TM4C129上、测得的 GPIO 中断延迟大约 为230ns。

    通过查看发布的代码、我无法看到大型中断延迟的原因。

    有关原始海报的其他一些问题包括：

    a)是否已验证 CPU 频率设置为120 MHz？

    b) CPU 在等待中断时是否处于睡眠模式？

    c)主代码是否禁用/重新启用中断？

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

    [引用 USER="Chester Gillon"]因此，使用 GPIOIntRegister ()不会考虑观察到的大中断延迟。

    切斯特、

    您似乎必须与编写 Tivaware 用户指南的同事争辩：

    那么、以下哪项陈述是正确的？ 我希望在我们公司的代码中仅采用运行时注册、但上面的文本一直在使我们为每个项目编辑启动文件。

    布鲁诺

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

    [引用 user="Bruno Saraiva">您可能需要与编写 Tivaware 用户指南的同事进行争论感谢您向我介绍 Tivaware 用户指南的该部分内容。 老实说，我对 GPIOIntRegister()的使用的评论是，该函数没有给中断处理程序增加任何额外的软件开销。 即 GPIOIntRegister()不添加任何软件中断调度逻辑。 正如您提到的、我在将矢量表从闪存移动到 RAM 时没有考虑任何硬件开销。

    此外、由于我不是 TI 员工、因此无法直接与 Tivaware 用户指南的作者交谈。

    [引用 user="Bruno Saraiva">那么，以下哪项陈述是正确的？ 我希望在我们公司的代码中仅采用运行时注册、但上面的文本一直在使我们编辑每个项目的启动文件。 Tivaware 用户指南中的陈述对小延迟作出模糊的陈述、而不会量化延迟的预期值。

    ARM Cortex-M4 中断延迟 文档显示：

    [引用]当被访问的存储器没有应用等待状态时、从发出中断到执行 ISR 第一条指令的最大延迟为12个周期。 当 FPU 选项被执行并且一个浮点上下文被激活并且怠惰堆栈未被启用时、这个最大延迟被增加至二十九个周期。 要执行的第一条指令与栈推并行获取。[/quot]与栈推并行执行第一条中断处理程序指令的 ARM 文档表示在栈推送发生之前已发生了中断处理程序表获取、 这与 Tivaware 用户指南不符。 ARM 和 Tivaware 文档之间的差异表明、应该执行一个测量来查看闪存.vs 中矢量表的中断延迟差异 RAM。

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

    [引用 user="Chester Gillon"]由于我不是 TI 员工、因此无法直接与 Tivaware 用户指南的作者交谈。

    很抱歉、Chester、我的错。 您的柜台上有太多积分、因此我无法正确阅读您的资格！！！ 当然、我的信息基调对于 TI 员工更有意义。 我相信你会忽略这种荒谬的说法。

    不错的回复。 我的(长)待办事项列表中、最终尝试进行此类测量。

    布鲁诺

  • 0
    TI__Guru**** 2347060 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    答复----(现在)编号六----表明需要一个全新的衡量标准----即"O.P. 延迟！"
    从我们过去运行的测试中、使用矢量表和"启动文件"中的矢量表-同时使用 LX4F 和4C123 -实际上可最大限度地降低"中断延迟！"
  • 0
    TI__Guru**** 2347060 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    你好！ 感谢您的建议、这些都是优点。 很抱歉、回复时间太长了、我尝试了有关此帖子的所有建议(很多！ :-))

    [引用 USER="CB1_MOBILE "]

    • 您在 D_RDY 的下降沿中断-但如果切换到上升沿-中断将更快发生！  (通过 D_RDY 的脉冲宽度) 目标是响应、而不是真正的延迟度量！
    [/报价]
    在这种情况下、DRDY 上升沿仅发生在 MCU 提供的 SCLK 的负边沿、该 MCU 是 ISR 的一部分。 这就是中断必须下降沿的原因。
    [引用 USER="CB1_MOBILE "]
    • 您"注册"中断-而不是将其放在 MCU 的"矢量表"中-我认为-可以实现更快的响应

    [/报价]

    你是对的、我一直在 MCU 矢量表中放置处理程序。 现在、单独使用矢量表过去对计时器中断很有用、但出于某种原因、它不适用于 GPIO 中断。 出于某种原因、我很难理解代码、仅在向量表中定义了中断并在"寄存器"函数中调用中断时才起作用。

    [引用 USER="CB1_MOBILE "]
    • 您将中断的时间设置为"清除"-加上函数的执行时间"SSIDataPut ()"-并将"这两个延迟"分类为中断延迟！    GPIO 切换不会像前面提到的处理程序中的第一条指令那样提供中断延迟的"真实情况"？

    [/报价]

    我尝试了 GPIO 切换；我发现延迟仍然大约为5us。 进入 ISR 后 SCLK 启动的时间(即、由于清零和 DataPut 而产生的延迟)仅约为0.5us。 因此、我假设问题与实际调用处理程序的过程有关。

    [引用 USER="CB1_MOBILE "]

    当运行速度超过特定速度时- MCU 是否会遭受更多 的"等待状态"和/或其他"严重影响？"

    除了上述内容之外、我会(理想情况下)切换到另一个端口、并确定所选端口和引脚是否会产生"延迟损失"。

    [/报价]

    您意味着什么严重的影响？ 我对 MCU 非常陌生、我仍在尝试弄清楚它们是如何工作的。

    此外、我从端口 F 切换到端口 A、但不再在 DRDY 的下降沿生成 SCLK。 我可能必须检查那里有什么问题。 不同的端口是否具有不同的速度？ 我认为每个中断的基本延迟是12个周期、无论什么。

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

    [引用 user="Stefan Manoharan">不同端口的速度是否不同？ 我认为每个中断的基本延迟都是12个周期、无论什么。

    您的想法是正确的(正确执行的端口表现出类似的延迟。)    然而-如果 (某些)形式的损坏-或负载-被本地化为您的"最初选择的引脚"会怎么样？   这就是我通过不同的端口和引脚引导您"重复"的动机。    (我确实注意到"D_Rdy"上升时间令人满意-似乎可以"规避"不必要负载的任何影响。)

    现在、无论是公司还是我都不使用129xx MCU (更喜欢快得多、功能更强)、但我记得  当 MCU "超过"特定系统时钟速度运行时、所施加的"限制"(具体而言是添加的等待状态)的读数。   根据执行情况、可能需要降低系统时钟的速度、以实现更快的执行速度、但这在很大程度上是一种"平衡行为"、最好由您"更深入、更详细地阅读/审阅 MCU 手册"来决定。   (再说一次-我对该 MCU 不太感兴趣)

    您对不同中断性能的看法-基于"正在使用的外设"-已经逃避了我的发现。   您的 MCU 是否有"配备"单个 PIN 中断？"的端口   如果是、我相信您可以很好地重复您的测试、但在(那个)特殊端口上-并进行报告。   在此期间、如果时间允许、我将让员工对我们的"123 MCU"运行测试、看看我们是否可以复制您的"延迟测试结果"。

    您的回答是非常完整的-非常感谢您的回答-如果您的"发现"是真实的-应该在这里证明您的使用/价值...   请切换到我建议的"特殊"端口-并进行测试和建议。  谢谢。

    最后一个建议是-公司/我工作@法律/技术/财务的联系-我们认为最好"始终快速响应-甚至是简短的"、这样您的"联系人"就可以知道他们的信息已收到-并保证您的兴趣。   另一方面、"静默"可能被视为：消息未送达、接收器不感兴趣、接收器不努力、接收器"过载"-这些都不是"好！"   一个好得多的替代方案将建模、"亲爱的客户-谢谢您-我们已收到您的请求-员工正在收集和分析数据-将在"小时、天等"内返回给您。   在美国、千禧一代人口几乎普遍"有罪"、"等待完美的回应"、"为我们的客户付出代价"、而不是像我一样"透露"的所有人-在这里...  (即公司被"解雇"、不知道"为什么！")   谢谢。。。

  • 0
    TI__Guru**** 2347060 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您好、Bruno 和 Chester、

    我尝试仅使用矢量表、但当我注释掉 IntRegister 函数时、代码不会进入 ISR。 这很奇怪、因为每当我使用计时器中断时、我通常不必使用 IntRegister。 您是否知道 GPIO 等特定端口是否需要此功能？
  • 0
    TI__Guru**** 2347060 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    请"重新阅读"我的(Moments 以前)发布内容-建议您通过特殊中断功能端口"进行此类发现"或添加到知识库中。 谢谢你。  (这些研究员(很可能)在工作中--我也是如此--也许直到(稍后)才能够作出反应。   (这是我的状况-现在...)

    另一点-请选择一个与其他用法"隔离"的端口-以便我们最好确保(其他因素)不会混淆您的测试！   我必须告诉您、我们已经使用了 LX4F 和4C123、据我所知、从未/曾经使用过"Int Register"、因为我发现它增加了延迟、需要额外的关注/处理、这证明是不合理的！   我们始终通过 GPIO 端口中断-始终。

    [编辑]员工会"杀死我"-但它会让您中断-但却经历了"增加的延迟"-我"怀疑"我们过去的测试(详尽)做出了这样的测量！

    您是否启用了全部三个中断级别？   处理器、外设和独立中断？   (我是"赔率"、这是您错过的一个机会！)   一定要去   [编辑] 因为命运会有它- GPIO 没有"专用"外设类中断(这是我的语言/描述)-您会注意到计时器、PWM、QEI 等 所有这些都具有此类外设中断机制/分配...

    [编辑]#3 - 再说一次-我从未使用过 IntRegister 函数-并且我们的所有端口都正确地进行 GPIO 中断！   除非这是您的 MCU 中的限制(我们不喜欢/也不使用)。

    Linked 是我最近的一篇文章、其中详细介绍了"中断机械师"-应该证明(部分)使用/协助-祝您好运。

    e2e.ti.com/.../605306

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

    [引用 USER="CB1_MOBILE "]

    您是否启用了全部三个中断级别？   处理器、外设和独立中断？   (我是"赔率"、这是您错过的一个机会！)   

    [/报价]

    您的困难确实有利于您！ 是的、INT 寄存器函数确实是问题的发生器；我使用以下格式启动了中断(根据您的建议、启用所有三个中断级别)、以便获得3.15us 的初始延迟(我可以处理) 持续延迟约为1us -与我之前处理的6uS 延迟相比、这是一个巨大的改进！ 非常感谢您的帮助！ 

    //中断设置
GPIOIntDisable (GPIO_PORTF_BASE、GPIO_PIN_0)； //为 PF0禁用中断(如果已启用)
GPIOIntTypeSet (GPIO_PORTF_BASE、GPIO_PIN_0、GPIO_FALLING_EDGE)； //为下降沿触发配置 PF0
GPIOIntClear (GPIO_PORTF_BASE、GPIO_PIN_0)； //清除 PF0的挂起中断
IntEnable (INT_GPIOF)；
GPIOIntEnable (GPIO_PORTF_BASE、GPIO_PIN_0)； //为 PF0启用中断
IntMasterEnable()；

  • 0
    TI__Guru**** 2347060 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    对你来说很好-你坚持-遵循建议-有条理-成功！ 您的验证和记录值得赞赏-应该使许多人受益-甚至那些"注册中断"并且愿意"跳过触发器"的人受益、从而获得"延迟的中断响应！"

    所有这些都很清楚、但对于您的"初始延迟与持续延迟"演示来说、是很清楚的！ 您是否会很好地"定义和描述"？ (我的期望是、每个/每个"下降沿"都会经历(几乎)相同的延迟-假设(其他)程序入侵被阻止和/或避免。 "初始延迟"的(明显)特殊行为"让我"迷失"了-以前从未听说过这个术语。 请说明一下。)

    工作日刚刚结束(CST 19：37)、我(另一个)在跑步机上度过了一个辉煌的日子-两个晚上前、动力"下降"时-(几乎)让我的220磅飞了。 大问题-除了我可能能够将这一点与您的体验相联系。 人们本来会"希望"跑步机-感应"功率下降"可能已经有一个电压比较器信号发送给"Precor" MCU -"准备好滑行！" 相反-平板制动器被抓取-所有房间的灯都熄灭了-并且"纯粹是运气"-我能够抓住把手-并生存下来。 但是、要从6英里/小时加速到制动、就必须提出质疑。 (我会这样做-除非有些读者"知道"-并且会在这里提供建议。)
  • 0
    TI__Guru**** 2347060 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    Stefan、

    我仍然对中断启动所需的时间感到困惑。

    -您是否三次确定您的 MCU 以120MHz 的频率运行？

    -您的项目中还有其他长 ISR 吗？

    看看这个非常小的代码段。 这是计时器中断中的前几行、实际上是由信号电平转换(计时器捕获)触发的、与您的不同。

    空 Int_Timer0A (空)

    ｛

      uint32_t ui32Status；

      encoderInternal[0].encoderLevel[3]= ROM_GPIOPinRead (GPIO_ENCGL_BASE、GPIO_ENCGL_PIN)；//尽快执行此操作！ 在可能的更改之前、我们有120个周期

    我们已经在多种条件下测量了 GPIO 读取后的瞬时值-系统中还有几个其他小中断(2个几乎连续的 UART 通信@921600、2300Hz 的 SPI 读数等)、最坏的情况是大约86个处理器周期、即0.7us。 几次我们得到的结果不到一半、因为没有提供其他 ISR。

    另一个方面：我知道您正在逻辑分析仪中查看您的信号、它始终显示出美丽的垂直转换... 但由于上拉过大、您的实际信号可能需要太长的时间才能下降？

    布鲁诺

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

    希望海报的从器件采用(SPI 的正常情况)"推挽"输出、从而避免了"上拉"的需要。
    请注意、在之前的帖子中-我认为是类似的-但不是由于"上拉"-而是潜在电容-这将导致类似的效果。   为了降低(或许消除)这种可能性-我要求海报"改变他的港口和 PIN "-他这样做了-并且没有注意到绩效的改变。

    我无法判断您的"信号电平转换"是到达"纯"GPIO 引脚(如海报)还是到达"计时器引脚"。   "重复实验条件"是最好的证明、它可以极大地减少(通常防止)外来因素"使测量工作产生困扰"。

    最后-"12个系统时钟介于信号到达和进入 ISR 之间"发生了什么情况？   (您刚刚报告了86个 SysClks)   "4C123" MCU -控制数据机构(MCU 手册)声明："

    ■确定性、快速中断处理：总是12个周期、或者尾链只需6个周期(这些 值不会反映 FPU 堆叠)   

    之前-在本主题海报中、切斯特报告(源极臂)"由(未堆叠) FPU 创建的负载-将中断延迟提高到29个周期！"   

    因此、这张海报和 Bruno 都报告了预期的延迟(超出预期)。   "正在运行"的(其他)中断具有相同或更高的优先级-因此"延长时间、直到(最终)进入 ISR？

    "中断注册"是否会导致比我们(很久以前)测量的延迟更"、同时又证明更复杂和更需要资源？   (减慢响应速度、需要 SRAM 并添加代码-"这种交易！")    (您注意到的74个添加的 SysClks 是您 RTOS 的"礼物"吗？)    这里不会(有什么东西)——“臭臭臭?”

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

    [引用 USER="CB1_MOBILE "]希望海报的从设备采用(SPI 的正常情况)"推挽"输出、从而避免了"上拉"的需要。 [/报价]

    我指的是逻辑信号布线、它告诉 MCU 有新的测量可用、而不是 SPI 通信布线。

    [引用 USER="CB1_MOBILE "]发生了什么情况："信号到达和进入 ISR 之间的12个系统时钟？"   (您刚刚报告了86个 SysClks)

    在启用了大量其他中断的系统中、报告的86个周期是"实际寿命测量"。 在我们的系统上、当一个中断被服务时、其他中断等待完成。 我的观点是、即使在更复杂的系统中、其他外设同时工作、"延迟"仍然比海报在他的系统中所面临的延迟要短得多。 因此，在他的情况下，我将检查建议的三点：

    －系统时钟

    -触发信号不会像海报所相信的那样快速升高/降低

    -在触发信号时运行的其他很长的中断。

    [引用 user="CB1_mobile "]您注意到的74个添加的 SysClks 是 RTOS 的"礼物"吗？

    这些数字不涉及 RTOS。 同样、它们不是科学实验、而是从信号转换到第一行中断时测量的实数。 我们并不是要证明12个周期是可以实现的、而是要指出海报上的数字、大约2ms、太长了。

    布鲁诺

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

    [引用用户="Bruno Saraiva"]

    CB1_MOBILE
    希望海报的从器件采用(SPI 的正常情况)"推挽"输出、从而避免了"上拉"的需要。

    我指的是逻辑信号布线、它告诉 MCU 有新的测量可用、而不是 SPI 通信布线。  [/报价]  

    Bruno -哪个"逻辑信号布线"-很明显、光标将该信号显示为"/DRDY -这是海报的 SPI 从器件的输出信号-最令人惊喜的是-"推挽"。

    [编辑]-令我感到震惊的是-虽然"官方 SPI 信号几乎肯定是"推挽"信号-但/DRDY -处于"正常 SPI"之外-可能是"漏极开路"-因此需要上拉...  如果海报"返回此处-请注意"、他的"DRDY "详细信息将会解决问题。

    对于记录、当我们在(低)"123"上测量了"高优先级中断"时、我们注意到~150nS "中断延迟"、就像预期的那样。    
    即使海报使用多个中断-通过正确使用"占先"-他也可以实现更好的"延迟降低"。    (假设(其他)中断正在侵入其基于 SPI 的中断)