引言
隨著Internet的發展和應用，越來越多的嵌入式系統接入網絡。然而，大部分嵌入式系統都是作為B/S模式中的應用服務器，必須隨時對客戶機的請求做出回應，要求具有較強的實時性。mC/OS-II是近年來發展迅速的一個開放源碼實時操作系統，具有移植性好、可裁剪、可固化的優點。將mC/OS-II引入網絡嵌入式系統，既可以實現系統的實時性要求，同時可以提高系統的可靠性，易于調試程序。
圖1 系統硬件結構框圖（點擊圖片放大）
圖2 系統TCP/IP協議部分程序流程圖（點擊圖片放大）
系統硬件設計
本系統設計中采用美國Cygnal公司生產的集成混合信號SoC芯片C8051F020，其內核與8051兼容。當它工作在最大系統時鐘頻率 25MHz 時，峰值速度可以達到 25MIPS。C8051F020除了256B的內部 RAM，還另有位于外部數據存儲器地址空間的 4KB的 XRAM，以及64KB可在系統編程的 FLASH 存儲器。因此，它有足夠的RAM空間用于存放1500B的以太幀，以及μC/OS-II中再入函數的模擬棧。C8051F020除了有標準8051的端口（ P0、P1、P2和P3）外，還附加4個端口（P4、P5、P6和P7），內部還有很多的功能器件。
系統的硬件結構框圖如圖1所示。網卡芯片使用臺灣 Realtek 公司生產的RTL8019AS。在系統中用到的網卡地址為十六進制的0300H~0310H，因此，C8051F020的P7口采用復用方式與RTL8019AS的數據/地址線相接，網卡的SA8腳則直接與高電平相接。C8051F020的 P5.2與RTL8019AS的復位端相連，用來復位網卡。RTL8019AS則外接一個隔離LPF濾波器，通過RJ45接口接入以太網。多個單總線溫度傳感器DS18B20共享一條總線，由 P3.0口進行控制。
系統軟件實現
TCP/IP協議實現
介質訪問層主要由以太網控制器 RTL8019AS來實現，其數據通信協議采用IEEE802.3 標準，只處理接收地址與本機物理地址相符或為廣播地址的以太幀，并只對ARP、IP數據報進行處理。
網絡層實現IP、ARP和ICMP 協議：IP 數據報的首部保留 20 字節的基本控制信息，每個IP數據報包含一個分片；實現完整的ARP 協議；對于ICMP協議， 只實現 ICMP 中類型號為 0 ，代碼為 0 的 Ping 應答協議。
傳輸層實現TCP協議。在系統中，TCP 協議只用于支持 HTTP 協議，由于在連接時一直處于被動服務的狀態，因此在設計中省去了SYN - SENT 狀態和CLOSED狀態，讓它一開始就處于 LISTEN 狀態，來監聽客戶端的連接請求，避免了主動打開的操作，可更高效地服務于客戶機。而當服務器發出數據報時，系統并不存儲，只是記錄下該數據報的狀態信息。由于系統中數據傳輸量少，滑動窗口可設置為一個固定值（1 500 字節 ）。
應用層實現HTTP 協議。現場監測設備與用戶的交互式數據交換通過 HTTP 協議來實現，HTTP在端口80上使用TCP的服務。系統TCP/IP協議部分程序的流程圖如圖2所示。
uC/OS-II對TCP/IP協議及溫度監測的實時管理
uC/OS-II在C8051F020單片機上的移植
uC/OS-II的移植，要求所用的C編譯器支持混合編程，在這里選用 KEIL C51集成開發環境。由于uC/OS-II是可剝奪的實時操作系統，任務隨時會被另一任務中斷，一段時間后再可以運行。為了防止在任務切換過程中相應數據被破壞，mC/OS-II中使用了大量的可重入函數。在KEIL C51中，Cx51編譯器為再入函數生成模擬棧，通過這個模擬棧完成參數傳遞和存放局部變量。根據再入函數所采用的編譯模式（SMALL、COMPACT、LARGE），模擬棧可以位于片內或片外存儲空間。對于本系統，模擬棧對RAM空間的要求較大，故選用LARGE模式。可直接利用芯片上集成的XRAM（4K），無須另外擴展外部數據存儲器。通過配置STARTUP.A51文件進行設置：
XBPSTACK EQU 1 ; //選用LARGE模式
XBPSTACKTOP EQU 1000H ; //設置再入棧棧頂指針
在移植過程中主要完成對以下五個文件的修改：與CPU相關的文件OS_CPU_A.ASM、OS_CPU_C.C、OS_CPU.H和與應用相關的文件OS_CFG.H、INCLUDES.H。
其移植過程在這里不是重點，下面簡要介紹與應用相關較緊密的部分設置。
0S-CPU.H：
#define OS_CRITICAL_ METHOD 1 //中斷方式1
#if OS_CRITICAL_METHOD == 1
#define OS_ENTER_ CRITICAL（） EA=0
//關中斷
#define OS_EXIT_CRITICAL（） EA=1 //開中斷
#endif
OS_CFG.H：
OSTimeDlyHMSM（）函數使應用程序無需知道延時時間對應的時鐘節拍數，直接按小時、分、秒、毫秒來定義時間，方便對任務運行時間進行管理。
#define OS_TIME_DLY_ HMSM_EN 1
//允許使用函數OSTimeDly HMSM（）。
由于每個嵌入式監測系統可以同時與多個PC機連接，向不同用戶提供信息，因此可在OS_CFG.H頭文件中定義一個包含各種連接信息的結構變量。當TCP報文到時，使用連接狀態信息檢查是否與已存在的連接相符，如果不存在則建立新的連接。這種處理可以使嵌入式監測系統同時處理來自同一或不同PC機的連接。
typedef struct
{
INT32U ipaddr;
INT16U port;
INT8U timer;
INT8U inactivity;
INT8U state;
char query［20］;
} CONNECTION;
在ARP協議部分，嵌入式系統將收到的IP數據報的物理地址存放在一結構變量中。如果是向同一PC機發送數據報，不需要再次發送ARP請求就可得到目的主機的物理地址，減少了建立連接的時間。
typedef struct
{
INT32U ipaddr;
INT8U hwaddr［6］;
} ARP_CACHE;
在其中設置每個嵌入式系統的MAC地址、IP地址、子網掩碼和網關地址。
uC/OS-II中任務創建及優先級設置
C8051F020的XRAM做輸入/輸出數據的內部緩沖區，RTL8019AS內部的16K SRAM做單片機的外部數據緩沖區，存儲輸入/輸出以太幀隊列。這樣C8051020就可以采用查詢方式讀取以太幀，并有充足的時間處理數據。由于輸入幀的大小不定，同時在ARP數據報發送或接收時，輸出幀必須存在輸出緩沖區中，因此，輸入/輸出數據緩沖區在C8051F020的XRAM中使用動態分配，由KEIL C51 提供的malloc（）和free（）函數完成。網頁存儲于單片機的FLASH存儲器中。當嵌入式系統向PC機發送網頁時，先將網頁從FLASH存儲器中取出放入XRAM，再根據用戶請求進行整理后放入RTL8019AS的SRAM，并發送到以太網上。
作為網絡服務器，C8051F020需要注意以下幾點：
1） 服務器向一客戶機發送ARP查詢分組后，如果在0.5秒內未收到ARP響應分組，則重發。
2） 如果TCP連接在0.5秒內未被激活，則調用初始化斷開連接程序，防止兩個TCP之間的連接處理長時期空閑。
3） 為了控制丟失數據報，TCP在規定時間（0.5秒）內如果沒有收到確認包 ，就重組這個包并發送 ，這樣不需要占用存儲區來存儲包。當收到客戶機接收到信息包的確認報后 ，就斷開連接。
uC/OS-II對系統的管理是通過對任務的管理來實現的。它把整個程序分成許多任務，每個任務相對獨立。然后在每個任務中設置超時函數，一旦任務的延時時間到，任務必須交出 CPU 的使用權。根據需要，系統中創建了5個任務，設置如下：
任務1：OSTaskCreate（eth_ arive，0，&mystack1［0］，4）;// 查詢RTL8019AS，是否有以太幀到達。
OSTimeDlyHMSM（0，0，0，500）;// 延時0.5秒
任務2：OSTaskCreate（arp_ retran，0，&mystack2［0］，5）;//重發ARP分組
OSTimeDlyHMSM（0，0，1，0）; // 延時1秒
任務3：OSTaskCreate（tcp_ inact，0，&mystack3［0］，6）;// 初始化斷開連接
OSTimeDlyHMSM（0，0，1，500）;// 延時1.5秒
任務4：OSTaskCreate（read _temp，0，&mystack3［0］，7）;// 讀溫度值
OSTimeDlyHMSM（0，0，2，0）; // 延時7秒
任務5：OSTaskCreate（tcp_ retran，0，&mystack3［0］，8）;//TCP數據報重發
OSTimeDlyHMSM（0，0，2，500）;// 延時2.5秒
結語
將網絡功能嵌入到溫度監測系統中，可在網絡中接入多個節點，每個節點連接多個單總線傳感器，以此實現真正的多點溫度監測，以滿足用戶的需要。由于DS18B20是單總線溫度傳感器，本身的溫度測量有些延時，因此在傳輸溫度數據時需要幾秒鐘的等待時間，但對整個系統的影響不大。采用嵌入式實時操作系統mC/OS-II，提高了系統的實時性和可靠性，有利于用戶的管理和對溫度的實時監測。
用戶可以利用廣泛存在的以太網資源，通過瀏覽器直接訪問節點，提高系統的開放性和互操作性，降低監控運行維護成本、提高監控運行維護效率。因此，基于嵌入式實時操作系統的嵌入式網絡有著廣闊的發展前景。