基于ARM 的火災信息傳輸網關設計

　　( 5) 管道寫操作

　　一旦管道創建完成，用戶就可以通過調用管道寫函數來寫數據。用于必須調用和初始化一致的寫函數。

　　如網絡模塊調用pipe_init_ netw o rk 函數初始化管道,必須通過調pipe_w rite_netw ork 來寫，若調用其他函數寫入將失敗，如表4 所示。

表4 管道寫函數

　　表4 中目的模塊ID 和控制字在conf ig . h 文件中定義。msg 是要發送數據的首地址，必須注意的是msg所指向的數據必須是字符串類型，必須以“ 0”結束，否則發送函數無法確定msg 數據包的長度。對于不是以msg 結尾的數據包，必須字符串化，否則發送函數的行為未定義。

　　( 6) 管道讀操作管道讀操作從管道讀取一個固定長度的數據包，并解析數據包，從數據包中分離信息。管道的讀操作可以是阻塞模式和非阻塞模式。在阻塞模式下，讀操作將阻塞直到有數據返回。用戶通過設置讀操作中的參數f lag 可以實現模式選擇。當f lag= 0 時，表示為阻塞模式; 當f lag= 1 時，表示為非阻塞模式。管道讀操作也要求管道必須正確的初始化，否則讀失敗，同時也要求必須選擇正確的管道讀函數，如表5 所示。

表5

　　表5 中，src 是unsigned shor t * 類型，如果不要求獲取源地址，可以傳遞NU LL。msg 用于存放接收數據的內存首地址，msg 必須大于或等于251 B。空間必須由用戶分配。函數假定msg 的空間已分配且空間足夠大 。

　　( 7) 基于TCP/ IP 的網絡通信

　　裝置采用串口采集消防主機上的數據，并且把數據轉換成TCP/ IP 協議能識別的數據包，因此串口采集的數據源要作為以太網幀的一部分。為了向設備提供透明的接口并區分數據源，需要制定統一的幀格式。幀格式如下:

　　其中，串*字段用來區分數據源; 幀頭、幀尾作為一個串口幀的起始分界( 可自定義) ; 數據部分是來自串口的原始數據流。

　　以太網方面采用面向連接的網絡通信，采用TCP/ IP網絡通信協議。數據包結構描述中控制單元格式如下:

　　應用數據單元基本格式如下:

　　消防主機發送的信息一般在10~ 100 B 之間，若選擇T CP 協議，會使協議開銷在網絡的吞吐量中占有很大的比例。U DP 協議支持實時多播通信，保證了網關向監控中心實時發送火警情報，并能有效地減少用戶信息傳輸裝置的開銷和網絡資源。UDP 協議的數據可靠性和完整性問題由應用程序來解決，因此在該系統中使用UDP 更合理。

　　TCP/ IP 通信模塊采用SOCKET 套接字編程實現。本系統采用服務器/ 客戶端編程模型，服務器和客戶端分別對應監控中心工作站服務器和用戶信息傳輸裝置。

　　4 結 語

　　本文詳細剖析了利用Internet 實現火災自動報警系統與城市遠程消防監控中心的連接及相關信息的交互，并設計了該系統的關鍵設備——嵌入式信息傳輸網關，采用已經移植有Linux 2. 6 內核操作系統的ARM9單片機，在此基礎上進行了應用程序的開發，實現了火災探測信息的處理轉發功能和上位機與嵌入式網關的信息交互功能。設備在實際環境中安裝后的測試結果表明，該嵌入式系統對火災探測數據及交互信息的處理和轉發穩定可靠、實時性好，不僅適用于基于IP 的火災信息傳輸網絡中，同時還可應用于其串口和以太網通信的場合中，應用前景廣闊。