2

这是我在这个论坛的第一篇文章。我正在开发一个基于 STM32F429DISCOVERY 板的 MIDI 音序器设备，该板以 180MHz 的频率运行。为了发送 midi 消息，USART1 被配置为 31250 波特，并且适当的 DMA 被配置为将存储在 ram 中的 3 字节数组传输到 USART。我正在通过配置 Timer 4 更新中断来测试发送 midi 消息的时间，在该服务例程中我启用了 memory-to-peripheralUSART1 DMA 操作。这使我可以通过 USART1 外设定期发送 3 字节消息。

一切都很好，并且频率和数据都正确，但是我有一个小问题，我已经研究了几天并且无法纠正。为了让事情更清楚，在定时器中断例程中，我将发现 (RG13) 上的 LED 设置为暂时闪烁并将示波器的 1 个通道连接到 LED 引脚。示波器的第二个通道连接到 USART TX 引脚。现在，当代码执行时，我可以看到示波器 CH1 上的 LED 脉冲，然后是 CH2 上的 USART 串​​行数据。但由于某种原因，LED 脉冲和串行数据传输开始之间的时间会随着每次发送数据而波动。它随着每次发送而增加，从大约 1uS 到大约 30uS，然后跳回到 1。我注意到如果我稍微改变 USART 波特率，脉冲和数据发送之间的时间波动以模式变化，变快或变慢，距离更长或更短。我尝试从 USART 和 DMA 重置所有适当的标志，尝试禁用/启用定时器，使用中断优先级，但没有任何方法可以消除时间波动。正如您所想象的那样，它的稳定性对于 MIDI 音序器硬件应用程序至关重要，因为它基于音乐事件的时序，而音乐事件的时序必须坚如磐石。我也尝试过在没有 DMA 的情况下单独使用 USART，手动发送每个字节，结果基本相同。中断驱动的 USART TX 表现出同样的结果。唯一似乎可以消除 USART TX 响应时间波动的方法是，在每次发送操作之前取消初始化 USART 和 DMA 模块并再次重新初始化它们。这似乎提供了稳定的操作，但在定时器中断和通过 USART 实际发送数据之间插入了很长的延迟，这是不可接受的。

如果有人对此有任何想法或做过类似的事情，我需要一个关于在哪里看的建议。

提前非常感谢！

最好的问候，康斯坦丁

4

1 回答 1

0

即使根据您的详细描述，错误的可能性也有很多种，所以我能做的就是猜测：

也许只是其中一个 TIM 设置有点错误：定时器的自动重载寄存器 (TIM4_ARR) 怎么样？

周期设置必须比所需的传输周期低一个单位除以（可能预分频）时钟周期（请参阅详细信息加计数/减计数规范）。

现在，如果重新加载值恰好等于该值，则第二次触发将延迟一小段时间，第三次触发将延迟两倍，依此类推（可能看起来像您所描述的那样）。然后，这种“延迟斜坡”会上升，直到不需要的延迟总和达到一个 UART 位周期（对于 31250 波特，恰好是 32uS，非常接近您描述的“大约 30uS”）。然后，下一个触发器将恰好适合相邻的 UART 位周期（没有太多延迟）。

将此假设与您的其他发现进行比较...

  • 更改 UART 波特率将保留基本错误，但令人讨厌的延迟持续时间会发生变化。它可能会改变其符号（“更快或更慢”），具体取决于（实际）TIM 周期和 UART 位周期之间的节拍特性。=> 好的

  • 将事件处理从 DMA 更改为 IRQ 处理程序不会对问题产生太大影响，而只会改变初始延迟的“阶段”（到 CPU 需要执行不同的 ST 库函数时）。=> 好的

  • 禁用和重新启用 UART 可能会改变行为，因为 UART 时钟可能会重新与底层总线时钟（USART2 的 APB2）重新同步，因此 TIM 触发后的延迟看起来是恒定的，您不会注意到波动. => 好的

于 2020-04-03T19:52:47.173 回答