序列程式設計/簡介和OSI模型
序列程式設計: 簡介和OSI網路模型 -- RS-232接線和連線 -- 典型的RS232硬體配置 -- 8250 UART -- DOS -- MAX232驅動器/接收器系列 -- Windows中的TAPI通訊 -- Linux和Unix -- Java -- Hayes相容調變解調器和AT命令 -- 通用序列匯流排(USB) -- 形成資料包 -- 錯誤糾正方法 -- 雙向通訊 -- 資料包恢復方法 -- 序列資料網路 -- 實際應用開發 -- 序列連線上的IP
歡迎來到序列資料通訊的奇妙世界。這是本系列文章的一部分，將涵蓋序列資料通訊的許多方面。我們將從基本原理開始，並採用分層方法。在閱讀完本書後，讀者將能夠在計算機之間透過線纜傳輸幾乎所有資料。我們也會討論一些無線通訊形式。
這個主題有很多方面，有時它是一個非常難以破解的難題。我將深入探討，嘗試從基礎開始，並介紹RS-232序列資料通訊標準。
首先，從計算機技術的角度來看，這裡將要描述的基本標準非常古老。你們中的一些人可能發現你們的祖父母甚至曾祖父母在大學期間使用過這種協議。同時，它的概念非常可靠，因此，放棄它的理由應該始終受到質疑。事實上，自從RS-232序列資料協議建立以來，已經開發出幾種其他資料傳輸方法，但這種“工作馬”仍然被廣泛使用，而且似乎每隔一段時間就會重新流行起來。
序列通訊意味著一次傳輸一位。它可以與並行通訊進行比較，在並行通訊中，多位資料同時傳輸。並行通訊比序列通訊速度更快，但它需要的訊號線比序列通訊更多，序列通訊只需要一根訊號線。
在其他方法都失敗的情況下，可以依賴RS-232序列通訊。當您嘗試將兩臺計算機裝置連線在一起時，有時更新的通訊方法會存在一些難以解決的限制，比如連線數量、射頻干擾、距離限制、物理障礙、敏感區域（比如醫療裝置，在那裡，雜散電壓可能是個問題），或者您絕對需要依靠資料傳輸的可靠性。作為RS-232的姊妹協議，RS-422協議甚至允許傳輸數英里的電纜。
序列資料通訊被廣泛應用。雖然通常人們認為PC可以處理您想讓它處理的任何問題，但仍然存在許多電子裝置包含需要記錄的大量資料。部分原因是該協議的年代久遠，有許多傳統裝置使用RS-232序列資料作為連線外界的唯一方式。但即使許多最新的網路裝置也具有RS-232“控制檯”埠，以方便初始配置並提供網路本身發生故障時的故障排除手段。由於硬體被廣泛應用和提供，加上許多軟體工具，使用該系統開發裝置和軟體相對便宜。特別是在傳輸速度並不重要的情況下，但資料需要定期傳送。RS-232序列資料是一種非常合理的解決方案，而不是更昂貴的10BASE-T TCP/IP解決方案或高速光纖。
序列資料通訊也很靈活。雖然通常的傳輸方式是透過兩點之間的銅線，但最近有一些轉換器可以將序列資料透過光纖線路、無線發射器、USB裝置甚至透過TCP/IP網路傳輸。真正令人驚訝的是，所有這些傳輸方法對於接收或傳輸序列資料的裝置來說都是完全透明的。它也可以作為TCP/IP的載體，並用於私有網路。
雖然序列資料通訊並非嚴格意義上的網路通訊協議，但瞭解分層通訊模型在處理任何型別的通訊協議時仍然很重要。通常，實現序列資料軟體的人必須構建該模型的多個層，即使他們在當時並不完全意識到這一點。
網路層
- 應用層
- 表示層
- 會話層
- 傳輸層
- 網路層
- 資料鏈路層
- 物理層
序列資料通訊通常並不實現所有這些不同的層，而且更常見的是，這些不同的層被組合在同一個模組中，甚至被組合在同一個函式中。這個模型最初是由國際標準化組織(ISO)於1984年開發的，以幫助人們瞭解不同的網路結構可以在哪裡分離和混合。這裡的要點是，您知道可以分離通訊子系統的不同部分，以幫助進行除錯過程，並將結構從一個子系統移動到另一個子系統。
如果您的軟體使用類似的模型編寫，那麼在更改特定層的模組時，不需要重新編寫上層和下層的軟體子例程。為了實現這一點，您需要為層之間的介面建立嚴格的標準，這些標準將在本文件的其他部分中介紹。例如，Web瀏覽器不需要知道HTML是透過光纖電纜、無線傳輸還是序列資料電纜傳送的。
對於序列資料通訊，我看到這種層模型更常見
- 序列資料應用
- 序列網路
- 資料包挑戰/驗證
- 基本序列資料包
- UART處理
- 原始RS-232訊號
在許多序列資料應用程式中，並不實現所有這些層。通常只是一些原始資料包被單向傳輸，但有時即使只是任何型別的訊號也可以指示計算機上發生了一些動作，無論內容如何。可以簡單地將原始RS-232訊號的邏輯電平包含在您的軟體中，但在某些時候，資料確實需要被轉換，並且RS-232中涉及的電壓可能會損壞硬體，因此這種情況很少見。
本系列文章並非旨在引發程式語言的聖戰。目前，我將使用 Turbo Pascal 和 Delphi 作為程式語言，主要是因為我對這個開發環境最為熟悉。如果優秀的 C/C++ 大師願意將這些例程“翻譯”成其他語言，我將表示歡迎，也歡迎將例程移植到其他適用的程式語言中。序列通訊本身就相當複雜，所以請避免使用像 Intercal 或 Malbolge 這樣的深奧語言。一個好的 BASIC 實現將受到歡迎，LISP 也一樣。我將盡量避免使用特定語言的特性，而是以通用方式處理函式，這樣優秀的程式設計師就可以將其翻譯成他們選擇的語言。
這些文章旨在教您序列資料通訊的基礎知識，而不是建立一個可用的序列資料驅動程式。儘管如此，所有的程式碼示例都將在列出之前經過實際編譯器的檢查和驗證，並儘可能進行完全除錯。完成這些步驟和任務沒有唯一的方案，因此我將鼓勵您動手實踐軟體和網路設定。
雖然我在處理多種序列資料協議方面（在資料包級別）擁有相當豐富的經驗，但我絕不是這方面的頂級專家。正如我之前所說，我在處理多個層級的通訊方面擁有相當豐富的經驗，我願意分享一些我辛苦得來的知識。
雖然我僅僅是一名軟體工程師，並不具備編寫教育教科書的“正式”資格，但我相信，學生透過實驗序列資料通訊，可以學到很多關於計算機網路的知識。這些文章的目標受眾是高中駭客/計算機極客和本科計算機科學專業學生。高中教師可以利用這些文章來教授相關主題，大學教師也可以在特殊主題課程中使用這些文章，讓學生能夠獲得關於通訊協議的實際經驗。OSI 模型的每一層都可以透過實踐的方式進行演示，讓學生們從第一手經驗中學習為什麼網際網路上實施了某些規則/系統，標準文件的含義，甚至可以參與標準文件的建立。
如果您是教授或高中教師，有興趣使用本文，我特別願意根據您的需求調整本文，或者與您合作涵蓋該主題。
從專業的角度來看，這個主題很少在大學裡教授，通常只是在快速介紹其他協議套件的時候一帶而過。軟體開發人員通常透過主管將一堆規格文件、帶有 API 文件的驅動程式磁碟以及通常很短的截止日期放到他們的辦公桌上，來接觸這個主題，要求他們在去年應該完成的任務上取得進展。真正瞭解序列資料通訊的軟體開發人員價值連城，而且即使是這些開發人員，通常也只是學到足以完成眼前任務的知識。
我還發現，從開發序列資料通訊中學到的技能可以應用到其他專案中，並能更深入地理解幾乎所有資料傳輸系統。除了我提到的其他群體之外，我還針對那些不幸的軟體工程師，他們試圖學習關於這個非常困難的主題的任何知識，卻不知道從哪裡開始。關於序列通訊的文件很少，而且有時自相矛盾。
這個主題並不一定很複雜，即使是普通人也能理解所有工作原理。
- 思科對 OSI 模型的解釋(頁面已刪除)
- 印第安納大學/Unix 支援小組對 OSI 的解釋(頁面已刪除)
- ISO OSI 標準目錄(頁面已刪除)
序列程式設計: 簡介和OSI網路模型 -- RS-232接線和連線 -- 典型的RS232硬體配置 -- 8250 UART -- DOS -- MAX232驅動器/接收器系列 -- Windows中的TAPI通訊 -- Linux和Unix -- Java -- Hayes相容調變解調器和AT命令 -- 通用序列匯流排(USB) -- 形成資料包 -- 錯誤糾正方法 -- 雙向通訊 -- 資料包恢復方法 -- 序列資料網路 -- 實際應用開發 -- 序列連線上的IP