《電子技術應用》
您所在的位置:首頁 > 通信與網絡 > 業界動態 > 微控制器撥號上網的實現

微控制器撥號上網的實現

2008-08-12
作者:黃承安, 張 躍

  摘? 要: 介紹了一種在微控制器" title="微控制器">微控制器(單片機)上實現PPP協議,并使其通過ISP連入Internet的方法。分析了PPP協議,論述了軟件系統的層次結構和實現難點,重點介紹了協議的簡化方法以適應單片機有限的存儲資源。

  關鍵詞: PPP? 微控制器? 單片機上網? 調制解調器

?

  微控制器(也稱單片機)把所有常用的資源,如存儲器、模數轉換器、通用輸入輸出口、定時器等,與CPU集成在一個芯片上,具有體積小、功耗低、使用方便的特點,廣泛應用于各種嵌入式系統中。隨著互聯網(Internet)的興起與普及,使微控制器也接入到互聯網,并通過互聯網傳送數據。但是實現單片機與互聯網通信的前提是需要在單片機上實現多種繁雜的互聯網協議。而微控制器一般處理能力較低、程序存儲器和數據存儲器資源有限,這就使微控制器上網變得非常困難。目前,一般采用微控制器直接驅動網卡芯片的方案。網卡芯片封裝了底層的以太網協議(如IEEE802.3),微控制器只需控制網卡芯片并實現傳輸層與網絡層協議(例如TCP、IP協議)即可以上網。但其缺點是必須應用在已經擁有局域網的地方,且網卡芯片(例如RTL8019等)價格不菲。

  本文針對微控制器上網的問題,提出一種在微控制器中實現PPP協議,并通過調制解調器(MODEM)連接到ISP(Internet Service Provider)實現上網的解決方案:微控制器控制MODEM撥號連接到ISP上,然后根據PPP協議(Point to Point Protocol)進行通信協商、密碼認證等握手過程,如果成功就可以通過ISP上網傳送數據。這種方案的優點在于:(1)可以應用于任何覆蓋電話網的地區,適用于廣大偏遠地區;(2)硬件實現比較簡單,程序比較短小;(3)只需外接電話線,安裝簡便。

1 硬件連接與底層驅動

  微控制器撥號上網解決方案中的硬件連接非常簡單,只需使用微控制器的標準串行口和I/O總線與MODEM相連。為了使程序更為簡化,在硬件設計中可以不使用MODEM的硬件握手信號。最終只需四根連接線來控制MODEM(如圖1所示):串口" title="串口">串口發送(TXD)、串口接收(RXD)、載波檢測CD(Carrier Detect)和終端準備DTR(Data Terminal Ready)信號。CD信號可以檢測MODEM是處于數據傳送狀態還是AT命令傳送狀態。DTR信號用來通知MODEM傳送工作已經結束。微控制器的串行口和I/O口不能直接與標準MODEM相連,需要使用電壓轉換芯片,如MAX232等,轉換為RS232標準。

?

  為了方便軟件編程,需要針對硬件編寫一些底層驅動程序。首先是串行口的驅動函數:打開串口(OpenComm)、關閉串口(CloseComm)、讀串口數據(ReadComm)、寫串口數據(WriteComm)等。然后在這些串口函數的基礎上編寫MODEM的驅動函數。單片機通過串行口控制MODEM,進行撥號、設置等操作。控制方法采用AT命令,例如:ATDT命令用來撥號、ATV命令控制MODEM返回值的格式等。在控制MODEM撥打ISP的電話號碼后,MODEM就轉入在線模式(On-Line),此時微控制器向串行口發送的所有數據都會直接傳送給ISP主機。同樣ISP主機的回答也傳回微控制器的串行口。可以說此時的MODEM和電話線建立了一個從微控制器到ISP的透明數據連接。當數據傳送完成需要斷開連接時,微控制器通知MODEM結束會話,并從在線模式轉回普通的命令模式。這可以通過置高MODEM的DTR線完成。同時,處于在線模式下微控制器也要不斷檢測CD線是否處于高電平,當線路由于異常斷開時,CD線會回復到平常的低電平。根據這些操作,編寫MODEM驅動函數:(1)MODEM初始化函數(ModemInit);(2)撥號函數(ModemDial);(3)斷開與ISP連接(ModemHangUp);(4)檢測MODEM是否處于在線狀態(ModemOnLine)等。

  這些底層的驅動函數將會使上層協議的編寫很方便;更重要的是,它提供了一個硬件抽象層。當底層硬件改動時,只需要對底層的驅動函數改動,而上層函數的代碼不變。

2 軟件整體結構

2.1 軟件層次結構

  程序中的所有代碼都由C語言編寫,采用分層結構,從底到上分別為:串口驅動層、MODEM驅動層、PPP協議層" title="協議層">協議層、IP協議層、UDP協議層與應用層" title="應用層">應用層。上層函數的實現需要應用到底層函數,而底層函數的任務就是為上層函數提供服務,最終完成應用層任務,傳送數據。各層的主要函數如圖2所示。

?

  可以看出,為了盡量簡化,在傳輸層使用了UDP協議而非TCP協議。其實大多數情況下使用無連接的UDP協議已經足夠,而且會使程序大幅簡化。

2.2 串口接收中斷的處理

  為了節省代碼空間,軟件未使用實時操作系統,例如μC/OS等,而是利用多個有限狀態機來控制程序的運行。其中最重要的就是MODEM狀態機。MODEM可以處在兩個狀態:命令狀態和在線狀態。當處于命令狀態時,串行口接收MODEM的返回值信息。而當微控制器進行撥號命令之后,MODEM轉而處于在線狀態,此時微控制器與ISP直接連接,它們之間的通信要符合PPP報文協議。因此,串行口接收的是PPP報文。在本程序中,串口使用中斷接收模式,因此在串口接收中斷處理函數中,首先要判斷MODEM是處于命令狀態還是在線狀態。如果處于在線狀態,則要按照PPP報文格式處理。找到一個完整的PPP報文后則通知主循環處理。中斷處理程序的總體結構如下:

  void serial0() interrupt 4 using 2

  { //串行口中斷處理函數

  unsigned char c;

?????? EA = 0;

?????? if(RI)

?????? {

????????????? RI = 0;

????????????? c = SBUF;  //獲得串口數據

????????????? if(ModemState == COM)

???????????????????? ProModemCommand(c);  //處于命令狀態

????????????? else

???????????????????? ProPPPReceive(c);   //處于在線狀態,尋找完整的PPP報文

?????? }

??? }

3 PPP協議的實現

  PPP(Point to Point Protocol)是數據鏈路" title="鏈路">鏈路層協議中的一種,是目前應用最廣的一種廣域網協議。PPP協議假定兩個對等實體間有一個雙向全雙工的連接,而且數據包按順序投遞,這正好符合串行口的通信方式。PPP協議不需要差錯控制、排序和流量控制,易于實現,而且支持對多種高層協議(如IP、TCP、UDP)的復用。所以使用PPP撥號上網是微控制器實現Internet連接的最佳選擇。大部分的ISP也正是通過PPP協議提供網絡服務的。

  PPP協議的幀結構如圖3(a)所示。串口中斷程序以包起始和結束符來判斷是否有完整的PPP包,并對PPP包的內容進行校驗以確定數據包的完整性和正確性。然后在主循環中進入PPP報文解析模塊,在撥號后初次與ISP通信階段,系統首先要與ISP進行通信鏈路的協商,即協商點到點的各種鏈路參數配置。協商過程遵守LCP(Link Control Protocol)、PAP(Password Authentication Protocol)和IPCP(Internet Protocol Control Protocol)等協議。其中LCP協議用于建立、構造、測試鏈路連接;PAP協議用于處理密碼驗證部分;IPCP協議用于設置網絡協議環境,并分配IP地址。協商機制用有限狀態機的模型來實現。一旦協商完成,鏈路已經創建,IP地址已經分配就可以按照協商的標準進行IP報文的傳輸了。根據應用的不同,IP報文中可以攜帶UDP報文也可以是TCP或ICMP報文。本系統正是采用UDP報文傳送數據信息的。數據傳輸完成后,下位機會向ISP發送LCP的斷開連接報文以終止網絡連接。

?

  值得注意的是,PPP報文、LCP、PAP、IP報文與UDP報文是互相嵌套的。即PPP報文中嵌入了IP報文和LCP、PAP等報文,而IP報文中嵌入了UDP報文。當PPP報文的協議符為0021時表示嵌入了IP數據報,為C021時表示嵌入LCP數據報,而為C023表示嵌入PAP數據報。PPP報文的基本解析過程如圖3(b)所示。

3.1 登錄ISP的協議協商過程

  系統的難點之一是微控制器登陸ISP并與ISP的協商過程,其中需要應用到LCP、PAP與IPCP協議。LCP、PAP與IPCP協議的幀結構大同小異,最常用的是請求(REQ)、同意(ACK)和拒絕(NAK)三種幀。微控制器與ISP協商時,任何一方都可以發送REQ幀請求某方面的配制,另一方如果覺得配置不能接受會回應NAK幀,如果可以接受則回應ACK幀。為了節省資源,這里只處理這三種數據幀,其它鏈路問題都由微控制器在程序控制下自己重新撥號解決。各種配置選項協商好以后,PPP才可以成功登陸。

  在撥號成功連接后,ISP首先返回一個PAP REQ數據幀,微控制器發送一個空LCP REQ幀以強迫ISP進行協議協商階段;隨后ISP發送LCP設置幀,微控制器拒絕所有的設置并請求驗證模式。ISP選擇CHAP或PAP方式驗證,這里只接受PAP方式。然后進行PAP驗證用戶名和密碼過程,如果成功,ISP會返回IPCP報文設置IP地址。此時,就完成了與ISP的協商過程,可以通過向ISP發送IP報文的方式連接互聯網傳送數據了。協商過程的狀態轉換圖如圖4所示。

?

3.2 IP與UDP報文的解析

  協商完成后進入IP數據報通信階段。此時,微控制器向ISP發送的所有包含IP報文的PPP報文都會被ISP傳送給IP報文內的相應IP地址,而遠端所有向微控制器IP地址發送的報文也都會經ISP傳送到單片機,從而完成微控制器與遠程主機通過互聯網的數據傳輸。

  為了使程序盡量簡化,選用IP承載UDP協議發送數據。在程序中實現IP與UDP報文的數據結構,向指定的主機IP地址發送UDP報文較易實現。但應注意,在應用層需要用戶實現自己的協議。例如對于遠程讀表系統,要規定儀表的數據傳輸協議;根據協議把相應的儀表數據放入UDP報文中,傳給主機;同時,主機也可以按照協議向單片機發送UDP報文。可以利用UDP報文的端口號,把不同的報文發送到不同的端口中以方便單片機的解析。

????經過優化,本系統的軟件代碼可以精簡到6K字節左右,共使用不到300字節的數據存儲器。由于程序使用C語言編寫,稍加改動就可以在各種系列的微控制器上實現。微控制器通過MODEM撥號上網技術,可以廣泛應用于需要遠程傳送數據的系統中,特別適合遠程抄表、遠程監控等領域。

?

參考文獻

1 Simpson W. The Point to Point Protocol(PPP). RFC1661, 1994

2 PPP in HDLC-Like Framing. RFC1662, 1994

3 PPP LCP Extensions.RFC1570,1994

4 李 藝. 面向機頂盒的PPP模塊的設計.小型微型計算機系統, 2001;1

本站內容除特別聲明的原創文章之外,轉載內容只為傳遞更多信息,并不代表本網站贊同其觀點。轉載的所有的文章、圖片、音/視頻文件等資料的版權歸版權所有權人所有。本站采用的非本站原創文章及圖片等內容無法一一聯系確認版權者。如涉及作品內容、版權和其它問題,請及時通過電子郵件或電話通知我們,以便迅速采取適當措施,避免給雙方造成不必要的經濟損失。聯系電話:010-82306118;郵箱:[email protected]
主站蜘蛛池模板: 91亚洲综合| 91久久亚洲精品一区二区 | 精品在线一区二区三区 | 亚洲七七久久精品中文国产 | 国产精品视频九九九 | 亚洲视频在线观看网址 | 欧美亚洲第一区 | 美女视频黄a视频免费全过程 | 最新最好看免费毛片基地 | 一级一级特黄女人精品毛片 | 成人二区 | 美国毛片毛片全部免费 | 精品一精品国产一级毛片 | 香港三级做爰大爽视频 | 美日韩一区二区三区 | 成年午夜一级毛片视频 | 欧美人体在线 | 欧美久久久久欧美一区 | 国产成人久久久精品一区二区三区 | 99国产精品久久久久久久成人热 | 国产在线欧美日韩精品一区二区 | 偷拍自拍第一页 | 韩国一大片a毛片 | 国产高中生粉嫩无套第一次 | 亚洲第一激情 | 手机看片久久国产免费不卡 | 欧美一区二区三区免费看 | 日韩精品a在线视频 | 久久精品视频久久 | 日本免费人成黄页在线观看视频 | 久草免费手机视频 | 久久夜视频 | 欧美成人爽毛片在线视频 | 久久99国产精品久久 | 亚洲欧美日韩一区 | 国产成人精品男人的天堂网站 | 黄色毛片子 | 加勒比久久综合 | 亚洲人成网址在线观看 | 久久99久久99精品 | 亚洲第一免费视频 |