微控制器撥號上網的實現
微控制器(也稱單片機)把所有常用的資源,如存儲器、模數轉換器、通用輸入輸出口、定時器等,與CPU集成在一個芯片上,具有體積小、功耗低、使用方便的特點,廣泛應用于各種嵌入式系統中。隨著互聯網(Internet)的興起與普及,使微控制器也接入到互聯網,并通過互聯網傳送數據。但是實現單片機與互聯網通信的前提是需要在單片機上實現多種繁雜的互聯網協議。而微控制器一般處理能力較低、程序存儲器和數據存儲器資源有限,這就使微控制器上網變得非常困難。目前,一般采用微控制器直接驅動網卡芯片的方案。網卡芯片封裝了底層的以太網協議(如IEEE802.3),微控制器只需控制網卡芯片并實現傳輸層與網絡層協議(例如TCP、IP協議)即可以上網。但其缺點是必須應用在已經擁有局域網的地方,且網卡芯片(例如RTL8019等)價格不菲。
本文引用地址:http://www.104case.com/article/149254.htm本文針對微控制器上網的問題,提出一種在微控制器中實現PPP協議,并通過調制解調器(MODEM)連接到ISP(Internet Service Provider)實現上網的解決方案:微控制器控制MODEM撥號連接到ISP上,然后根據PPP協議(Point to Point Protocol)進行通信協商、密碼認證等握手過程,如果成功就可以通過ISP上網傳送數據。這種方案的優點在于:(1)可以應用于任何覆蓋電話網的地區,適用于廣大偏遠地區;(2)硬件實現比較簡單,程序比較短小;(3)只需外接電話線,安裝簡便。
1 硬件連接與底層驅動
微控制器撥號上網解決方案中的硬件連接非常簡單,只需使用微控制器的標準串行口和I/O總線與MODEM相連。為了使程序更為簡化,在硬件設計中可以不使用MODEM的硬件握手信號。最終只需四根連接線來控制MODEM(如圖1所示):串口發送(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協議層、IP協議層、UDP協議層與應用層。上層函數的實現需要應用到底層函數,而底層函數的任務就是為上層函數提供服務,最終完成應用層任務,傳送數據。各層的主要函數如圖2所示。

{//串行口中斷處理函數
unsigned char c;
EA = 0;
if(RI)
{
RI = 0;
c = SBUF;//獲得串口數據
if(ModemState == COM)
ProModemCommand(c);//處于命令狀態
else
ProPPPReceive(c);//處于在線狀態,尋找完整
的PPP報文
}
}

值得注意的是,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所示。

評論