干过嵌入式网络通信的人大概率都有一段和实时操作系统的恩怨。VxWorks下的UDP通信表面上看就是几个套接字API的拼装但真正上手调通需要处理的不只是代码还有内核组件、网络驱动、任务调度、内存缓冲区这些上下文。这篇记录把我在项目里调UDP的完整思路整理出来围绕收发两端的代码实现、超时控制、避坑清单展开。适合刚开始在VxWorks上做网络通信的嵌入式工程师也适合被UDP收发异常折腾得头大的同学。先讲一下我为什么单独拿UDP出来写。很多工程师手头都有Linux或Windows下的TCP/UDP编程经验拿到VxWorks下意识按原来那套写结果要么socket创建失败要么recvfrom直接把系统搞死要么发送成功但设备端半天没反应。这些现象背后不是语法问题而是VxWorks的协议栈、任务模型和内存管理跟通用操作系统有本质区别。把这点理解透比抄一段代码有用得多。1. 先搞清楚VxWorks的UDP为什么要单独讲1.1 网络协议栈和组件裁剪带来的第一道门槛VxWorks不是像Linux那样一套内核自带完整网络栈它通过组件方式把网络功能裁剪进镜像。同一份代码在这个开发板能跑换个BSP或者换个VxWorks版本可能连socket函数都找不到原因就是网络协议栈没被编译进去。在VxWorks 7的Image Project里你需要在Components界面搜索与网络相关的关键字。常见的有IPCOM协议栈、UDP协议、BSD Socket接口、网络接口驱动。如果这几个组件没勾全编译阶段可能不会报错但运行到socket()就会返回ERROR或者根本链接不到符号。提示最省事的方式是先查目标板出厂BSP自带的示例镜像通常默认包含IP和UDP组件。在此基础上增加自己的应用代码比从最小镜像开始逐项配置要稳得多。1.2 UDP最合适的场景和实时性权衡UDP在VxWorks里最常见的用途是测控数据下发、状态信息上报、日志流传输以及板卡间的实时协同。它的优势是开销小、无连接、协议栈处理快非常适合周期性小包通信。但别把UDP和“必然快”划等号。VxWorks的高实时性来自于任务调度和中断响应而不是网络协议栈。如果UDP接收任务优先级太低或者收发处理里出现了复杂运算、内存拷贝、打印照样会造成数据积压和丢包。实时性要从整个任务链去设计不是选UDP就高枕无忧。1.3 与Linux/Windows网络编程的三个关键差异第一个差异是任务阻塞模型。VxWorks的recvfrom默认会阻塞当前任务这个任务不是线程它占用的是系统任务上下文。阻塞期间其他低优先级任务可以跑但如果这个任务还持有信号量或资源可能把整个系统拖住。第二个差异是错误处理方式。Linux下可以直接读errnoVxWorks多数版本要用errnoGet()返回当前任务错误码而且在某些版本里errno是任务级变量不同任务互不影响。第三个差异是地址结构和API集合。虽然VxWorks提供BSD兼容接口但头文件路径、某些宏定义和版本差异明显。直接在gcc编译的Linux工程里复制socket代码过来大概率要调整头文件和类型名称。2. 环境与组件配置UDP跑不起来的头号原因2.1 在VxWorks镜像项目里确认网络组件我在实际项目里见过太多“代码写对了但运行报socket无效”的情况。排查到最后十有八九是镜像里没带网络协议栈。操作步骤很简单打开VxWorks Image Project的组件配置界面按关键字过滤确保下面这几类组件是Include状态网络协议栈主组件IPCOM或者兼容的IP栈UDP协议组件对应UDP报文处理BSD Socket兼容接口组件sockLib网络接口驱动比如Target板载网卡的end driver地址解析协议ARP组件这个没有的话发送时解析不到对端MAC照样发不出去这些组件的名称在不同VxWorks版本里会变我的习惯是直接搜索“udp”“socket”“inet”“ipcom”这些关键字然后逐个看依赖项。配置界面里通常会把依赖组件自动带出来如果某个组件依赖关系不满足需要一并勾选。2.2 静态配置IP、子网掩码和网关开发调试阶段我不建议依赖DHCP尽量手工指定IP减少一个变量。VxWorks里可以在启动脚本运行ifconfig例如在shell里执行ifconfig fei0 192.168.1.100 netmask 255.255.255.0 up这里的“fei0”是实际网卡设备名不同BSP不一样。可以先在shell输入ifconfig不带参数看当前有哪些网络接口。如果你的板子需要访问网关以外的地址还要设置route add default。同网段的UDP通信不需要网关但如果上位机和板卡不在一个网段又没配置路由发送端sendto可能返回成功数据却到不了目的地。2.3 网络缓冲区大小和内存池的取舍VxWorks的网络缓冲区由协议栈维护默认大小往往是针对通用场景设置的。连续收发大数据包或者高频次小包时默认的可用缓冲区可能不够表现为接收端丢包、发送端sendto偶尔返回内存不足。在配置组件里通常能调整网络缓冲区总数和单个缓冲区大小。比如把mbuf cluster数量调大或者把接收队列长度调大。修改后需要重新编译镜像不是运行时动态修改的。注意网络缓冲区要占用系统内存这部分内存由协议栈预留不能随意无限调大。尤其在内存只有几十兆的板卡上每个缓冲区增加100字节几千个缓冲区就是几百K需要仔细核算。3. 套接字API细节阻塞、超时和字节序不能凭感觉3.1 socket、bind、sendto、recvfrom的标准套路VxWorks的UDP通信核心API和BSD socket长得几乎一样。但有几个细节我每次都提醒自己#include vxWorks.h #include sockLib.h #include inetLib.h #include netinet/in.h #include arpa/inet.h #include errnoLib.h #include string.h #include stdio.h创建socket用socket(AF_INET, SOCK_DGRAM, 0)如果返回-1用errnoGet()拿到具体错误码。这里有个容易踩的坑VxWorks里很多系统函数返回ERROR也就是-1但失败原因要让errnoGet()去查不能直接看返回值是NULL还是0来判断。发送端如果要固定端口需要bind本机地址。bind用的sockaddr_in结构体里端口和IP都必须转成网络字节序。端口用htons()IP如果直接用inet_addr()转换字符串结果已经是网络字节序不要再多余转一遍。接收端的核心循环是bind端口、等待recvfrom、处理数据、继续等待。recvfrom返回的是实际字节数如果小于预期要检查是否发生了截断UDP的recvfrom通常是整包上报缓冲区不够时会返回需要的长度并把包丢弃。3.2 超时控制SO_RCVTIMEO还是select默认recvfrom是无限阻塞的这在很多应用里不合适。比如和上位机的握手协议如果对方掉线了接收任务会永远挂在recvfrom上其他逻辑全停。两种办法一是设置SO_RCVTIMEO二是用select做超时检测。设置SO_RCVTIMEO时不同VxWorks版本的参数单位不一样。我遇到过的版本里有的接受timeval结构体有的直接用毫秒整数。最稳妥的办法是翻一下当前版本的头文件或手册确认setsockopt第五个参数结构。代码类似struct timeval tv; tv.tv_sec 1; tv.tv_usec 0; setsockopt(sockFd, SOL_SOCKET, SO_RCVTIMEO, (char *)tv, sizeof(tv));设置之后超时发生后recvfrom返回ERROR再用errnoGet()判断是不是超时从而跳出阻塞继续做别的事。我个人更推荐select方案因为一套代码在不同版本VxWorks上更容易保持一致。3.3 地址绑定、端口复用和字节序的处理bind时如果用INADDR_ANY表示监听从任意本地地址进入的包适合单网卡设备。如果设备有多个网卡要精确绑定某个网卡IP否则可能有乱入的数据包。端口复用要小心。VxWorks里如果两个socket绑定同一个端口SO_REUSEADDR不一定像Linux那样允许所有复用场景。与其依赖这个选项不如在任务架构上保证每个端口只有一个socket持有。我的原则是一个UDP端口对应一个socket对应一个接收任务不要搞多任务并发读同一个socket。字节序是个老生常谈但也最容易错的地方。比如端口号2000正确写法是htons(2000)。有些时候对端是PC上位机PC是小端VxWorks板卡也可能是小端但是网络协议规定大端所以必须显式转换。发送结构体数据时还要考虑成员对齐和填充字节最好用紧凑格式或者序列化。4. 可直接复用的UDP通信代码发送端接收端4.1 发送端完整代码循环发数加错误打印下面这段代码完成的是创建一个UDP socket绑定本地固定端口然后周期性向对端发送一段测试数据。我把错误打印写到宏里方便调试时快速定位。#include vxWorks.h #include sockLib.h #include inetLib.h #include netinet/in.h #include arpa/inet.h #include errnoLib.h #include string.h #include stdio.h #define LOCAL_PORT 5000 #define REMOTE_PORT 6000 #define REMOTE_IP 192.168.1.200 static void udpSendTask(void) { int sockFd; struct sockaddr_in localAddr, remoteAddr; char sendBuf[64]; int n 0; sockFd socket(AF_INET, SOCK_DGRAM, 0); if (sockFd ERROR) { printf(create socket error: 0x%x\n, errnoGet()); return; } memset(localAddr, 0, sizeof(localAddr)); localAddr.sin_family AF_INET; localAddr.sin_port htons(LOCAL_PORT); localAddr.sin_addr.s_addr htonl(INADDR_ANY); if (bind(sockFd, (struct sockaddr *)localAddr, sizeof(localAddr)) ERROR) { printf(bind error: 0x%x\n, errnoGet()); close(sockFd); return; } memset(remoteAddr, 0, sizeof(remoteAddr)); remoteAddr.sin_family AF_INET; remoteAddr.sin_port htons(REMOTE_PORT); remoteAddr.sin_addr.s_addr inet_addr(REMOTE_IP); while (1) { sprintf(sendBuf, vx udp test packet %d, n); int len sendto(sockFd, sendBuf, strlen(sendBuf) 1, 0, (struct sockaddr *)remoteAddr, sizeof(remoteAddr)); if (len ERROR) { printf(sendto error: 0x%x\n, errnoGet()); } else { printf(send ok len%d\n, len); } taskDelay(sysClkRateGet() / 2); /* 0.5秒发送一次 */ } }这里我做了几件事本地端口固定方便对端识别每次发送长度是strlen1等于把字符串结尾的\0也发过去接收端可以直接当字符串处理发送循环里带一个序号n接收端可以看出来有没有丢包。4.2 接收端完整代码独立任务加超时保护接收端一般要跑在单独任务里不能被其他业务阻塞。任务栈大小要留够recvfrom的缓冲区、打印函数、可能调用的协议处理都要吃栈空间。下面这个任务带select超时控制#include vxWorks.h #include sockLib.h #include inetLib.h #include netinet/in.h #include arpa/inet.h #include errnoLib.h #include selectLib.h #include string.h #include stdio.h #define RECV_PORT 6000 static void udpRecvTask(void) { int sockFd; struct sockaddr_in localAddr; struct sockaddr_in srcAddr; int srcAddrLen sizeof(srcAddr); char recvBuf[256]; fd_set readFds; struct timeval timeout; int ret; sockFd socket(AF_INET, SOCK_DGRAM, 0); if (sockFd ERROR) { printf(create socket error: 0x%x\n, errnoGet()); return; } memset(localAddr, 0, sizeof(localAddr)); localAddr.sin_family AF_INET; localAddr.sin_port htons(RECV_PORT); localAddr.sin_addr.s_addr htonl(INADDR_ANY); if (bind(sockFd, (struct sockaddr *)localAddr, sizeof(localAddr)) ERROR) { printf(bind error: 0x%x\n, errnoGet()); close(sockFd); return; } while (1) { FD_ZERO(readFds); FD_SET(sockFd, readFds); timeout.tv_sec 2; timeout.tv_usec 0; ret select(sockFd 1, readFds, NULL, NULL, timeout); if (ret ERROR) { printf(select error: 0x%x\n, errnoGet()); break; } else if (ret 0) { printf(recv timeout, do other things\n); continue; } if (FD_ISSET(sockFd, readFds)) { int len recvfrom(sockFd, recvBuf, sizeof(recvBuf), 0, (struct sockaddr *)srcAddr, srcAddrLen); if (len ERROR) { printf(recvfrom error: 0x%x\n, errnoGet()); } else { printf(recv from %s:%d len%d data%s\n, inet_ntoa(srcAddr.sin_addr), ntohs(srcAddr.sin_port), len, recvBuf); } } } close(sockFd); }在主程序里用任务创建接口把这个函数跑起来taskSpawn(udpRcv, 100, 0, 0x4000, (FUNCPTR)udpRecvTask, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0);taskSpawn参数比较多前5个分别是任务名、优先级、选项、栈大小、函数指针后面的都是传给任务的参数。这里用不到参数全部填0。优先级100只是建议值实际要根据业务实时性调整。4.3 在开发板上验证通信的三种方法代码写完我一般先在开发板上自测不直接连设备。方法一是两块开发板之间对发一端跑发送端代码一端跑接收端代码看消息序号是否连续方法二是用电脑上的网络调试助手向板卡固定端口发UDP数据观察板卡串口打印方法三是板卡向电脑发送电脑端用Wireshark抓包确认源IP、目的IP、端口和数据载荷。我强烈推荐先把Wireshark抓包作为最终手段。它能直接看出包有没有发出来、对端MAC是否解析正确、是否存在IP分片。很多时候代码没问题是前面的交换机或安全软件把UDP挡了抓包能立刻定位。4.4 编译链接和任务创建时容易忽略的细节在VxWorks Workbench里给工程加源文件之后要注意链接器能否找到socket相关库。老一些的BSP里网络库通常是默认链接的但如果你用的是裁剪过的自定义镜像可能需要在工程配置里手动添加库。任务创建时最常踩的坑是栈空间不足。UDP任务里如果调printf、inet_ntoa、协议解析函数栈需求很快上去。我遇到过栈给0x20008KB时任务跑一段时间就异常重启后来加到0x8000才稳定。尤其是字符串处理和结构体解析这类操作栈用量很难估算宁可给大一点也不能让任务栈溢出。5. 实际调试中的高频问题和排查清单5.1 recvfrom一直阻塞任务像死了一样现象是任务创建后串口没有输出看起来系统卡住了。排查思路先确认是不是真的阻塞在recvfrom最简单的办法是在进入while前打印一行日志。如果“before recv”能打出来后面一直没有输出基本就是阻塞。原因通常是没有人给它发包或者包没送到这个端口。先看网卡IP是否配置正确再检查对端是否发到了正确的IP和端口。还有就是本地绑定端口和实际通信端口不一致代码里写6000调试工具发到6001自然收不到。把recvfrom加个超时保护任务就不会无限制挂死。用select方案还能让任务在没有报文的时候执行轮询、看门狗或别的维护逻辑。5.2 发送返回成功接收端却收不到这是UDP调试里最磨人的一个问题。sendto返回成功只能说明数据交给了协议栈不代表对端收到了。原因有几种目标IP不在同一网段且没配网关对端端口没有进程在监听包被协议栈静默丢弃防火墙或者中间网络设备过滤了UDP报文网卡驱动发送错误但VxWorks没有把错误反馈到应用层对端缓冲区满包被丢弃我建议先用ping验证链路层通不通。注意有些板卡对ICMP回显支持需要单独组件如果ping不通但UDP能通也有可能。更可靠的办法是Wireshark抓包在发送端和接收端的网络上任意一侧抓包看到底包有没有到达。5.3 收到的数据内容错乱、半包和丢包UDP是报文边界清晰的正常情况下不会出现半包但会出现数据错乱和丢失。错乱往往是因为发送端和接收端的字节序不一致或者结构体对齐导致字段偏移。丢包的原因通常是接收端处理太慢接收缓冲区满了新到的包就直接被丢弃。针对丢包第一步看是不是单个数据包超过MTU出现IP分片。两个分片里只要一个丢了整个UDP包就废了对端收不到但抓包能看到一部分。我建议UDP应用层单包控制在1200字节以内给IP头、UDP头和链路头留足余量。第二步是调大接收缓冲区。setsockopt的SO_RCVBUF可以设置但这个值还会受到网络协议栈可用mbuf的限制。如果调了也没用就要检查接收任务里是不是有耗时操作把数据处理挪到另一个任务保证recvfrom能尽快回环。5.4 任务调度和优先级导致的收发延迟VxWorks是优先级抢占式调度如果接收任务优先级太低高优先级任务一直霸占CPU网络中断就算来了接收任务也排不上队等它运行的时候包可能早被协议栈缓存或丢弃了。我一般在把接收任务的优先级设得偏高但不能超过中断服务程序锁资源的程度。如果是中断里简单通知、任务里处理数据的模式可以考虑用信号量或消息队列把收包事件传递出去而不是在接收任务里做全部业务。这块设计做得好整个系统的实时性才立得住。6. 让UDP更可靠超时重传与多路收发的扩展思路6.1 在应用层补一个轻量重传机制UDP不保证送达很多工业现场又不想引入TCP的复杂度于是就在UDP之上做一层简单可靠协议。我的做法是每个应用层包头带一个16位序号接收端收到后立即回一个ACK确认包。发送端发出后启动一个超时定时器如果在50毫秒内没有收到对应ACK就重传同一包重传超过三次就上报错误。这里要注意ACK包本身也是UDP也可能丢。所以接收端不能只确认最后一个包而是应该把最近收到的连续序号返回给发送端。更简单的场景下发送端周期性发数据接收端周期性上报状态天然带确认性质不一定要逐包ACK。6.2 用select同时管理多个socket和超时当设备同时要监听从机协议、上位机命令、调试口日志三路UDP数据时起三个接收任务太浪费资源。select可以把多个socket放进同一个等待集合一次等待谁有数据就处理谁。fd_set readFds; struct timeval timeout; FD_ZERO(readFds); FD_SET(sockA, readFds); FD_SET(sockB, readFds); FD_SET(sockC, readFds); timeout.tv_sec 1; timeout.tv_usec 0; ret select(maxFd 1, readFds, NULL, NULL, timeout); if (ret 0) { if (FD_ISSET(sockA, readFds)) handleA(); if (FD_ISSET(sockB, readFds)) handleB(); if (FD_ISSET(sockC, readFds)) handleC(); }这种方式把多个接收通道并到一个任务里减少了任务数量和栈开销也方便统一维护超时逻辑。不过要注意最大fd值要传实际最大值加1漏了这个细节select的行为会很诡异。6.3 广播与组播的UDP配置有些场景需要一发多收比如时间同步、群体状态分发。广播地址比如192.168.1.255发送端把目标地址设成广播地址即可但很多路由器默认隔离广播域只适合在同一个二层网络里用。组播更麻烦一些需要在socket上设置IP_ADD_MEMBERSHIP加入指定组播组。VxWorks下组播要确认协议栈组件支持IGMP否则加入组播组不会生效。代码逻辑和Linux差别不大但调试时经常出现“上位机能收板卡收不到”的情况重点检查网卡驱动是否开启了组播接收模式以及交换机是否做了IGMP Snooping。我在实际项目里用得最多的还是单播两个板卡之间保持定长数据帧通信。组播适合一对多但调试成本高普通项目先用单播把数据链路打通再考虑组播扩展。最后分享一个小经验在VxWorks上调UDP不要把精力全放在代码语法上先用最小例子跑通回环也就是板卡自己发自己收确认协议栈和socket链路是好的然后再分两端联调。回环测试能排除大部分网络驱动和组件配置问题把变量缩小到应用层逻辑。后面再遇到问题就是一个个抓包、数序号、查字节序的事了。
干过嵌入式网络通信的人大概率都有一段和实时操作系统的恩怨。VxWorks下的UDP通信表面上看就是几个套接字API的拼装但真正上手调通需要处理的不只是代码还有内核组件、网络驱动、任务调度、内存缓冲区这些上下文。这篇记录把我在项目里调UDP的完整思路整理出来围绕收发两端的代码实现、超时控制、避坑清单展开。适合刚开始在VxWorks上做网络通信的嵌入式工程师也适合被UDP收发异常折腾得头大的同学。先讲一下我为什么单独拿UDP出来写。很多工程师手头都有Linux或Windows下的TCP/UDP编程经验拿到VxWorks下意识按原来那套写结果要么socket创建失败要么recvfrom直接把系统搞死要么发送成功但设备端半天没反应。这些现象背后不是语法问题而是VxWorks的协议栈、任务模型和内存管理跟通用操作系统有本质区别。把这点理解透比抄一段代码有用得多。1. 先搞清楚VxWorks的UDP为什么要单独讲1.1 网络协议栈和组件裁剪带来的第一道门槛VxWorks不是像Linux那样一套内核自带完整网络栈它通过组件方式把网络功能裁剪进镜像。同一份代码在这个开发板能跑换个BSP或者换个VxWorks版本可能连socket函数都找不到原因就是网络协议栈没被编译进去。在VxWorks 7的Image Project里你需要在Components界面搜索与网络相关的关键字。常见的有IPCOM协议栈、UDP协议、BSD Socket接口、网络接口驱动。如果这几个组件没勾全编译阶段可能不会报错但运行到socket()就会返回ERROR或者根本链接不到符号。提示最省事的方式是先查目标板出厂BSP自带的示例镜像通常默认包含IP和UDP组件。在此基础上增加自己的应用代码比从最小镜像开始逐项配置要稳得多。1.2 UDP最合适的场景和实时性权衡UDP在VxWorks里最常见的用途是测控数据下发、状态信息上报、日志流传输以及板卡间的实时协同。它的优势是开销小、无连接、协议栈处理快非常适合周期性小包通信。但别把UDP和“必然快”划等号。VxWorks的高实时性来自于任务调度和中断响应而不是网络协议栈。如果UDP接收任务优先级太低或者收发处理里出现了复杂运算、内存拷贝、打印照样会造成数据积压和丢包。实时性要从整个任务链去设计不是选UDP就高枕无忧。1.3 与Linux/Windows网络编程的三个关键差异第一个差异是任务阻塞模型。VxWorks的recvfrom默认会阻塞当前任务这个任务不是线程它占用的是系统任务上下文。阻塞期间其他低优先级任务可以跑但如果这个任务还持有信号量或资源可能把整个系统拖住。第二个差异是错误处理方式。Linux下可以直接读errnoVxWorks多数版本要用errnoGet()返回当前任务错误码而且在某些版本里errno是任务级变量不同任务互不影响。第三个差异是地址结构和API集合。虽然VxWorks提供BSD兼容接口但头文件路径、某些宏定义和版本差异明显。直接在gcc编译的Linux工程里复制socket代码过来大概率要调整头文件和类型名称。2. 环境与组件配置UDP跑不起来的头号原因2.1 在VxWorks镜像项目里确认网络组件我在实际项目里见过太多“代码写对了但运行报socket无效”的情况。排查到最后十有八九是镜像里没带网络协议栈。操作步骤很简单打开VxWorks Image Project的组件配置界面按关键字过滤确保下面这几类组件是Include状态网络协议栈主组件IPCOM或者兼容的IP栈UDP协议组件对应UDP报文处理BSD Socket兼容接口组件sockLib网络接口驱动比如Target板载网卡的end driver地址解析协议ARP组件这个没有的话发送时解析不到对端MAC照样发不出去这些组件的名称在不同VxWorks版本里会变我的习惯是直接搜索“udp”“socket”“inet”“ipcom”这些关键字然后逐个看依赖项。配置界面里通常会把依赖组件自动带出来如果某个组件依赖关系不满足需要一并勾选。2.2 静态配置IP、子网掩码和网关开发调试阶段我不建议依赖DHCP尽量手工指定IP减少一个变量。VxWorks里可以在启动脚本运行ifconfig例如在shell里执行ifconfig fei0 192.168.1.100 netmask 255.255.255.0 up这里的“fei0”是实际网卡设备名不同BSP不一样。可以先在shell输入ifconfig不带参数看当前有哪些网络接口。如果你的板子需要访问网关以外的地址还要设置route add default。同网段的UDP通信不需要网关但如果上位机和板卡不在一个网段又没配置路由发送端sendto可能返回成功数据却到不了目的地。2.3 网络缓冲区大小和内存池的取舍VxWorks的网络缓冲区由协议栈维护默认大小往往是针对通用场景设置的。连续收发大数据包或者高频次小包时默认的可用缓冲区可能不够表现为接收端丢包、发送端sendto偶尔返回内存不足。在配置组件里通常能调整网络缓冲区总数和单个缓冲区大小。比如把mbuf cluster数量调大或者把接收队列长度调大。修改后需要重新编译镜像不是运行时动态修改的。注意网络缓冲区要占用系统内存这部分内存由协议栈预留不能随意无限调大。尤其在内存只有几十兆的板卡上每个缓冲区增加100字节几千个缓冲区就是几百K需要仔细核算。3. 套接字API细节阻塞、超时和字节序不能凭感觉3.1 socket、bind、sendto、recvfrom的标准套路VxWorks的UDP通信核心API和BSD socket长得几乎一样。但有几个细节我每次都提醒自己#include vxWorks.h #include sockLib.h #include inetLib.h #include netinet/in.h #include arpa/inet.h #include errnoLib.h #include string.h #include stdio.h创建socket用socket(AF_INET, SOCK_DGRAM, 0)如果返回-1用errnoGet()拿到具体错误码。这里有个容易踩的坑VxWorks里很多系统函数返回ERROR也就是-1但失败原因要让errnoGet()去查不能直接看返回值是NULL还是0来判断。发送端如果要固定端口需要bind本机地址。bind用的sockaddr_in结构体里端口和IP都必须转成网络字节序。端口用htons()IP如果直接用inet_addr()转换字符串结果已经是网络字节序不要再多余转一遍。接收端的核心循环是bind端口、等待recvfrom、处理数据、继续等待。recvfrom返回的是实际字节数如果小于预期要检查是否发生了截断UDP的recvfrom通常是整包上报缓冲区不够时会返回需要的长度并把包丢弃。3.2 超时控制SO_RCVTIMEO还是select默认recvfrom是无限阻塞的这在很多应用里不合适。比如和上位机的握手协议如果对方掉线了接收任务会永远挂在recvfrom上其他逻辑全停。两种办法一是设置SO_RCVTIMEO二是用select做超时检测。设置SO_RCVTIMEO时不同VxWorks版本的参数单位不一样。我遇到过的版本里有的接受timeval结构体有的直接用毫秒整数。最稳妥的办法是翻一下当前版本的头文件或手册确认setsockopt第五个参数结构。代码类似struct timeval tv; tv.tv_sec 1; tv.tv_usec 0; setsockopt(sockFd, SOL_SOCKET, SO_RCVTIMEO, (char *)tv, sizeof(tv));设置之后超时发生后recvfrom返回ERROR再用errnoGet()判断是不是超时从而跳出阻塞继续做别的事。我个人更推荐select方案因为一套代码在不同版本VxWorks上更容易保持一致。3.3 地址绑定、端口复用和字节序的处理bind时如果用INADDR_ANY表示监听从任意本地地址进入的包适合单网卡设备。如果设备有多个网卡要精确绑定某个网卡IP否则可能有乱入的数据包。端口复用要小心。VxWorks里如果两个socket绑定同一个端口SO_REUSEADDR不一定像Linux那样允许所有复用场景。与其依赖这个选项不如在任务架构上保证每个端口只有一个socket持有。我的原则是一个UDP端口对应一个socket对应一个接收任务不要搞多任务并发读同一个socket。字节序是个老生常谈但也最容易错的地方。比如端口号2000正确写法是htons(2000)。有些时候对端是PC上位机PC是小端VxWorks板卡也可能是小端但是网络协议规定大端所以必须显式转换。发送结构体数据时还要考虑成员对齐和填充字节最好用紧凑格式或者序列化。4. 可直接复用的UDP通信代码发送端接收端4.1 发送端完整代码循环发数加错误打印下面这段代码完成的是创建一个UDP socket绑定本地固定端口然后周期性向对端发送一段测试数据。我把错误打印写到宏里方便调试时快速定位。#include vxWorks.h #include sockLib.h #include inetLib.h #include netinet/in.h #include arpa/inet.h #include errnoLib.h #include string.h #include stdio.h #define LOCAL_PORT 5000 #define REMOTE_PORT 6000 #define REMOTE_IP 192.168.1.200 static void udpSendTask(void) { int sockFd; struct sockaddr_in localAddr, remoteAddr; char sendBuf[64]; int n 0; sockFd socket(AF_INET, SOCK_DGRAM, 0); if (sockFd ERROR) { printf(create socket error: 0x%x\n, errnoGet()); return; } memset(localAddr, 0, sizeof(localAddr)); localAddr.sin_family AF_INET; localAddr.sin_port htons(LOCAL_PORT); localAddr.sin_addr.s_addr htonl(INADDR_ANY); if (bind(sockFd, (struct sockaddr *)localAddr, sizeof(localAddr)) ERROR) { printf(bind error: 0x%x\n, errnoGet()); close(sockFd); return; } memset(remoteAddr, 0, sizeof(remoteAddr)); remoteAddr.sin_family AF_INET; remoteAddr.sin_port htons(REMOTE_PORT); remoteAddr.sin_addr.s_addr inet_addr(REMOTE_IP); while (1) { sprintf(sendBuf, vx udp test packet %d, n); int len sendto(sockFd, sendBuf, strlen(sendBuf) 1, 0, (struct sockaddr *)remoteAddr, sizeof(remoteAddr)); if (len ERROR) { printf(sendto error: 0x%x\n, errnoGet()); } else { printf(send ok len%d\n, len); } taskDelay(sysClkRateGet() / 2); /* 0.5秒发送一次 */ } }这里我做了几件事本地端口固定方便对端识别每次发送长度是strlen1等于把字符串结尾的\0也发过去接收端可以直接当字符串处理发送循环里带一个序号n接收端可以看出来有没有丢包。4.2 接收端完整代码独立任务加超时保护接收端一般要跑在单独任务里不能被其他业务阻塞。任务栈大小要留够recvfrom的缓冲区、打印函数、可能调用的协议处理都要吃栈空间。下面这个任务带select超时控制#include vxWorks.h #include sockLib.h #include inetLib.h #include netinet/in.h #include arpa/inet.h #include errnoLib.h #include selectLib.h #include string.h #include stdio.h #define RECV_PORT 6000 static void udpRecvTask(void) { int sockFd; struct sockaddr_in localAddr; struct sockaddr_in srcAddr; int srcAddrLen sizeof(srcAddr); char recvBuf[256]; fd_set readFds; struct timeval timeout; int ret; sockFd socket(AF_INET, SOCK_DGRAM, 0); if (sockFd ERROR) { printf(create socket error: 0x%x\n, errnoGet()); return; } memset(localAddr, 0, sizeof(localAddr)); localAddr.sin_family AF_INET; localAddr.sin_port htons(RECV_PORT); localAddr.sin_addr.s_addr htonl(INADDR_ANY); if (bind(sockFd, (struct sockaddr *)localAddr, sizeof(localAddr)) ERROR) { printf(bind error: 0x%x\n, errnoGet()); close(sockFd); return; } while (1) { FD_ZERO(readFds); FD_SET(sockFd, readFds); timeout.tv_sec 2; timeout.tv_usec 0; ret select(sockFd 1, readFds, NULL, NULL, timeout); if (ret ERROR) { printf(select error: 0x%x\n, errnoGet()); break; } else if (ret 0) { printf(recv timeout, do other things\n); continue; } if (FD_ISSET(sockFd, readFds)) { int len recvfrom(sockFd, recvBuf, sizeof(recvBuf), 0, (struct sockaddr *)srcAddr, srcAddrLen); if (len ERROR) { printf(recvfrom error: 0x%x\n, errnoGet()); } else { printf(recv from %s:%d len%d data%s\n, inet_ntoa(srcAddr.sin_addr), ntohs(srcAddr.sin_port), len, recvBuf); } } } close(sockFd); }在主程序里用任务创建接口把这个函数跑起来taskSpawn(udpRcv, 100, 0, 0x4000, (FUNCPTR)udpRecvTask, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0);taskSpawn参数比较多前5个分别是任务名、优先级、选项、栈大小、函数指针后面的都是传给任务的参数。这里用不到参数全部填0。优先级100只是建议值实际要根据业务实时性调整。4.3 在开发板上验证通信的三种方法代码写完我一般先在开发板上自测不直接连设备。方法一是两块开发板之间对发一端跑发送端代码一端跑接收端代码看消息序号是否连续方法二是用电脑上的网络调试助手向板卡固定端口发UDP数据观察板卡串口打印方法三是板卡向电脑发送电脑端用Wireshark抓包确认源IP、目的IP、端口和数据载荷。我强烈推荐先把Wireshark抓包作为最终手段。它能直接看出包有没有发出来、对端MAC是否解析正确、是否存在IP分片。很多时候代码没问题是前面的交换机或安全软件把UDP挡了抓包能立刻定位。4.4 编译链接和任务创建时容易忽略的细节在VxWorks Workbench里给工程加源文件之后要注意链接器能否找到socket相关库。老一些的BSP里网络库通常是默认链接的但如果你用的是裁剪过的自定义镜像可能需要在工程配置里手动添加库。任务创建时最常踩的坑是栈空间不足。UDP任务里如果调printf、inet_ntoa、协议解析函数栈需求很快上去。我遇到过栈给0x20008KB时任务跑一段时间就异常重启后来加到0x8000才稳定。尤其是字符串处理和结构体解析这类操作栈用量很难估算宁可给大一点也不能让任务栈溢出。5. 实际调试中的高频问题和排查清单5.1 recvfrom一直阻塞任务像死了一样现象是任务创建后串口没有输出看起来系统卡住了。排查思路先确认是不是真的阻塞在recvfrom最简单的办法是在进入while前打印一行日志。如果“before recv”能打出来后面一直没有输出基本就是阻塞。原因通常是没有人给它发包或者包没送到这个端口。先看网卡IP是否配置正确再检查对端是否发到了正确的IP和端口。还有就是本地绑定端口和实际通信端口不一致代码里写6000调试工具发到6001自然收不到。把recvfrom加个超时保护任务就不会无限制挂死。用select方案还能让任务在没有报文的时候执行轮询、看门狗或别的维护逻辑。5.2 发送返回成功接收端却收不到这是UDP调试里最磨人的一个问题。sendto返回成功只能说明数据交给了协议栈不代表对端收到了。原因有几种目标IP不在同一网段且没配网关对端端口没有进程在监听包被协议栈静默丢弃防火墙或者中间网络设备过滤了UDP报文网卡驱动发送错误但VxWorks没有把错误反馈到应用层对端缓冲区满包被丢弃我建议先用ping验证链路层通不通。注意有些板卡对ICMP回显支持需要单独组件如果ping不通但UDP能通也有可能。更可靠的办法是Wireshark抓包在发送端和接收端的网络上任意一侧抓包看到底包有没有到达。5.3 收到的数据内容错乱、半包和丢包UDP是报文边界清晰的正常情况下不会出现半包但会出现数据错乱和丢失。错乱往往是因为发送端和接收端的字节序不一致或者结构体对齐导致字段偏移。丢包的原因通常是接收端处理太慢接收缓冲区满了新到的包就直接被丢弃。针对丢包第一步看是不是单个数据包超过MTU出现IP分片。两个分片里只要一个丢了整个UDP包就废了对端收不到但抓包能看到一部分。我建议UDP应用层单包控制在1200字节以内给IP头、UDP头和链路头留足余量。第二步是调大接收缓冲区。setsockopt的SO_RCVBUF可以设置但这个值还会受到网络协议栈可用mbuf的限制。如果调了也没用就要检查接收任务里是不是有耗时操作把数据处理挪到另一个任务保证recvfrom能尽快回环。5.4 任务调度和优先级导致的收发延迟VxWorks是优先级抢占式调度如果接收任务优先级太低高优先级任务一直霸占CPU网络中断就算来了接收任务也排不上队等它运行的时候包可能早被协议栈缓存或丢弃了。我一般在把接收任务的优先级设得偏高但不能超过中断服务程序锁资源的程度。如果是中断里简单通知、任务里处理数据的模式可以考虑用信号量或消息队列把收包事件传递出去而不是在接收任务里做全部业务。这块设计做得好整个系统的实时性才立得住。6. 让UDP更可靠超时重传与多路收发的扩展思路6.1 在应用层补一个轻量重传机制UDP不保证送达很多工业现场又不想引入TCP的复杂度于是就在UDP之上做一层简单可靠协议。我的做法是每个应用层包头带一个16位序号接收端收到后立即回一个ACK确认包。发送端发出后启动一个超时定时器如果在50毫秒内没有收到对应ACK就重传同一包重传超过三次就上报错误。这里要注意ACK包本身也是UDP也可能丢。所以接收端不能只确认最后一个包而是应该把最近收到的连续序号返回给发送端。更简单的场景下发送端周期性发数据接收端周期性上报状态天然带确认性质不一定要逐包ACK。6.2 用select同时管理多个socket和超时当设备同时要监听从机协议、上位机命令、调试口日志三路UDP数据时起三个接收任务太浪费资源。select可以把多个socket放进同一个等待集合一次等待谁有数据就处理谁。fd_set readFds; struct timeval timeout; FD_ZERO(readFds); FD_SET(sockA, readFds); FD_SET(sockB, readFds); FD_SET(sockC, readFds); timeout.tv_sec 1; timeout.tv_usec 0; ret select(maxFd 1, readFds, NULL, NULL, timeout); if (ret 0) { if (FD_ISSET(sockA, readFds)) handleA(); if (FD_ISSET(sockB, readFds)) handleB(); if (FD_ISSET(sockC, readFds)) handleC(); }这种方式把多个接收通道并到一个任务里减少了任务数量和栈开销也方便统一维护超时逻辑。不过要注意最大fd值要传实际最大值加1漏了这个细节select的行为会很诡异。6.3 广播与组播的UDP配置有些场景需要一发多收比如时间同步、群体状态分发。广播地址比如192.168.1.255发送端把目标地址设成广播地址即可但很多路由器默认隔离广播域只适合在同一个二层网络里用。组播更麻烦一些需要在socket上设置IP_ADD_MEMBERSHIP加入指定组播组。VxWorks下组播要确认协议栈组件支持IGMP否则加入组播组不会生效。代码逻辑和Linux差别不大但调试时经常出现“上位机能收板卡收不到”的情况重点检查网卡驱动是否开启了组播接收模式以及交换机是否做了IGMP Snooping。我在实际项目里用得最多的还是单播两个板卡之间保持定长数据帧通信。组播适合一对多但调试成本高普通项目先用单播把数据链路打通再考虑组播扩展。最后分享一个小经验在VxWorks上调UDP不要把精力全放在代码语法上先用最小例子跑通回环也就是板卡自己发自己收确认协议栈和socket链路是好的然后再分两端联调。回环测试能排除大部分网络驱动和组件配置问题把变量缩小到应用层逻辑。后面再遇到问题就是一个个抓包、数序号、查字节序的事了。
