都是串口工具惹的禍

五一假期這幾天，魚(yú)鷹準備寫(xiě)一個(gè)方便使用、移植的串口框架（適用于 STM32、GD32），花了幾天時(shí)間，終于把 DMA 發(fā)送、接收的框架寫(xiě)好了，進(jìn)入了最終的測試階段。

于是魚(yú)鷹使用 XCOM 這個(gè)串口工具準備測試一波。

畢竟之前用的時(shí)候，感覺(jué)也還行，沒(méi)啥大問(wèn)題，比較穩定，一般串口穩定性測試的時(shí)候都用它。

不過(guò)這次通過(guò)定時(shí) 20 ms 發(fā)送字符串的方式驗證串口接收程序，發(fā)現工具發(fā)送的字節數和單片機接收的字節數總是對不上。

剛開(kāi)始幾百 K 字節，是沒(méi)問(wèn)題的，當達到 1 M 左右字節時(shí)，發(fā)現總是單片機接收的字節數大于工具顯示的已發(fā)送字節數，莫名其妙（從這得到經(jīng)驗，代碼測試一定要經(jīng)過(guò)長(cháng)時(shí)間測試才行）。

魚(yú)鷹對自己寫(xiě)的無(wú)鎖隊列串口程序還是比較自信的《終極串口接收方式，極致效率》《附源碼-終極串口接收（二）》，畢竟驗證了多年，雖然這次為了減少空間使用，稍微修改了一下代碼，但也檢查了使用這些變量的位置，并沒(méi)有發(fā)現問(wèn)題。

所以，出于對自己的自信，懷疑是串口工具出現了問(wèn)題，于是準備搬出魚(yú)鷹學(xué)習 51 時(shí)的老古董工具：STC -ISP

同樣的代碼，同樣的字符串，同樣的 20 ms 定時(shí)發(fā)送，發(fā)現不管是短期測試，還是長(cháng)期測試，工具顯示的發(fā)送數據長(cháng)度和代碼打印的接收數據長(cháng)度總是保持一致，這說(shuō)明魚(yú)鷹的接收程序不存在問(wèn)題。

這下石錘了，XCOM 工具有問(wèn)題！

虧咱那么信任它。果然除了自己，誰(shuí)都要持懷疑態(tài)度。

做技術(shù)就是如此，懷疑所有，直到你通過(guò)測試消除你的懷疑。

STC 這款多功能工具，魚(yú)鷹也是用了很久了，大學(xué)四年+工作一年都在用它的串口功能，直到后來(lái)，用了 XCOM，感覺(jué)也不錯，而 STC-ISP 軟件，如果串口拔出，操作不當（沒(méi)有關(guān)閉串口的情況下直接發(fā)送數據），會(huì )導致該工具卡死（只能通過(guò)任務(wù)管理器關(guān)閉，很煩），而且界面做的也不是很好，于是棄用了。

不過(guò)現在看來(lái)，有些工具看著(zhù)很 LOW，真正用起來(lái)，核心功能還是非常給力的，不應該有了新歡，忘了舊愛(ài)。

最后，最近微信出了顯示 IP 歸屬地的功能，大家可以在此留言看看自己的歸屬地在哪，是不是還在國內。