串列埠通訊接收資料位和資料對齊的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位接收就能夠正常顯示記錄頭。

如圖，結構體

讀取下位機測試記錄時，沒有資料顯示。

然後也是用同樣的方法測試，發到表中去，結果能夠顯示。說明下位機的收發函式和儲存資料都是沒有問題。然後想到是不是浮點數傳送會出錯，結果還真是碰到浮點數就發現問題。老大提醒是不是資料對齊問題，然後就在資料讀取結構體宣告就加了按四位元組對齊，

__io __align(4) lcdcom_struct lcdcom_mcb; 結果發現還是不行。

然後就直接列印結構體第乙個引數的位址和浮點數的位址，結果發現相差12，而上位機接收浮點數資料是從位10開始的。這樣接收資料肯定錯了，因為資料儲存是按連續的實體地址儲存的，又因為結構體是按四個位元組對齊，那麼浮點數儲存資料的位是從12位開始。

所以上位機接收這個浮點數資料要從第12位開始。（開始是從第10位開始的）。故修改從第12位開始接收。這樣表中的資料就能夠正常顯示。

總結：從以上找bug的過程學到，串列埠通訊過程中資料不對，可能是資料位數的問題或者收發過程的問題，可以乙個個排除；另外就是上位機接收資料時，接收的資料位一定要對，要考慮資料對齊的問題，這樣就不會產生bug了。記錄就到這裡。