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

引言

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

1 系統方案

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

該系統的核心就是在基于STM32F105RB的小車(chē)控制板上實(shí)現對RT5370 WiFi模塊的支持，使該控制板工作在A(yíng)P模式，手機通過(guò)WiFi從控制板獲得IP，然后運行相應的Android應用程序控制小車(chē)。

2 硬件設計

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

3 軟件流程及移植

系統軟件架構如圖3所示。整個(gè)系統由USB驅動(dòng)、WiFi協(xié)議棧、網(wǎng)絡(luò )協(xié)議棧、應用程序4個(gè)主要部分組成。

USB部分實(shí)現WiFi網(wǎng)卡和系統MCU之間的通信，WiFi網(wǎng)卡收發(fā)的數據通過(guò)USB與MCU進(jìn)行交互，STM32F105RB作為USB主機，WiFi網(wǎng)卡作為USB客戶(hù)端。

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

TCP/IP協(xié)議棧實(shí)現IP、ICMP、UDP、TCP等協(xié)議，包括實(shí)現協(xié)議封裝、解析以及基本的路由。當前有很多優(yōu)秀的開(kāi)源TCP/IP協(xié)議棧，本項目中選用LWIP，因為該協(xié)議比較成熟，適合資源有限的嵌入式系統。LWIP支持DHCP客戶(hù)端，但是在該系統中作為AP來(lái)用，需要DHCP服務(wù)器，這里自己設計了一個(gè)簡(jiǎn)單的DHCP服務(wù)器。

應用程序部分，調用網(wǎng)絡(luò )編程接口和手機進(jìn)行通信，將收到的數據轉化為驅動(dòng)小車(chē)輸出的PWM信號，來(lái)驅動(dòng)小車(chē)。

3.1 USB驅動(dòng)

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

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

3.1.1 USB主機初始化

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

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

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

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

用戶(hù)定義的初始化函數是給用戶(hù)提供一個(gè)實(shí)現自己特定初始化操作的接口，這里沒(méi)有用到。

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

3.1.2 USB狀態(tài)機

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

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

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

3.2 802.1 1協(xié)議驅動(dòng)

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

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

3.3 TCP/IP協(xié)議棧LWIP

完成了WiFi驅動(dòng)從Linux到STM32F105RB系統的移植后，相當于實(shí)現了OSI模型中網(wǎng)絡(luò )層的移植，后續就是相應協(xié)議棧的移植。本項目中協(xié)議棧選用LWIP，版本是v1.3.2。需要指出的是，由于該項目的USB WiFi工作于A(yíng)P模式，需要實(shí)現DHCP服務(wù)器的功能。而在LWIP中只有DHCP客戶(hù)端功能，服務(wù)器需要自己實(shí)現，在本項目中根據需要實(shí)現了一個(gè)簡(jiǎn)單的DHCP服務(wù)器。

3.4 應用程序

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

結語(yǔ)

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

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