这是我在这个论坛上的第一篇文章。 我正在开发一种基于STM32F429DISCOVERY板的MIDI音序器设备，该板以180MHz的速度运行。为了发送midi消息，USART1配置为31250波特，并且相应的DMA配置为将存储在ram中的3字节阵列传输到USART。我正在测试甚至发送midi消息的时间，通过配置定时器4更新中断，在我启用内存到外设USBART1 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实际发送数据之间插入了很长的延迟，这是不可接受的。
如果有人对此有任何想法或做过类似的事情，我需要建议在哪里查看。
提前多多感谢！
祝你好运， 康斯坦丁
答案 0 :(得分：0)
即使根据您的详细描述，错误的可能性也很多种，所以我能做的就是猜测：
也许只是TIM设置之一只是略有错误：计时器的自动重载寄存器（TIM4_ARR）呢？
周期设置必须比期望的传输周期低低一个单位，再除以（可能是预先缩放的）时钟周期（请参见向上计数/向下计数的详细信息）。
现在，如果重载值恰好等于该值，则第二个触发器将延迟一个微小的周期，第三个触发器将延迟两倍，依此类推（依此类推）您所描述的）。 然后，这种“延迟斜坡”将上升，直到不想要的延迟加起来达到一个UART位周期（对于31250波特，恰好是32uS，非常接近您所描述的“大约30uS”）。这样，下一个触发器就适合相邻的UART位周期（没有太多延迟）。
将此假设与您的其他发现进行比较...
更改UART波特率将保留基本错误，但令人讨厌的延迟时间会改变。它可能会更改其符号（“更快或更慢”），具体取决于（实际）TIM周期和UART位周期之间的拍子特性。 =>确定
将事件处理从DMA更改为IRQ处理程序不会对问题有太大改变，而只是初始延迟的“阶段”（到CPU需要执行其他ST库函数的时间）。 =>确定
禁用和重新启用UART可能会改变行为，因为UART时钟可能会与基础总线时钟（USART2的APB2）重新进行新的同步，因此TIM触发后的延迟将保持不变，并且您不会注意到波动。 =>确定