英伟达tk1板的串口数据收发出错问题

最近在做一个项目，需要用到英伟达的tk1板做开发，其中利用到了tk1上的串口做开发。

其中遇到了一个隐藏的bug，在用tk1板传输数据时，tk1的驱动会把部分数据如连续的多格0或者0x11这类数据吃掉，到串口上读的时候发现有远比我要发送的数据要少。

因为一开始做的时候，就知道串口数据错乱是正常的，所以自己也在每一条消息后面加了校验。所以当这个问题出现的时候，我是没有意识到问题会出现在串口驱动上面。

因为我们的tk1板为了适应产品，自己画的电路板。所以也没有第一时间定位是硬件问题还是驱动问题。后来在板上外接了usb转串口，并且在上面复现了直连串口出现的问题后，才能肯定不是硬件问题。但是当时还没有对这个bug的产生条件有充分的认识，只想着为了实现功能上的可靠性传输，我就自己仿制tcp协议栈编写了一个低版本的可靠串口通信协议，花了我一个星期做这个事情，只要有一次的数据传输对了就可以保证整个通讯的完整性。结果在完成了大部分之后，上板上跑起来，才发现一个重要的问题出现了，一次有效的数据包都没有出现，一出现都是错乱的，我开始针对这个问题尝试进行修改，将一个报文复制三次拼接在一起发送，结果三次接收的报文出现问题的地方是一致的，都是在连续的四个字节的0后面的数据就乱了。仿佛抓到规律的我针对这一个现象进行了修正，既然连续的0有问题，而我的自定义协议中又要有0，那么在组成数据包之后，发送之前将每一个字节都和一个定值进行异或操作，接收的时候也同样进行异或操作，那么在发送的时候出现连续的0的可能性就大大的降低了，实际测试的时候发现通过率大大增加了，但是关键在于，没通过的一定也通不过，同样的也有问题，后来我又想了一下，将数据原来abcd的，我每个字节扩充到原本的三倍，即aaabbbcccddd这样，然后对第二个相同的数做一组异或，对第三个相同的数做另外一组异或，保证了即使传输同样的字节，出现的可能性更加低了，加上三次中两次相同极为正确的校验，效果强了很多，实际上测试也是这样的，可是吃字节的事情还在发生，我都快对这个驱动失望了。因为又发现了对与0x11这种数据都有大概率被吃掉。导致aaabbbcccddd会变化成为aabbbcccddd，一旦错位，立马gg了。最后发现对于可见字符编码如a-zA-Z0-9的变异特性能少，于是我最终在校验的基础上添加了一成base64编码的方式，这个问题总算被规避掉了,遇到不对的直接重发就好了