【正文】 om 進(jìn)行 eeprom 中的默認(rèn)配置的讀取， 其中就包括了射頻芯片信息的讀取，每個(gè)信道發(fā)射功率的配置， MAC 地址等信息。 rt2501_switch_channel 進(jìn)行初步的信道選擇 ，不進(jìn)行此步驟也可以，這僅僅用來(lái)測(cè)試。 ieee80211_init 協(xié)議棧的初始化。 b) 幀數(shù)據(jù)的發(fā)送 根據(jù) 幀的類型的不同，可以分為控制幀，管理幀，和數(shù)據(jù)幀，其中管理幀和數(shù)據(jù)幀是必須使用到的，所以驅(qū)動(dòng)程序必須實(shí)現(xiàn)對(duì)管理幀和數(shù)據(jù)幀的處理。而控制幀主要用來(lái)對(duì)數(shù)據(jù)的分片和 RTS， CTS 進(jìn)行處理這部分對(duì)于簡(jiǎn)單的通信來(lái)講是不需要的，所以并沒(méi)有實(shí)現(xiàn)控制幀的處理。 數(shù)據(jù) 幀發(fā)送的一般流程： 上 層 封 裝 好 的 數(shù) 據(jù)一 般 為 以 太 網(wǎng) 幀r t 2 5 0 1 _ s e n d執(zhí) 行 對(duì) 數(shù) 據(jù) 幀 的 封 裝是 否 已 連接 到 A P開(kāi) 始加 密 模 式 ？（ 未 實(shí) 現(xiàn) ）N O N E 。W E P 6 4 。W E P 1 2 8 。W P A 。8 0 2 . 1 1 地 址 ；L L C 層 ；填 充r t 2 5 0 1 _ m a k e _ t x _ d es c r i p t o r發(fā) 送 描 述 符 填 充結(jié) 束r t 2 5 0 1 _ t x執(zhí) 行 B U L K O U T 傳 輸結(jié) 束( 回 調(diào) 函 數(shù) 可 選 ） 圖 程 上層封裝好的數(shù)據(jù)包一般是以太網(wǎng)數(shù)據(jù)包， 因?yàn)樯蠈右话闶且粋€(gè) TCP/IP 協(xié)議棧，故這里需要對(duì)以太網(wǎng)數(shù)據(jù)包進(jìn)行轉(zhuǎn)換， 首先需去掉以太網(wǎng)幀頭，只保留 IP 包數(shù)據(jù)，然后根據(jù)此時(shí)連接的模式和網(wǎng)絡(luò)配置進(jìn)行對(duì) 幀頭的封裝， 幀頭比較重要的有兩個(gè)域，一是加密模式，因?yàn)榧用苣Ｊ降牟煌瑫?huì)影響許多域的設(shè)置，這里只實(shí)現(xiàn)了簡(jiǎn)單的無(wú)加密模式的封裝方式，二是地址域的裝填， addr1 裝填關(guān)聯(lián)到的路由的 MAC地址， 本 科 畢 業(yè) 設(shè) 計(jì) 第 23 頁(yè) 共 51 頁(yè) addr2 裝填 RT73 無(wú)線網(wǎng)卡的 MAC 地址 (源地址 )， addr3 裝填以太幀中的目的地址。 除裝填 協(xié) 議幀頭外，還需裝填基帶處理芯片的發(fā)送描述符，對(duì)于精簡(jiǎn)的驅(qū)動(dòng)程序而言，如果選擇無(wú)加密模式，需要設(shè)置的發(fā)送描述域較少，而且一些域比較固定。 將所有數(shù)據(jù)裝填好后，就可以調(diào)用 USB 發(fā)送函數(shù)發(fā)送數(shù)據(jù)了，真正的發(fā)送過(guò)程在中斷中啟動(dòng)，并在中斷中確認(rèn)結(jié)束，這里可以選用兩種方案進(jìn)行 USB 發(fā)送過(guò)程， 一種是等待 USB發(fā)送過(guò)程的結(jié)束，一種是發(fā)送完畢后通知主程序。 第一種方案效率比較低，第二種方案的軟件編寫(xiě)較復(fù)雜，所以后面具體實(shí)現(xiàn)時(shí)采用了 RTOS 的方法。 c) 幀數(shù)據(jù)的接收 和數(shù)據(jù)幀的發(fā)送相比， 數(shù)據(jù)幀的接收比較復(fù)雜，因?yàn)閿?shù)據(jù)幀 的發(fā)送本質(zhì)上是異步的，當(dāng)有數(shù)據(jù)幀需要發(fā)送時(shí)，隨即調(diào)用發(fā)送函數(shù)將數(shù)據(jù)幀發(fā)送出去，而數(shù)據(jù)幀的接收本質(zhì)是一個(gè)中斷的過(guò)程，而 USB 總線的特點(diǎn)是主機(jī)輪詢，所以當(dāng)有數(shù)據(jù)幀放入基帶芯片的緩沖區(qū)中時(shí)， 基帶芯片不能主動(dòng)通知 PIC32，而需要 PIC32 主動(dòng)試探，當(dāng)沒(méi)有數(shù)據(jù)時(shí)，基帶芯片返回 NAK 握手包，直到有數(shù)據(jù)才返回?cái)?shù)據(jù)， 這樣 PIC32 的輪詢頻率就是一個(gè)關(guān)鍵的變量，輪詢的時(shí)間間隔不能過(guò)小，過(guò)小會(huì)導(dǎo)致 CPU 負(fù)荷較重，也不能間隔過(guò)大，過(guò)大會(huì)使數(shù)據(jù)通信延遲 變大 ， 綜合考慮將 BULKIN，傳輸設(shè)置為 1ms 進(jìn)行一次，也就是每次 sof包后 立即進(jìn)行一次 BULKIN 傳輸。當(dāng)有數(shù)據(jù)時(shí)隨即進(jìn)行讀入，當(dāng)收到 NAK 握手包時(shí)， 等待下一次 sof 包后 進(jìn)行 BULKIN 傳輸。 具體的接收流程如圖 ： 等 待R T 7 3 初 始 化 ？8 0 2 . 1 1 協(xié) 議 棧 初 始 化 ？連 接 A P ？啟 動(dòng) 一 次 B U L K I N 傳 輸否是返 回 數(shù) 據(jù) 幀8 0 2 . 1 1 協(xié) 議 棧 處 理拷 貝 上 層 數(shù) 據(jù)完 成返 回 N A K 包沒(méi) 有 數(shù) 據(jù)發(fā) 送 I N 令 牌等 待 s o f 包得 到 數(shù) 據(jù)沒(méi) 有 數(shù) 據(jù)T C P / I P 上 層 處 理 圖 當(dāng)經(jīng)過(guò) 協(xié)議棧處理后，如果是管理幀，則我們直接進(jìn)行管理幀的封裝然后發(fā)送出去進(jìn)行響應(yīng)，當(dāng)是網(wǎng)絡(luò)數(shù)據(jù)包時(shí)，需要將數(shù)據(jù)包暫存起來(lái)然后經(jīng)由 TCP/IP 層協(xié) 本 科 畢 業(yè) 設(shè) 計(jì) 第 24 頁(yè) 共 51 頁(yè) 議處理 。 d) 協(xié)議棧處理 協(xié)議棧處理部分是整個(gè)驅(qū)動(dòng)程序協(xié)議棧處理的核心，因?yàn)檫@里沒(méi)有實(shí)現(xiàn)linux中類似的 MLME和 CMD核心線程， 所以一些類似的管理幀都由接收時(shí)的協(xié)議棧處理 。圖 是接收幀的 整體處理 流程 P r o t o c o l S t a c k _ 8 0 2 1 1處 理 接 收 幀 主 函 數(shù)判 斷 數(shù) 據(jù) 校 驗(yàn)i e e e 8 0 2 1 1 _ i n p u t實(shí) 際 的 幀 處 理 函 數(shù)O K數(shù) 據(jù) 幀 處 理 管 理 幀 處 理 控 制 幀 處 理 圖 處理程序根據(jù)不同的幀的類型轉(zhuǎn)到了不同的處理函數(shù)中 ，見(jiàn)圖 i e e e 8 0 2 1 1 _ i n p u t _ m g t管 理 幀 數(shù) 據(jù) 進(jìn) 入具 體 幀 類 型 的 判 定P r o b e r e s p o n s e幀B e a c o n 幀A s s o c i a t e r e s p o n s e 幀獲 取 A P 的 基 本 信息 ， 加 密 模 式 ， 支持 的 速 率 ， B S S I D ，S S I D 等處 于 S C A N 狀 態(tài) ？S C A N 回 調(diào) 函 數(shù)是切 換 為 R U N 狀 態(tài) 圖 管理幀處理 進(jìn)入 ieee80211_input_mgt 處理后，首先根據(jù) subtype 域判定收到的幀狀態(tài)，根據(jù)不同的幀狀態(tài)執(zhí)行不同的處理。 probe response 幀和 beacon 幀 的處理代碼相同，因?yàn)檫@兩種幀都是由 AP 發(fā)送出 本 科 畢 業(yè) 設(shè) 計(jì) 第 25 頁(yè) 共 51 頁(yè) 的用來(lái)宣告網(wǎng)絡(luò)存在的管理幀，這兩種幀包含的信息基本相同，通常情況下，無(wú)線 AP會(huì)隔一段時(shí)間發(fā)送一個(gè) beacon 幀，而 probe response 幀是 在 probe request 幀發(fā)出后，無(wú)線 AP 的回應(yīng)幀，包括了無(wú)線網(wǎng)絡(luò)的參數(shù)， BSSID， SSID，加密的方式，支持的速率等信息。 當(dāng)收到 beacon 幀或 probe response 幀后，如果無(wú)線 網(wǎng)卡處于 SCAN 狀態(tài)下，會(huì)將處理后的 beacon 幀結(jié)果傳入 scan_callback 回調(diào)函數(shù)中， 在這個(gè)回調(diào)函數(shù)中，單片機(jī)會(huì)發(fā)送 association 幀，最終會(huì)和無(wú)線 AP 建立鏈路層的連接。 數(shù)據(jù)幀處理流程 ，見(jiàn) i e e e 8 0 2 1 1 _ i n p u t _ d a t a數(shù) 據(jù) 幀 輸 入判 斷 地 址 域 的 地 址 是否 匹 配 ？i e e e 8 0 2 1 1 _ n e w _ r s s i _ s a m p l e根 據(jù) 收 到 的 數(shù) 據(jù) 計(jì) 算 新 的r s s i 采 樣 值判 斷 D A T A 類 型 ？N O _ D A T A 類 型P i n g f r o m A PR e p l a y i n g !結(jié) 束 處 理正 常 的 通 信 數(shù) 據(jù)去 除 l l c 層 數(shù) 據(jù)直 接 在 本 地 緩 沖 裝 填為 以 太 幀 圖 數(shù)據(jù)幀處理 數(shù)據(jù)幀一般有兩種類型，一種類型為 NO_DATA 數(shù)據(jù)，此種數(shù)據(jù)只是無(wú)線 AP 為了求證工作站是否還存在于網(wǎng)絡(luò)中，每當(dāng)工作站有一段時(shí)間沒(méi)有進(jìn)行通信后， 無(wú)線 AP 就會(huì)發(fā)送 NO_DATA 數(shù)據(jù)包；另外一種數(shù)據(jù)幀就是正常的網(wǎng)絡(luò)數(shù)據(jù)包，這種數(shù)據(jù)包只需將幀頭簡(jiǎn)單處理即可將 數(shù)據(jù)幀變?yōu)橐蕴W(wǎng)數(shù)據(jù)幀。 這里并沒(méi)有進(jìn)行數(shù)據(jù)的拷 貝，主要是效率的考慮，直接利用 USBIN 傳輸?shù)慕邮站彌_區(qū)，所以在以太網(wǎng)幀封裝好后立即進(jìn)行 TCP/IP 層的處理。 LWIP 和 FreeRTOS 的移植 WIFI 控制系統(tǒng)僅僅有網(wǎng)卡驅(qū)動(dòng)是不夠的，還需實(shí)現(xiàn)上層 TCP/IP 協(xié)議 ， TCP/IP 協(xié)議 本 科 畢 業(yè) 設(shè) 計(jì) 第 26 頁(yè) 共 51 頁(yè) 選用的是 LWIP，輕量型的 TCP/IP 協(xié)議，實(shí)現(xiàn)了 TCP/IP 大部分的功能， 此外，系統(tǒng)的軟件結(jié)構(gòu)決定了 WIFI 控制系統(tǒng)的數(shù)據(jù)實(shí)時(shí)性和吞吐率 ，一般而言，單片機(jī)程序的結(jié)構(gòu)為前后臺(tái)型。前后臺(tái)程序，中斷處理程序?yàn)榍芭_(tái)程序， main 函數(shù)中的循環(huán)為后臺(tái)程序，當(dāng)有數(shù)據(jù)中斷主循環(huán)時(shí)， 系統(tǒng)會(huì)跳至中斷程序中對(duì)中斷數(shù)據(jù)進(jìn)行處理，中斷程序會(huì)設(shè)置全局變量通知主循環(huán)中的函數(shù)對(duì)數(shù)據(jù)進(jìn)行處理，所以從數(shù)據(jù)中斷產(chǎn)生到對(duì)數(shù)據(jù)進(jìn)行處理之間有一個(gè)延遲，這個(gè)延遲決定于主循環(huán)的時(shí)間，如果主循環(huán)循環(huán)一次時(shí)間較長(zhǎng)，或者有類似延時(shí)的阻塞代碼，此時(shí)響應(yīng)時(shí)間會(huì)大大增加 。和前后臺(tái)程序相對(duì)應(yīng)的一種程序結(jié)構(gòu)是基于實(shí)時(shí)操作系統(tǒng) (RTOS)的結(jié)構(gòu)，這個(gè)時(shí)候最底層 運(yùn)行的是 RTOS， 每當(dāng)有數(shù)據(jù)中斷發(fā)生時(shí)，數(shù)據(jù)處理任務(wù)一般處于一個(gè)較高的優(yōu)先級(jí)中，所以會(huì)搶占正在運(yùn)行的低優(yōu)先級(jí)的任務(wù)的 CPU時(shí)間，此時(shí)中斷中的數(shù)據(jù)就會(huì)得到立即響應(yīng)。 采用 RTOS 的 缺點(diǎn)是 RTOS 本身就占用了一定的資源，所以 RTOS 一般用在資源相對(duì)豐富的嵌入式系統(tǒng)中。 本節(jié) 將 LWIP協(xié)議棧和實(shí)時(shí)操作系統(tǒng) FreeRTOS放在一起主要是考慮這兩個(gè)組件聯(lián)系密切， LWIP 是輕量級(jí)的 IP 協(xié)議棧，并且具有靈活的配置選項(xiàng)，方便裁剪和配置。 根據(jù)系統(tǒng)的需要和系統(tǒng)資源的限制，對(duì) LWIP 進(jìn)行了裁剪和配置。移植 LWIP 最重要的是實(shí)現(xiàn)鏈路層的設(shè)備接口 ，故 分別添加了 iwif 無(wú)線 WiFi 的接口定義和底層數(shù)據(jù)包的收發(fā)代碼，此外還需實(shí)現(xiàn)操作系統(tǒng)模擬層的代碼，這部分 FreeRTOS 支持的比較完善。 LWIP 協(xié)議棧的移植 LWIP 的作者已經(jīng)為移植提供了框架和接口，移植需要改動(dòng)以下的文件： a) 這個(gè)文件中實(shí)現(xiàn)了操作系統(tǒng)模擬層， LWIP 可以被配置為在 RTOS 中運(yùn)行，它內(nèi)部會(huì)有一個(gè)核心 TCP/IP 線程，這個(gè) TCP/IP 線程在沒(méi)有數(shù)據(jù)包收到時(shí)處于阻塞狀態(tài)，一旦有數(shù)據(jù)包收到，此時(shí)網(wǎng)卡接口層會(huì)向 TCP/IP 線程發(fā)送數(shù)據(jù)包的指針， TCP/IP 線程接收到數(shù)據(jù)包指針開(kāi)始處理收到的數(shù)據(jù)幀。 基本上 FreeRTOS 提供的系統(tǒng)服務(wù)能夠滿足 LWIP 的需要。 b) 網(wǎng)絡(luò)接口層， LWIP 作者已實(shí)現(xiàn) 了程序框架，只要進(jìn)行修改即可。 網(wǎng)絡(luò)接口層最終需要實(shí)現(xiàn)三個(gè)底層操作，分別是設(shè)備初始化，數(shù)據(jù)包接收和數(shù)據(jù)包發(fā)送，分別對(duì)應(yīng)的實(shí)現(xiàn)函數(shù)為 low_level_init, low_level_input 和 low_level_output， low_level_init 初始化中主要完成 MAC地址的讀取， low_level_input 中主要是 將從 USB 中獲取的 本 科 畢 業(yè) 設(shè) 計(jì) 第 27 頁(yè) 共 51 頁(yè) 幀進(jìn)行處理，在此函數(shù)中會(huì)調(diào)用 協(xié)議棧處理函數(shù)，如果收到數(shù)據(jù)包會(huì)申請(qǐng)內(nèi)存空間，經(jīng)過(guò)此函數(shù)處理后的數(shù)據(jù)包會(huì)從 數(shù)據(jù)包變?yōu)闃?biāo)準(zhǔn)的以太網(wǎng)數(shù)據(jù)包 ；low_level_output 中的處理正好相反，是把上層的以太網(wǎng)的數(shù)據(jù)幀的頭部轉(zhuǎn)化成無(wú)線WIFI 的數(shù)據(jù)幀的格式，然后通過(guò)網(wǎng)卡發(fā)送出去。 c) 此文件中實(shí)現(xiàn)了 LWIP 協(xié)議棧的入口程序，包括網(wǎng)卡的裝載以及協(xié)議棧的初始化 ，LWIP 支持多網(wǎng)卡，這里 RT73 無(wú)線網(wǎng)卡會(huì)裝載到 LWIP 的網(wǎng)卡鏈表中。 LWIP 協(xié)議棧的配置 LWIP 的基本配置信息在文件 中，以下是基本配置信息 ： define TCPIP_THREAD_STACKSIZE 400 TCP/IP 核心線程棧大小 define IP_REASSEMBLY 0 不 需要 IP片重組 define IP_FRAG 0 不需要分片 define LWIP_UDP 1 支持 UDP define LWIP_TCP 1 支持 TCP define LWIP_ARP 1 支持 ARP define LWIP_SOCKET 1 BSD socket 支持 define MEM_LIBC_MALLOC 1 使用庫(kù)函數(shù)申請(qǐng)內(nèi)存 define MEMP_MEM_MALLOC 1 不采用內(nèi)存池 define MEM_ALIGNMENT 4 PIC32 CPU 采用 4字節(jié)對(duì)齊 define NO_SYS 0 啟用操作系統(tǒng)支持 協(xié)議 棧配置的要求是在滿足應(yīng)用層的需求的前提下使資源的使用量最小， 為了測(cè)試RT73 網(wǎng)卡驅(qū)動(dòng)程序， 這里配置 支持 TCP 和 UDP 協(xié)議。 另外一部分就是數(shù)據(jù)包收發(fā)所占用的緩存空間，這部分空間雖然對(duì)于網(wǎng)絡(luò)應(yīng)用算是小的了，但是對(duì)于 RAM 只有 32K 的 PIC單片機(jī)來(lái)說(shuō)是非常有限的，所以在配置的時(shí)候