不平凡，就不是生活

win32api所提供的serial port讀寫方式有分兩種
同步方式: 讀夠了指定的字元才會返回(執行緒不會先返回去做其他工作)
非同步方式: ReadFile/WriteFile函式被呼叫之後,執行緒會先返回,win32api自動幫你新增一個執行緒在背景做IO工作,你必須去檢查OVERLAPPED結構的hEvent物件是否已被觸發,才知道背景IO工作是否已經結束

標準做法是先用WaitForSingleObject去檢查hEvent物件,如果觸發了,才使用GetOverlappedResult去檢查執行的結果(IO工作結束後有很多種結果,讀取到的字元可能介於0~N個你指定的字元,可能是順利讀完之後返回或是因為timeout被迫先返回而實際讀取字元=0或是<N)

win32做IO的方式(serial port/檔案讀寫/和其他IO都適用)會受到timeout的影響,否則同步方式很容易會鎖死,如果是在XP系統,逾時機制的預設值應該都是0,也就是不使用timeout機制
你在開啟通訊埠使用CreateFile函式的時候並沒有指定要用overlapped非同步方式去執行,我也沒看到你有去設定timeout值,所以你的IO執行緒是以同步方式在跑,overlapped結構和設定等等動作是白做的,因為ReadFile根本不會去使用

因此你的程式應該是會鎖死住,一直等到ReadFile讀夠了256個bytes才會返回...,我建議你要把一些事情做好,比較容易debug

1. 開啟通訊埠之後,把UART晶片的緩衝區一律清除掉,否則程式上一次執行所傳送的資料仍然會在緩衝區裡面等著被讀取(至系統記憶體內),事實上一般白牌的UART晶片的接收緩衝區大約是16到256個bytes,很容易就被塞暴,因此windows事實上在背後幫你提早接收了這些資料,並自行保管,等到你去讀取serial port的時候,它就直接把資料給你(系統記憶體的複製動作),所以你會發現寫入serial port返回的時間跟baudrate以及字數有相關,但是讀取serial port卻是""瞬間""完成,即使你的baudrate很低...我把這個稱之為windows所提供的""軟體緩衝區"",實測結果是這個軟體緩衝區可以放超過1MB以上的資料(雖然被灌暴的時候,win32API函式有檢查overrun的事件和機制,也可以警告你,但是資料仍然被存放入軟體緩衝區裡面,一個byte都沒少也不會被丟掉),所以開啟/關閉通訊埠的動作要確實,該清空/reset的動作都要做,不然改過的新程式碼去讀取軟體緩衝區裡面的舊資料,改對了還是可能產生錯誤結果

2. 因為win32api提供了timeout返回的機制,所以你可以沒事就去讀取看看,大不了就是沒資料可讀而已,這種方式特別適合資料固定在流動,但是資料量不定的情況(而且最新資料可以取代舊資料),另一種方式是先檢查接收緩衝區之後,知道了有無字元和實際數量,然後才去做讀取動作,這種方式如果出了問題比較好debug