由于嵌入式技術的發展 ，嵌入式 Web 服務器軟件越來越大 ，對硬件的要求也相應地提高 ，但在工業現場的底層控制中 ，一般嵌入式系統的硬件配置都不是很高 ，導致了軟件和硬件的沖突。本文就是對實際應用過程中 ，偶爾出現的 Web 頁面訪問出錯問題進行深入的研究。

　　1 嵌入式 Web 在系統中的應用

　　多支點觸發系統包括以下幾個模塊 ： 控制臺模塊、網絡觸發源模塊、被觸發設備模塊。其中 ，網絡觸發源和被觸發設備都是掛載在總線上的 通過現場總線可以將系統各個節點相互連接起來以方便管理。嵌入式 Web 就是應用于網絡觸發源模塊中 ，它負責控制臺和被觸發設備之間的通信。控制臺通過瀏覽器訪問網絡觸發源 ，在 Web 頁面上完成相應控制操作后 ，由網絡觸發源把操作命令發送到總線上 ，被觸發設備從總線上接收到命令后 ，完成相應操作。在網絡觸發源模塊中 ，Web 服務器采用的是 Boa ，嵌入式操作系統采用的是 uClinux ，處理器采用的是 Sam2sung 公司的 S3C44B0。多支點觸發系統結構如圖 1 所示。

　　2 Boa 的運行流程及出現的問題

　　Boa 是單任務的 http 服務器 ，源碼開放 ，性能高。與傳統的 Web 服務器不同 ，它并不對每個進入服務器的連接開辟新的進程 ，所有活動的 http 連接都在內部進行處理 ，而只為每個 CGI 連接啟動新進程。在已進行的測試中 ，Boa服務器比其他的 Web 服務器要快 ，所以它應用在嵌入式系統中是具有良好前景的。圖 2 是 Boa 基本的運行流程 。

　　在 Boa 運行過程中 ，用戶請求初始 Lo2gin 頁面時 ，系統能正常響應操作。當用戶輸入正確的 Login 信息 ， 要實 現頁 面跳 轉時 ， PC 機上的瀏覽器里面不能正確瀏覽 ，提示錯誤“： 502 bad gate2way The CGI was notCGI/ 1. 1 compliant ”。由于運行的是 CGI 程序 ，通過調試和查看錯誤日志 ，發現系統停留在步驟 ⑤～ ⑦間。在排除 CGI 程序錯誤后 ，通過串口調試終端打印出的錯誤信息發現 ：在執行 CGI 程序時 ，內核申請內存時出錯 ，提示申請的內存塊不能得到 ，即內存丟失。

　　3 系統內存丟失分析

　　3. 1 uClinux 的內存管理

　　uClinux 不能使用處理器的虛擬內存管理技術 ，它仍然采用存儲器的分頁管理。系統啟動時對存儲器分頁 ，加載應用程序對程序分頁加載。由于沒有 MMU 管理 ，所以uClinux 采用實存儲器管理。uClinux 系統對內存的訪問是直接的（它對地址的訪問不經 MMU ，而是直接送到地址線上輸出） ，所有程序訪問的地址是物理地址。那些比物理內存還大的程序將無法執行［2 ］ 。

　　uClinux 將整個物理內存劃分成為 4 KB 的頁面。由數據結構 page 管理 ，有多少頁面就有多少 page 結構 ，它們又作為元素組成數組 men_map 。物理頁面可作為進程代碼、數據和堆棧的一部分 ，還可存儲裝入的文件 ，也可作緩沖區。

　　3. 2 內存丟失原因

　　由于 uClinux 提供了跟普通 Linux 一樣的內存分配器 ，普通 Linux 中缺省的內存分配器是使用“2 的冪”的分配方法 ，這樣可以快速找到符合要求的內存區域。

　　在系統開發過程初期 ，采用的就是“2 的冪”的分配方法。如果一個應用程序要求（ X） KB 內存空間進行裝載 ，則實際使用占用的內存空間大小為 Y = 2m（ Y ≥X） 。試想一個 65 KB 應用程序 ，如果按照“2 的冪”的分配方法 ，就必須分配 128 KB （2 的 7 次方） 的內存空間 ，這樣就有63 KB的內存空間不能被利用上。這對于小內存的嵌入式系統來說是相當大的浪費。

　　多支點觸發系統運行時 ，嵌入式操作系統 uClinux 使用“2 的冪”的內存分配方法 ，大多數情況下都能正常工作。但在不斷反復測試中 ，偶爾會出現上述頁面出錯問題。錯誤的原因是不能獲得足夠的內存加載程序。通過調試終端 ，用free 命令查看系統內存分配情況如表 1 所列。

　　由表 1 可以看出 ，空閑的內存空間還有 1560 KB ，而應用程序所需的內存空間為 400 多 KB ，但是內核認為并沒有足夠的內存空間用來加載程序。例如一個系統內存大小為1 MB ，有 400 KB 的空閑內存 ，為了裝載一個應用程序需要分配 100 KB 的空間。大家可能覺得這個需要肯定能得到滿足 ，然而 ，由于 uClinux 必須給應用程序分配連續內存空間的特性 ，所以必須有 100 KB 連續的內存空間才能滿足這個需要。而當系統內存分配如圖 3 所示時 ，最大的連續內存塊的大小只有 80 KB ，這樣是沒有辦法分配給這個應用程序的。這就是系統中頁面訪問出錯的問題所在 ，雖然有足夠的空閑內存空間 ，但是沒有應用程序所需的連續內存空間。

　　這就是內存丟失問題。雖然系統會顯示大量的可用內存 ，但是應用程序卻不能得到。

　　4 內存丟失問題的解決

　　由于系統的內存管理默認采用“2 的冪”的分配方法 ，這就造成了內存空間的巨大浪費 ，當某些應用程序要申請較大的連續空間時 ，卻不能滿足。為了解決這個問題 ，專門為 uClinux 內核設計了可選的內存分配器。不同的內核版本 ，這個可選的內存分配器不同 ，一般是 page_alloc2和 kmalloc2。

　　page_alloc2 能解決缺省的分配方法造成的浪費問題。雖然它也是使用“2 的冪”的分配方法 ，但它是按頁（每頁4 096B ，即 4 KB） 分配的 ，分配的內存大小如果已經滿足了要求 ，則只是將當前的一頁分配出去 ，其他的就不再分配。還是一個 65 KB 的應用程序 ，如果使用這種方法 ，就只是分配 68 KB（ ≥65 KB ，且為整頁） 即可 ，這樣就能節省60 KB 的空間。

　　page_alloc2 還采取了一些避免內存碎片的方法。它將所有的兩頁（8 KB） 或更少的內存需求從空閑內存開始部分向上分配 ，所有大的內存需求從剩余內存的末尾部分開始向下分配。這樣防止了網絡緩存等的臨時分配 ，避免了內存碎片的出現。同時 ，它支持一次申請超過 1 MB 的內存空間 ，這對一些大的應用程序是很好的支持。

　　采用此方法后 ，在系統運行過程中 ，并未出現過頁面訪問出錯問題。通過 free 命令查看內存分配如表 2 所列。

　　結語

　　在嵌入式系統應用日益廣泛的情況下 ，本文結合嵌入式 Web 在多支點觸發系統中的應用 ，介紹了 Web 訪問出現的問題以及它的解決方法。在實際應用中 ，新的內存分配方法能讓系統穩定地工作 ，但是從表 2 可以發現 ：采用“page_alloc2”的內存分配方法時 ，系統的 Cache 較小 ，這就造成了頁面訪問有一定的延時。而“2 的冪”的分配方法 ，系統的 Cache 較大 ，訪問速度較快。從這個對比得知 ，在反應時間要求不是很高的情況下“， page_alloc2”的內存分配方法更適合小內存的嵌入式系統 ;而“2 的冪”的分配方法更合適那些內存足夠大的嵌入式系統。系統開發者可以根據實際情況采用不同的方案。