mcu串口发送的有趣现象:一个printf居然和另一个printf有关?!!AI完全无法解释!!!

        刚才在玩一个f4的代码的时候发现了一个有趣的现象:

        我在命令表中执行led on的命令的时候,会有一个printf("LED ON\r\n");但是我发现如果我在回调函数中加入printf("in command\r\n");的调试信息时,串口只显示发送了两次"in command",而"LED ON"却没有显示.如图:

        我一开始很好奇为什么串口偏偏只发两次,按理说它应该会发8次才对,而且我的LED ON回传信息居然不见了!我转头去问AI,结果AI跟我装死,非要说因为\r\n判断两次所以发了两次.我跟他说你看看printf("in command")我放在判断\r\n的前面了,你别胡说.它想了2分钟然后继续跟之前一样胡说......

        于是我自己试图找到原因.我又做了如下图的测试:

        好好好,我心心念念的8次回传它出现了,我的"LED ON"它也出现了!

        根据以上现象我推测:在115200波特率的情况下,串口的发送无法再很短的间隔连续发送超级多的字符.因此才会在要发的数据多的时候只发两条.于是我又测试一个超长的字符串的发送    printf("in commandaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\r\n");我猜它依然会发出来两次.结果如图

所以:

肯定是因为我在发送的时候只有8个byte,所以在进入串口发送底层的时候它只来得及发送一次8字节的字符串.但是出现两次说明肯定还有一个机制:发着一个,预备着发一个,所以在它甚至发不完一次完整串口数据的情况下,它刚好可以发送两次!这是一个时间间隔的问题!也正好是"发一备一"的机制,导致我的8个i和一个"LED ON"9个数据也可以在只收8bytes的进8次回调函数的情况下刚好发得出来.