STM32F407+DP83848+LWIP实现网口串口双向透传实战

简介：面向串口设备联网需求的嵌入式开发者，这是一份基于STM32F407ZG与DP83848 PHY、采用LWIP协议栈的网口串口双向数据透传例程，适用于远程监控、数据采集和工业网关等场景。资源包共517个文件、约6.67MB，以h头文件和c源码为主，同时包含KEIL工程文件、编译生成的axf与hex、以太网驱动及LWIP协议栈相关配置文件，便于直接导入工程查看和二次开发。例程基于DMA实现不定长度数据收发，波特率115200，将串口接收数据转发至网口192.168.1.240:2040，网口侧数据也能实时回写到串口1，实现双向透传。从源码中可以学习DP83848硬件初始化、STM32F4以太网MAC配置、DHCP与LWIP协议栈的整合方式，并理解DMA不定长收发的处理思路，为后续移植到其他串口设备或扩展多路透传提供完整参考。目前已有3219人学习下载，适合中高级嵌入式工程师作为串口转以太网项目的起点方案。

1. STM32F407ZG+DP83848+UART1+LWIP网口串口双向数据透传：为什么值得搭建

在工业现场，大量仪表、PLC和传感器只留了一个RS232串口，而监控上位机在几公里外的机房。最省事的做法是拉一条网线，在设备端加一个串口转以太网的透传模块。这套方案就是基于STM32F407ZG、DP83848以太网PHY、UART1和LWIP协议栈，用纯软件实现网口串口双向数据透传：UART1收到的数据打包成TCP报文发出去，远端TCP回包再拆成字节从UART1吐出。适合谁？手上有F407开发板、想省掉一颗透传模块芯片钱的嵌入式工程师，或者正在做STM32网关类产品、需要彻底搞懂LWIP中断收发的开发者。下文从硬件接线讲起，到LWIP移植、透传逻辑和踩坑记录，尽量让你能照着复现。

2. 硬件搭建与接口设计：DP83848的RMII接线和UART1的DMA配置

STM32F407ZG内置10/100M以太网MAC，但PHY芯片必须外接。DP83848是TI的工业级百兆PHY，支持MII和RMII两种模式。这套方案里我选RMII，原因很直接：占用引脚少，把GPIO留给UART1和调试口。选择DP83848还有一个容易被忽略的理由：绝大多数F407开发板的PHY地址默认是0x01，LWIP底层驱动按这个地址去读PHY ID，换其他PHY芯片时地址不匹配会导致MDIO读写全部失败，后面那个坑会让人浪费至少半天。

2.1 为什么选DP83848而不是LAN8720

LAN8720在低成本方案里非常流行，但DP83848有几个实打实的优势。第一是工业级温度范围，DP83848的工作范围是-40℃到+85℃，LAN8720只有0℃到+70℃，现场柜体夏天温度很容易超过这个值。第二是中断引脚和状态LED可以直接映射到GPIO，不需要额外读MDIO寄存器就能判断链路状态。第三是电源设计，DP83848的AVDD和DVDD都是3.3V单电源，内部生成1.8V核心电压，电压测量点更直观。

选型还有一个隐性考虑：DP83848的RMII时钟输入支持50MHz外部有源晶振，也可以由STM32的MCO引脚输出50MHz。而LAN8720通常需要外接50MHz晶振或者由STM32_MCO提供，晶振起振时序在低温下容易出问题。DP83848的时钟容忍度更好，在-40℃环境实测没有出现PHY失锁的情况，LAN8720在同样条件下偶尔会有link up但ping不通的现象。

还有一点涉及供货和成本：DP83848的库存和替代料比LAN8720更稳定，尤其在近两年芯片交期波动时，DP83848的pin-to-pin替代方案更多。不过它的封装是LQFP-48，手工焊接比LAN8720的QFN封装容易，对小批量打板调试更友好。综合来看，做网关而不是消费级网卡，选DP83848的容错率高一个档次。

2.2 RMII模式接线：12根线和一个坑

RMII模式接线分四组。第一组是数据线：TXD0、TXD1、TXD_EN接到PHY的对应引脚，RXD0、RXD1、RXD_ER从PHY接回来，RXD_ER在F407上要映射到PA3。第二组是时钟：REF_CLK必须是50MHz，从DP83848的XI引脚输入。这里有个常见的选择：让PHY自己产生时钟，还是让STM32产生时钟？我建议用STM32的MCO1输出50MHz到DP83848的XI，因为这样PHY和MAC的时钟同源，不需要等晶振起振。第三组是MDIO接口：MDC和MDIO两根线既用来配置PHY寄存器，也用来读取链路状态。第四组是复位和中断：PHY_RST接一个带RC延时的GPIO，PHY_INT接EXTI。

这个接线里有一个非常容易翻车的坑：DP83848的RX_DV和CRS_DV在RMII模式下要短接后接STM32的RMII_CRS_DV引脚。很多原理图只画了RX_DV，漏了CRS_DV，结果就是PHY能link up但收不到任何数据包。我见过好几块板子在这个引脚上飞线才调通。正确的接法是DP83848的第37脚RX_DV和第46脚CRS_DV直接连在一起，再连到STM32的PA7。

注意PA1在F407上同时是TIM2的CH2，很多做电机控制的同学会把TIM2_CH2也映射到PA1，两套外设抢引脚，这是项目后期最难排查的问题之一。建议在原理图阶段就把PA1标注为ETH_REF_CLK，不要复用。另外DP83848的PHY地址由RX_DV引脚上的上下拉电阻决定，默认悬空为0x01，手册里写的是PHYAD[0]引脚内部下拉。如果板子上把PHYAD[0]拉高了，地址会变成0x00，LWIP驱动读PHY ID时会全部得到0xFFFF，链路永远起不来。

2.3 UART1的DMA与中断配置

UART1这路串口用来做透传数据，波特率要看远端设备的实际配置。我常用的套路是115200 8N1，但这不代表每个项目都能跑满。DP83848和LWIP的转发延迟在毫秒级，如果串口对端是个9600波特率的老PLC，你发得太快它会丢字节，所以透传模块最好在UART1的驱动里加一个可配置的发送间隔。代码上我倾向用中断接收、DMA发送：

void UART1_Init(uint32_t baudrate) { USART_InitTypeDef usart; GPIO_InitTypeDef gpio; NVIC_InitTypeDef nvic; RCC_APB2PeriphClockCmd(RCC_APB2Periph_USART1, ENABLE); RCC_AHB1PeriphClockCmd(RCC_AHB1Periph_GPIOA, ENABLE); // PA9-TX, PA10-RX gpio.GPIO_Pin = GPIO_Pin_9 | GPIO_Pin_10; gpio.GPIO_Mode = GPIO_Mode_AF; gpio.GPIO_Speed = GPIO_Speed_50MHz; gpio.GPIO_OType = GPIO_OType_PP; gpio.GPIO_PuPd = GPIO_PuPd_UP; GPIO_Init(GPIOA, &gpio); GPIO_PinAFConfig(GPIOA, GPIO_PinSource9, GPIO_AF_USART1); GPIO_PinAFConfig(GPIOA, GPIO_PinSource10, GPIO_AF_USART1); usart.USART_BaudRate = baudrate; usart.USART_WordLength = USART_WordLength_8b; usart.USART_StopBits = USART_StopBits_1; usart.USART_Parity = USART_Parity_No; usart.USART_Mode = USART_Mode_Rx | USART_Mode_Tx; usart.USART_HardwareFlowControl = USART_HardwareFlowControl_None; USART_Init(USART1, &usart); nvic.NVIC_IRQChannel = USART1_IRQn; nvic.NVIC_IRQChannelPreemptionPriority = 1; nvic.NVIC_IRQChannelSubPriority = 0; nvic.NVIC_IRQChannelCmd = ENABLE; NVIC_Init(&nvic); USART_ITConfig(USART1, USART_IT_RXNE, ENABLE); USART_Cmd(USART1, ENABLE); }

这里的接收中断启用的是RXNE，也就是接收寄存器非空中断，每收一个字节进一次中断。对于115200波特率，一字节中断间隔约87微秒，CPU完全扛得住。但对高速透传来说，更省CPU的做法是启用空闲中断（IDLE）配合DMA，收满一帧再统一搬进环形缓冲，我后面章节细说。

这段代码里有一个参数值得单独说：USART_IT_RXNE和USART_IT_IDLE不能同时只开一个。RXNE保证单字节不丢，IDLE保证半包和粘包能切分。如果项目里既要低延迟又要低CPU占用，建议两个都开，在中断服务函数里先读SR再读DR，清掉RXNE之后判断IDLE标志。DMA发送的初始化要额外配置DMA_Stream和中断，DMA传输完成中断和UART的TC中断不要混用，混用会导致前文提到的丢最后一个字节问题。

3. LWIP协议栈移植：跑通TCP透传的最小内存配置

LWIP建议用2.1.x版本，F407的标准库或者HAL库都能直接编译。这一章讲三件事：内存参数怎么设、TCP服务器怎么起、用netconn还是raw API。另外还有一个常被忽略的前置操作：把ST官方以太网驱动里的PHY地址从0x00改成DP83848的0x01，否则MDIO读回来的是全F，PHY初始化直接失败。

3.1 内存配置：MEM_SIZE、PBUF_POOL_SIZE和MEMP_NUM_TCP_SEG

LWIP的lwipopts.h里有几个参数直接决定透传是否稳定。

#define MEM_SIZE (12 * 1024) // 堆内存池总大小 #define MEMP_NUM_PBUF 16 // PBUF数量 #define MEMP_NUM_TCP_SEG 16 // TCP段描述符数量 #define PBUF_POOL_SIZE 16 // PBUF池大小 #define TCP_WND (4 * TCP_MSS) // 接收窗口 #define TCP_SND_BUF (4 * TCP_MSS) // 发送缓冲 #define TCP_MSS 1460 // 最大段大小 #define TCP_QUEUE_OOSEQ 0 // 不启用乱序队列

MEM_SIZE是LWIP内部堆的总大小，netconn模式下TCP控制块和pbuf都要从这里分配。12KB是我在F407上实测比较稳的配置，再小到8KB就会出现长时间传输后TCP窗口不增长的问题。PBUF_POOL_SIZE控制的是接收路径上的pbuf池，这个值不够时表现是接收大文件到一半卡住，因为底层驱动没有空闲pbuf把新数据放进去。

有个容易被忽略的联动参数是TCP_QUEUE_OOSEQ。透传场景数据包基本是按序到达的，乱序队列可以关掉，省下约1.5KB RAM。如果你的网络拓扑里有大量交换机且存在多路径转发，再考虑打开。项目管理上我建议把TCP_QUEUE_OOSEQ设为0，并且把LWIP_NETCONN设为1才能用netconn API。

3.2 创建TCP服务器：listen+accept的回调机制

透传模块在绝大多数场景里是TCP服务器，上位机主动连它。初始化流程分两步：先调用tcp_new()创建PCB，绑定端口后tcp_listen()进入监听，然后注册accept回调。

static struct tcp_pcb *server_pcb; void LwIP_TCP_Server_Init(void) { err_t err; server_pcb = tcp_new(); if (server_pcb == NULL) { return; } err = tcp_bind(server_pcb, IP_ADDR_ANY, 5000); if (err != ERR_OK) { return; } server_pcb = tcp_listen(server_pcb); tcp_accept(server_pcb, LwIP_TCP_Accept_Callback); } static err_t LwIP_TCP_Accept_Callback(void *arg, struct tcp_pcb *newpcb, err_t err) { tcp_recv(newpcb, LwIP_TCP_Recv_Callback); tcp_sent(newpcb, LwIP_TCP_Sent_Callback); tcp_poll(newpcb, LwIP_TCP_Poll_Callback, 1); return ERR_OK; }

监听端口5000是我常用的默认值，你可以改成项目规定的端口。注意tcp_listen()返回的pcb和原来的pcb不是同一个指针，如果不接住返回值，accept永远不会触发。这是从LwIP 1.x迁移到2.x最常见的翻车点，老代码里tcp_listen(pcb)直接忽略返回值还能跑，2.x里这种行为的后果无法预测。

accept回调里注册了三个回调。tcp_recv处理数据到达，tcp_sent处理发送完成，tcp_poll处理连接空闲判断。透传这种长连接场景，客户端可能拔网线不打招呼就消失，靠tcp_poll才能定时检测到并回收资源。poll间隔参数填1表示每250ms轮询一次，一般30到60次没收到ACK就可以判定连接已经死了。

3.3 netconn还是raw API：透传场景的选型

LWIP的API分两派：netconn是线程安全的顺序API，适合配RTOS用；raw是回调驱动的非阻塞API，适合裸机。裸机透传模块用raw API更合适，原因不只是省一个线程，更重要的是raw API的数据流天然是事件驱动的。

netconn模式下，TCP数据到达会挂在netconn的接收队列里，你得在tcpip_thread里用netconn_recv()主动去取。这个模式如果串口发送慢，TCP接收队列会一直堆积，内存压力落在LWIP堆上。raw模式下数据在tcp_recv回调里直接给你指针，只需要把数据拷进自己的环形缓冲然后排队发串口，不拷贝就是ACK延迟变大，不会出现队列堆积。这个差异在长时间大流量透传时非常明显。

选型结论就一句话：如果主程序里有Modbus轮询之类对时间敏感的循环，用raw API；如果只是把LWIP当服务跑、主程序用RTOS管理，netconn更省心。下面章节的透传逻辑都用raw API写，代码保持一致避免混用。

4. 双向透传核心逻辑：UART1中断与TCP回调的协同

透传模块的核心不是把LWIP移植好，而是让TCP和UART两条数据通道互不阻塞。这里的做法是给每个方向各分配一个环形缓冲，发送方只管写入，接收方在合适时机读取，两者用状态机协调。

4.1 数据流设计：谁在等谁

先说清楚两个方向的数据流。方向A：上位机TCP发数据到模块，模块从LWIP回调里拿到payload，写入串口发送环形缓冲，然后UART1逐个字节发出去。方向B：串口对端设备发数据到UART1，UART1中断里把字节写入网络发送环形缓冲，主循环检测到缓冲非空就调用LWIP的tcp_write发出去。

这里的关键是：方向A的瓶颈在串口波特率，TCP来多少数据都得按串口速度慢慢吐；方向B的瓶颈在网络带宽，串口几毫秒的碎片数据要攒成TCP段再发。所以两个环形缓冲的大小不一样，串口发送缓冲要大，至少能装下网络一个MSS的数据，1460字节；网络发送缓冲可以小，但也要能攒下串口一帧的数据。

typedef struct { uint8_t buffer[2048]; volatile uint16_t head; volatile uint16_t tail; uint16_t size; } RingBuffer; void RingBuffer_Init(RingBuffer *rb, uint16_t size) { rb->head = 0; rb->tail = 0; rb->size = size; } int RingBuffer_Write(RingBuffer *rb, uint8_t *data, uint16_t len) { uint16_t i; for (i = 0; i < len; i++) { uint16_t next = (rb->head + 1) % rb->size; if (next == rb->tail) { return i; // 缓冲满，写不进去 } rb->buffer[rb->head] = data[i]; rb->head = next; } return len; }

这段环形缓冲的实现有一个值得注意的地方：head和tail都必须是volatile，因为一个在中断里被改，一个在主循环里被改，编译器优化可能把其中一个缓存到寄存器里导致判断错误。另外环形缓冲的size必须是2的幂，%运算才能用&替代，性能差别不大但代码风格上更统一。

4.2 网口数据到串口：TCP回调里做DMA发送

LWIP的tcp_recv回调里拿到的是pbuf链，你可能已经习惯用pbuf_copy_partial把整个链拷到本地数组。但在透传场景里，更好的做法是一边遍历pbuf链一边写入串口发送缓冲区：

static err_t LwIP_TCP_Recv_Callback(void *arg, struct tcp_pcb *tpcb, struct pbuf *p, err_t err) { struct pbuf *q; uint8_t *data; uint16_t len; if (p == NULL) { // 对端关闭连接 tcp_close(tpcb); return ERR_OK; } for (q = p; q != NULL; q = q->next) { len = q->len; data = (uint8_t *)q->payload; // 写入串口发送环形缓冲 RingBuffer_Write(&uart1_tx_rb, data, len); } tcp_recved(tpcb, p->tot_len); pbuf_free(p); // 通知主循环去发送串口数据 uart1_tx_pending = 1; return ERR_OK; }

这里tcp_recved很重要。TCP协议有窗口机制，你只有调用了tcp_recved(pcb, len)，对端才允许继续发数据。透传模块的数据最终要经过串口发出去，如果串口很慢，tcp_recved不能立刻调用，否则对端几秒钟就能把你8KB的接收窗口打满。正确做法是把数据拷进环形缓冲后就调用tcp_recved，因为数据已经在本地了，TCP ACK可以照常返回，对端窗口不会被饿死。如果你的应用是要求串口对端每条消息都响应透传过来的数据，那还要考虑TCP层ACK和串口响应的时序关系，这里不展开。

主循环里怎么把环形缓冲的数据通过UART1发出去，有两种做法：

// 方法1：轮询发送（简单，但会阻塞TCP收包） void UART1_Poll_Send(void) { while (ring_buffer_not_empty(&uart1_tx_rb)) { uint8_t byte = RingBuffer_Read(&uart1_tx_rb); HAL_UART_Transmit(&huart1, &byte, 1, 100); } } // 方法2：DMA发送（推荐，每次发送一帧） void UART1_DMA_Send(void) { uint16_t len; uint8_t *ptr = RingBuffer_GetReadPointer(&uart1_tx_rb, &len); if (len > 0) { HAL_UART_Transmit_DMA(&huart1, ptr, len); RingBuffer_UpdateReadIdx(&uart1_tx_rb, len); uart1_tx_busy = 1; } }

方法1的问题很致命：HAL_UART_Transmit阻塞时，LWIP的tcpip_thread或者主循环卡在串口上，此时网络接收完全断掉，TCP接收窗口会迅速减小到0。方法2用DMA发送，主循环可以继续处理网络事件，DMA完成后在HAL_UART_TxCpltCallback里清uart1_tx_busy标志。我在项目里坚持用方法2，代价是多了一层DMA中断，换来的是透传吞吐量从不足50kbps翻了八倍不止。

4.3 串口数据到网口：UART空闲中断与LWIP发送

方向B的难点在于串口数据是碎片化的。设备可能一次发32字节，也可能隔10ms发一个单字节。如果每收到一字节就调tcp_write，效率极低，TCP段里全是1字节payload。所以要引入空闲中断（IDLE）概念：UART接收线在收到一字节后的空闲时间里没有新数据，就认为当前帧结束。

void USART1_IRQHandler(void) { if (USART_GetITStatus(USART1, USART_IT_RXNE) != RESET) { uint8_t byte = (uint8_t)USART_ReceiveData(USART1); RingBuffer_Write(&uart1_rx_rb, &byte, 1); USART_ClearITPendingBit(USART1, USART_IT_RXNE); } if (USART_GetITStatus(USART1, USART_IT_IDLE) != RESET) { USART_ReceiveData(USART1); // 读DR清IDLE标志 USART_ClearITPendingBit(USART1, USART_IT_IDLE); uart1_rx_frame_done = 1; // 通知主循环攒够一帧 } }

注意IDLE中断的清除方法：必须先读SR再读DR。上面代码里USART_ReceiveData这个读操作就是在清IDLE标志。有个玄学问题是，如果读SR和读DR之间来了新字节，IDLE标志会重新置位，导致同一个空闲时间被再次中断。解决方法是进中断时先把SR读出来，再读DR，两个操作之间关一下全局中断或者在判断IDLE之前先把RDR读完。

主循环里看到uart1_rx_frame_done置位后，把环形缓冲里的数据打包发给TCP对端：

void UART1_To_Network_Send(void) { uint16_t len; uint8_t buf[512]; err_t err; if (uart1_rx_frame_done == 0) { return; } uart1_rx_frame_done = 0; len = RingBuffer_Read(&uart1_rx_rb, buf, sizeof(buf)); if (connected && len > 0) { err = tcp_write(client_pcb, buf, len, TCP_WRITE_FLAG_COPY); if (err == ERR_OK) { tcp_output(client_pcb); } } }

TCP_WRITE_FLAG_COPY这个标志也要解释。LWIP默认不拷贝数据，直接引用你的指针，所以你在tcp_write返回后立刻修改buf会破坏发送数据。加上COPY标志后LWIP把数据拷进自己的内存，代价是每次发送多一次内存拷贝。透传场景数据量不大，COPY标志的代价可以接受，换来的是代码不用等tcp_sent回调就可以复用buf。如果你要在中断里直接调tcp_write，务必加COPY标志，否则缓冲区生命周期问题会变成随机丢包。

5. 常见问题与排查：五个实测踩坑记录

透传方案看着简单，真正调通要过的坑一点都不少。这里列五个我实际踩过的，按现象、原因、解决三步写，每条都能省你半天时间。

5.1 现象：ping得通但TCP连接不上

板子启动后电脑能ping通，但TCP客户端连接迟迟不成功。一开始以为是LWIP的问题，后来加调试串口打印tcp_bind返回值，才发现是端口绑定失败，返回的是ERR_USE。原因是端口5000被LWIP内部某个监听占用，或者上一次连接没有完全关闭，tcp_pcb还在TIME_WAIT状态。解决方法是绑定时先调tcp_abort老连接，或者在tcp_bind前调socket_set_reuse_address风格的接口。如果只是Windows开发机上的问题，还要检查防火墙是否拦截了入站TCP连接，这个不属于单片机问题但非常常见。

5.2 现象：串口能发数据但收不到TCP回包

方向A能通，方向B不通。原因是UART1的接收中断没有把数据搬进网络发送缓冲，或者搬进去了但tcp_write没被调用。最常见的原因是我写的uart1_rx_frame_done标志被主循环清零之后，如果tcp_write返回的不是ERR_OK，这个标志已经丢了，下次不会再尝试发送。解决方法是把标志改成状态机，发送失败后回到等待状态而不是直接清零。另一个低级坑是连接没有建立，connected变量没有更新，主循环里看到connected==0直接return，我调试时经常忘记在accept回调里赋值。

5.3 现象：长时间透传后TCP窗口归零

这个现象很典型：刚连接时速度正常，跑了10分钟后对端的TCP接收窗口变成0，数据卡死。原因是接收路径上tcp_recved调用太晚或者根本没调用。LWIP的raw API不会自动扩展窗口，你不调tcp_recved，窗口就永远停在初始值。解决方法是确保在tcp_recv回调里每处理完一个pbuf就调用tcp_recved(tpcb, p->tot_len)。如果串口发送确实来不及，可以考虑在DMA发送完成后再把pbuf释放并调tcp_recved，但这会降低吞吐，我一般不推荐，优先调整环形缓冲大小。

5.4 现象：上电后PHY link灯亮但网口ping不通

PHY link灯亮说明物理层已经协商成功，ping不通的问题在MAC或者DMA描述符。常见原因有三个：一是RMII模式下ETH_REF_CLK没有接对，PA1要由MCO1输出50MHz，有些板子误接了PC1的MCO2或外部晶振；二是DMA描述符分配的RAM区没有重映射到能同时被MAC和CPU访问的内存区，F407的D2域RAM不连续，描述符只能放在D1域；三是ETH_Init里ETH_AutoNegotiation参数用了ETH_AutoNegotiation_Enable但PHY的地址没对上，DP83848地址为0x01，如果你用了地址0x00，MDIO读写全部失败。

解决顺序建议先看PHY寄存器读不读得出来，在ETH_Init之后读PHY_BCR寄存器的bit12，能读到1说明PHY自协商正常。再ping一次，确认链路层通了再查IP配置。排查DMA描述符时，要注意描述符数组必须4字节对齐，有些工程从别的项目拷代码时对齐属性丢失，表现就是收发都无反应。

5.5 现象：DMA发送串口偶发丢最后一个字节

UART1用DMA发送时，DMA传输完成中断和串口空闲中断可能最后一个字节还没完全移出移位寄存器，你立刻把uart1_tx_busy清了，下一个DMA传输启动把当前数据冲掉。解决方法是使用UART1的TC中断（传输完成中断），在TC中断里清标志，或者至少在DMA完成中断后加一个微妙级延时。这个坑我踩了很久，表现很随机，只有高波特率下才出现。建议在初始化时打开USART_IT_TC，在中断服务函数里看USART_GetITStatus(USART1, USART_IT_TC)，确认真正发完再动下一个DMA描述符。

6. 验证与进阶：用回环测试和重传率衡量方案

怎么验证这个透传方案能不能用？不能只拿串口工具连一下就算数。我习惯做三个测试：第一是回环测试，串口侧把TX和RX短接，网络侧用TCP调试工具发一串随机数据，看经过串口回环后回来的数据是否和原数据完全一致；第二是双向并发测试，同时往TCP发大文件并让串口设备持续发数据，观察是否有某一方向被饿死；第三是长时间稳定性测试，跑24小时以上记录TCP重传率。这三个测试过了，方案才算能交付出门。

6.1 回环测试的命令和判断标准

先用串口线把UART1的TX和RX短接，然后用网络调试助手往板子的5000端口发一段已知数据。如果数据原样返回，说明网口到串口和串口到网口两条路径都是通的。为了验证可靠性，我一般发1MB随机数据，然后在PC端统计收到的字节数和重传次数。重传率超过0.1%就要检查是不是环形缓冲溢出或者TCP窗口太小。测试时要把电脑的防火墙关掉，否则很多包会被拦在协议栈外面，干扰判断。

这个回环测试还有一层意义：它能判断UART1的DMA和中断配置是否正确。如果数据在回环过程中出现个别字节丢失，多半是DMA的TC中断处理问题，也就是5.5节那个坑。如果数据出现重复，多半是IDLE中断清除不彻底，导致同一帧被处理了两次。这些现象在纯逻辑仿真里很难复现，必须靠回环实测才能暴露。

6.2 参数微调：让吞吐和数据完整性都达标

性能上有一个参数值得专门调：TCP窗口和串口波特率的匹配关系。串口115200波特率理论吞吐约11.5KB/s，对应TCP窗口8KB足够，窗口太大反而让系统频繁处理大块数据，内存压力上升。如果串口波特率改成460800，建议把TCP_WND调大到16KB，同时把PBUF_POOL_SIZE加到24。我实测在460800波特率下，用DMA收发和raw API能跑到约40KB/s的稳定透传吞吐，CPU占用率大约25%。

还有一个技巧：在tcp_sent回调里补发。如果tcp_write在发送缓冲满时返回ERR_MEM或ERR_WOULDBLOCK，把当前数据保留在环形缓冲里，等tcp_sent回调触发后再试一次。这个机制能让串口数据不丢包，代价是环形缓冲会攒下未发送的数据，所以缓冲上限要设大一点。我在生产代码里把网络发送缓冲做到了4KB，实测从未出现溢出。

做这个项目的最大教训是：调试透传不要先上大流量，一定要先用单字节回环把两个方向的路径分别跑通，再合到一起加压。这套方案的价值在于省掉一颗独立的透传芯片，也省掉Modbus网关一类设备，前提是你愿意折腾LWIP和DMA。希望帮到你。

本文还有配套的精品资源，点击获取