最近几天由于自己写的图像板显示程序在与主机的串口通信时概率性的出现了
某部分画面不更新的问题。每次测试要烧写程序和连接主机再等待错误出现，相当的头痛，
当时通信用的波特率是115200，数据位8位，停止位1位，无校验位（然后通信协议
使用数据包的校验进行校验。显示该部分画面的命令包30~150个字节，而且重发几遍，听
经理说以前这样也很是可靠，而且经检测经理写的主机（单片机）程序确实有发送出正常的数据；
就想着应该是自己程序问题了。
后来到晚上加班时直接加多了个调试界面，发现有时候并未成功接收到该包。于是第二天早上
我测了下不同波特率下的通信情况，主要是测试图像板接收到的和PC机发出的字节数的比例。
在115200波特率下分别发送10K、100k之间的多个数据测得接收率为93%~98%。而在9600波特率下
相应的接收率达到99%~100%。这样看来波特率越大时数据的传输质量就越低 。
当然这只是接收到的，可能在这些数据之中还存在着电平不一致的可能性，导致检验和错误故丢弃。
根据测试结果，再加上我们的通信数据量不大，我改为9600的波特率最后终于成功了。当时还以为是
别人的串口函数封装不好导致的，还自己更换了再中断模式下去读串口的寄存器取数据，结果也使白忙活。
由于这点小问题而花费了一天多将近两天的时间，实在是一次惨痛的教训。主要原因是以为程序简单，没有输出
必要的调试信息。
因为现在是在一块韩国公司出的单片机上编程，缺乏必要的调试接口。看来以后要写一个调试模块，将输出
可以任意定向到串口、文件、或画面显示上。这样就容易找出问题所在了。而且在关键的通信部分是否也要给串口
通信加个确认机制呢，保证其可靠性？希望大家能给点意见。
有趣的是，我发现二分法也是检测程序错误的好方法。比如在这次问题上，如果能首先确认是程序的问题还是
通信问题就马上把问题缩小在1/2的范围内了。再这样接着找下去，下次遇到问题应该可以很快找到出错的地方了。
log2n的复杂度~~