lwip之 pbuf.c 檔案學習
pbuf 資料結構
各欄位說明：
next 字段指標指向下乙個 pbuf 結構，因為實際傳送或接收的資料報可能很大，而每個 pbuf 能夠管理的資料可能很少，所以，往往需要多個 pbuf 結構才能完全描述乙個資料報。所以，所有的描述同乙個資料報的 pbuf 結構需要鏈在乙個鍊錶上，這一點用 next 實現。
payload 是資料指標，指向該 pbuf 管理的資料的起始位址，這裡，資料的起始位址可以是緊跟在 pbuf 結構之後的 ram，也可能是在 rom上的某個位址，而決定這點的是當前 pbuf 是什麼型別的，即 type 欄位的值；
len 字段表示當前 pbuf 中的有效資料長度；
tot_len 表示當前 pbuf 和其後所有 pbuf的有效資料的長度。顯然， tot_len 欄位是 len 欄位與 pbuf 鏈中隨後乙個 pbuf 的 tot_len 欄位的和；pbuf 鏈中第乙個 pbuf 的 tot_len 字段表示整個資料報的長度，而最後乙個 pbuf 的 tot_len欄位必和 len 字段相等。 （p->tot_len == p->len + (p->next? p->next->tot_len: 0)）
type 字段表示 pbuf 的型別，主要有四種型別： pbuf_ram、 pbuf_rom、 pbuf_ref和 pbuf_pool。
flags 欄位也表示 pbuf 的型別 (misc flags ).
ref 字段表示該 pbuf 被引用的次數。初始化乙個 pbuf 的時候， ref 字段值被設定為 1，當有其他 pbuf 的 next 指標指向該 pbuf 時，該 pbuf 的 ref 欄位值加一。所以，要刪除乙個 pbuf 時，ref 的值必須為 1 才能刪除成功，否則刪除失敗。
詳細原理見原著：
《 design and implementation of the lwip： tcp/ip stack》，不過有點老了，其中**說明和最新更新的lwip有所變化。
剩餘函式
void pbuf_realloc(struct pbuf *p, u16_t size);
u8_t pbuf_header(struct pbuf *p, s16_t header_size);
void pbuf_ref(struct pbuf *p);
u8_t pbuf_free(struct pbuf *p);
u8_t pbuf_clen(struct pbuf *p);
等，見：
《嵌入式網路那些事-lwip協議深度剖析與實戰演練》，第7章有比較清楚的解釋pbuf資料報各函式的使用。
《lwip協議棧原始碼詳解》。
LWIP 移植檔案
要將乙太網驅動和lwip鏈結在一起還需要一些中間檔案，這些檔案很重要。這些中間檔案包括 cc.h cpu.h perf.h sys arch.c 和sys arch.h。stm32f4x7 eth bsp.c netconf.c 為硬體驅動配置檔案。stm32f4x7 eth.c 驅動庫傳輸層硬體配...
一LWIP學習筆記之資料報管理
一 資料報管理 tcp ip 是一種資料通訊機制，因此，協議棧的實現本質上就是對資料報進行處理。資料報管理應該能提供一種高效的機制，使協議棧各層能對資料報進行靈活的處理，同時減少資料在各層間傳遞時的時間與空間開銷，這是提高協議棧工作效率的關鍵點。在 lwip 中，也有個類似的結構，稱之為 pbuf，...
LwIP之網路介面管理
協議棧內部使用netif的結構體來描述網路介面，先來看一下這個結構體。netif結構體 struct netif 關於標誌位的定義如下 網路介面標誌位 define netif flag up 0x01u 網路介面是否已被上層使能 define netif flag broadcast 0x02u ...