LWIP使用經驗

<h1 align="center"><a name="t0"></a>LWIP使用經驗</h1>

<h2><a name="t1"></a>一 LWIP記憶體管理</h2>

LWIP的記憶體管理使用了2種方式：記憶體池memp和記憶體堆mem，如圖1所示。

記憶體池的特點是預先開辟多組固定大小的記憶體塊組織成連結清單，實作簡單，配置設定和回收速度快，不會産生記憶體碎片，但是大小固定，并且需要預估算準确。

記憶體堆的本質是對一個事先定義好的記憶體塊進行合理有效的組織和管理，主要用于任意大小的記憶體配置設定，實作較複雜，配置設定需要查找，回收需要合并，容易産生記憶體碎片，需要合理估算記憶體堆的總大小。

圖1記憶體池與記憶體堆

<h3><a name="t2"></a>1.     資料包管理</h3>

資料包管理結構pbuf共有四種類型，它們的特點和使用場合如表1所示。

<tbody>

<tr>

類别

</td>

配置設定方式

</td>

特點

</td>

使用場合

</td>

</tr>

<tr>

PBUF_RAM

</td>

記憶體堆，包括pbuf和資料區

</td>

長度不定，配置設定耗時

</td>

應用程式和協定棧

</td>

</tr>

<tr>

PBUF_POOL

</td>

記憶體池，包括pbuf和資料區

</td>

長度固定，配置設定快

</td>

中斷服務程式

</td>

</tr>

<tr>

PBUF_ROM

</td>

記憶體池，僅包括pbuf

</td>

所指資料位于ROM中

</td>

應用程式引用記憶體區

</td>

</tr>

<tr>

PBUF_REF

</td>

記憶體池，僅包括pbuf

</td>

所指資料位于RAM中

</td>

應用程式引用記憶體區

</td>

</tr>

</tbody>

</table>

表1  pbuf類型與特點

每一種pbuf配置設定記憶體的方式都不一樣，如圖2所示。

圖2四種資料包管理結構

隻有選擇合适的pbuf類型才能發揮LWIP的最大性能，一個資料包可能是多種pbuf的組合，用連結清單連接配接起來，如圖3所示。

圖3  pbuf連結清單

<h3><a name="t3"></a>2.     設定記憶體大小</h3>

為LWIP開辟一個專用的記憶體堆是應該的，這樣一來LWIP的mem_alloc()和mem_free()都将基于該堆記憶體進行配置設定和回收，不影響其他系統記憶體的使用。如圖1左所示，lwipopt.h檔案中宏MEM_SIZE定義了堆區的大小，對于一個負荷較重的系統堆區需要配置設定較大。

圖4堆和PBUF_ROM記憶體區

LWIP使用PBUF_ROM類型的記憶體池來發送“隻讀”資料（處于ROM中或者其他程序中不可修改），宏MEMP_NUM_PBUF定義了該緩沖池的個數，如圖2右所示。

在ISR（中斷服務程式中）經常需要快速配置設定一部分記憶體進行資料存儲，這是通過PBUF_POOL類型的緩沖區實作的。為此需要定義兩個宏：PBUF_POOL_SIZE定義緩沖池的個數，PBUF_POOL_BUFSIZE定義單個緩沖區的大小，如圖5所示。

圖5

PBUF_POOL記憶體區

<h3><a name="t4"></a>3 宏編譯開關</h3>

若定義MEM_LIBC_MALLOC=1，直接使用C庫中的malloc、free來配置設定動态記憶體；否則使用LWIP自帶的mem_malloc、mem_free等函數。

若定義MEMP_MEM_MALLOC=1，則memp.c中的全部内容不會被編譯，用記憶體堆來實作記憶體池配置設定，使用這種方式得考慮是否能忍受記憶體堆配置設定帶來的時間延遲。

若定義MEM_USE_POOLS=1，則mem.c中的全部内容不會被編譯，用記憶體池來實作記憶體堆的配置設定，使用這種方式得考慮是否能忍受因為POOL記憶體固定大小而帶來的記憶體浪費。此外使用者需要定義宏MEM_USE_CUSTOM_POOLS=1，還需要額外實作一個頭檔案lwippools.h，并在其中開辟一些用于記憶體堆配置設定函數的記憶體池POOL，開辟空間的格式如下：

LWIP_MALLOC_MEMPOOL_START

LWIP_MALLOC_MEMPOOL(20, 256)

LWIP_MALLOC_MEMPOOL(10, 512)

LWIP_MALLOC_MEMPOOL_END

<h2><a name="t5"></a>二 LWIP啟動時序</h2>

圖6展示了LWIP啟動時序，大部分函數都是LWIP自帶的，主要的移植代碼是eth_init()實作初始化以太網接口，啟動程式會建立2個線程：tcpip_thread負責LWIP的絕大部分工作（主要是協定棧的解析和系統運作），ethernetif_thread負責從網口接收資料包再傳遞給tcpip_thread線程進行處理。

圖6 LWIP啟動函數

<h2><a name="t6"></a>三 LWIP運作邏輯</h2>

<h3><a name="t7"></a>1 接收資料包</h3>

圖7接收資料包

當以太網口接收到一個資料包後，EMAC_IRQ中斷服務程式通過信号量通知ethernetif線程，ethernetif線程調用low_level_input()接收該資料包并通過郵箱傳遞給tcpip_thread線程，tcpip_thread根據該資料包的類型進行相應處理。它是建立在消息傳遞的基礎上的，如圖8所示。

圖8資料包消息的産生和處理

<h3><a name="t8"></a>2  SequentialAPI函數調用</h3>

API設計的核心在于讓使用者程序負責盡可能多的工作，例如資料的計算、拷貝等；而協定棧程序隻負責簡單的通信工作，這是很合理的，因為系統可能存在多個應用程式，它們都使用協定棧程序提供的通信服務，保證核心程序的高效性和實時性是提高系統性能的重要保障。程序之間通信使用IPC技術，包括郵箱、信号量和共享記憶體，如圖9所示。

圖9協定棧API實作

以函數netconn_bind()為例看API是如何實作的，首先使用者程式中調用函數netconn_bind()綁定一個連接配接，則這個函數實作時，是通過向核心程序發送一個TCPIP_MSG_API類型的消息，告訴核心程序執行do_bind函數：在消息發送後，函數阻塞在信号量上，等待核心處理該消息；核心在處理消息時，會根據消息内容調用do_bind，而do_bind會根據連接配接的類型調用核心函數udp_bind、tcp_bind或raw_bind；當do_bind執行完後，它會釋放信号量，這使被阻塞的netconn_bind得以繼續執行，整個過程如圖10所示。

圖10 API函數實作

<h2><a name="t9"></a>四 TCP/IP核心知識點</h2>

圖11滑動視窗

接收視窗相關的字段中，rcv_nxt是自己期望收到的下一個位元組編号，rcv_wnd表示接收視窗的大小，rcv_ann_wnd表示将向對方通告的視窗大小值，這個值在封包發送時會被填在首部中的視窗大小字段，rcv_ann_right_edge記錄了上一次視窗通告時視窗右邊界取值。上面這四個字段都會随着資料的發送和接收動态地改變，如圖12所示。

圖12接收視窗

發送視窗中，lastack記錄了被接收方确認的最高序列号，snd_nxt表示自己将要發送的下一個資料的起始編号，snd_wnd記錄了目前的發送視窗大小，它常被設定為接收方通告的接收視窗值，snd_lbb記錄了下一個被應用程式緩存的資料的起始編号，如圖10所示。

上面這四個字段的值也是動态變化的，每當收到接收方的一個有效ACK後，lastack的值就做相應的增加，指向下一個待确認資料的編号，當發送一個封包後，snd_nxt的值就做相應的增加，指向下一個待發送資料，snd_nxt和lastack之間的內插補點不能超過snd_wnd的大小。

由于實際資料發送時是按照封包段的形式組織的，是以可能存在這樣的情況：即使發送視窗允許，但并不是視窗内的所有資料都能發送以填滿視窗，如圖13中編号為11～13的資料，可能因為它們太小不能組織成一個有效的封包段，是以不會被發送。發送方會等到新的确認到來，進而使發送視窗向右滑動，使得更多的資料被包含在視窗中，這樣再啟動下一個封包段的發送。

圖13發送視窗

圖14連接配接建立過程

<h3><a name="t12"></a>3.       斷開連接配接</h3>

圖15連接配接斷開過程

<h3><a name="t13"></a>4.      TCP狀态轉換</h3>

圖16  TCP狀态轉換圖

圖17雙方同時打開

圖18雙方同時關閉

<h2><a name="t16"></a>五正确使用LWIP</h2>

一般說來LWIP協定棧是比較穩定的，尤其像V1.3.2經曆過業界廣泛使用和工程應用，完全可以應用于<a href="http://lib.csdn.net/base/embeddeddevelopment" target="_blank" rel="external nofollow" class="replace_word" title="嵌入式開發知識庫" target="_blank" style="color:#df3434; font-weight:bold;">嵌入式</a>産品。那為什麼還是有很多人反映LWIP不穩定呢？主要是以下幾個方面的原因：

1.      網絡硬體驅動 確定EMAC口接收與發送穩定可靠

2.      移植LWIP 基于OS的移植代碼正确穩定

3.      配置LWIP 根據裝置RAM尺寸進行合理配置

1)        值(PBUF_POOL_SIZE * PBUF_POOL_BUFSIZE)必須大于TCP_SND_BUF和TCP_WND，否則容易引起錯誤；

2)        當記憶體有限時TCP發送不能太快（具體值依賴于配置設定記憶體的大小），否則引起tcp_enqueue()邏輯錯誤；

4.      調用LWIP的API函數 正确使用API函數，特别防止記憶體洩露。

5.      資源不足 打開報警提醒，當資源不夠時提醒設計者

<h2><a name="t17"></a>六 LWIP常見問題</h2>

<h3><a name="t18"></a>1.       網卡驅動程式</h3>

首先，必須将協定棧完全初始化才能打開網絡接收功能，接收中斷必須将資料封裝在PBUF中，然後交會給協定棧核心處理。其次，LWIP的全局變量（arp_table,netif_list,udp_pcbs等）確定賦初值0，否則容易一運作就崩潰。

<h3><a name="t19"></a>2.       記憶體洩露</h3>

第一個原則（責任制）：誰配置設定記憶體，誰就負責回收。

第二個原則（對稱性）：配置設定記憶體者與回收記憶體者一一對應構成閉環。

另外，需要特别注意一些系統函數的調用，它們也會帶來記憶體洩露，如：

例1

newconn = netconn_accept(conn);

do_something_for(newconn);

netconn_close(newconn);

netconn_delete(newconn);

例2

inbuf = netconn_recv(conn);

do_something_for(inbuf);

netbuf_delete(inbuf);

<h3><a name="t20"></a>3.      PC機無法與LWIP建立TCP連接配接</h3>

問題：PC機能夠與LWIP裝置PING操作成功，但是無法建立TCP連接配接。

原因：通過代碼跟蹤，發現LWIP發出了SYN+ACK資料包，但是PC機無法接收該握手資料包，該資料包為60位元組，小于以太網的最小長度（64位元組），而LWIP裝置的EMAC沒有設定短小資料包填充功能，導緻PC機無法接收該短資料包。

解決：使能EMAC的短小資料包填充功能。

</div>

LWIP使用經驗

繼續閱讀

千兆以太網測試儀價格

10G_Ethernet_03 Example Design1 Example Design 簡介2 Example Design 詳解3 Test Bench4 Example Design 的仿真5 設計資源傳送門

Ethernet and the NicheStack TCP/IP Stack - NIOS II Edtion

lwip---（五）以太網資料接收

以太網模型以及以太網的接入方案

RS-232、RS-485與以太網介紹

rj45連接配接器 10引腳_什麼是RJ45連接配接器？ RJ代表注冊傑克 (RJ Stands For Registered Jack) RJ45零件 (RJ45 Parts) RJ45電纜 (RJ45 Cabling)

計網--資料鍊路層(3)--資料鍊路層的硬體裝置資料鍊路層的硬體裝置網卡

涉及幀間隙的CSMA/CD的偵聽多久該發送

思科CCNA第三學期第五章答案

ESP32 應用實踐：ethernet 轉 WiFi 實作

【計算機通信網絡複習】Ethernet基本工作原理1. Ethernet幀結構2. Ethernet資料發送、接收流程分析

計算機網絡——以太網幀結構/格式

Android物聯網進階指令彙總(Root,系統簽名)

現代作業系統之多處理機系統（上）多處理機

計算機網絡原理——資料鍊路層的這些知識你真的知道嗎？以太網