一種新型嵌入式遠(yuǎn)程監(jiān)控系統(tǒng)的設(shè)計開發(fā)

1 引言

嵌入式監(jiān)控系統(tǒng)是當(dāng)前工業(yè)自動化監(jiān)控應(yīng)用領(lǐng)域研究的熱點之一。微電子技術(shù)和微處理器制造工藝的提高以及網(wǎng)絡(luò)技術(shù)的飛速發(fā)展，使得構(gòu)建基于Web的嵌入式遠(yuǎn)程監(jiān)控系統(tǒng)得以實現(xiàn)。這樣的遠(yuǎn)程監(jiān)控系統(tǒng)可以直接通過TCP/IP網(wǎng)絡(luò)協(xié)議接入Internet實現(xiàn)遠(yuǎn)程監(jiān)控，成為真正不受時間和空間限制的遠(yuǎn)程監(jiān)控系統(tǒng)。

由于近年來一些半導(dǎo)體廠家新推出的MCU的存儲能力都有了很大的提高，以及用C語言編寫的程序具有移植性強(qiáng)、可讀性好等優(yōu)點，因此本文監(jiān)控軟件采用標(biāo)準(zhǔn)C語言編寫，并在m6811-elf-gcc中編譯通過。本文將從嵌入式Web監(jiān)控系統(tǒng)的通信基礎(chǔ)--以太網(wǎng)接口模塊著手，分別講述各個功能模塊的設(shè)計與實現(xiàn)。

2 以太網(wǎng)接口程序設(shè)計

以太網(wǎng)接口程序是與硬件設(shè)計中的網(wǎng)絡(luò)控制芯片密切相關(guān)的，不同的網(wǎng)絡(luò)控制芯片具有不同的以太網(wǎng)接口程序，但是一個完整的以太網(wǎng)接口程序通常包括三個部分：硬件模塊初始化、以太幀的發(fā)送和以太幀的接收。

1、硬件模塊初始化

本文使用的Freescale公司的MC9S12NE64 MCU集成了EPHY和EMAC兩個硬件子模塊，它們的初始化必須嚴(yán)格按照技術(shù)手冊進(jìn)行，避免忽略一些細(xì)節(jié)。

    2、以太幀的發(fā)送

在NE64中發(fā)送一個以太幀，必須將該幀內(nèi)容寫入至EMAC模塊的發(fā)送緩沖區(qū)(TX緩沖區(qū))，然后再通過發(fā)送命令將其發(fā)送出去，接下來的工作由下層硬件完成。與以太幀的發(fā)送相關(guān)的寄存器包括發(fā)送緩沖區(qū)幀結(jié)束指針寄存器(TXEFP)、發(fā)送控制和狀態(tài)寄存器(TXCTS)。

3、以太幀的接收

判斷以太幀的接收有兩種方法：查詢法和中斷法。由于中斷法有更好的執(zhí)行效率，本文使用了中斷法接收以太幀。由于NE64有兩個接收緩沖區(qū)A和B，因此到達(dá)的幀可能存儲在A緩沖區(qū)也可能存儲在B緩沖區(qū)，所以中斷矢量也有兩個：A緩沖區(qū)接收完成中斷和B緩沖區(qū)接收完成中斷，其矢量地址分別是$FFB2和$FFB4。無論是A緩沖區(qū)還是B緩沖區(qū)接收到數(shù)據(jù)，處理方法是一樣的，都是將接收到的數(shù)據(jù)幀讀出來，再進(jìn)行相應(yīng)的處理。

3 uIP協(xié)議實現(xiàn)的程序設(shè)計

3.1 TCP協(xié)議的實現(xiàn)

TCP協(xié)議是嵌入式Web的核心，它提供一種基于連接的帶確認(rèn)的可靠的數(shù)據(jù)流傳輸方式，可增強(qiáng)網(wǎng)絡(luò)的服務(wù)質(zhì)量。TCP協(xié)議的機(jī)制很復(fù)雜，它的完整實現(xiàn)對處理器的存儲能力和運(yùn)算能力要求較高。這對于嵌入式系統(tǒng)來說是比較奢侈的，因此必須對其進(jìn)行簡化。本文要實現(xiàn)的是一個基于嵌入式Web服務(wù)器的監(jiān)控系統(tǒng)，經(jīng)過仔細(xì)分析，本文得到如圖1所示的簡化的TCP狀態(tài)機(jī)。其中連接的斷開由服務(wù)器主動執(zhí)行，通過多次實驗總結(jié)出來該方式在本文系統(tǒng)中，比標(biāo)準(zhǔn)的TCP協(xié)議主動斷開連接的狀態(tài)機(jī)簡單且穩(wěn)定。

圖1 服務(wù)端簡化的TCP狀態(tài)圖

另外本系統(tǒng)可以根據(jù)不同的應(yīng)用要求調(diào)整TCP所支持的連接數(shù)量，但是通常在同一時刻僅支持單個TCP連接。同時為了避免因為數(shù)據(jù)報的丟失而造成狀態(tài)機(jī)的死鎖，本文使用簡單定時機(jī)制，使TCP狀態(tài)機(jī)在超時后復(fù)位。

TCP協(xié)議連接建立的過程被稱為“三次握手”。首先，客戶端向服務(wù)端提出連接請求。此時客戶端在TCP報頭中插入自己的ISN，并置SYN標(biāo)志為1，表示序列號字段合法，需要檢查。其次，服務(wù)端收到該TCP分段后，以自己的ISN回應(yīng)，同時確認(rèn)收到客戶端的TCP分段，置ACK標(biāo)志為1。最后，客戶端確認(rèn)收到服務(wù)端的ISN，置ACK標(biāo)志為1。至此完整的TCP連接建立，開始全雙工模式的數(shù)據(jù)傳輸過程。

3.2 其他協(xié)議的實現(xiàn)

在實現(xiàn)以太網(wǎng)底層驅(qū)動的基礎(chǔ)上，接下來實現(xiàn)用于以太網(wǎng)通信的上層協(xié)議。ARP協(xié)議是為了通信雙方獲取對方MAC地址的通信協(xié)議，是網(wǎng)絡(luò)通信的基礎(chǔ)，本文實現(xiàn)了ARP請求報文的發(fā)送和接收以及ARP響應(yīng)報文的接收和處理功能。為方便網(wǎng)絡(luò)調(diào)試，在uIP中實現(xiàn)了Ping命令，當(dāng)監(jiān)控設(shè)備正常工作后可省略該部分內(nèi)容。SD12-MCS是實現(xiàn)一個基于嵌入式Web的應(yīng)用設(shè)備，并非嵌入式網(wǎng)關(guān)或路由器，因此為了節(jié)約嵌入式系統(tǒng)資源，本文裁減了IP協(xié)議的路由功能，有關(guān)路由問題都由默認(rèn)網(wǎng)關(guān)完成。盡管基于Web方式的SD12-MCS使用了TCP協(xié)議，但是目前也有一些應(yīng)用是基于UDP協(xié)議的，為了系統(tǒng)具有更好的擴(kuò)展性，本文也實現(xiàn)了UDP協(xié)議。

4 Web服務(wù)器的設(shè)計與實現(xiàn)

該監(jiān)控系統(tǒng)的工作模式為嵌入式Web服務(wù)器方式，因此本文在實現(xiàn)uIP協(xié)議的基礎(chǔ)上，設(shè)計并實現(xiàn)了應(yīng)用層的HTTP協(xié)議以及CGI處理程序。

4.1 HTTP協(xié)議的設(shè)計與實現(xiàn)[!--empirenews.page--]

Web的應(yīng)用層協(xié)議HTTP是Web的核心。HTTP協(xié)議實現(xiàn)的客戶機(jī)/服務(wù)器模式是一種請求/響應(yīng)結(jié)構(gòu)?？紤]到系統(tǒng)實現(xiàn)時嵌入式TCP協(xié)議同時支持的連接次數(shù)和安全性問題，本文采用HTTP1.0協(xié)議，Web服務(wù)器每次發(fā)送完響應(yīng)就斷開連接。狀態(tài)碼的含義很多，本文使用了兩種：當(dāng)請求網(wǎng)頁成功時，返回狀態(tài)碼200，原因短語為OK；當(dāng)所請求的網(wǎng)頁不存在時，返回狀態(tài)碼404，原因短語為NOT FOUND。頭部字段名也是可選部分，但是本文使用了其中一個選項Content-Length:指出所發(fā)送對象的字節(jié)數(shù)，以方便程序調(diào)試。實體部分就是響應(yīng)的具體內(nèi)容，譬如一個HTML網(wǎng)頁或者一張圖片等等。

本文HTTP協(xié)議靜態(tài)頁面的實現(xiàn)需要完成如下內(nèi)容：首先獲取URL中的文件名，接著根據(jù)該文件名調(diào)用https_calculatehash()函數(shù)獲取文件句柄，即文件處理入口數(shù)據(jù)結(jié)構(gòu)中的hash域值，根據(jù)該值查找文件的起始地址，然后將文件裝入TCP套接字發(fā)送緩沖區(qū)。當(dāng)所發(fā)送的文件過長而大于發(fā)送緩沖區(qū)的大小時則會發(fā)生緩沖區(qū)的溢出問題，本文的解決辦法是：首先判斷文件的長度，當(dāng)文件過長時，將文件分割成多個不大于發(fā)送緩沖區(qū)大小的分段，然后循環(huán)發(fā)送出去。HTTP協(xié)議中靜態(tài)頁面處理的程序流程如圖2所示。

圖2 HTTP靜態(tài)頁面處理流程圖

4.2 CGI的設(shè)計與實現(xiàn)

在該監(jiān)控系統(tǒng)中，除了支持靜態(tài)頁面，還必須支持動態(tài)內(nèi)容和動態(tài)表單的處理，主要包括動態(tài)生成實時采集數(shù)據(jù)頁面和處理控制命令表單。為了實現(xiàn)該功能，本文設(shè)計了CGI接口處理程序。

考慮到實際應(yīng)用情況，本文無需在NE64中移植操作系統(tǒng)，因此為Web服務(wù)器創(chuàng)建CGI接口不能照搬標(biāo)準(zhǔn)CGI。首先，本文的Web服務(wù)器不能同時運(yùn)行多個應(yīng)用程序，每個應(yīng)用程序的運(yùn)行都會獨占CPU，直到完成才會釋放CPU。其次，本文未實現(xiàn)復(fù)雜的緩存機(jī)制，所以反復(fù)執(zhí)行應(yīng)用程序是個低速的過程。因此，本文對標(biāo)準(zhǔn)CGI進(jìn)行了裁減，設(shè)計了嵌入式CGI(Embedded CGI)，通過該方法實現(xiàn)了嵌入式Web服務(wù)器的數(shù)據(jù)的采集和監(jiān)控。其工作處理流程如圖3所示。

圖3 CGI處理流程

5 A/D采集子程序

為了實現(xiàn)不同精度、更多路的數(shù)據(jù)采集，系統(tǒng)既使用了NE64集成的A/D采集模塊，又使用了通過SPI外擴(kuò)的專用的A/D采集芯片TLC2543。因此，A/D采集子程序包含了這兩部分的內(nèi)容。在具體實現(xiàn)時，本文通過變量TLCAD控制調(diào)用哪個采集子程序，當(dāng)TLCAD＝100時，調(diào)用TLC2543采集子程序；當(dāng)TLCAD＝99時，調(diào)用集成A/D采集子程序。系統(tǒng)在采集數(shù)據(jù)時，模擬量輸入信號從最小的通道號依次接入，實際模擬量的個數(shù)由變量NE64ADNmb和TLCADNmb決定，分別表示采集精度為10位的模擬量個數(shù)以及采集精度為12位的模擬量個數(shù)。

在A/D數(shù)據(jù)采集過程中，不可避免地會受到隨機(jī)噪聲的干擾，從而造成采集數(shù)據(jù)的不準(zhǔn)確，進(jìn)而得出錯誤的結(jié)論。為了防止脈沖干擾該系統(tǒng)，本文作者采用了中值濾波的方法。在中值濾波的基礎(chǔ)上，為了保證采集數(shù)據(jù)的穩(wěn)定性，本文作者采用了算術(shù)平均值濾波的方法。

6 模塊測試

該監(jiān)控系統(tǒng)軟件的主要功能是實現(xiàn)多路數(shù)據(jù)采集、網(wǎng)絡(luò)協(xié)議通信以及對象控制機(jī)制。模塊測試部分主要針對各模塊進(jìn)行軟件測試。由于篇幅限制，下面主要針對起數(shù)據(jù)采集部分介紹其測試部分。SD12-MCS共支持30路模擬量數(shù)據(jù)采集，其中8路10位精度的AD屬于NE64的A/D模塊，剩余22路屬于2片TLC2543采集芯片。為了驗證每個采集程序是否正確，本文設(shè)計了這樣一個測試用例：首先單獨運(yùn)行其中一種精度的采集程序，發(fā)送所有通道采集到的數(shù)據(jù)，通過串行口發(fā)送給高端PC機(jī)，并由PC機(jī)的測試用例顯示，若顯示數(shù)據(jù)正確，則程序正確。在此基礎(chǔ)上，發(fā)送參數(shù)確定調(diào)用哪種子程序，同時控制采集多路模擬量，由于本文設(shè)置模擬量采集都是從第0通道開始，并依此類推，因此不需要設(shè)置究竟是采集哪個通道的模擬量，從而簡化程序處理。

本文作者創(chuàng)新點:

本文主要介紹了一種基于Web的嵌入式監(jiān)控系統(tǒng)控制策略設(shè)計與實現(xiàn)。通過對各功能模塊測試顯示該監(jiān)控系統(tǒng)性能良好，符合相關(guān)設(shè)計要求。