用RT5370模塊實現的低成本嵌入式WiFi系統

引言

眾所周知，WiFi與其他短距離無線通信相比，具有通信速率高、穩定、安全、支持設備多等優點。尤其是近幾年智能手機迅速發展，使WiFi快速普及，這就給傳統的嵌入式系統無線通信帶來了機遇和挑戰。就通信角度而言，數以億計的智能手機其實就是一個個潛在的手持遙控器或數據終端，如果能在嵌入式系統中支持WiFi網絡，將極大地拓展與外部的通信方式。但是，由于WiFi對系統資源要求比較高，所以嵌入式系統采用WiFi的發展相對滯后，常見的方案是，在原有的嵌入式系統中外接一個WiFi通信轉接模塊，將Wi Fi信號轉換為UART、SPI等常見的通信方式。這種方式實現比較簡單，但是缺點也非常明顯，額外增加了成本，這也是阻礙嵌入式系統WiFi發展的一個主要因素。本文介紹了直接將WiFi網卡集成到嵌入式系統的解決方案，系統MCU直接驅動USB接口的WiFi網卡，從而省去了WiFi轉UART等橋接模塊，明顯降低了系統成本，而且同時理論上解決了采用橋接模塊潛在的通信速率瓶頸問題。

1 系統方案

本文設計的嵌入式WiFi方案是智能手機以WiFi方式遙控智能小車的系統，系統架構如圖1所示。手機端就是一個運行在手機上的Android應用程序，小車端的核心控制板采用STM32F105RB芯片，WiFi網卡采用基于RT5370的嵌入式模塊。RT5370是一款USB接口的WiFi芯片，基于其實現的USB無線網卡非常常見，價格優勢明顯。STM32F105RB是ST公司STM32系列芯片的一款，72 MHz主頻，具有128 KB Flash、48 KB RAM和豐富的I/O資源，同時價格比較低，在中小嵌入式系統中廣泛采用，同時其支持USB OTG，可以驅動RT5370。

該系統的核心就是在基于STM32F105RB的小車控制板上實現對RT5370 WiFi模塊的支持，使該控制板工作在AP模式，手機通過WiFi從控制板獲得IP，然后運行相應的Android應用程序控制小車。

2 硬件設計

小車控制板包括WiFi接口和功率輸出驅動兩大部分。因為本文的重點是嵌入式WiFi實現，所以只給出該部分的硬件實現，如圖2所示。圖中STM32F105RB的USB工作在主機模式，與WiFi模塊通過6引腳2.0 mm的單排針連接。由于STM32F105RB USB模塊內部有下拉電阻，所以電路連接非常簡單。

3 軟件流程及移植

系統軟件架構如圖3所示。整個系統由USB驅動、WiFi協議棧、網絡協議棧、應用程序4個主要部分組成。

USB部分實現WiFi網卡和系統MCU之間的通信，WiFi網卡收發的數據通過USB與MCU進行交互，STM32F105RB作為USB主機，WiFi網卡作為USB客戶端。

WiFi協議棧負責802.11協議的解析和封裝，向下和USB驅動交互，向上和TCP/IP協議棧交互：發送端，從TCP/IP協議棧接收數據，封裝成WiFi封包，通過調用USB驅動實現物理發送;接收端，從USB驅動接收數據，解析802.11協議，傳送給TCP/IP協議棧，實現向應用層的傳遞。

TCP/IP協議棧實現IP、ICMP、UDP、TCP等協議，包括實現協議封裝、解析以及基本的路由。當前有很多優秀的開源TCP/IP協議棧，本項目中選用LWIP，因為該協議比較成熟，適合資源有限的嵌入式系統。LWIP支持DHCP客戶端，但是在該系統中作為AP來用，需要DHCP服務器，這里自己設計了一個簡單的DHCP服務器。

應用程序部分，調用網絡編程接口和手機進行通信，將收到的數據轉化為驅動小車輸出的PWM信號，來驅動小車。

3.1 USB驅動

ST公司的固件庫提供了對于USB的支持。本系統就基于該USB庫架構，實現了USB WiFi模塊需要的特定功能。

STM32的USB庫架構如圖4所示，其給用戶提供的接口非常清晰，包括USB主機的初始化，以及對應狀態機的實現。

3.1.1 USB主機初始化

USB主機的初始化通過USBH_Init函數實現，這個函數有5個結構類型的參數，在調用這個函數前，需要先設置好這5個參數的內容。該函數原形如下：

參數pdev，phost分別代表STM32 USB的核心控制結構和USB主機的控制結構，在STM32的USB庫中已經定義，對應USB_OTG_CORE和USB_HOST。USB_OTG_FS_CORE_ID表示工作在USB的全速方式。參數Class_cb和usr_cb為用戶定義的USB類控制結構和用戶定義的初始化結構。這兩個結構是要實現的內容，其中，用戶定義的USB類控制結構，包括初始化、釋放、請求和狀態機4個處理函數，分別在代表用戶設計的USB類的初始化、釋放、初始化請求和正常工作狀態中會用到。

用戶根據要求分別實現對應的功能，對應本項目的WiFi模塊，具體的移植實現如下：

其中，USBH_CDC_InterfaceInit實現WiFi模塊的初始化，對應Linux版本驅動中的芯片寄存器配置、通信緩沖區配置、加載固件的掛鉤函數等處理，以及在MainVirtualIF_open中實現打開WiFi等操作。USBH_CDC_Handle則實現USB的狀態機功能。

用戶定義的初始化函數是給用戶提供一個實現自己特定初始化操作的接口，這里沒有用到。

這些參數都設置好后，直接調用USBH_Init即可實現對USB硬件和架構的初始化。

3.1.2 USB狀態機

USB初始化完成后，其核心處理都是由USB狀態機USBH_Process來實現從枚舉、功能處理到異?；謴偷鹊墓芾?，其中會通過函數掛鉤的方式調用在初始化過程中設置的對應函數。

具體狀態轉換過程如圖5所示。首先主機檢測是否有USB模塊插入，如果有，則轉入枚舉過程。對于本系統來說，WiFi模塊直接安裝在控制板上，上電后就會檢測到有插入并轉入枚舉過程;枚舉結束后，STM32F105RB的USB庫會給用戶提供一個用戶輸入和特定類初始化的操作，對于該WiFi模塊，歸屬于通信類，在類初始化操作中會作WiFi模塊相應地初始化，包括讀取模塊的配置信息、MAC地址等;在這些初始化過程完成后，會進入模塊狀態機處理過程，對于該WiFi模塊來說，就是循環處理接收數據的過程。在這個過程中如果發生異常，則進入異常處理后重新從空閑狀態開始狀態切換。標準的STM32F105RBUSB模塊還有USB模塊拔除的狀態轉換，由于該項目中WiFi模塊直接裝在母板上，所以不會進入這個狀態。

特別地，USB WiFi狀態機處理函數主要實現WiFi數據的傳輸，具體的傳輸通過USB的批處理傳輸方式進行。對于數據接收，系統會一直輪詢WiFi模塊，判斷是否有數據可用。如果有，則將數據讀入接收緩沖區中，并設置相應的標志通知上層軟件。對于數據發送，上層直接發起數據傳輸，調用USB發送函數，進行發送。

3.2 802.1 1協議驅動

WiFi協議棧的實現基于Mediatek官方提供的Linux源碼驅動，相應移植到該項目的STM32F105RB系統中。圖6分析了RT5370 Linux的驅動流程和需要完成的對應移植工作。

從左邊的驅動流程可以看出，首先是設置Linux驅動架構下面的probe、open等函數，在本系統中這塊并不需要，直接從硬件初始化開始，由于驅動本身就是可移植性比較好的C語言代碼，所以這塊代碼基本可以直接移植過來;然后是驅動所需的通信緩沖區的資源初始化，這部分和操作系統相關，根據本系統的情況，直接預留相應的內存作為通信緩沖區;WiFi對應的配置信息在Linux下是一個配置文件，在存在根文件的系統中，對于沒有文件系統的情況，直接將對應的配置值以默認值的方式保存，但是這也導致了一個問題，相應的WiFi配置(如SSID等)不可以更改，需要在后續實現中完善;這些設置工作都準備好后，啟動對應的定時器和2個任務分別處理WiFi的廣播Beacon連接信息和實際用戶數據，并用相應的定時器和模塊實現。

3.3 TCP/IP協議棧LWIP

完成了WiFi驅動從Linux到STM32F105RB系統的移植后，相當于實現了OSI模型中網絡層的移植，后續就是相應協議棧的移植。本項目中協議棧選用LWIP，版本是v1.3.2。需要指出的是，由于該項目的USB WiFi工作于AP模式，需要實現DHCP服務器的功能。而在LWIP中只有DHCP客戶端功能，服務器需要自己實現，在本項目中根據需要實現了一個簡單的DHCP服務器。

3.4 應用程序

在實現了WiFi驅動、協議棧以及DHCP服務器后，基于STM32的WiFi已經可以工作，分別用手機和計算機與控制板連接，成功獲得IP，在計算機端運行ping命令，可以成功ping通。在此基礎上，編寫基于LWIP的套接子程序，以及相應的小車驅動程序，實現通過手機可以流暢地控制小車。

結語

試驗表明，該系統實現的WiFi除具有成本方面的優勢外，還具有系統啟動快、通信響應快的特點，通常系統2 s即可以啟動，手機3 s即可以獲得IP，比常用路由器的響應快了很多;ICMP響應通常小于2 ms，響應速度的優勢也非常明顯。用手機通過WiFi控制智能小車，可以做到流暢控制。理論和實踐證明，在基于Cortex—M3的低成本嵌入式系統中實現WiFi是完全可行的。

當然，由于時間限制，該項目WiFi系統的加密功能，以及通常的WiFi系統需要的基于web界面方式的配置功能尚未實現?？紤]到當前STM32F105RB的資源使用情況，我們使用了80 KB空間，系統還留有48 KB空間，后續完整實現加密和Web界面配置在理論上是可行的，有待進一步驗證。