序列埠程式設計/調變解調器和AT命令
序列埠程式設計: 簡介和OSI網路模型 -- RS-232佈線和連線 -- 典型的RS232硬體配置 -- 8250 UART -- DOS -- MAX232驅動器/接收器系列 -- Windows中的TAPI通訊 -- Linux和Unix -- Java -- Hayes相容調變解調器和AT命令 -- 通用序列匯流排 (USB) -- 形成資料包 -- 糾錯方法 -- 雙向通訊 -- 資料包恢復方法 -- 序列資料網路 -- 實際應用開發 -- IP over序列連線
簡介
[edit | edit source]概況
[edit | edit source]此內容是序列埠程式設計書籍的一部分。它涵蓋了Hayes和Hayes相容電話調變解調器的程式設計。這種型別的調變解調器在消費者應用和許多專業應用中很常見——基本上，只要調變解調器仍在使用的地方都會使用它們。
調變解調器程式設計正逐漸成為一種失落的藝術，特別是在使用者從撥號線路遷移到DSL的趨勢中，這是出於效能上的明顯原因。然而，調變解調器在許多應用中仍在使用。近年來，調變解調器出現在以前未曾出現的新領域。例如，機器中的嵌入式調變解調器用於在機器需要維修時自動“呼叫”製造商。這通常透過無線電話系統完成，無線模組仍然為撥號和資料傳輸提供Hayes相容介面。
原始的Hayes調變解調器命令集在此模組中僅用作參考。本模組不涵蓋供應商特定的擴充套件，也不屬於本模組。該模組解釋了術語Hayes的起源以及相關的AT命令。它還包含有關調變解調器是什麼以及如何與調變解調器進行信令的一些基本資訊。該模組隨後繼續描述調變解調器程式設計的基礎知識，包括開發環境的設定。
此外，該模組提供了詳細的（但不完整）程式設計資訊，以及原始Hayes命令集和暫存器的不完整參考。
管理資訊
[edit | edit source]本節特別針對潛在作者。請注意
- 本模組不是用於隨機的調變解調器程式設計資訊和民間傳說的垃圾場。
- 本模組是作業系統無關的。序列埠資料通訊程式設計書籍提供了其他模組來提供此類資訊。
- 本模組處理通用Hayes調變解調器，而不是任何供應商特定的擴充套件。如果你真的想看到你自己的特定產品被涵蓋，請提供一個包含該供應商/品牌特定資訊的附錄。
- 不要假設僅僅因為某些功能在你的特定調變解調器上有效，它就是標準並且其他調變解調器也是這樣做的。如果你沒有第一手經驗表明某些功能在“幾乎”所有Hayes相容調變解調器上都是相同的，那麼請將其省略，或者至少將其標記為有疑問。
本模組堅持使用原始Hayes命令集的原因是，為了有一個明確的界限。本模組並非旨在用作參考手冊。一旦有人掌握了基本命令集並實現了程式碼，處理供應商特定的擴充套件就相當簡單了。其他擴充套件，例如非常粗略和基本的傳真擴充套件，需要深入瞭解所涉及的協議（例如，在傳真的情況下，需要深入瞭解傳真資料在電話線上的詳細編碼、壓縮和定時）。這超出了本書的範圍。如果你知道如何處理傳真擴充套件，那就寫你自己的書吧。
什麼是Hayes?
[edit | edit source]Hayes Microcomputer Products, Inc.是一家調變解調器製造商，從1980年代初成立到1990年代末，其鼎盛時期在1990年代初。Hayes這個名字仍然作為一個品牌名稱存在，屬於Zoom Telephonics, Inc.（截至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），用於特定應用和擴充套件，並且還有一些補充。當然，還有許多標準定義了調變解調器的其他方面，例如壓縮和傳輸。
另請參見
什麼是 AT 命令？
[edit | edit source]幾乎所有 Hayes 調變解調器命令都以兩個字母序列 AT 開頭 - 用於獲取調變解調器的 *注意*。因此，調變解調器命令通常被稱為 *AT 命令*。這對於許多製造商特定的命令集擴充套件仍然適用。大多數也以 AT 開頭，也被稱為 *AT 命令*。請注意，僅僅因為 AT 命令包含一個 *&* 並不意味著它是擴充套件。*&* 命令已經是最初的 Hayes 命令集的一部分。
術語 *AT 命令集* 的確切用法在不同的製造商之間略有不同，通常取決於營銷宣傳。一般來說，可以假設具有 *AT 命令集* 的調變解調器
- 使用大多數以
AT開頭的命令， - 使用最初的 Hayes 方式來區分資料和命令，以及
- 支援最初的 Hayes 命令和暫存器設定作為子集。
什麼是調變解調器？
[edit | edit source]
從傳統意義上講，調變解調器是用於透過模擬線路傳輸數字資訊的 **mo**dulator/**dem**odulator，例如模擬電話系統的雙線或四線線路。這個詞已經成為用於連線計算機到另一臺計算機或廣域網 ( 維基百科：WAN ) 的許多通訊裝置的通用俚語。例如，Ricochet 無線資料收發器通常被稱為“Ricochet 調變解調器”。
本模組討論的是經典型別的 *智慧* 調變解調器，旨在將資料從/到序列介面轉換為/從模擬線路轉換。本模組也適用於提供經典序列介面但透過不同物理層（例如數字線路）連線的調變解調器，以及為其他目的提供序列調變解調器式介面的裝置。對於我們的目的，調變解調器是經典的 DCE (資料通訊裝置)，透過序列線路由經典的 DTE (資料終端裝置) (例如計算機) 控制。
根據調變解調器的型別，調變解調器可以使用多種不同的技術和速度來透過模擬線路傳輸資料。這些技術的細節在這裡沒有特別感興趣，只是注意到，對於大多數調變解調器來說，可以指定這些通訊引數（例如，停用壓縮或更改調製技術）。本模組處理的資料不是模擬線路上的資料，而是序列介面上 DTE 和 DCE 之間的資料。即裝置（例如計算機）讀寫的資料。
( *智慧* ) 調變解調器還提供輔助服務，例如撥打特定號碼以建立連線。因此，調變解調器可以處於多種不同的狀態和模式，這些狀態和模式並不總是正交的。例如，調變解調器可以在命令模式下，同時保持與遠端方的連線（有關詳細資訊，請參見 +++ 序列）。
非智慧調變解調器必須依賴於其他裝置（例如 ACU (自動呼叫單元)）來提供這些輔助服務，但它們如今實際上已經滅絕。
帶內信令
[edit | edit source]最初的 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 (資料載波檢測)。這會造成調變解調器驅動軟體不僅要處理帶內信令，還要處理與調變解調器的帶外信令的情況。這會略微使通訊軟體的 狀態機 變得複雜。
此外，特別是隨著手機調變解調器的興起，製造商再次開始引入更多的帶外信令。這些調變解調器提供多個虛擬序列介面。其中一些介面專門用於資料傳輸，由另一個序列介面控制，該介面要麼專門用於信令（即帶外信令），要麼仍然可以用於更傳統的帶內信令場景。在這種情況下，通訊軟體需要管理更復雜的狀態。
命令狀態/線上狀態
[edit | edit source]關於控制調變解調器，Hayes 相容調變解調器處於兩種主要狀態之一
- 命令狀態
- 調變解調器將來自 DTE 的資料解釋為調變解調器命令。調變解調器可以在命令狀態下，同時保持與遠端方的連線。
- 線上狀態
- 調變解調器將來自 DTE 的資料解釋為有效負載，並將其傳輸到對方。這種狀態要求已建立與遠端站點的連線。
在這些主要狀態記憶體在許多子狀態。此外，關於其他問題，調變解調器具有一系列通訊狀態，例如，是否檢測到遠端載波。
發起模式/應答模式
[edit | edit source]- 發起模式
- 處於發起模式的調變解調器是正在建立連線的調變解調器，例如，透過撥打遠端站點的號碼並啟動協議協商。
- 應答模式
- 處於應答模式的調變解調器是等待被聯絡並準備“接聽電話”的調變解調器。
命令響應
[edit | edit source]調變解調器應該為它接收的幾乎所有命令傳送響應。這些響應可以是 ASCII 字串形式，也可以是數值形式。響應型別可以使用命令切換，但通常使用 ASCII 響應。
DTE 需要非常小心地跟蹤響應。除了其他資訊外，它們還告知 DTE 遠端站點的撥號是否成功，以及調變解調器是否從命令狀態切換到線上狀態。
不幸的是，自原始 Hayes 調變解調器以來，響應訊息集得到了很大增強，並且通常可以透過額外的AT命令進行配置。建議不要嚴格解析響應訊息，而應寬容地檢查它們是否包含有趣的關鍵字，例如CONNECT。還建議仔細研究特定調變解調器的使用手冊。
所謂的 S-暫存器也是 Hayes 的傳統，所有與 Hayes 相容的調變解調器都支援。它們是調變解調器中的暫存器，包含各種設定。與 AT 命令一樣，它們也已由不同的調變解調器製造商進行了廣泛的增強。
它們被稱為S-暫存器的確切原因尚不清楚。有些人說S代表調變解調器的設定。有些人說它們就是這麼稱呼的，因為它們是用ATS…命令設定和讀取的。在常用術語中，它們通常被稱為儲存暫存器，因為即使在斷電後，它們也會永久儲存值。
其他幾個AT命令也會改變特定 S-暫存器的值。透過 S-暫存器直接設定值與透過其他AT命令設定值之間通常沒有區別。哪種方法更好取決於具體情況。
為了對實際的調變解調器進行程式設計，最好獲得該特定調變解調器的命令參考。不幸的是，無名調變解調器在沒有任何可用命令參考的情況下出貨已變得很常見。由於 Windows 的即插即用功能，在 Windows 上不再需要了解各個命令。相反，調變解調器在 Windows 上執行所需的只是隨附必要的.inf檔案（通常隱藏在某些“安裝程式”軟體中，稱為“驅動程式”，從技術上講並非如此，Windows 已經包含必要的驅動程式）。
如果調變解調器沒有附帶命令參考，那麼下一步就是搜尋網路。但是，不幸的是，近年來，許多調變解調器資訊已從地球表面和網路上消失。隨著寬頻網際網路連線的興起，調變解調器已成為過時的裝置，許多資源不再可用。找到有關特定調變解調器型別基本資訊的難度越來越大。即使對於像手機調變解調器這樣的現代調變解調器，也可能難以找到必要的資訊。
如果沒有附帶調變解調器，則可以透過多種方法獲得命令參考
- 也許經銷商在其網站上提供了一個
- 也許 OEM 製造商提供了一個。
這需要識別 OEM 製造商。一種可能的方法是使用裝置的 FCC 號碼，然後在 FCC 網站上查詢原始製造商。 - 也許晶片組製造商提供了一個。
消費級調變解調器通常只是圍繞來自大型硬體製造商的“現成”調變解調器晶片組構建的。調變解調器越便宜，調變解調器製造商在韌體中不做任何更改，並使用來自晶片組製造商的原始示例軟體的可能性就越大。一些晶片組供應商為其調變解調器提供命令參考。 - 透過檢視相應的 Windows
.inf檔案，至少可以獲得基本命令 - 透過使用本 Wiki 書模組中的通用 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 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/then/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 的硬體流控制。
實用提示：認識到 Control 鍵是一個特殊的“Shift”鍵，它會截斷第 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>
 |
本頁或本節是未完成的草稿或提綱。 您可以幫助開發工作，或者您可以在專案室尋求幫助。 |
|
本頁或本節是未完成的草稿或提綱。 您可以幫助開發工作，或者您可以在專案室尋求幫助。 |
以下是原始 Hayes 命令的列表。不同的調變解調器使用略微不同的命令。但是，此列表應該是儘可能通用的，不應擴充套件到特定於調變解調器的命令。相反，建議在附錄中提供此類命令列表。
|
本頁或本節是未完成的草稿或提綱。 您可以幫助開發工作，或者您可以在專案室尋求幫助。 |
以下是 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（零）。
- 以下命令不能在命令列中跟隨更多命令。它們必須始終是命令列中的最後一個命令。如果它們後面跟著其他命令，則這些其他命令將被忽略。但是，其中一些命令接受命令修飾符，並且後面的命令可能會意外地被解釋為命令修飾符。因此，應注意不要在這些命令後面再新增任何命令。相反，它們應該放在自己的命令列中。
- 如果尚未輸入終止的#<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命令 N - Z
參見AT& 命令
參見結果程式碼
參見S-暫存器
現代消費類調變解調器提供了一些最初對調變解調器來說不常見的功能，但隨著時間的推移，這些功能已成為標準功能。本節概述瞭如何程式設計這些功能。
|
本頁或本節是未完成的草稿或提綱。 您可以幫助開發工作，或者您可以在專案室尋求幫助。 |
序列埠程式設計: 簡介和OSI網路模型 -- RS-232佈線和連線 -- 典型的RS232硬體配置 -- 8250 UART -- DOS -- MAX232驅動器/接收器系列 -- Windows中的TAPI通訊 -- Linux和Unix -- Java -- Hayes相容調變解調器和AT命令 -- 通用序列匯流排 (USB) -- 形成資料包 -- 糾錯方法 -- 雙向通訊 -- 資料包恢復方法 -- 序列資料網路 -- 實際應用開發 -- IP over序列連線