.Net 海角點部落

終於要來完成整個發送回應的畫面主體程式，基本上這個程式是由 [Serial Port 系列(7) 基本篇 -- 建立一個簡單的純發送程式(多緒型範例)] 改編而來。

這部份來處理接收的協定，接收的部份比起發送會更形複雜一些，先初步分解其工作為以下三大區塊。

在建立了通訊協定最上層的類別後，開始來處理發送部份的協定。

從這篇起要開始慢慢以較為複雜的方式來寫程式，開始要進入自訂類別的初步練習，我會儘量地將步驟拆解的詳細一些，這也意味著每一篇產出的間隔時間也可能會拉長。

發送回應模型應該是寫序列埠通訊最常遇到的，從這篇開始會分成幾篇來一步步完成這個模型的程式。

情境三：具備長度資料
有些協定是會帶長度資料的，以下的例子在第一個Byte 所帶的開頭碼為十進位值 249 ，第二個Byte 所代表的是後面資料內容的長度。

具備開頭結尾字元 
有一些通訊協的形式是具備了開頭結尾字元形式的，當然不一定是一個字，不過通常的情形是開頭或結尾字元絕不會出現在中間的資料內容段中，以下的圖例是以大寫字母S做為開頭字元；而大寫E字母做為結尾字元的通訊協定形式。 
 

在進入『發送接收模型』的議題之前，先來討論關於接收資料完整性的問題，在我之前的文章中都是接收緩衝區有多少資料就收多少回來，這產生一個問題是我們常常會遇到分段接收的狀況，也就是說傳送端一次傳送了一份完整的資料，但接收端卻未必會一次就收的完，這樣不完整接收的現象不僅在 SerialPort 會發生，在 Socket 也一樣會產生這種狀況，所以必須採用一些技巧來確認資料的完整性。不過這有非常多不同的情境，在這幾篇文章中會舉出幾項例子但請注意未必能完全符合各種情境的需要。

在邊寫這系列文邊和朋友們討論的過程中，璉大跟我提了一個想法『不要使用 DataReceived 事件，而自行用執行緒來檢查緩衝區』，這其實很類似在Socket 程式中利用Thread加上同步接收來達成非同步效果的方法，這篇就來討論如何來完成這樣的功能。

在使用DataReceived事件的時候要避免執行緒暴衝的狀況有幾個簡單的方式可以避免。

DataReceived事件的黑暗面源自於它自己的特性 -- 在次要執行緒上引發 DataReceived 事件，如果你曾經寫過通訊程式會發現一個現象，即使發送端只呼叫一次發送方法，接收端卻有可能會分很多次接收，問題的根源在於傳輸是需要時間的，所以有可能在接收緩衝區還沒收到所有資料前就讀取緩衝區，一個簡單的方式是你可以使用這系列文之前簡單的發送端 與接收端，然後去觀察你每次所收到的資料。

終於進入接收資料的開始，就從DataReceived事件來進入這個階段。
純接收的模型一般來講用DataReceived事件是很方便的，雖然它其實有一些毛病，我們暫且先拋開這些毛病，從最簡單的程式碼看起。

經過了上一篇的說明，應該都瞭解基本發送的做法，記得我在 [Serial Port 系列(2) 在開始寫程式之前]提到了多執行緒，現在就用多執行緒來實做發送。
為什麼通訊的部份應該要放在多執行緒中呢？有幾種狀況我們會遇到，例如像單次通訊的時間很長、亦或使用大量甚至無限迴圈進行通訊，在使用者操作軟體的時候你不會希望聽到他說：「我按了通訊後你的程式就當掉了，畫面都不會動。」諸如此類的評論；所以我一向很習慣把通訊寫在另一個執行緒來執行。這個會複雜點，希望你們有耐心看得下去。

之前在[Serial Port 系列(6) 基本篇 -- 建立一個簡單的純發送程式(一般型範例)] 中有提到關於 IsOpen 的問題，後來我在測試的過程中發現一些狀況，所以寫這篇簡單記錄一下觀察的心得。

來從最簡單的程式碼開始着手，沒意外的話應該不會有太多的例外狀況把自己弄糊塗，就發送，管他三七二十一個送，有沒有人接資料，再說吧！

SerialPort類別建構函式是建立SerialPort執行個體的基本，主要因為它有不少的多載，所以切出一篇來聊一下。

噹噹噹！感謝各位耐心等候，終於要開始進入基本程式。且慢！先來把建構函式和基本屬性走過一遍吧。

很好！這篇還是不打算講程式，應該有很多人開始想打我了。可是我覺得通訊模型會牽扯到程式設計的基本架構，所以非寫這一篇不可。

在開始寫序列埠程式之前有一些我們需要能夠先有基礎瞭解的東西，關於 RS232 接腳的認識在前一篇已經談過了，這篇則列示一些我們該有的事前準備。

不論是在論壇或是部落格上，長久以來關於序列埠程式的開發一直都還有滿多人在詢問相關的議題，也因此讓我想要寫一個關於這方面比較完整的系列文，只是我這個大懶鬼不曉得要花多久時間才能把整個系列做完。不過這總是個開始，第一篇咱們不談程式，先來瞭解序列埠的基本知識。