企业官网建设流程全解析

1. 从TCP到UDP：为什么要在裸机LWIP上做这个切换

做过ZYNQ裸机网络开发的朋友大概率都经历过这样一个过程：好不容易把LWIP协议栈在裸机上跑通了，TCP回环测试也过了，结果一到实际项目里发现TCP那套重传、拥塞控制、三次握手的机制反而成了累赘。尤其是在做实时数据采集、周期性状态上报这类场景时，TCP的可靠性保障机制带来的延迟抖动和内存开销，往往比它解决的问题还多。

我这次做的就是把之前已经跑通的7100平台裸机LWIP TCP通信，改成UDP方式。听起来好像只是把tcp_new()换成udp_new()的事，但实际操作下来，涉及的东西比想象中多不少——从LWIP配置文件的宏开关，到回调函数的注册方式，再到pbuf的分配策略，每一处都有坑。

这篇文章适合两类人看：一类是已经在ZYNQ裸机上跑通了LWIP TCP、想切换到UDP的开发者；另一类是刚开始接触LWIP裸机移植、想直接走UDP路线的朋友。我会把整个改造过程拆开揉碎，包括每一步为什么这么做、参数怎么算、哪些地方容易翻车，尽量让你看完就能直接上手改自己的代码。

先说一下我的硬件和软件环境：7100开发板（ZYNQ系列），LWIP版本是1.4.1（xilinx自带的那套），开发环境是SDK裸机工程，PHY芯片是常见的千兆PHY，通过MIO接的MDIO接口。这些信息后面涉及具体配置的时候会反复用到。

2. 改造前的整体设计思路与方案选型

2.1 为什么选UDP而不是继续用TCP

先说清楚一个前提：UDP和TCP没有谁好谁坏，只有适不适合。我这次切换的核心原因是项目需求变了——数据采集端每1ms产生一帧传感器数据，每帧固定64字节，允许偶尔丢帧但不能有累积延迟。TCP的Nagle算法、延迟ACK、拥塞窗口这些机制在这种场景下全是副作用。

具体来说，TCP在这个场景下的三个致命问题：

• 延迟不可控：TCP的重传超时（RTO）最小值在LWIP里默认是3秒（TCP_RTO_MIN），即使实际网络很好，偶尔一个包丢了就要等重传，这1ms的采集周期直接崩了。
• 内存开销大：每个TCP连接需要维护发送窗口、接收窗口、重传队列，LWIP里一个TCP PCB结构体加上相关缓冲，轻松吃掉几KB的RAM。UDP的PCB就轻量得多。
• 连接管理复杂：TCP需要维护连接状态机，断线重连、半关闭这些状态处理在裸机上写起来很啰嗦。UDP无连接，发完就完事。

当然，UDP的代价是可靠性要自己保证。我的方案是在应用层加一个简单的帧序号和校验，丢帧就丢帧，不重传，因为下一帧1ms后就来了，重传旧数据没意义。

2.2 LWIP裸机下UDP的架构设计

裸机LWIP的UDP通信架构和TCP有一个本质区别：TCP是面向连接的，你可以用阻塞式API（netconn）或者回调式API（raw）来收发；UDP在裸机下基本只能用raw API，因为netconn的阻塞语义需要RTOS支持。

我的架构是这样的：

应用层（数据采集任务） ↓ 调用 udp_sendto() LWIP UDP层 ↓ 封装UDP头部 IP层 ↓ 封装IP头部 以太网驱动（EMAC） ↓ DMA发送 PHY → 网线

接收方向反过来：

PHY → EMAC DMA接收 ↓ 中断触发 ethernetif_input() ↓ ip4_input() → udp_input() ↓ 自定义udp_recv回调 ↓ 应用层处理

这个链路里，最关键的两个点是：pbuf的分配策略和回调函数的执行上下文。前者决定了你能不能稳定发送，后者决定了你会不会在中断里做太多事情导致丢包。

2.3 改造范围界定

这次改造不是从零开始，是在已有TCP工程基础上做增量修改。需要动的地方包括：

不需要动的地方：EMAC驱动、PHY初始化、时钟配置、中断控制器配置。这些底层的东西TCP和UDP是共用的，省了不少事。

3. LWIP配置文件的针对性调整

3.1 lwipopts.h里必须改的宏

LWIP的配置文件是整個协议栈行为的控制中心。从TCP切到UDP，有几个宏是必须调整的，不改的话要么编译报错，要么运行异常。

第一个是LWIP_UDP，这个必须置1：

#define LWIP_UDP 1

第二个是MEMP_NUM_UDP_PCB，这个决定同时能有多少个UDP控制块。我这边只需要一个发送socket和一个接收socket，所以设2就够了，但考虑到调试方便，我设了4：

#define MEMP_NUM_UDP_PCB 4

第三个是UDP_TTL，默认是255，我改成64，跟常规IP包的TTL保持一致，避免被某些网络设备当成异常包：

#define UDP_TTL 64

还有一个容易被忽略的LWIP_NETCONN，如果你之前用netconn API写的TCP代码，切到UDP raw API后可以把它关掉省内存：

#define LWIP_NETCONN 0

但注意，关掉netconn之后，sys_thread_new相关的函数也不能用了，确保你的代码里没有残留调用。

3.2 内存池参数的重新计算

UDP场景下pbuf的分配模式和TCP不一样。TCP有发送缓冲队列，pbuf可以排队等发送；UDP是发出去就不管了，所以pbuf的周转更快，但峰值需求可能更高（因为应用层可能连续快速发送）。

我算一下我的需求：每帧64字节数据，加上UDP头8字节、IP头20字节、以太网头14字节，总共106字节。LWIP的pbuf有两种：PBUF_POOL（从内存池分配，适合小包）和PBUF_RAM（从堆分配，适合大包）。

106字节用PBUF_POOL就够了，一个pbuf pool元素默认大小是PBUF_POOL_BUFSIZE，我设的是1520（跟MTU对齐），所以一个元素就能装下。但考虑到突发发送，我设了MEMP_NUM_PBUF为16，PBUF_POOL_SIZE为16：

#define MEMP_NUM_PBUF 16 #define PBUF_POOL_SIZE 16 #define PBUF_POOL_BUFSIZE 1520

这里有个经验：PBUF_POOL_SIZE不要设太小，否则pbuf_alloc返回NULL，发送直接失败。但也不要太大，裸机内存有限，16个1520字节就是24KB，已经不少了。

3.3 校验和与调试宏的取舍

CHECKSUM_GEN_UDP和CHECKSUM_CHECK_UDP这两个宏，我建议在调试阶段都打开，正式发布时根据PHY是否支持硬件校验和来决定。

#define CHECKSUM_GEN_UDP 1 #define CHECKSUM_CHECK_UDP 1

打开校验和会稍微增加CPU开销，但裸机下这点开销可以接受，而且能帮你快速定位数据错误。等稳定了再考虑关掉。

调试宏方面，UDP_DEBUG设成LWIP_DBG_ON可以在串口打印UDP层的收发信息，非常有用：

#define UDP_DEBUG LWIP_DBG_ON

但注意，调试打印本身会消耗时间，如果发送频率很高（比如1ms一次），打印会严重拖慢速度甚至导致丢包。所以调试完记得关掉。

4. UDP通信核心代码的完整实现

4.1 UDP控制块的创建与绑定

先看创建和绑定的代码。和TCP不同，UDP不需要listen和accept，创建完直接bind就能收发了。

#include "lwip/udp.h" #include "lwip/ip_addr.h" static struct udp_pcb *g_udp_send_pcb = NULL; static struct udp_pcb *g_udp_recv_pcb = NULL; #define LOCAL_PORT 8080 #define REMOTE_PORT 9090 #define REMOTE_IP IPADDR4_INIT_BYTES(192, 168, 1, 100) int udp_app_init(void) { ip4_addr_t local_ip, remote_ip; err_t err; /* 创建发送用PCB */ g_udp_send_pcb = udp_new(); if (g_udp_send_pcb == NULL) { xil_printf("udp_new send failed\r\n"); return -1; } /* 绑定本地端口，不绑定IP表示监听所有本地地址 */ err = udp_bind(g_udp_send_pcb, IP_ADDR_ANY, LOCAL_PORT); if (err != ERR_OK) { xil_printf("udp_bind send failed: %d\r\n", err); udp_remove(g_udp_send_pcb); g_udp_send_pcb = NULL; return -1; } /* 创建接收用PCB */ g_udp_recv_pcb = udp_new(); if (g_udp_recv_pcb == NULL) { xil_printf("udp_new recv failed\r\n"); return -1; } err = udp_bind(g_udp_recv_pcb, IP_ADDR_ANY, LOCAL_PORT + 1); if (err != ERR_OK) { xil_printf("udp_bind recv failed: %d\r\n", err); udp_remove(g_udp_recv_pcb); g_udp_recv_pcb = NULL; return -1; } /* 注册接收回调 */ udp_recv(g_udp_recv_pcb, udp_recv_callback, NULL); xil_printf("UDP app init done\r\n"); return 0; }

这里有几个细节值得说：

为什么发送和接收用两个PCB？严格来说一个PCB也能同时收发，但分开的好处是逻辑清晰，而且可以绑定不同端口，方便调试时区分方向。另外，如果接收回调里需要回复发送方，用独立的发送PCB可以避免在回调上下文里操作同一个PCB带来的潜在重入问题。

IP_ADDR_ANY的含义：绑定的时候传IP_ADDR_ANY表示不限制本地IP，任何到达本机该端口的数据都收。如果你的板子有多个网口或者多个IP，想只收特定IP的包，就传具体的IP地址。

端口选择：我用了8080和8081，实际项目里选端口要注意避开系统保留端口（0-1023），虽然裸机下没这个限制，但养成好习惯。

4.2 发送函数的实现与pbuf管理

发送是UDP的核心操作，也是最容易出问题的地方。看代码：

int udp_send_data(uint8_t *data, uint16_t len) { struct pbuf *p; err_t err; ip4_addr_t dst_ip; if (g_udp_send_pcb == NULL || data == NULL || len == 0) { return -1; } /* 分配pbuf，PBUF_TRANSPORT表示预留传输层头部空间 */ p = pbuf_alloc(PBUF_TRANSPORT, len, PBUF_POOL); if (p == NULL) { xil_printf("pbuf_alloc failed, len=%d\r\n", len); return -1; } /* 拷贝数据到pbuf */ err = pbuf_take(p, data, len); if (err != ERR_OK) { xil_printf("pbuf_take failed: %d\r\n", err); pbuf_free(p); return -1; } /* 设置目标IP */ IP4_ADDR(&dst_ip, 192, 168, 1, 100); /* 发送 */ err = udp_sendto(g_udp_send_pcb, p, &dst_ip, REMOTE_PORT); if (err != ERR_OK) { xil_printf("udp_sendto failed: %d\r\n", err); pbuf_free(p); return -1; } /* 发送完成后释放pbuf */ pbuf_free(p); return 0; }

这段代码里有三个关键点：

第一，pbuf_alloc的层参数用PBUF_TRANSPORT。这个参数告诉LWIP在pbuf头部预留多少空间给下层协议。PBUF_TRANSPORT会预留UDP头、IP头、以太网头的空间，这样后续各层封装时不需要重新分配内存，直接在前面填头部就行。如果你用PBUF_RAW，那就要自己处理头部空间，很容易出错。

第二，pbuf_take和直接memcpy的区别。pbuf_take会处理pbuf链的情况——如果数据长度超过一个pbuf的容量，pbuf会形成链表，pbuf_take会自动把数据分散到各个pbuf里。直接memcpy只能处理单个pbuf，遇到链式pbuf就崩了。所以永远用pbuf_take，别图省事用memcpy。

第三，pbuf_free的时机。udp_sendto返回后，pbuf就可以释放了。因为udp_sendto内部会把pbuf交给IP层，IP层再交给网卡驱动，驱动发送完成后会自己释放（或者由LWIP的pbuf机制管理引用计数）。你在应用层调用pbuf_free只是减少引用计数，不会导致驱动那边访问野指针。但如果你在udp_sendto之前就释放，那就完蛋了。

注意：udp_sendto返回ERR_OK只表示pbuf成功交给了IP层，不代表数据已经上了网线。真正的发送完成是异步的，由EMAC的中断来确认。所以不要指望udp_sendto返回后对方就收到了。

4.3 接收回调函数的编写要点

接收回调是UDP通信里最需要小心的地方，因为它在中断上下文中执行（准确说是从EMAC中断里一路调用上来的）。看代码：

static void udp_recv_callback(void *arg, struct udp_pcb *pcb, struct pbuf *p, const ip_addr_t *addr, u16_t port) { uint8_t rx_buf[256]; uint16_t copy_len; if (p == NULL) { /* p为NULL表示远端关闭，UDP下很少见，但要做保护 */ return; } /* 限制拷贝长度，防止溢出 */ copy_len = (p->tot_len > sizeof(rx_buf)) ? sizeof(rx_buf) : p->tot_len; /* 把pbuf链里的数据拷贝到连续缓冲区 */ if (pbuf_copy_partial(p, rx_buf, copy_len, 0) != copy_len) { xil_printf("pbuf_copy_partial failed\r\n"); pbuf_free(p); return; } /* 在这里处理数据，注意不要做耗时操作 */ process_rx_data(rx_buf, copy_len, addr, port); /* 必须释放pbuf */ pbuf_free(p); }

回调函数里有几个铁律：

铁律一：必须释放pbuf。回调收到pbuf的所有权，处理完必须pbuf_free，否则内存池很快耗尽，后续接收全部失败。这是新手最容易犯的错误。

铁律二：不要在回调里做耗时操作。回调在中断上下文执行，你在这里花1ms，中断就延迟1ms，可能导致EMAC的DMA缓冲区溢出丢包。正确的做法是把数据拷贝到一个环形缓冲区，然后在主循环里处理。

铁律三：注意数据长度。p->tot_len是pbuf链的总长度，p->len是当前pbuf节点的长度。如果数据跨多个pbuf，p->len只是第一个节点的长度。用pbuf_copy_partial可以安全地跨节点拷贝。

铁律四：地址参数的生命周期。addr和port指向的内存只在回调期间有效，如果要保存发送方地址用于后续回复，必须自己拷贝一份。

4.4 主循环与中断的配合

裸机LWIP的收发都依赖中断，但应用层的逻辑要在主循环里跑。我的主循环结构是这样的：

#define RX_RING_SIZE 32 #define RX_FRAME_SIZE 128 static volatile uint8_t g_rx_ring[RX_RING_SIZE][RX_FRAME_SIZE]; static volatile uint16_t g_rx_len[RX_RING_SIZE]; static volatile uint32_t g_rx_head = 0; static volatile uint32_t g_rx_tail = 0; /* 回调里只做入队 */ static void udp_recv_callback(...) { uint32_t next = (g_rx_head + 1) % RX_RING_SIZE; if (next == g_rx_tail) { /* 环形缓冲区满，丢弃 */ pbuf_free(p); return; } uint16_t len = (p->tot_len > RX_FRAME_SIZE) ? RX_FRAME_SIZE : p->tot_len; pbuf_copy_partial(p, (void *)g_rx_ring[g_rx_head], len, 0); g_rx_len[g_rx_head] = len; g_rx_head = next; pbuf_free(p); } /* 主循环里出队处理 */ int main(void) { platform_init(); udp_app_init(); while (1) { if (g_rx_tail != g_rx_head) { uint32_t idx = g_rx_tail; process_rx_data((uint8_t *)g_rx_ring[idx], g_rx_len[idx], NULL, 0); g_rx_tail = (idx + 1) % RX_RING_SIZE; } /* 周期性发送 */ static uint32_t last_send = 0; if (get_tick() - last_send >= 1) { last_send = get_tick(); uint8_t tx_data[64]; fill_sensor_data(tx_data, sizeof(tx_data)); udp_send_data(tx_data, sizeof(tx_data)); } } }

这个结构的关键是中断和主循环的解耦。回调只负责把数据搬进环形缓冲区，主循环负责处理。环形缓冲区的大小要算好：如果主循环处理一帧需要100us，接收频率是1ms一帧，那缓冲区有4-8个槽位就够应对突发了。我设了32个，留足余量。

5. 调试过程中踩过的坑与排查方法

5.1 发送成功但收不到包

这是最常见的问题。udp_sendto返回ERR_OK，但上位机抓包看不到任何数据。排查思路按顺序来：

第一步，确认ARP有没有解析成功。UDP发送前，IP层需要知道目标MAC地址。如果ARP表里没有目标IP的条目，LWIP会先发ARP请求，等ARP回复期间，你的UDP包会被排队或者直接丢弃。用UDP_DEBUG打开调试，看有没有udp_send: sending之类的打印，如果没有，说明卡在ARP了。

解决方法：在发送前先ping一下目标，或者手动调用etharp_request触发ARP解析，等ARP表更新后再发UDP。

第二步，检查PHY链路状态。用xil_printf打印PHY的BMSR寄存器，确认link up且速率正确。我遇到过一次PHY自协商失败，链路是down的，但LWIP不知道，照样往下发，全丢。

第三步，检查发送描述符。EMAC的DMA发送描述符如果配置不对，数据写不进FIFO。这个要看具体驱动实现，Xilinx的驱动里XEmacPs_BdRingAlloc和XEmacPs_BdRingToHw的调用顺序不能错。

5.2 接收回调不触发

发送正常但收不到数据，回调不执行。可能的原因：

我遇到过一次回调完全不触发，查了半天发现是udp_bind的端口写错了——发送用8080，接收绑了8081，但上位机往8080发的。这种低级错误在调试时很常见，建议在初始化完成后把绑定的端口打印出来确认。

5.3 大数据包分片问题

UDP包超过MTU（通常1500字节）会触发IP分片。LWIP默认支持分片重组，但裸机下内存有限，分片重组需要额外的pbuf，很容易失败。

我的建议是：应用层控制单包不超过1400字节，留出UDP头和IP头的空间。如果确实要传大数据，自己在应用层做分片和重组，比依赖IP分片可靠得多。

如果非要开IP分片，确保这几个宏打开：

#define IP_REASSEMBLY 1 #define IP_FRAG 1 #define MEMP_NUM_REASSDATA 4

MEMP_NUM_REASSDATA是同时支持的重组任务数，设太小会导致重组失败。

5.4 校验和错误导致的静默丢包

UDP校验和算错的话，接收端会静默丢弃，没有任何提示。调试时如果发现发送正常、接收端抓包也有数据，但应用层收不到，大概率是校验和问题。

排查方法：在udp_input函数里加打印，看校验和检查是否通过。或者临时把CHECKSUM_CHECK_UDP设为0，看能不能收到。如果能收到，说明是校验和计算问题。

校验和出错的常见原因：pbuf链式结构下校验和计算没有覆盖所有节点。LWIP的udp_send内部会处理这个，但如果你自己手动构造UDP包，就要注意用pbuf_take保证数据连续。

6. 性能优化与稳定性加固

6.1 发送路径的零拷贝优化

前面的发送代码里，数据从应用层缓冲区拷贝到pbuf，这是一次拷贝。如果数据源本身就在DMA可访问的内存里，可以跳过这次拷贝，直接把pbuf的payload指针指向数据源。

但零拷贝有个前提：数据源的生命周期要覆盖整个发送过程。如果数据源是栈上的局部数组，函数返回后就失效了，零拷贝会出问题。所以零拷贝适合数据源是全局缓冲区或者静态分配的场景。

实现方式是用pbuf_alloced_custom或者直接操作pbuf结构体：

struct pbuf *p = pbuf_alloc(PBUF_TRANSPORT, len, PBUF_REF); if (p != NULL) { p->payload = data; /* 直接指向数据源，不拷贝 */ udp_sendto(pcb, p, &dst_ip, port); pbuf_free(p); }

注意PBUF_REF类型的pbuf不会拷贝数据，pbuf_free时也不会释放payload内存。用这种方式要特别小心内存管理。

6.2 接收环形缓冲区的容量计算

环形缓冲区的大小不是拍脑袋定的，要算。公式是：

缓冲区槽位数 = 最大突发帧数 + 主循环最大延迟时间内到达的帧数

假设主循环最坏情况下100us处理一帧，接收频率1ms一帧，那主循环延迟期间最多积累0.1帧，加上突发余量，8个槽位足够。我设32是留了4倍余量，防止意外。

每个槽位的大小要能装下最大UDP包。如果应用层限制了包长不超过256字节，槽位就设256。不要设成MTU大小，浪费内存。

6.3 中断优先级的合理安排

EMAC中断的优先级要高于其他非关键中断，但低于系统tick中断（如果有的话）。在ZYNQ的GIC里，EMAC中断一般配成优先级5-8（数值越小优先级越高），tick中断配成3-4。

如果EMAC中断被其他中断阻塞太久，DMA接收缓冲区会溢出。ZYNQ的EMAC有多个接收缓冲区，具体数量看驱动配置，一般4-8个。按每个缓冲区能存一个MTU包算，8个缓冲区就是12KB，能扛住几毫秒的中断延迟。

6.4 长时间运行的稳定性验证

裸机系统跑久了容易出各种奇怪问题，UDP通信的稳定性验证至少要做这几项：

• 连续运行24小时：看有没有内存泄漏（pbuf池耗尽）、计数器溢出。
• 满负荷压力测试：上位机用iperf或者自己写脚本，以最大速率发包，看丢包率和板子响应。
• 异常包测试：发超长包、发空包、发错误校验和的包，看板子会不会崩。
• 网络闪断测试：拔插网线，看恢复后通信是否正常。

我实测下来，pbuf池耗尽是长时间运行最常见的问题，根源基本都是回调里忘了pbuf_free，或者某条错误分支提前return没释放。

7. 上位机测试脚本与验证方法

7.1 Python测试脚本

上位机用Python的socket库就能测试，不需要额外依赖：

import socket import struct import time LOCAL_IP = "192.168.1.100" LOCAL_PORT = 9090 BOARD_IP = "192.168.1.10" BOARD_PORT = 8080 sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM) sock.bind((LOCAL_IP, LOCAL_PORT)) sock.settimeout(1.0) # 发送测试 for i in range(100): payload = struct.pack("<II", i, int(time.time() * 1000) & 0xFFFFFFFF) payload += b"\x00" * (64 - len(payload)) sock.sendto(payload, (BOARD_IP, BOARD_PORT)) time.sleep(0.001) # 接收测试 recv_count = 0 lost_count = 0 last_seq = -1 start = time.time() while time.time() - start < 10: try: data, addr = sock.recvfrom(2048) seq = struct.unpack("<I", data[:4])[0] if last_seq >= 0 and seq != last_seq + 1: lost_count += (seq - last_seq - 1) last_seq = seq recv_count += 1 except socket.timeout: pass print(f"recv={recv_count}, lost={lost_count}")

这个脚本能测发送、接收、丢包统计。struct.pack用来构造二进制帧，比发字符串更接近实际场景。

7.2 Wireshark抓包分析要点

Wireshark是排查UDP问题的利器，重点看这几个地方：

• 过滤规则：udp.port == 8080只看目标端口的包。
• 校验和状态：如果显示"incorrect"，说明校验和算错了。
• 时间间隔：看发送间隔是否稳定，抖动大说明发送路径有问题。
• 包长度：确认实际发送的字节数是否符合预期。

有个小技巧：如果板子发送的包Wireshark抓不到，但在板子本地用回环测试能收到，那问题在PHY或网线；如果回环也收不到，问题在协议栈或应用层。

7.3 回环测试的配置

LWIP支持回环接口，可以在没有物理网络的情况下测试协议栈逻辑。打开回环需要：

#define LWIP_HAVE_LOOPIF 1 #define LWIP_NETIF_LOOPBACK 1

然后给回环接口配一个IP（比如127.0.0.1），往这个IP发UDP，数据会直接回到本机的接收路径，不经过PHY。这是验证协议栈配置是否正确的最快方法。

回环测试通过后再接网线测物理链路，能快速定位问题是出在协议栈还是硬件。

8. 从TCP工程迁移的检查清单

最后给一份从TCP迁移到UDP的检查清单，照着过一遍能避免大部分问题：

这份清单是我踩了无数坑之后总结的，每一条背后都有至少一次翻车经历。尤其是pbuf释放和端口绑定这两项，新手几乎必踩。

实际改下来，从TCP切到UDP的代码量并不大，核心逻辑两三百行就够，但调试和稳定性验证花的时间远超写代码。裸机环境没有操作系统兜底，任何一个小疏忽都会直接表现为通信异常，所以每一步都要想清楚为什么这么做。我个人的体会是，UDP在裸机上的难点不在协议本身，而在内存管理和中断时序的控制，把这两块吃透了，剩下的就是体力活。