GD32F407裸机LWIP移植实战

GD32F407裸机环境下LWIP移植实战

在工业控制和物联网终端设备中，网络通信能力正逐渐成为标配功能。然而，并非所有项目都能负担操作系统的开销——尤其是那些对实时性要求高、资源紧张的嵌入式系统。这时候，一个轻量级、可裁剪的TCP/IP协议栈就显得尤为重要。

GD32F407作为国产Cortex-M4内核MCU中的佼佼者，主频高达168MHz，集成了完整的以太网MAC控制器，配合外接PHY芯片（如LAN8720或KSZ8081），完全可以胜任基础网络应用的需求。而LWIP（Lightweight IP）正是为此类场景量身打造的解决方案：它能在仅几十KB RAM的条件下运行，支持TCP、UDP、DHCP等核心协议，且具备良好的可移植性。

更关键的是，在无操作系统环境下，LWIP采用“轮询+中断”机制工作，避免了任务调度带来的复杂性和不确定性。这使得开发者可以在裸机系统中实现稳定可靠的网络功能，同时最大限度地控制资源消耗。

---

要让LWIP在GD32F407上跑起来，第一步是打通底层硬件驱动与协议栈之间的桥梁。整个系统的核心在于 ethernetif.c 文件中几个关键接口函数的实现： low_level_init 、 low_level_input 、 low_level_output ，以及主循环中的定时器处理逻辑。

GD32F407的以太网子系统由三部分组成：MAC控制器、DMA引擎和外部PHY芯片。其中MAC负责帧格式封装与CRC校验，DMA管理数据缓冲区传输，而PHY完成物理层信号转换和链路协商。它们通过RMII接口协同工作，使用50MHz参考时钟进行同步。

典型的初始化流程如下：

• 开启相关时钟（RCU_ENET、GPIO等）
• 配置RMII引脚为复用推挽输出模式
• 复位并配置PHY（通过MDIO/MDC接口设置自协商、双工模式等）
• 初始化DMA描述符环形队列
• 启动MAC和DMA

这里有个细节容易被忽视：DMA缓冲区必须32字节对齐。否则可能导致总线访问异常或性能下降。因此，在定义接收/发送缓冲区时应使用 __ALIGN32 宏：

__ALIGN32 uint8_t rx_buffer[ENET_RXBUF_NUM][ENET_BUFSIZE];
__ALIGN32 uint8_t tx_buffer[ENET_TXBUF_NUM][ENET_BUFSIZE];

DMA描述符则构成一个环形链表，每个描述符包含状态、控制信息、数据长度和缓冲区地址。接收描述符初始化时需将OWN位设为1，表示DMA拥有该缓冲区；发送描述符初始状态为空闲。最后一个描述符的RER（Receive End of Ring）或TER（Transmit End of Ring）位需要置位，形成闭环。

rx_desc_tab[i].status = DES0_RX_CTRL_OWN;
rx_desc_tab[i].control_size = ENET_BUFSIZE;
rx_desc_tab[i].buffer1_addr = (uint32_t)&rx_buffer[i];

当数据包到达时，PHY解码后交由MAC处理，DMA自动将帧写入指定RX Buffer，并触发中断。此时CPU进入中断服务程序，调用 low_level_input() 函数从描述符中提取有效数据长度，并将其封装成LWIP所需的 pbuf 结构体。

struct pbuf *low_level_input(struct netif *netif) {
    struct eth_dma_desc *d = rx_desc_cur;

    if (d->status & DES0_RX_CTRL_OWN)
        return NULL; // 缓冲区仍在DMA手中

    uint32_t len = ((d->status & DES0_RX_CTRL_FL) >> 16) - 4; // 减去CRC
    struct pbuf *p = pbuf_alloc(PBUF_RAW, len, PBUF_POOL);

    if (p != NULL) {
        pbuf_take(p, (void*)d->buffer1_addr, len);
    }

    d->status = DES0_RX_CTRL_OWN; // 归还给DMA
    rx_desc_cur = (struct eth_dma_desc *)d->buffer2_addr; // 指向下一项

    return p;
}

这里使用了 pbuf_take 函数直接拷贝数据到新分配的pbuf中。虽然这不是零拷贝方案，但对于大多数应用场景已足够高效。若追求极致性能，可通过PBUF_REF方式引用DMA缓冲区，但需确保在发送完成前不被覆盖。

相比之下，发送过程更为直接。应用层构造好pbuf链后， low_level_output() 将其内容复制到TX Buffer，并更新描述符状态以启动DMA传输：

err_t low_level_output(struct netif *netif, struct pbuf *p) {
    struct eth_dma_desc *d = tx_desc_cur;

    if (d->status & DES0_TX_CTRL_OWN)
        return ERR_BUF; // 发送忙

    uint8_t *buf = (uint8_t*)d->buffer1_addr;
    for (struct pbuf *q = p; q != NULL; q = q->next) {
        memcpy(buf, q->payload, q->len);
        buf += q->len;
    }

    d->control_size = p->tot_len;
    d->status = DES0_TX_CTRL_FD | DES0_TX_CTRL_LD |
                DES0_TX_CTRL_FS | DES0_TX_CTRL_LS |
                DES0_TX_CTRL_IC | DES0_TX_CTRL_OWN;

    tx_desc_cur = (struct eth_dma_desc *)d->buffer2_addr;

    // 触发发送（如果DMA未运行）
    if (!(ENET_DMA_STAT & DMAC_STAT_TST))
        ENET_DMA_CTL |= DMAC_CTL_STE;

    return ERR_OK;
}

注意最后检查DMA是否处于暂停状态，必要时手动重启发送通道。这一点在某些低负载场景下尤为关键，否则可能造成数据滞留。

---

LWIP本身并不依赖多任务环境，其核心设计允许在单线程上下文中运行。这意味着所有网络操作都必须串行执行，不能并发访问。这也是为什么在裸机系统中我们通常采用“主循环轮询”的方式驱动协议栈。

每次循环中，至少要做两件事：

1. 调用 sys_check_timeouts() 处理各种周期性任务：
   - ARP表维护（每5秒一次）
   - TCP重传与连接状态更新（每250ms一次）
   - DHCP租期续订（粗粒度/细粒度定时器）

2. 检查是否有新数据包到达：
   c ethernetif_input(netif); // 内部调用low_level_input

这两个步骤缺一不可。如果忽略定时器处理，TCP连接可能会因超时不恢复而断开；如果不及时收包，则会导致DMA缓冲区溢出丢帧。

推荐主循环频率不低于10ms一次，理想情况下保持在2~5ms以内，以保证网络响应的及时性。例如：

while (1) {
    sys_check_timeouts();
    ethernetif_input(&g_netif);

    // 其他任务...
    modbus_poll();
    led_blink();
}

当然，也可以结合空闲中断或DMA完成中断来减少轮询开销，但在高吞吐量场景下仍建议保留主循环检查，以防中断丢失导致死锁。

---

内存管理是另一个不容忽视的环节。LWIP提供了多种内存分配策略，但在裸机环境中最稳妥的选择是使用静态内存池（memp_malloc）而非动态malloc。这样可以避免堆碎片问题，并精确控制资源占用。

通过 lwipopts.h 中的宏定义，我们可以根据实际需求调整各项参数：

#define MEM_SIZE               16*1024      // 可用内存总量
#define MEMP_NUM_PBUF          16
#define MEMP_NUM_UDP_PCB       4
#define MEMP_NUM_TCP_PCB       5
#define MEMP_NUM_TCP_SEG       8
#define PBUF_POOL_SIZE         8
#define TCP_MSS                1460
#define LWIP_ARP               1
#define LWIP_IGMP              0
#define LWIP_ICMP              1
#define LWIP_DHCP              1
#define LWIP_DNS               1

对于仅有64KB SRAM的GD32F407来说，把MEM_SIZE设为16KB是比较合理的折中方案。过多会挤压应用程序空间，过少则容易引发连接失败或内存耗尽错误。

此外，关闭不必要的功能模块也能显著降低开销。比如SNMP、IGMP、PPP等功能在多数工业网关中并无用途，完全可以禁用。调试日志也应在发布版本中关闭：

#ifndef DEBUG_BUILD
#define NETIF_DEBUG             LWIP_DBG_OFF
#define ETHARP_DEBUG            LWIP_DBG_OFF
#define TCP_DEBUG               LWIP_DBG_OFF
#endif

启用这些宏后，可通过串口输出详细的协议交互日志，配合Wireshark抓包工具快速定位问题。例如，当发现DHCP无法获取IP时，打开 DHCP_DEBUG 就能看到客户端是否发出Discover报文，服务器是否有回应Offer。

---

实际工程中常见的几个痛点也值得特别关注：

PHY链接状态不稳定？
务必在初始化阶段正确配置PHY寄存器。以LAN8720为例，需通过SMI接口写入BMCR寄存器开启自协商，并定期读取BMSR确认链路状态。可在主循环中加入链路检测逻辑：

static void check_link_status(void) {
    uint16_t bmsr = phy_read(PHY_REG_BMSR);
    if (bmsr & BMSR_LINK_STATUS) {
        if (!(g_netif.flags & NETIF_FLAG_LINK_UP)) {
            netif_set_link_up(&g_netif);
        }
    } else {
        if (g_netif.flags & NETIF_FLAG_LINK_UP) {
            netif_set_link_down(&g_netif);
        }
    }
}

网络延迟偏高？
优先提升以太网中断优先级。在NVIC中将DMA Rx/Tx中断设为较高抢占优先级（如1），避免被其他外设中断长时间阻塞。同时考虑启用TCP_NODELAY选项关闭Nagle算法，适用于小数据包频繁传输的场景。

连接频繁断开？
适当增大 TCP_MSL 和 TCP_MAXRTX 值，并开启keep-alive机制：

#define TCP_TMR_INTERVAL   250
#define TCP_MSL            60000
#define TCP_MAXRTX         12
#define TCP_KEEPALIVE      1

这些参数直接影响TCP的健壮性。特别是在网络波动较大的工业现场，合理的重试策略能大幅提升稳定性。

---

最终形成的系统架构清晰明了：

+---------------------+
|     Application     |  ← HTTP Server / Modbus TCP Client
+----------+----------+
           ↓
+----------v----------+
|       LWIP Stack    |  ← 协议解析、连接管理
+----------+----------+
           ↓
+----------v----------+
|   netif (ethernetif)|  ← 用户实现的驱动接口
+----------+----------+
           ↓
+----------v----------+
| GD32F407 MAC + DMA  |  ← 硬件加速数据搬运
+----------+----------+
           ↓
+----------v----------+
|   External PHY      |  ← 物理层收发信号
+---------------------+

在这个架构下，开发者只需专注于业务逻辑的实现，底层复杂的协议交互由LWIP代劳。无论是做远程数据采集、智能网关还是小型Web服务器，这套方案都能提供坚实的基础。

展望未来，该平台还可进一步扩展：结合FatFS实现本地网页托管，集成MQTT协议接入云平台，或是利用RAW API开发低延迟的Modbus TCP从站设备。更重要的是，这一整套技术路径完全基于国产MCU构建，为工业自动化领域的自主可控提供了切实可行的落地案例。

这种高度集成的设计思路，正引领着国产嵌入式网络设备向更可靠、更高效的方向演进。