我本身是從事工業自動控制控相關產業...因為工作的需要必須與各種控制與檢測的設備.打交道@@ 所以通訊的處理是很重要的一環...與工控設備通訊的方式主要有 IEEE-488.x(GPIB) . IEEE-1394 . RS-232C|RS-422|RS-485 . USB . 乙太網路 . 藍芽等......其中又以 RS-232C 歷久不衰且最為普遍......

以 Windows 作業系統開發人機介面是一個不錯的選擇...在通訊方面也有累積相當多的控制元件.函式庫可供使用...一般用途都還能勝任...但用在較講求嚴苛.精確.精密.多設備.長時間運作的監控系統上...基於掌握度的考量就必須自己打造...在面對數十個串列通訊 Windows API 的同時...要如何拼湊出所需的通訊工作是一項艱難的工程...十多年前這個問題讓我困擾不已...這樣的問題同樣也讓世界上許多程式設計師感到困惑......

目前 Windows 對於周邊設備統一以檔案為對象處理...串列通訊亦然...關於串列通訊相關的基礎知識...多半侷限在單一寫出或單一讀取的論述與範例...但在實際的應用裡為對話協定模式以確保資料的正確性~ 通訊的程式是嚴謹的一來一往間的對話確認之協定...而非只是單純的傳送與接收......

先撇開線路之環境干擾因素程式上的誤用...串列硬體有些本身就是不穩定的瑕疵品...或是在線路上不當的連接造成串列機能受損...也同樣會造成通訊不穩定的後遺症...為了確保串列硬體的可靠性...在寫串列程式前得先對硬體串列做檢驗以確保正常......

電腦在做對外的通訊與內部的記憶體資料搬移不同...對外的通訊存在著許多不確定因子...比如通訊過程中受到外在電氣設備干擾.通信端子電器特性受損.通訊過程中端子抽拔所產生的彈跳效應...因而造成訊息失真或大量亂碼湧進讀取緩衝區...所以在通訊上必須採取不信任的嚴格處理程序來把關......

通訊的資料必須包裝為封包來確保完整性與正確性...封包的基本結構為 : 起始碼 + 封包 BYTE 數 + 資料........ + 錯誤檢測碼(Check 或 CRC) + 終止碼...當資料量較大...可以分為多個資料封包來傳送...若通訊資料有關機密需將資料做加密...資料的傳送或接收間的決策對話為通訊協定...通訊的過程中若發現不正確或延誤傳送或接收超時(TimeOut)...得要求通信的對方重新發送資料或終止......

其實使用 Windows API 很容易...不管對視窗操作或是周邊硬體操作...都得先向作業系統取得 HANDLE...HANDLE 就像是一個 C++ 的類別的指標...所有相關操作的方法皆圍繞在 HANDLE 來運作....執行函式後皆會反映傳回成功或失敗...失敗時一律以  GetLastError 得知錯誤碼...藉由錯誤碼就可知道問題所在......

串列通訊使用 API 對於通訊的上的應用...雖然程式上的細節複雜了點但可以得到更精確的掌控...現成的各式串列控制元件是可以完成許多任務沒錯...不過要達到精確實用的程度反而需要經過修飾而變得臃腫......

SetupComm API 雖然是用來設定讀寫緩衝的用途...不過只能做為建議而已! 實際上有沒有設定都沒差別...真正 Windows 串列的讀寫緩衝各為內定 4096 Byte...當一次讀或寫超過 4096 Byte 時...多的資料被會被屏棄......

使用 Windows API 計時器事件雖然方便好用...可是會因為 Windows UI 在操作所影響而導致被停滯...若對於沒有時間差異性的控制應用沒啥問題...不過對於講求精確的自動測量系統(ATS)建議還是以多執行序來的好! 且以多執行序來做通訊對話協定反而容易簡單~