嵌入式單片機PPP協議的應用介紹
加入技術交流群
(3)默認情況下，如果字符的值小于0x20（例如ASCII控制字符），一般都要進行轉義。例如，遇到字符0x01時需連續傳送0x7D和0x21兩個字符(這時，第6個比特取補碼后變為1，而前面兩種情況均把它變為0)。這樣做是防止它們出現在雙方主機的串行接口驅動程序或調制解調器中，因為它們有時會把這些控制字符解釋成特殊的含義。另一種可能是用鏈路控制協議來指定是否需要對這32個字符中的某些值進行轉義。默認情況下是對所有的32個字符都進行轉義。
關于PPP協議的詳盡描述可以參閱RFC1661文檔。
3 單片機PPP協議
單片機PPP協議是PPP協議在單片機中的應用，有其特點。單片機的存儲空間只有64KB，而PPP協議包括LCP、PAP、IPCP以及NCP等協議，并且在連接建立后還要用到數據傳輸協議(TCP/IP、UDP等)、各種壓縮協議等。要把這些協議完全嵌入單片機是不可能的，所以只能根據實際需要選擇其中的一部分。
例如采用UDP協議而不是功能相對齊全但協議內容過于龐大的TCP/IP協議來傳輸數據，傳輸中基本上不使用數據壓縮協議，跳過單片機作為服務器端時的密碼驗證過程，省略IPX、AppleTalk等網絡層協議等。也就是說，本文的單片機PPP協議，事實上只包含了從PPP連接的建立到實現簡單的數據傳輸所必需的協議，而不包括PPP協議的所有功能。這種協議的取舍是由硬件的客觀限制以及實際的應用需要共同決定的。
4 單片機PPP協議PPP連接的建立
建立后的單片機PPP連接狀態如圖2所示。
|
其中，C51系統是已經植入PPP協議的51系列單片機，電話線部分也可以是某個網絡的一部分，甚至是Internet。
單片機PPP協議流程圖如圖3所示。
|
PPP連接的建立主要經過三個階段，分別是LCP協商、密碼認證以及網絡層協議配置。
4.1 LCP處理階段
首先，第一個LCP數據包被服務器端發送后，從服務器端返回一個PPP拒絕包給除密碼認證外的所有選項，接著服務器端強制認證協議進行協商(先前來自否定幀的PAP和CHAP都被發送)。隨后服務器端返回一個拒絕包給CHAP，本文用PAP來代替。然后服務器端認同并返回一個新的請求，這時候需要進行PAP。接下去對PAP進行確認，系統對字符映射的丟棄進行協商。最后所有控制特性被服務器端同意丟棄。
linux操作系統文章專題:linux操作系統詳解（linux不再難懂）
評論