modem握手

dows的XModem函式。 fig，XModemSen XModemReceive。

什麼是modem握手？
RS -232通行方式允許簡單連線三線：Tx、Rx和地線。但是對於數據傳輸，雙方必須對數據定時採用使用相同的波特率。儘管這種方法對於大多數套用已經足夠，但是對於接收方過載的情況這種使用受到限制。這時需要串口的握手功能。在這一部分，我們討論三種最常用的RS-232握手形式：軟體握手、硬體握手和 Xmodem。
a，軟體握手：我們討論的第一種握手是軟體握手。通常用在實際數據是控制字元的情況，類似於GPIB使用命令字元串的方式。必須的線仍然是三根：Tx， Rx和地線，因為控制字元在傳輸線上和普通字元沒有區別，函式SetXModem允許用戶使能或者禁止用戶使用兩個控制字元XON和OXFF。這些字元在通信中由接收方傳送，使傳送方暫停。
例如：假設傳送方以高波特率傳送數據。在傳輸中，接收方發現由於CPU忙於其他工作，輸入buffer已經滿了。為了暫時停止傳輸，接收方傳送XOFF，典型的值是十進制19，即十六進制13，直到輸入buffer空了。一旦接收方準備好接收，它傳送XON，典型的值是十進制17，即十六進制11，繼續通信。輸入buffer半滿時，LabWindows傳送XOFF。此外，如果XOFF傳輸被打斷，LabWindows會在buffer達到75％和 90％時傳送XOFF。顯然，傳送方必須遵循此守則以保證傳輸繼續。
b，硬體握手：第二種是使用硬體線握手。和Tx和Rx線一樣，RTS/CTS和DTR/DSR一起工作，一個作為輸出，另一個作為輸入。第一組線是RTS （Request to Send）和CTS（Clear to Send）。當接收方準備好接收數據，它置高RTS線表示它準備好了，如果傳送方也就緒，它置高CTS，表示它即將傳送數據。另一組線是DTR（Data Terminal Ready）和DSR（Data Set Ready）。這些現主要用於Modem通信。使得串口和Modem通信他們的狀態。例如：當Modem已經準備好接收來自PC的數據，它置高DTR線，表示和電話線的連線已經建立。讀取DSR線置高，PC機開始傳送數據。一個簡單的規則是DTR/DSR用於表示系統通信就緒，而RTS/CTS用於單個數據包的傳輸。
在LabWindows，函式SetCTSMode使能或者禁止使用硬體握手。如果CTS模式使能，LabWindows使用如下規則：
當PC傳送數據：
RS-232庫必須檢測CTS線高后才能傳送數據。
當PC接收數據：
如果連線埠打開，且輸入佇列有空接收數據，庫函式置高RTS和DTR。
如果輸入佇列90％滿，庫函式置低RTS，但使DTR維持高電平。
如果連線埠佇列近乎空了，哭喊數置高RTS，但使DRT維持高電平。
如果連線埠關閉，庫函式置低RTS和DTR。
c，XModem握手：最後討論的握手叫做XModem檔案傳輸協定。這個協定在Modem通信中非常通用。儘管它通常使用在Modem通信中， XMODEM協定能夠直接在其他遵循這個協定的設備通信中使用。在LabWindows中，實際的XModem套用對用戶隱藏了。只要PC和其他設備使用 XModem協定，在檔案傳輸中就使用LabWindows的XModem函式。函式是XModemConfig，XModemSend和 XModemReceive。
XModem使用介於如下參數的協定：start_of_data、end_of_data、neg_ack、wait_delay、 start_delay、max_tries、packet_size。這些參數需要通信雙方認定，標準的XModem有一個標準的定義：然而，可以通過 XModemConfig函式修改，以滿足具體需要。這些參數的使用方法由接收方傳送的字元neg_ack確定。這通知傳送方其準備接收數據。它開始嘗試傳送，有一個逾時參數start_delay；當逾時的嘗試超過max_ties次數，或者收到接收方傳送的start_of_data，傳送方停止嘗試。如果從傳送方收到start_of_data，接收方將讀取後繼信息數據包。包中含有包的數目、包數目的補碼作為錯誤校驗、packet_size位元組大小的實際數據包，和進一步錯誤檢查的求和校驗值。在讀取數據後，接收方會調用wait_delay，然後想傳送方傳送回響。如果傳送方沒有收到回響，它會重新傳送數據包，直到收到回響或者超過重發次數的最大值max_tries。如果一直沒有收到回響，傳送方通知用戶傳輸數據失敗。
由於數據必須以pack_size個位元組按包傳送，當最後一個數據包傳送時，如果數據不夠放滿一個數據包，後面會填充ASCII碼NULL（0）位元組。這導致接收的數據比原數據多。在XModem情況下一定不要使用XON/XOFF，因為XModem傳送方發出包的數目很可能增加到XON/OFF控制字元的值，從而導致通信故障。