又是一个坑爹的BUG

为了追查一个串口命令解析模块的BUG。为了验证初始串口收到的字符没有问题，我在Uart_Int_Handler中加入了打印信息。命令开始接收和结束接收的时候加入printf。 

奇怪的事情发生了。第一条命令总是接收不全了。但是第二条命令可以接收完整。

        最后注掉所有的处理过程，收到字符之后就打印出来----》发现还是丢字符，(超过两个字符就非常容易丢失)。开始以为是硬件问题（不过也说不通，如果硬件有问题，应该一个字符也收不到，不应该只收到其中的几个。）

又修改成收到一个字符，用最原始的uart_tx_byte发送一个R字符来表示接收到。这样是不会丢失的。

(这个时候就应该想到是printf延时太大，导致中断丢失的缘故)

然后我又把波特率降低到9600。发现还是不行。

没办法，我只好修改了uart_config函数，把uart的fifo打开。发现有了fifo buffer，就不会丢失字符。所以我才意识到是printf占用的时间太长了。导致了在中断服务历程(interrupt routine)中的时间太长，使新的串口中断丢失。

而且也能解释为啥第一个命令不能接收正确(因为开始的时候有打印信息，导致字符丢失)。而第二个命令没有再次打印(因为此时已经开始接收了)。所以没有printf的延时，字符就可以全部收到。

115200的波特率，发送一个byte。大概需要87us(10* 1/115200 * 1000000us)。时间还是非常短的。而printf的时间应该大于这个。

最后把printf全部拿掉，终于又好了。欣喜的事，命令解析模块的BUG也找到了，是有地方资源没有释放。导致新的命令无法获取--key。所以无法解析。

其实这个问题，我同事也出现过。他也是在接收字符的打印出来，（来直观的验证是否接收正确）。结果导致就是字符丢失的问题。当时没有引以为戒，浪费了2天的时间也来调试。悲剧。

今特记于此。。。教训。。。