用RT5370模塊實現(xiàn)的低成本嵌入式WiFi系統(tǒng)

引言

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

1 系統(tǒng)方案

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

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

2 硬件設(shè)計

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

3 軟件流程及移植

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

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

WiFi協(xié)議棧負(fù)責(zé)802.11協(xié)議的解析和封裝，向下和USB驅(qū)動交互，向上和TCP/IP協(xié)議棧交互：發(fā)送端，從TCP/IP協(xié)議棧接收數(shù)據(jù)，封裝成WiFi封包，通過調(diào)用USB驅(qū)動實現(xiàn)物理發(fā)送;接收端，從USB驅(qū)動接收數(shù)據(jù)，解析802.11協(xié)議，傳送給TCP/IP協(xié)議棧，實現(xiàn)向應(yīng)用層的傳遞。

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

應(yīng)用程序部分，調(diào)用網(wǎng)絡(luò)編程接口和手機進(jìn)行通信，將收到的數(shù)據(jù)轉(zhuǎn)化為驅(qū)動小車輸出的PWM信號，來驅(qū)動小車。

3.1 USB驅(qū)動

ST公司的固件庫提供了對于USB的支持。本系統(tǒng)就基于該USB庫架構(gòu)，實現(xiàn)了USB WiFi模塊需要的特定功能。

STM32的USB庫架構(gòu)如圖4所示，其給用戶提供的接口非常清晰，包括USB主機的初始化，以及對應(yīng)狀態(tài)機的實現(xiàn)。

3.1.1 USB主機初始化

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

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

用戶根據(jù)要求分別實現(xiàn)對應(yīng)的功能，對應(yīng)本項目的WiFi模塊，具體的移植實現(xiàn)如下：

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

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

這些參數(shù)都設(shè)置好后，直接調(diào)用USBH_Init即可實現(xiàn)對USB硬件和架構(gòu)的初始化。

3.1.2 USB狀態(tài)機

USB初始化完成后，其核心處理都是由USB狀態(tài)機USBH_Process來實現(xiàn)從枚舉、功能處理到異?；謴?fù)等的管理，其中會通過函數(shù)掛鉤的方式調(diào)用在初始化過程中設(shè)置的對應(yīng)函數(shù)。

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

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

3.2 802.1 1協(xié)議驅(qū)動

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

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

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

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

3.4 應(yīng)用程序

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

結(jié)語

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

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