序列程式設計/調變解調器和 AT 命令

序列程式設計: 介紹和 OSI 網路模型 -- RS-232 佈線和連線 -- 典型 RS232 硬體配置 -- 8250 UART -- DOS -- MAX232 驅動/接收器系列 -- Windows 中的 TAPI 通訊 -- Linux 和 Unix -- Java -- Hayes 相容調變解調器和 AT 命令 -- 通用序列匯流排 (USB) -- 形成資料包 -- 錯誤校正方法 -- 雙向通訊 -- 資料包恢復方法 -- 序列資料網路 -- 實際應用開發 -- IP 透過序列連線

介紹

概述

此內容是序列程式設計書籍的一部分。它涵蓋了 Hayes 和 Hayes 相容電話調變解調器的程式設計。這種型別的調變解調器是消費類應用的標準，也是許多專業應用的標準 - 基本上，只要調變解調器仍在使用的地方。

調變解調器程式設計正在慢慢成為一種失傳的技藝，尤其是在使用者從撥號線路遷移到 DSL 的過程中，原因顯而易見。然而，調變解調器仍然用於許多應用。近年來，調變解調器出現在以前沒有出現的新領域。例如，機器中的嵌入式調變解調器用於在機器需要維護時自動“呼叫”製造商。這通常透過無線電話系統完成，其中無線模組仍然為撥號和資料傳輸提供 Hayes 相容的介面。

原始的 Hayes 調變解調器命令集僅在本模組中用作參考。不包括供應商特定的擴充套件，也不屬於本模組。該模組解釋了術語Hayes的起源以及相關的AT 命令。它還包含一些有關調變解調器是什麼以及如何與調變解調器進行訊號傳輸的基本資訊。然後該模組繼續描述調變解調器程式設計的基礎知識，包括設定開發環境。

此外，該模組還提供了詳細的（但不完整）程式設計資訊以及不完整的原始 Hayes 命令集和暫存器的參考。

管理資訊

本節特別針對潛在的作者。請注意

• 本模組不是用於隨機調變解調器程式設計資訊和民間傳說的垃圾場。
• 本模組是作業系統不可知的。程式設計序列資料通訊書籍提供了其他模組以獲取此類資訊。
• 本模組處理通用 Hayes 調變解調器，而不是任何供應商特定的擴充套件。如果您確實想看到您的特定“心頭愛”被涵蓋，請提供一個包含該供應商/品牌特定資訊的附錄。
• 不要認為僅僅因為某些功能在您的特定調變解調器上有效，它就是標準，而其他調變解調器也是以相同的方式執行。如果您沒有第一手經驗證明某項功能在“幾乎”所有 Hayes 相容調變解調器上都以相同的方式執行，那麼就不要包括它，或者至少將其標記為可疑。

這個模組堅持使用原始的 Hayes 命令集的原因是為了有一個明確的界限。此模組並非意圖作為參考手冊。一旦掌握了基本集並實現了程式碼，處理特定於供應商的擴充套件就相當簡單。其他擴充套件，例如非常粗糙和基本的傳真擴充套件，需要深入瞭解所涉及的協議（例如，在傳真情況下，需要了解傳真資料在電話線上的詳細編碼、壓縮和時序）。這超出了本書的範圍。如果您知道如何處理傳真擴充套件，請自己編寫一本關於傳真擴充套件的書籍。

什麼是 Hayes？

Hayes 微型計算機產品公司是一家調變解調器製造商，從 20 世紀 80 年代初到 90 年代末，其鼎盛時期是在 90 年代初。Hayes 這一名稱仍然作為一個品牌名稱存在，歸 Zoom 電信公司所有（截至 2004 年秋季）。

1981 年，Hayes 開發了Hayes Smartmodem。這在當時是一款獨特的產品，因為該調變解調器不再僅僅是“啞”裝置，盲目地將序列資料轉換為音訊音調，而是包含了一些“智慧”。可以向調變解調器傳送命令以配置它，執行某些操作（例如撥號、靜音揚聲器、結束通話電話等），以及讀取連線的當前狀態。Hayes 開發併發布了一個命令集，用於透過序列線控制調變解調器。該命令集在消費級調變解調器製造商中流行起來，並被許多不同的製造商克隆。它被稱為“Hayes 命令集”和“AT 命令集”，長期以來一直是控制消費級調變解調器以及許多專業調變解調器的實際標準。支援此命令集的調變解調器被稱為Hayes 相容。

這些命令在某個時間點進行了標準化，但是，正如標準中常見的，存在多個標準。當然，還存在特定於供應商的擴充套件，並且不同調制解調器中的實現略有不同。這些增強功能中的一部分是必需的，以便支援當時新興的功能，例如資料壓縮和傳真支援。因此，現代調變解調器的命令集彼此並不完全相容。但是，原始的 Hayes 命令仍然可以正常工作，並且仍然構成幾乎所有消費級調變解調器命令集的核心。

基本命令集在某個時間點被標準化為 TIA/EIA-602，語法為 EIA/TIA-615。但如前所述，調變解調器製造商添加了他們的擴充套件。一個更大的擴充套件集，特別是在手機制造商的壓力下，被標準化為 ITU V.250（舊名稱為 V.25ter）。它通常構成專業 Hayes 相容調變解調器和內建資料調變解調器的手機的基礎。ITU V.250 進一步引用了一組其他標準（例如 V.251、V.252、V.253）以用於特定應用和擴充套件，並且還有一些補充。當然，還有許多標準定義了調變解調器的其他方面，例如壓縮和傳輸。

另請參見

• 維基百科：Hayes 通訊
• 在標準撥號調變解調器之間傳輸資料

什麼是 AT 命令？

幾乎所有 Hayes 調變解調器命令都以兩位字母序列AT開頭，用於獲得調變解調器的注意。因此，調變解調器命令通常被稱為AT 命令。這對許多特定於製造商的命令集擴充套件仍然有效。它們中的大多數也以AT開頭，也被稱為AT 命令。請注意，僅僅因為 AT 命令包含一個&並不意味著它是一個擴充套件。&命令已經是原始 Hayes 命令集的一部分。

術語AT 命令集的具體用法因製造商而異，通常取決於營銷宣傳。一般來說，可以假設具有AT 命令集的調變解調器

• 使用以AT開頭的命令，
• 使用原始 Hayes 的方法來分離資料和命令，以及
• 支援原始的 Hayes 命令和暫存器設定作為子集。

什麼是調變解調器？

從經典意義上講，調變解調器是用於透過模擬線路傳輸數字資訊的調製/解調器，例如模擬電話系統的雙線或四線線路。該術語已經成為可以接受的俚語，用於描述許多通訊裝置，這些裝置用於將計算機連線到另一臺計算機或廣域網 (維基百科：WAN)。例如，Ricochet 無線資料收發器通常被稱為“Ricochet 調變解調器”。

本模組處理經典型別的智慧調變解調器，旨在將資料從/向序列介面轉換為/從模擬線路。該模組也適用於提供經典序列介面但透過不同的物理層（例如數字線路）連線的調變解調器，以及為其他目的提供序列調變解調器式介面的裝置。就我們的目的而言，調變解調器是經典的 DCE（資料通訊裝置），透過序列線由經典的 DTE（資料終端裝置）（例如計算機）控制。

根據調變解調器的型別，調變解調器可以使用多種不同的技術和速度在模擬線路上傳輸資料。這些技術的細節在這裡不是特別重要，除了要注意，大多數調變解調器都可以指定這些通訊引數（例如，停用壓縮或更改調製技術）。本模組處理的資料不是模擬線路上的資料，而是出現在 DTE 和 DCE 之間的序列介面上的資料。也就是說，由計算機等裝置讀取和寫入的資料。

（智慧）調變解調器還提供輔助服務，例如撥號以建立連線。因此，調變解調器可以處於多種不同的狀態和模式，這些狀態和模式並不總是正交的。例如，調變解調器可以在命令模式下，同時保持與遠端方位的連線（有關詳細資訊，請參見+++序列）。

非智慧調變解調器必須依賴其他裝置（如 ACU（自動呼叫單元））才能提供這些輔助服務，但它們在今天實際上已經滅絕了。

帶內訊號

原始的 RS232C/V.24 規範包含用於傳輸資料的 TX 線和用於接收資料的 RX 線，以及其他完全獨立的線，用於在 DTE 和 DCE 之間傳輸控制資訊，其目的是分離資料和控制資訊。在電信術語中，這被稱為帶外訊號。

Hayes 相容調變解調器幾乎不使用任何這些 RS232C/V.24 功能。相反，與調變解調器的通訊幾乎完全透過用於傳輸資料的相同 RX/TX 線完成。這種機制被稱為帶內訊號。

帶內訊號有很大的缺點。在任何時間點，DTE 和 DCE 都必須知道透過 TX 和 RX 線傳送或接收的資訊是用於訊號目的，還是資料，應該透明地處理。因此，DTE 和 DCE 必須同步執行。如果它們不同步，資料將丟失，資料將被錯誤地解釋為命令，或者訊號資訊將被解釋為資料，從而有效地破壞原始資料。

帶內訊號的優點是 DTE 和 DCE 之間的佈線更簡單，並且至少乍一看，DTE 中的通訊軟體更簡單。

如前所述，Hayes 相容調變解調器幾乎不使用任何 RS232 控制線。但這僅僅是幾乎。例如，它們通常驅動 DCD（資料載波檢測）。這會造成這樣的情況，即調變解調器驅動軟體現在不僅要處理帶內訊號，還要處理與調變解調器的帶外訊號。這會稍微複雜化通訊軟體的 狀態機。

此外，特別是在手機調變解調器興起的情況下，製造商再次開始引入更多帶外訊號。這些調變解調器提供多個虛擬序列介面。這些介面中的一些專門用於資料傳輸，由另一個序列介面控制，該介面要麼專門用於訊號（即帶外訊號），要麼仍然也可以用於更傳統的帶內訊號場景。在這種情況下，通訊軟體需要管理更復雜的狀態。

命令狀態 / 聯機狀態

在控制調變解調器方面，Hayes 相容調變解調器處於兩種主要狀態之一

命令狀態

調變解調器將來自 DTE 的資料解釋為調變解調器命令。調變解調器可以在命令狀態下，同時保持與遠端方的連線。

聯機狀態

調變解調器將來自 DTE 的資料解釋為有效負載，並將其傳輸到另一方。此狀態要求已建立與遠端站點的連線。

在這些主要狀態內部，還有許多子狀態。此外，在其他問題方面，調變解調器還有許多通訊狀態，例如，遠端載波是否被檢測到。

發起模式 / 應答模式

發起模式

處於發起模式的調變解調器是指正在建立連線的調變解調器，例如透過撥打遠端站點的號碼並啟動協議協商來建立連線。

應答模式

處於應答模式的調變解調器是指正在等待被聯絡，並準備“接聽電話”的調變解調器。

命令響應

調變解調器應該對收到的幾乎所有命令傳送響應。這些響應可以是 ASCII 字串的形式，也可以是數值形式。響應型別可以透過命令切換，但通常使用 ASCII 響應。

DTE 需要非常仔細地跟蹤響應。除了其他資訊外，它們還向 DTE 提供有關遠端站點撥號是否成功，以及調變解調器是否從命令狀態切換到線上狀態的資訊。

不幸的是，自原始的 Hayes 調變解調器以來，響應訊息集已經得到了很大的擴充套件，並且通常可以透過額外的 AT 命令進行配置。建議不要嚴格解析響應訊息，而是寬容地檢查它們是否包含有趣的關鍵字，例如 CONNECT。還建議仔細研究特定調變解調器的使用手冊。

S-暫存器

所謂的 S-暫存器也是 Hayes 的遺產，所有與 Hayes 相容的調變解調器都支援它。它們是調變解調器中的暫存器，包含各種設定。與 AT 命令一樣，它們也被不同的調變解調器製造商廣泛增強。

它們被稱為S-暫存器的原因有點不清楚。有些人說S代表調變解調器的設定。有些人說它們就這樣被稱作，因為它們是透過ATS... 命令設定和讀取的。在通俗的說法中，它們通常被稱為儲存暫存器，因為它們即使在斷電後也會永久儲存值。

其他幾個AT命令也會改變特定 S-暫存器的值。直接透過 S-暫存器設定值或透過其他AT命令設定值通常沒有區別。哪種設定暫存器的方法更好取決於具體情況。

調變解調器程式設計基礎

命令參考

為了對實際的調變解調器進行程式設計，最好獲取該特定調變解調器的命令參考。不幸的是，無名調變解調器沒有附帶任何可用的命令參考已經變得非常普遍。由於 Windows 的即插即用功能，在 Windows 上不再需要知道單獨的命令。相反，調變解調器在 Windows 上執行所需要的只是附帶必要的.inf檔案（通常隱藏在一些“安裝程式”軟體中，被稱為“驅動程式”，這在技術上是不正確的，因為 Windows 已經包含了必要的驅動程式）。

如果調變解調器沒有附帶命令參考，那麼下一個合乎邏輯的步驟是在網上搜索。然而，不幸的是，近年來，許多調變解調器資訊已經從地球表面和網際網路上消失了。隨著寬頻網際網路連線的興起，調變解調器已經成為過時的裝置，許多來源不再可用。找到有關特定調變解調器型別的基本資訊變得越來越困難。即使對於現代的調變解調器，例如手機調變解調器，也可能難以找到必要的資訊。

如果沒有調變解調器附帶命令參考，那麼可以透過多種方法獲取它

• 也許經銷商會在其網站上提供。
• 也許 OEM 製造商會提供。
  這需要識別 OEM 製造商。一種可能的方法是使用裝置的 FCC 號碼，然後在 FCC 網站上查詢原始製造商。
• 也許晶片組製造商會提供。
  消費級調變解調器通常只是圍繞來自大型硬體製造商的“現成”調變解調器晶片組構建的。調變解調器越便宜，調變解調器製造商在韌體中沒有進行任何更改，而是使用晶片組製造商提供的原始示例軟體的可能性就越大。一些晶片組供應商為其調變解調器提供命令參考。
• 透過檢視相應的 Windows .inf 檔案，至少可以獲取基本命令
• 透過使用本華夏公益教科書模組中的通用 Hayes 命令參考。
• 如果存在表明特定調變解調器符合此類命令標準的指示，則獲取之前提到的標準文件。
• 使用某種嗅探程式來監控調變解調器和 DTE 之間的通訊，並使用獲得的資訊反向工程命令。這要求 (a) 反向工程在您的司法管轄區內是合法的，以及 (b) 有一些可用的 DTE 通訊軟體可以處理特定的調變解調器，以便有一些有效的通訊可以嗅探。

設定開發環境

強烈建議在開始編寫調變解調器的驅動程式或軟體之前，花一些時間來設定一個合適的開發環境。大部分工作都是硬體設定。

建議使用一臺“遠端”計算機和一臺處於應答模式的第二臺調變解調器來建立一個小網路。“遠端”計算機在這種情況下是指一臺與開發機器相鄰但透過調變解調器連線的計算機。如果正在開發終端程式，那麼“遠端”計算機應該執行一些小型 BBS 軟體（例如），這樣總有人可以接聽，或者執行協議分析/資料轉儲軟體。沒有這樣的設定，開發調變解調器軟體會非常令人沮喪。這樣的設定可以使開發時間縮短，壓力減輕百倍。同樣，所使用的調變解調器應該有真正的揚聲器，並支援ATMn 命令，這樣您就可以在整個連線過程中保持揚聲器開啟（理想情況下，可以選擇始終保持揚聲器開啟）。“透過耳朵除錯”對於調變解調器來說是現實的，尤其是在相容性測試期間。

如果可能的話，應該獲得一個硬體協議分析儀，或者至少一個RS-232 分線盒。如果需要，這些可以放在計算機和調變解調器之間，以對序列鏈路進行故障排除，並確保資料確實在調變解調器和計算機之間傳輸——這是一個比你想象中更經常派上用場的健全性檢查。實際的硬體協議分析儀價格驚人地昂貴，但是，舊的 Wyse 終端並不昂貴，並且幾乎可以滿足這個目的。如果您找到一個，就買下來吧。支援自動波特率檢測的終端特別有用。

如果還需要測試調變解調器的撥號功能，那麼需要一個小型模擬 PABX 用於家庭使用。這些 PABX 機器的價格非常便宜；一個用於四個內部線路和一個外部線路的模擬 PABX 應該不超過 50 美元。如果不需要撥號，那麼調變解調器應該能夠在專線模式下直接驅動兩線或四線線路；否則，仍然需要 PABX。

可能的設定例如

a) 專線模式

+-------------+  serial  +---------+  2-wire  +----------+  serial  +----------+
| Development |----------| Modem A |----\/----| Modem B  |----------| BBS      |
|  Computer   |----------|         |----/\----| (answer) |----------| Computer |
+-------------+          +---------+          +----------+          +----------+

或者

b) 使用 PABX

+-------------+  serial  +---------+  phone wire  +------+  phone wire  +----------+  serial  +----------+
| Development |----------| Modem A |--------------| PABX |--------------| Modem B  |----------| BBS      |
|  Computer   |----------|         |--------------|  X   |--------------| (answer) |----------| Computer |
+-------------+          +---------+              +------+              +----------+          +----------+

或者

c) 使用協議分析儀的專線模式

+-------------+  serial  +---------+  serial  +---------+  2-wire  +----------+  serial  +----------+
| Development |----------| Y Cable |----------| Modem A |----\/----| Modem B  |----------| BBS      |
|  Computer   |----------| Breakout|----------|         |----/\----| (answer) |----------| Computer |
+-------------+          +---------+          +---------+          +----------+          +----------+
                              ||
                              ||
                              ||
                         +----------+ 
                         | Protocol |
                         | Analyser |
                         +----------+

當然，其他組合也很有用。而且能夠輕鬆地重新連線協議分析儀，例如，在調變解調器 B 和 BBS 計算機之間，也很有用。

作業系統、程式語言和通訊基礎

在處理調變解調器處理的細節之前，應該先了解一些基礎知識。首先，應該確保與序列介面的通訊正常。這包括理解特定作業系統提供的用於序列通訊的 API（如果有的話）。如果作業系統沒有提供此類 API，那麼建議首先實現 UART 訪問，並將其封裝到一個庫中，如果某些硬體中的序列 UART 應該直接程式設計。或者，可以使用提供方便的序列介面訪問的程式語言。

無論使用什麼，都應該在開始對調變解調器進行程式設計之前進行測試。沒有什麼比不知道特定錯誤行為是由與調變解調器的序列通訊故障引起，還是由調變解調器本身的問題（通常是由傳送給它的命令引起的）更令人惱火。

除非是最簡單的情況，建議使用硬體握手與調變解調器通訊，特別是對於大於2400 bit/s或9600 bit/s的速度。因此，所使用的低階序列通訊軟體和硬體應支援硬體握手。如果UART支援某些FIFO，例如16550 UART，則應啟用FIFO（用於傳送和接收資料）。

尚不清楚透過輪詢或中斷接收資料哪種更好。如果每個傳入位元組都會引發一箇中斷，則在高速通訊情況下會產生許多中斷，而且令人驚訝的是，在這種情況下，輪詢UART可能更有效。

調變解調器支援的通訊通常是半雙工的。要麼是DTE要麼是DCE說話，另一方應該傾聽。與調變解調器的通訊最好使用以下方式：

• 8位
• 無奇偶校驗
• 1個停止位

有關速度資訊，請參見下一節。

線路速度不是DTE/DCE速度

+-------------+  DTE/DCE speed +---------+  line speed
|    DTE /    |----------------| Modem / |--------------
|  Computer   |----------------|  DCE    |--------------
+-------------+                +---------+ 

有用提示！
一些調變解調器製造商將DTE/DCE速度稱為DTE速度，並將線路速度稱為DCE速度。另一些則區分DTE速度（序列介面上的DTE/DCE速度）、DCE速度（調變解調器之間的bps）和線路速度（調變解調器之間的波特率）。仔細觀察術語可以幫助正確理解制造商的文件。

一個非常令人困惑的問題是線路速度（電話線上的資料傳輸速度）與DTE（計算機）和DCE（調變解調器）之間序列線路上的速度之間的區別。

首先，線路速度總是存在一些普遍的混淆，因為一些線路速度是在考慮壓縮的情況下給出的，而其他資料則是在不考慮壓縮的情況下給出的。此外，由於線上使用的調製方案，bps和波特率之間存在差異。此外，營銷宣傳模糊了畫面。我們不會在這裡嘗試清理長期存在的波特率與bit/s之間的混淆（這是無望的:-))。只是建議，每當調變解調器返回有關線路速度的資訊時，都要考慮到上述差異，以避免任何誤解。

其次，電話線上的速度不一定要與序列線上的速度相同。事實上，它通常與現代調變解調器不同。建議將DTE/DCE速度設定為固定速度，而不是遵循線路速度。從邏輯上講，固定DTE/DCE速度應該足夠大，以應對預期的最高線路速度。例如，V.90調變解調器應該透過序列介面以115200 bit/s或更高的速度訪問。

在現代調變解調器上設定DTE/DCE速度非常簡單。它們都在序列介面上使用自動檢測。也就是說，它們自己檢測從DTE接收到的資料的速度，並使用相同的速度將資料返回給計算機。它們通常也自動檢測奇偶校驗和7位/8位資料長度。通常，調變解調器在自動檢測序列介面時假設一個停止位。因此，只需將DTE上的序列介面配置為所需的DTE/DCE通訊引數，並讓調變解調器自行解決即可。

在極少數情況下，自動檢測可能會失敗，一些調變解調器的自動檢測可能已損壞。如果調變解調器傾向於自動檢測失敗，可以嘗試在DTE配置好後，用一個或多個nop AT命令啟動初始通訊

AT<CR>

重複有限的次數，直到調變解調器開始返回

OK

用於nop命令。

當調變解調器與遠端方建立連線時，它可以報告使用過的速度。事實上，它可以報告線路速度或僅僅是DTE速度（一些調變解調器可以同時報告兩者）。終端使用者最有可能對線路速度感興趣，而不是DTE/DCE速度。所以從這個角度來看，最好將調變解調器設定為報告線路速度，例如，將接收到的資訊寫入日誌檔案。但是，一些舊的通訊軟體或調變解調器驅動程式將調變解調器的響應解釋為更改DTE/DCE速度的請求。在這種情況下，必須將調變解調器設定為始終返回DTE/DCE速度。由於此DTE/DCE速度將與透過自動檢測檢測到的速度相同，因此不會發生速度變化。

在極少數情況下，DTE/DCE速度確實應該跟隨線路速度，那麼調變解調器的響應應該設定為返回線路速度。然後，DTE軟體必須評估響應，並相應地更改DTE/DCE速度。現在確實不建議這樣做。

有關如何設定要獲取哪個響應的詳細資訊，請參見#W: 協商進度訊息選擇命令。

字元集和字元大小寫

傳送到調變解調器的命令和文字響應應該使用ISO 646字元集。ISO 646只是熟悉的7位ASCII字元集的另一個名稱。通常，調變解調器會將它們接收到的任何第8位截斷。它們將結果解釋為如果命令僅使用7位字元傳送。但是，不建議依賴於此，而是確保命令僅使用7位字元傳送。

命令不區分大小寫，假設是現代調變解調器。一些早期的調變解調器堅持使用全大寫命令。儘管如此，一個通用的驅動程式可以做的是確保所有命令都以大寫形式傳送，並且所有響應都以不區分大小寫的方式解釋。通常，AT命令字首的兩個字母必須具有相同的大小寫。因此，AT和at是可以接受的，而At和aT則不是。

歡迎來到狀態機世界

調變解調器程式設計意味著進入電信世界。這對大多數業餘程式設計師以及專業程式設計師來說都是一個未知的領域。電信高度依賴於狀態機。事實上，如果不使用狀態機，就很難或不可能對調變解調器進行程式設計。調變解調器在任何時刻都處於特定狀態，任何試圖控制和使用調變解調器的DTE軟體都需要在自己的狀態機中跟蹤調變解調器的狀態。這是必要的，因為Hayes相容的調變解調器只有在特定狀態下才能執行某些操作。例如，它只有在未連線到任何遠端站點時才能撥出。

調變解調器部分狀態可以透過特定RS-232線路進行跟蹤。例如，DCD（資料載波檢測）可以用來判斷調變解調器是否檢測到遠端調變解調器的載波訊號。其他資訊由流控制線路提供。但是，一些狀態和相關資料需要透過解釋調變解調器的結果程式碼來跟蹤。

不熟悉狀態機理論和實踐的人經常試圖透過“硬編碼”來規避這個問題。這意味著，他們將越來越多的程式碼新增到問題中（包裹在if/the/else/otherwise/maybe/...語句中），直到事情看起來可以工作——有點。如果他們幸運的話，他們已經隱式地建立了一個可以工作的狀態機。如果他們不走運，他們最終會得到一個部分狀態機，如果通訊中發生異常情況，它就會崩潰。這通常伴隨著一個問題，即軟體沒有被設計為在發生故障時恢復。因此，此類軟體往往會掛起或崩潰。

首先花幾個小時學習簡單狀態機的基礎知識，然後花幾個小時將與調變解調器的通訊描述為狀態機，效率會高得多。這種規劃的結果可以作為實現DTE軟體的良好模板。

流控制

慢速裝置需要一種方法來告訴其對等方，它目前很忙，因此必須停止進一步的傳入資料，直到此慢速裝置另行通知。這種機制由流控制提供。有兩種方法可以實現流控制：透過硬體或軟體。

硬體流控制

硬體流控制通常使用 CTS（清除傳送）和 RTS（請求傳送）線路實現，這需要裝置之間單獨的硬體資料線路。這是在 RS-232 電纜規範中分配的。

基於 DSR（資料裝置就緒）和 DTR（資料終端就緒）的硬體流控制並不常見，特別是對於調變解調器而言。它通常可以在序列印表機上找到。同樣，DSR/DTR 硬體流控制需要裝置之間額外的硬體資料線路。

從程式設計的角度來看，程式設計 CTS/RTS 或 DSR/DTR 硬體流控制通常沒有太大區別。硬體必須提供驅動/讀取序列介面中相應訊號的方法。如果硬體同時支援 CTS/RTS 和 DSR/DTR 流控制，則建議同時支援兩者，併為使用者提供配置選項。

需要注意的是，某些硬體或作業系統驅動程式不提供驅動/讀取不太常見的 DSR/DTR 組合的方法。如果遠端裝置堅持使用 DTR/DSR 流控制，一種常見的解決方法是在軟體中使用 CTS/RTS，但重新連線佈線，使 CTS/RTS 線實際上連線到 DSR/DTR。

軟體流控制

這種流控制不需要像硬體流控制那樣需要額外的訊號線，而是使用資料內容中的特殊控制字元。為了停止進一步的傳入資料，接收裝置傳送 XOFF 字元。為了啟用更多資料，將傳送一個 XON 字元。

但是，由於正在傳送的資料不能包含這些字元（除非您知道接收裝置忽略此類資訊），因此二進位制（非 ASCII）資料無法以這種方式傳輸。軟體流控制通常用於與終端和其他基於字元的裝置的通訊。不應以這種方式傳送二進位制資料，因為它可能隨機包含這些字元。通常使用使用 RTS/CTS 的硬體流控制。

有用提示：意識到控制鍵是一個特殊的“移位”鍵，它切斷了第 100 位（八進位制），因此很容易記住用於傳送 XOFF 的 ASCII 字元是 Control-S（八進位制 23），而 XON 的字元是 Control-Q（八進位制 21）。[想想“S”表示停止，“Q”表示繼續……你不這樣拼寫嗎？]

狀態更改

概述

從命令狀態更改為線上狀態或反之亦然，要麼很簡單，要麼就是一個巨大的謎團。本模組涵蓋了更模糊的方法。

線上狀態到命令狀態

當然可以透過斷開連線（用調變解調器術語來說是結束通話電話）從線上狀態切換到命令狀態。也可以在保持連線的情況下臨時切換到命令狀態。

以程式設計方式結束通話電話（而不是透過斷開調變解調器控制線）需要首先在保持連線的情況下切換到命令狀態。

切換到命令狀態，實際上是在資料傳輸過程中（線上狀態沒有別的意思）需要傳送一個特定的轉義序列作為資料的一部分。調變解調器檢測到該轉義序列，調變解調器更改狀態。由於此字元序列也可能是正常資料的組成部分，因此需要額外的機制來將轉義序列與正常資料區分開來。這是帶內信令的詛咒。

轉義序列的分隔是透過使用所謂的保護時間完成的，保護時間曾經是 Hayes 的專利。結果，一些調變解調器製造商使用稱為時間無關轉義序列的替代轉義序列消除了保護時間。無論如何，只有在來自 DTE（終端）沒有其他資料至少持續保護時間，並且在轉義序列後來自終端沒有其他資料至少持續保護時間的情況下，調變解調器才會識別該轉義序列。

轉義序列由三次相同的特定字元組成。字元以及保護時間是可配置的。預設情況下，字元是+，保護時間為一秒。因此，在預設配置下，更改為命令狀態需要

<1 sec. nothing>+++<1 sec. nothing>

如果連線應該斷開，則此轉義序列後面應該跟著AT 命令以結束通話電話，即ATH0

<1 sec. nothing>+++<1 sec. nothing>ATH0<CR>

命令狀態到線上狀態

從命令狀態切換到線上狀態的通常方法是透過撥號遠端站點（參見D 命令）。但是，如果連線已經存在，並且調變解調器已透過轉義序列切換到命令模式，則方法不同。

如果連線不應斷開，而是應該繼續資料傳輸，則需要使用ATO0（字母 o，數字零）命令

<1 sec. nothing>+++<1 sec. nothing>
send a few more modem commands, then go back on-line
ATO0<CR>

AT 命令

以下列表是原始 Hayes 命令的列表。不同的調變解調器使用略微不同的命令。但是，此列表應該儘可能“通用”，不應擴充套件到調變解調器特定的命令。建議在附錄中提供此類命令列表。

AT 命令格式

以下是 AT 命令的格式和語法的總結。請注意，大多數控制字元是可配置的，總結只使用預設控制字元。

• 只有在命令模式下，調變解調器才會接受 AT 命令。可以透過#+++: 轉義序列強制調變解調器進入命令模式。

• 命令分組到命令列中。

• 每條命令列必須以#AT: 命令字首開頭，並以#<CR>: 行結束符結尾。唯一的例外是#A/: 重複上次命令命令。

• 命令列的正文由可見的 ASCII 字元（ASCII 碼 32 到 126）組成。空格（ASCII 碼 32）和 ASCII 控制字元（ASCII 碼 0 到 31）被忽略，除了#<BS>: 退格符、#<CAN>: 取消字元和#<CR>: 行結束符。

• 所有在#AT: 命令字首之前的字元都被忽略。

• 命令列的解釋/執行從第一個（也是命令列終止符）#<CR>: 行結束符的接收開始。

• 在初始#AT: 命令字首之後，以及#<CR>: 行結束符之前的字元被解釋為命令。除了一些例外，一條命令列中可以有多個命令。

• 每個基本命令都由一個單個 ASCII 字母或一個以&為字首的單個 ASCII 字母，後跟一個數值組成。缺少的數值被解釋為0（零）。

• 以下命令不能在命令列中跟隨更多命令。它們必須始終是命令列中的最後一個命令。如果它們後面跟著其他命令，則這些其他命令將被忽略。但是，其中一些命令採用命令修飾符，並且可能會錯誤地將後續命令解釋為命令修飾符。因此，應注意不要在同一條命令列中使用這些命令之後的任何命令。相反，它們應該放在單獨的命令列中。
  • #A: 應答命令
  • #D: 撥號命令
  • #Z: 軟復位命令

• 如果未輸入終止的#<CR>: 行結束符，可以使用#<BS>: 退格符一次刪除一個命令列字元來編輯命令列。初始#AT: 命令字首無法編輯/刪除（它已經處理過了，因為在接收到#AT: 命令字首時，調變解調器立即開始命令列解析和編輯，但沒有執行）。

• 當 #E: 命令狀態字元回顯選擇 處於開啟狀態時，調變解調器會回顯命令列和編輯內容（令人驚訝的是，它確實會這樣做 :-)).

• 當回顯開啟時，#<BS>: 退格字元 會以 <BS> <BS>（退格、空格、退格）的序列回顯，用於擦除 DTE 上例如終端程式中的最後一個字元。

• 在傳送終止符 #<CR>: 行結束符 之前，可以透過傳送 #<CAN>: 取消字元 來隨時取消命令列。在這種情況下，命令列中的任何命令都不會被執行。

• 只要與遠端站點的手握過程尚未完成，#A: 接聽命令 和 #D: 撥號命令 也可以被取消。取消是透過傳送一個額外的字元來完成的。理論上，傳送哪個字元並不重要。但要注意，在手握過程已經完成的情況下，不要嘗試取消命令。在這種情況下，調變解調器已經切換到線上狀態 (#命令狀態到線上狀態)，並且該字元將被髮送到遠端站點。避免此問題的安全方法是始終使用 #+++: 轉義序列，然後使用 #H: 掛機命令選項 掛機。如果調變解調器已經處於線上狀態，這將斷開連線。如果調變解調器仍然處於手握階段，則 #+++: 轉義序列 的第一個字元將取消命令（其餘字元將被解釋為正常的命令列，不會造成任何損害）。

• 當命令列中的第一個命令失敗或整個命令列已執行完畢時，命令列執行停止。在失敗命令之前的每個命令都已執行。命令列中失敗命令之後的每個命令以及失敗命令本身都沒有被執行。

• 沒有特別指示哪條命令在命令列中失敗，只知道有一條命令失敗。最好重複整個命令列，或者在從錯誤中恢復之前先將調變解調器重置到已知狀態。

• 調變解調器只有在先前命令列執行完畢後才會接受新的命令列（半雙工通訊）。因此，應注意僅在收到先前命令列的結果程式碼後才傳送下一條命令列。

命令描述模板

所有命令都文件化後，將刪除。

語法

<The syntax of the command, when necessary in EBNF>

描述

<命令描述，包括關於目的和效果的資訊>

結果程式碼

結果程式碼

程式碼	描述
OK	引數有效 <成功描述>
ERROR	其他情況 <失敗描述>

相關命令和暫存器

• <相關命令和暫存器連結列表>

特殊命令和字元序列

參見 特殊命令和字元序列參考

AT 命令 A - M

參見 AT 命令 A - M

AT 命令 N - Z

參見 AT 命令 N - Z

AT& 命令

參見 AT& 命令

結果程式碼

參見 結果程式碼

S-暫存器

參見 S-暫存器

高階功能

介紹

現代消費級調變解調器提供許多額外的功能，這些功能最初在調變解調器中並不常見，但隨著時間的推移已成為標準功能。本節概述瞭如何對這些功能進行程式設計。

語音服務

序列程式設計: 介紹和 OSI 網路模型 -- RS-232 佈線和連線 -- 典型 RS232 硬體配置 -- 8250 UART -- DOS -- MAX232 驅動/接收器系列 -- Windows 中的 TAPI 通訊 -- Linux 和 Unix -- Java -- Hayes 相容調變解調器和 AT 命令 -- 通用序列匯流排 (USB) -- 形成資料包 -- 錯誤校正方法 -- 雙向通訊 -- 資料包恢復方法 -- 序列資料網路 -- 實際應用開發 -- IP 透過序列連線