我做了这样的测试，第一帧只做同步OUT， 第二帧只做同步IN，即一帧只做一种同步传输，如此循环。但它依然会产生未完成周期性传输(Incomplete periodic transfer)中断。所以应该不是STM32F4速度不够。但为什么IN 和 OUT 通道都打开就会出现这样的问题？
嗯。这个地方看起来是有点别扭。 但在我们应用时，都会根据需求针对接收或发送端点做具体配置。 打个可能不太恰当的比方，5个人去某商场买米，商场总共就500斤了，原则上每个人可以买走200斤。最终那500斤米怎么分配，看具体需求来定。
H533应该是今年的新品了，其实也不用刻意去在乎低功耗，低功耗是个加分项，除非你做的应用真的需要低功耗。不然H533感觉性能还是满足很多小应用的吧
你现在的state值 来自于HAL_UART_Receive（）函数的返回，它如果不OK的话，原因可能很多。 简单地将！HAL_OK做为结束标志来判断似乎不太合理。因为可能是出错、可能是busy、可能是超时。 另外，RxXferCount应该是 还没有接收到的数据个数，并非已收到的数据个数。 基本操作流程及做法可以参考下其它系列的IAP例程。
其实STM32Cube是个系列了,或说是个系统工具，不知你这里具体指的什么。 它包括最常用最受欢迎的图形化配置工具 STM32CbueMx， 有针对STM32各个系列的Cube固件库，比方STM32CubeG4,STM32CubeH7,STM32CubeH5，STM32CubeU5等等， 还有专门为STM32开发提供免费IDE工具 STM32CubeIDE; 还有可以用来烧录和协助调试的软件工具STM32CubeProgrammer； 以及用于对STM32芯片实时调试与监控的STM32CubeMonitor; 你到www.stmcu.com.cn搜索stm32cube，可以找到不少跟STM32Cube有关的中文资料。 关于中文教程，个人觉得 必要性不大，主要是多用。
这是那个程序一直发送数据导致GDB端口占用，才上传不了。 先修改Boot跳线帽 H 0 1 boot0 _____ boot1 让STM32从系统储存器启动 在上传一个不包括串口的程序 在修改回原来的跳线帽 在上传一个不包括串口的程序 上传成功
基于DMA方式进行UART数据通信并不需要基于死循环来检查是否转运完成，我们可以基于DMA传输完成事件 或空闲事件，待事件发生时 才 会基于中断去处理。 基于DMA方式做UART的发送和基于中断方式做数据发送，在CPU的占用上有明显差别。基于中断方式的发送，定会每 发生1个数据得申请中断让CPU来搬运数据到发送寄存器，如果是基于DMA方式，发送过程中CPU可以被完全释放出来。 对于大量数据的传输，使用DMA比串口中断方式更能释放CPU，让其做更重要或紧急的事情。 至于效率的高低，看你站在哪个角度来评价。单从实现传输的角度讲，DMA方式未必就一定比基于中断方式高。 打个比方，你想发个东西给某人，你自己亲历亲为跟选择快递，谁的效率高，不可一概而论。但可以肯定， 若选择快递，你可以释放出来做其它事情。 对于少量数据来说，是否dma驱动方式与串口中断驱动区别不大。很多场合可能差别不大，反正只是种提供数据的方式。 我觉得关键是要看，整个系统中CPU是否忙得过来，CPU响应中断时会不会影响更重要事情的及时处理。
微信公众号
手机版
.png)
