#串口通信接收数据位和数据对齐的BUG

前言
最近好像和BUG杠上了，一直在忙着找bug，上个礼拜修了一个礼拜的电路板，前天又开始找程序的BUG，直到今天才结束。在本次找程序BUG中自己学会了数据对齐和串口通信注意的地方。本次主要记录找BUG和解决BUG的过程。不喜勿喷。

背景
本次刚来公司几个月，接收了别人之前做过的产品，那我就负责产品维护，另外就是研发新产品。本次的BUG就是stm32下位机存储在DGUS屏中的数据，不能正常被上位机所读出（上位机是老大用C#写的）。
BUG one：
记录头不能正常显示，而是显示为 已用：1000，剩余:20301，总量85。正常上位机会显示为已用：50， 剩余:950， 总量1000。
就开始在下位机上找BUG，找啊找，发现另外一个串口能够读出数据，并用printf发到SecureCRT，那就是发送上位机的程序问题。然后去找问题。如图

然后单独用这个函数发送数据。没有问题。慢慢发现，记录头的结构体的第一个参数出了问题，他是16位的整形数据，而上位机是32位整形接收。后修改为16位接收就能够正常显示记录头。
如图，结构体


BUG Two
读取下位机测试记录时，没有数据显示。

然后也是用同样的方法测试，发到表中去，结果能够显示。说明下位机的收发函数和存储数据都是没有问题。然后想到是不是浮点数发送会出错，结果还真是碰到浮点数就发现问题。老大提醒是不是数据对齐问题，然后就在数据读取结构体声明就加了按四字节对齐，
__IO __align(4) LCDCOM_STRUCT LCDCOM_mcb; 结果发现还是不行。

然后就直接打印结构体第一个参数的地址和浮点数的地址，结果发现相差12，而上位机接收浮点数数据是从位10开始的。这样接收数据肯定错了，因为数据存储是按连续的物理地址存储的，又因为结构体是按四个字节对齐，那么浮点数存储数据的位是从12位开始。
所以上位机接收这个浮点数数据要从第12位开始。（开始是从第10位开始的）。故修改从第12位开始接收。这样表中的数据就能够正常显示。


总结：
从以上找BUG的过程学到，串口通信过程中数据不对，可能是数据位数的问题或者收发过程的问题，可以一个个排除；另外就是上位机接收数据时，接收的数据位一定要对，要考虑数据对齐的问题，这样就不会产生BUG了。记录就到这里。