本帖最后由 shaoyinli 于 2019-4-25 01:27 编辑

  谈起USART，许多人一笑而过，不就是USART么但谈到TC中断用一万个表情...（希望大神不要打我）。小菜我这几天真的是被TC给搞得生活不能自理，各种清除状态都不起作用，而且会出现各种各样的奇怪现象，倔强的本小菜展现了强大的求生欲...TC的水很深吗？没错，TC的水确实很深。
切入正题...首先，在USART被使能后，也就是USART_Cmd（）调用后，TC就会被置1，如果开了中断，程序就发疯了的进中断。还好小菜我还没疯——ST的参考手册上有一句话：在数据传输过程中，若TE上有个上升沿（除了在智能卡模式下），会在数据字传输完成之后发送一个“前导符”（空闲总线）。于是小菜我先使能UE（即调用USART_Cmd(USART1，ENABLE)）再使能TE（即在USART_Init( )中的参数结构体中设置USART_Mode=USART_Mode_Tx）会使TE上出现一个上升沿，导致前导符的发送；或者先使能TE再使能UE，由于UE是USART的上电开关，同样会导致TE上出现一个上升沿，导致前导符的发送。将TE的使能与UE的使能分别去掉再实验，都不会发送前导符。前导符的发送完成是系统的第一次数据发送完成，所以会使TC置1，这就是使能USART的发送数据功能之后即使不做任何操作TC也会置1的原因。此时我心中无比狂喜~TC也不过如此嘛..于是我在使能之后立即使用USART_ClearFlag(USART1，USART_FLAG_TC)来一波清除，motherfucker不起作用!TC仍然会抽风似的置1，我得世界颠覆了...
于是小菜我不得不大胆瞎猜：是时间同步的问题，即发送前导符需要一定的时间，当TC手动清除之后前导符还没发送完成，这样就导致清除TC后，TC还是会被置1，也就是不是加清除函数不起作用，而是作用时间不够。通过测量，小菜我是对的~~奉上数据： baudrateleading character sending  time/us baudrate*time 115200 95 10944000 76800 141 10828800 14400 762 10972800 9600 1144 10982400