前言

很久之前就開始整理下面的優化項列表了，但是有很多問題研究不深，一時不敢冒失推出。
前不久，有人在論壇上提問，當時我給的答案比現在少，但是現在列出來的這些也不能保證是全部，以后再做補充吧。

lwip 協議棧、sal socket 抽象層使用了很多全局數組變量當作線程棧，可以修改成從內存堆動態申請的內存。
有些功能和特性在嵌入式設備里是用不到的，可以先去掉。
還有的是可有可無的特性，如果想用，也存在優化空間，可以自己實現。

以下說明不限于 lwip ，sal 部分也有涉及。

裁剪詳解

sal 可裁剪優化項

1. `SAL_INTERNET_CHECK`: 網絡檢測，使用到了 workqueue 。檢測原理就是嘗試連接 "link.rt-thread.org::8101"，發送檢測數據。
這個或者可以去掉檢測，或者換成自家服務器。
2. `#define SAL_SOCKETS_NUM 4`: 這個可能是支持創建 socket 的最大數量。
3. `RT_USING_NETDEV`: 網絡接口設備，沒有終端操作的情況下可以優化掉。其中，`NETDEV_USING_IFCONFIG` `NETDEV_USING_PING` `NETDEV_USING_NETSTAT` `NETDEV_USING_AUTO_DEFAULT` 分別可以單獨增刪。
4. `NETDEV_IPV6`: 目前支持還不普及的吧，可以關掉，如果需要才開啟。

lwip 可裁剪優化項

1. `RT_LWIP_IGMP` 組播需要用到的，不用組播可能可以去掉
2. `RT_LWIP_ICMP` ping 命令使用的協議，沒有 ping 也不需要這個協議。
3. `RT_LWIP_DNS` 局域網不需要這個，或者說，直接使用 ip 地址進行連接而不是使用 url 鏈接地址，可以不使用 dns。
4. `RT_LWIP_TCP_WND` tcp 接收窗口，這個應該是申請內存大小。可以適當減小。不定義就是 1460 x 2 字節
5. `RT_LWIP_TCP_SND_BUF` tcp 發送緩存，同上，不定義就是 1460 x 2 字節
6. `LWIP_NO_TX_THREAD` 和 `LWIP_NO_RX_THREAD` eth 線程，發送一個，接收一個。以下是幾個相關宏定義，如果不定義堆棧大小，默認使用 1024

   #define RT_LWIP_ETHTHREAD_PRIORITY 12
   #define RT_LWIP_ETHTHREAD_STACKSIZE 1024
   #define RT_LWIP_ETHTHREAD_MBOX_SIZE 8
   #define LWIP_NO_TX_THREAD
   #define LWIP_NO_RX_THREAD

源碼里，這部分還有很大優化空間，具體見下文詳解。
7. `LWIP_NETIF_STATUS_CALLBACK` 和前邊的 SAL_INTERNET_CHECK 有關，這里設置網絡連接回調。可以通知應用層連接上 INTERNET 了。
8. `LWIP_NETIF_LINK_CALLBACK` 網卡連接狀態，僅表示物理連接接入網絡，有可能是和電腦直連，或者交換機、路由器等等。
9. `SO_REUSE` 端口復用，這個在組播，而且是 UDP 協議才有用。不需要就定義成 0
10. `LWIP_SO_SNDTIMEO` `LWIP_SO_RCVTIMEO` `LWIP_SO_RCVBUF` 這三個，如果 rtconf.h 里沒有定義， lwipopts.h 會定義，所以不需要就定義成 0。
其中 LWIP_SO_RCVBUF 接收緩沖，涉及到接收緩沖上限。多數情況下不會有影響，只有網絡數據多的時候才可能達到這個緩存上限。
11. `RT_LWIP_USING_PING` 這個和前面的 NETDEV_USING_PING RT_LWIP_ICMP 有關。
12. `RT_LWIP_STATS` 這是一組 stat 的總開關，詳細細節查看 lwipopts.h 文件內的定義。或者取消 RT_LWIP_STATS 定義，關閉所有 stat 項，或者單獨修改 lwipopts.h 文件中某些 stat 定義。

13. 修改 eth_rx_thread 和 eth_tx_thread ，啟用 RT_USING_HEAP 后，添加動態創建線程。這兩個線程被初始化在 INIT_PREV_EXPORT 階段。片上內存堆和片外內地堆初始化注冊都在 INIT_BOARD_EXPORT 階段，可以申請使用動態內存。

erx etx 兩個線程

以 etx 為例。`ethernetif_linkoutput` 函數主要操作如下：

   if (rt_mb_send(e_tx_thread_mb, (rt_uint32_t) &msg) == RT_EOK)
   {
       /* waiting for ack */
       rt_sem_take(&(enetif->tx_ack), RT_WAITING_FOREVER);
   }

發送了一個郵箱，然后等待一個信號量。這個信號量從哪兒來？看下面的 etx 線程入口函數。

static void eth_tx_thread_entry(void* parameter)
{
   struct eth_tx_msg* msg;
   while (1)
   {
       if (rt_mb_recv(e_tx_thread_mb, (rt_ubase_t *)&msg, RT_WAITING_FOREVER) == RT_EOK)
       {
           struct eth_device* enetif;

           RT_ASSERT(msg->netif != RT_NULL);
           RT_ASSERT(msg->buf   != RT_NULL);

           enetif = (struct eth_device*)msg->netif->state;
           if (enetif != RT_NULL)
           {
               /* call driver's interface */
               if (enetif->eth_tx(&(enetif->parent), msg->buf) != RT_EOK)
               {
                   /* transmit eth packet failed */
               }
           }

           /* send ACK */
           rt_sem_release(&(enetif->tx_ack));
       }
   }
}

etx 等待 `ethernetif_linkoutput` 的郵件消息，然后調用 eth 驅動接口函數，完成后釋放信號量給 `ethernetif_linkoutput`一個應答。

從這里看，用上這個線程，需要額外增加兩次 ipc 消息。
去掉 etx 之后呢？`ethernetif_linkoutput` 變成下面的樣子。

static err_t ethernetif_linkoutput(struct netif *netif, struct pbuf *p)
{
   struct eth_device* enetif;
   RT_ASSERT(netif != RT_NULL);
   enetif = (struct eth_device*)netif->state;

   if (enetif->eth_tx(&(enetif->parent), p) != RT_EOK)
   {
       return ERR_IF;
   }
   return ERR_OK;
}

與使用 etx 線程唯一不同的是：使用線程時，發送數據操作 eth 驅動都在 etx 線程里進行的；如果去掉，就有可能多個應用線程同時發送數據，出現多個線程競爭 eth 驅動資源的現象。但是，這個可以經過優化應用層業務邏輯進行規避。

更多關于不使用 etx 和 erx 線程的修改，請移步我的 gitee 倉庫。

本系列提到的所有代碼更改已經提交到 gitee ，歡迎大家測試
https://gitee.com/thewon/rt_thread_repo

審核編輯：湯梓紅