简介面向嵌入式开发者的VxWorks串口通信示例程序以TestUart工程为线索完整演示串口驱动模型下从初始化、参数配置到收发数据与中断处理的实操方法适合正在学习VxWorks设备驱动或进行板级调试的初、中级工程师。压缩包共25个文件涵盖main.c、usart.c/h等源码文件以及编译生成的map、hex、mcs、mcp工程文件与sym、cof等调试辅助文件便于对照代码结构理解工程组织包体仅26KB轻量易用。已有762人学习下载是一份非常实用的入门参考。读者可从中掌握serialOpen、serialSetSpeed、serialWrite、serialRead等核心API的调用方式并了解与ISR、任务调度配合的串口处理思路为在实时系统中自主实现稳定可靠的数据通信打下基础。 做嵌入式开发的人对串口通信应该都不陌生尤其是有VxWorks开发经历的朋友。VxWorks作为一款硬实时操作系统在航空航天、工业控制、电力电子等领域用得非常广而串口恰恰是这些场景里最基础、最常用、也最容易被忽略的通信手段。很多刚接触VxWorks的开发者上来第一件事往往不是点灯而是调串口——因为串口不仅是业务数据通道更是调试输出和日志采集的生命线。这篇博文我想以一套完整的VxWorks串口通信示例程序为主线把从驱动配置、设备打开、参数设置到数据收发、协议解析的整个过程讲清楚。我会结合自己实际调板子的经验给出可以直接抄作业的代码和排查思路。内容适合两类读者一类是刚把VxWorks跑起来、正在写第一个串口程序的初学者另一类是已经在做驱动或应用开发、但碰到串口疑难杂症想找参考的老手。1. 串口通信程序的整体设计思路1.1 为什么串口在VxWorks开发中如此重要在VxWorks的开发调试阶段串口承担的角色远不止业务通信这么简单。VxWorks的bootrom启动引导、内核加载、WindShell调试命令行默认都跑在串口终端上。也就是说你的目标板能不能正常启动、内核有没有起来、任务调度是否正常首先就要靠串口来确认。我自己就经历过不止一次新板子拿来网口驱动还没调好整个系统能不能跑起来完全依赖那一根串口线。从业务层面看VxWorks设备通常需要和上位机、GPS模块、传感器、下位机控制器等外部设备通信串口因为协议简单、抗干扰能力强、实现成本低成了最普遍的选择。很多老设备维护项目里串口通信甚至是唯一的前端数据通道。可以说串口程序写得好不好直接决定了你在VxWorks平台上能不能顺利干活。1.2 示例程序的功能定位与模块划分我设计的这个示例程序功能上遵循“实用优先”的原则不搞花里胡哨的架构就用最直接的API调用来实现串口数据的收发。程序要覆盖这样几个核心功能点——串口设备的打开与关闭、波特率和数据位等参数的配置、轮询方式的数据接收与发送、超时接收处理以及一个简单的帧解析逻辑。模块划分上我把它分成三个层次驱动层配置确认BSP里串口驱动是否正确初始化设备节点名是什么。核心通信层封装open、ioctl、read、write、close这些POSIX风格接口提供带超时的读函数。应用层协议在裸串口字节流之上设计一个简单的帧格式和状态机解析器处理粘包、半包这类实际问题。为什么要做到应用层协议因为真机环境里串口收到的不是教科书那种“一次一帧”的干净数据而是一串连续字节流。你要是把所有的read结果直接当完整报文处理十有八九会出问题。这个设计思路在后面的代码里会体现得很清楚。2. 驱动层准备工作确认设备名与系统配置2.1 确定串口设备节点VxWorks里的串口设备一般注册为/tyCo/0、/tyCo/1这类字符设备老版本里也叫/tyCo/0。不同BSP、不同硬件平台会有差异比如在某些Zynq平台上串口设备名可能是/tyS0或/uart/0。所以写程序之前第一件事不是写代码而是先确认你的板子上串口到底叫什么名字。最简单的确认方法是在WindShell里执行- devs这个命令会把当前系统里所有已注册的设备列出来。如果你看到类似/tyCo/0这样的条目说明串口驱动加载成功了。如果列表里连串口设备都没有那就要回到BSP配置层面去查是不是config.h里没打开串口组件的宏定义或者底层驱动初始化函数没有被调用。2.2 BSP与内核配置要点这里特别提醒一点使用VxWorks 6.x及以上版本时串口驱动往往不是通过传统方式直接编进内核的而是依赖系统的设备树或BSP初始化代码来注册。比如在Zynq平台做VxWorks移植时很多朋友会遇到“驱动代码看着没问题但系统起来之后串口就是不出数据”的情况——这通常是底层中断没有正确配置或者设备的基地址和板子实际硬件不一致导致的。另外如果你只是做应用层开发不打算动BSP那至少要确认内核里已经包含了串口驱动组件。VxWorks镜像工程里通常可以在组件配置界面搜索“serial”或“uart”来确认对应的驱动组件是否被include进来。没有这一步后面应用程序写得再漂亮也是白搭因为open的时候根本找不到设备节点。3. 核心API用法与示例代码实现3.1 打开与配置串口的基本姿势VxWorks对串口的操作和Linux非常相似核心其实就是几个POSIX接口open、ioctl、read、write、close。我见过不少刚转过来的人喜欢用老的tyOpen这类专用接口但正规做法还是建议直接用open/ioctl这套标准接口因为API稳定、可读性好、代码跨平台也方便。打开串口#include fcntl.h #include ioLib.h #include sys/ioctl.h int fd; fd open(/tyCo/0, O_RDWR, 0); if (fd ERROR) { printf(open /tyCo/0 failed, errno 0x%x\n, errnoGet()); return -1; }设置波特率、数据位、停止位、校验位用的是ioctl配合FIOBAUD和SIO_HW_OPTS_SET这些命令。这里有个细节很多人会搞混FIOBAUD只能设置波特率而数据位、校验位这些参数需要透过ioctl的SIO_HW_OPTS_SET命令来配置。不过不同BSP对SIO_HW_OPTS_SET的支持程度不一样有些平台只认8位数据位、无校验、1停止位的默认配置写别的参数它直接给你返回ERROR。我在实际项目里遇到这种情况比较多稳妥的办法是先用默认配置把收发调通再根据需要折腾高级参数。int baudRate 115200; if (ioctl(fd, FIOBAUD, baudRate) ERROR) { printf(set baud failed\n); close(fd); return -1; }3.2 一个可直接编译的示例程序下面给出一段我实际用过的串口通信示例程序骨架功能是打开串口、设置参数、发送一段数据、然后以指定超时时间读取数据。代码风格偏工程化大家可以直接拿去改。/* vx_uart_demo.c */ #include vxWorks.h #include stdio.h #include fcntl.h #include string.h #include errno.h #include ioLib.h #include sys/ioctl.h #include sys/select.h #include sys/types.h #include time.h #define UART_DEV /tyCo/0 #define BAUDRATE 115200 #define READ_TIMEOUT_MS 2000 static int uart_open(const char *dev, int baud) { int fd open(dev, O_RDWR, 0); if (fd ERROR) { printf(open %s error: 0x%x\n, dev, errnoGet()); return ERROR; } if (ioctl(fd, FIOBAUD, baud) ERROR) { printf(set baud %d error: 0x%x\n, baud, errnoGet()); close(fd); return ERROR; } return fd; } static int uart_send(int fd, const char *buf, int len) { int n write(fd, buf, len); if (n ! len) { printf(uart write error: %d, errno0x%x\n, n, errnoGet()); return ERROR; } return n; } static int uart_recv_timeout(int fd, char *buf, int maxLen, int timeoutMs) { struct timeval tv; fd_set rfds; int ret, n; FD_ZERO(rfds); FD_SET(fd, rfds); tv.tv_sec timeoutMs / 1000; tv.tv_usec (timeoutMs % 1000) * 1000; ret select(fd 1, rfds, NULL, NULL, tv); if (ret ERROR) { printf(select error\n); return ERROR; } else if (ret 0) { return 0; /* timeout, no data */ } n read(fd, buf, maxLen); return n; } void uart_demo_task(void) { int fd; char wbuf[] hello vxworks uart\r\n; char rbuf[256]; fd uart_open(UART_DEV, BAUDRATE); if (fd ERROR) return; uart_send(fd, wbuf, strlen(wbuf)); while (1) { int n uart_recv_timeout(fd, rbuf, sizeof(rbuf) - 1, READ_TIMEOUT_MS); if (n 0) { rbuf[n] \0; printf(recv %d bytes: %s\n, n, rbuf); } else if (n 0) { printf(recv timeout, no data\n); } else { printf(recv error\n); break; } } close(fd); }这段代码的调试入口可以直接从WindShell里调用也可以在应用代码里通过taskSpawn创建一个独立任务来跑。实际项目中我更建议用独立任务的方式不要放到启动脚本里用命令行调因为阻塞在select上的任务一旦比较多在Shell里会严重影响调试效率。3.3 关于select超时接收的补充说明上面代码用select来实现超时接收这在VxWorks里是标准做法。为什么不直接用read加ioctl(fd, FIONREAD, ...)轮询因为纯轮询太浪费CPU尤其是VxWorks这种实时系统CPU空转在关键设备上是不能接受的。select则可以让任务在等待数据时进入阻塞态等内核检测到串口FIFO有数据后再唤醒任务实时性和CPU效率都兼顾了。还有一点要注意VxWorks的select第一个参数在实现上并没有严格的“文件描述符最大值1”的语义但为了可移植性大家一般还是会传fd1。如果你同时监听多个串口或者网络Socket记得每次都重新初始化fd_set因为select返回后fd_set会被内核修改不能复用。4. 从裸字节流到可靠协议帧状态机解析实践4.1 为什么需要自定义协议帧很多初学者会有一个疑问我直接read串口拿到什么就处理什么不就行了答案是在真实环境下不行。真实串口数据有几个典型特征数据是字节流没有天然边界TCP、UDP那种“消息”概念在串口里不存在。对端设备发送的帧长度可能大于你每次read的缓冲区大小导致一帧数据被拆成多次read。多个帧可能连续到达一次read可能拿到两帧甚至三帧数据的首尾拼接。偶尔会丢字节、错字节导致帧内容整体偏移。所以写串口应用基本绕不开“组帧”和“拆帧”这一步。我习惯的设计是这样帧头 长度域 数据域 校验域。以这个帧格式为基础在接收端用一个状态机来解析解决半包、粘包、错位这些问题。4.2 一个极简但能用的状态机解析器假设帧格式为帧头(0xAA 0x55) | 长度LEN(1字节) | 数据DATA[LEN] | 校验CS(1字节)帧头2字节固定为0xAA 0x55长度域表示数据域的字节数校验域用累加和。下面我给出一个常用的状态机解析代码思路是每来一个字节就驱动状态机往前推进收到完整帧后回调处理函数。#define FRAME_HEAD1 0xAA #define FRAME_HEAD2 0x55 #define FRAME_MAX_LEN 128 typedef enum { ST_WAIT_HEAD1 0, ST_WAIT_HEAD2, ST_WAIT_LEN, ST_WAIT_DATA, ST_WAIT_CS } parse_state_t; typedef struct { parse_state_t state; unsigned char buf[FRAME_MAX_LEN 4]; int len; int cnt; unsigned char cs; } frame_parser_t; void frame_parser_reset(frame_parser_t *p) { p-state ST_WAIT_HEAD1; p-len 0; p-cnt 0; p-cs 0; } int frame_parser_push(frame_parser_t *p, unsigned char ch) { switch (p-state) { case ST_WAIT_HEAD1: if (ch FRAME_HEAD1) { p-buf[0] ch; p-state ST_WAIT_HEAD2; } break; case ST_WAIT_HEAD2: if (ch FRAME_HEAD2) { p-buf[1] ch; p-state ST_WAIT_LEN; } else { p-state ST_WAIT_HEAD1; /* 重新等待帧头 */ } break; case ST_WAIT_LEN: p-len ch; p-buf[2] ch; p-cnt 0; p-cs 0; p-state ST_WAIT_DATA; break; case ST_WAIT_DATA: p-buf[3 p-cnt] ch; p-cs ch; p-cnt; if (p-cnt p-len) { p-state ST_WAIT_CS; } break; case ST_WAIT_CS: if (ch p-cs) { /* 一帧完整接收返回帧长度外部处理 */ return p-len 4; } frame_parser_reset(p); break; default: frame_parser_reset(p); break; } return -1; /* 尚未收到完整帧 */ }这个状态机的好处是不管串口一次read返回1个字节还是100个字节只需要把每个字节逐个喂给frame_parser_push它对半包、粘包天然免疫。坏处是处理速度受单字节调用开销的影响不过串口波特率就是115200满打满算也就每秒1万多字节在VxWorks这种实时OS上跑这点开销完全可以忽略。4.3 实际项目里的扩展技巧状态机是最基本的手段实际项目里我会在这个基础上再加一个环形缓冲区ring buffer。具体做法是read串口返回的原始数据先全部存入ring buffer然后由应用层周期性或事件触发去ring buffer里取字节喂给状态机。这样做的好处是解耦了“底层接收”和“上层解析”即使上层任务繁忙暂时没空处理数据也不会丢只会暂存在ring buffer里。另外校验你可以根据自己的场景升级。累加和虽然简单但抗突发错误的能力弱对可靠性要求高的场合建议用CRC8甚至CRC16。如果对端设备是自定义协议这个可以协商如果对接的是标准协议比如Modbus RTU那校验规则就是CRC16不能乱改。5. 调试方法与常见问题排查实录5.1 硬件链路排查先分清是硬件问题还是软件问题串口通信调不通第一反应不要急着改代码先做链路排查。我常用的手段是回环测试把串口的TX和RX短接或者用一个USB转串口工具接电脑自身回环。如果发送的数据能自己收回来说明板卡的串口收发路径基本正常问题大概率出在对端设备或协议参数上。在调试阶段我还会配合上位机串口助手来做交叉验证。一边是VxWorks目标板一边是PC串口助手先用串口助手发数据给板子板子收到后原样回发。这种方式能快速确认板子侧是“发不出去”还是“收不进来”定位思路清晰很多。5.2 高频问题的现象、原因与解决办法下面这张表是我在实际项目里总结的串口问题速查表几乎每个问题我都亲手踩过现象可能原因解决方法open设备失败串口驱动组件未包含设备名错误驱动注册失败检查devs输出核对BSP配置检查sysSerialHwInit能发不能收对方未发数据波特率或帧格式不匹配中断没挂上逻辑分析仪看波形核对参数检查uart驱动中断注册能收不能发TX引脚未使能write后未排空检查引脚复用write后调用ioctl(fd, FIOFLUSH, 0)收到乱码波特率不一致电平不匹配接地不良核对双方波特率检查RS232/RS485电平检查共地丢数据接收缓冲区太小应用处理不及时流控未使能增大read缓冲区用环形缓冲区分流必要时打开硬件流控偶发错字节干扰噪声地电位差电源不稳使用屏蔽线检查接地降低波特率验证select等待不返回fd不是阻塞模式超时时间未生效信号干扰确认fd类型检查struct timeval赋值用taskDelay做后备方案这里面最容易被卡住的一类问题就是“能发不能收”。有一次我调试一块Zynq平台的板子串口发数据完全正常但就是收不到外部设备发来的数据。折腾了很久后来发现是外部设备默认用的3.3V TTL电平而板卡串口脚被复用成了别的功能BSP初始化的时候根本没有把该引脚的UART接收功能使能。这种问题光靠软件查是查不出来的必须回头查原理图和BSP的引脚配置。所以在VxWorks下做串口开发我强烈建议大家手里随时准备一份板卡的硬件原理图和BSP源码软件查不下去的时候一定要敢往硬件方向想。5.3 几个值得养成的编程习惯顺着上面的问题我想分享几条基于个人经验的开发习惯非常适合VxWorks下的串口应用开发第一所有对串口的操作都要检查返回值。open失败要打印errnoread/write返回值和预期不符要打印实际长度和错误码。串口不像文件系统那么容易出大错但因为出错时很隐蔽错误码是你定位问题的重要线索。第二发送数据后不要立即close串口或者切换波特率。串口是字符设备write返回并不代表数据已经全部从硬件FIFO发出去了。必要的时候需要调用ioctl(fd, FIOFLUSH, ...)做排空操作或者加一个小的taskDelay延时。在高速率通信场景里这个细节很关键。第三尽量把串口通信封装成独立模块不要让业务代码里到处都是read和write。设备号、波特率、帧格式、超时时间这些全部做成可配置项。VxWorks项目通常会持续维护好多年硬件可能换批次、对端设备可能换型号把这些参数集中管理后续维护会省很多事。6. 升级思路从裸串口到可靠通信的演进方向6.1 考虑中断驱动替代轮询前面的示例程序是采用select阻塞等待方式适合应用层简单收发。但在某些场景下比如串口数据量很大或者数据到达不规律且需要极低延迟响应我会建议直接改成中断驱动方式在BSP驱动里注册串口接收中断每次中断到来后由中断服务程序把数据放入缓冲区并发送信号量应用任务再通过semTake等待信号量来读取数据。这种方式的最大优势是实时性好任务不需要轮询等待中断到来立刻被激活。代价是编码复杂度更高而且ISR里不能调用printf、malloc这类非中断安全的函数数据搬运需要特别小心。如果你是新手我建议先用select版本把功能跑通再根据实际需求评估有没有必要上中断驱动。6.2 协议层进阶思路如果对端设备的协议比较复杂比如带帧序号、带时间戳、带多段变长字段状态机依然可以扩展但代码会越来越难维护。遇到这种情况更推荐引入分层解析的思路底层仍然用状态机从字节流中切出“帧”上层再用专门的解码器解析帧内容。切帧和解析分离这样每一层的逻辑都简单清晰也方便单元测试。另一个比较实在的经验是协议设计阶段一定不要把帧头定得太短或者太简单。比如帧头就一个0xAA在噪声干扰下很容易产生误同步导致一整段数据全部解析失败。我自己的习惯是帧头至少2字节并且两字节之间最好有明确的特征关系比如一高一低、一固定一变这样同步可靠性高很多。7. 串口通信在Zynq平台移植时的额外提醒热词里提到“VxWorks移植到Zynq 7100”这个方向现在确实很火很多项目都在做。如果你的目标平台也是Zynq系列那么VxWorks下的串口通信除了前面说的通用知识还有几点值得专门注意。第一Zynq的UART控制器默认走的是PSProcessing System侧不属于PLProgrammable Logic侧逻辑。也就是说串口驱动的初始化通常依赖FSBLFirst Stage Boot Loader预先配置好引脚和时钟。如果板子上电后串口完全没有输出先检查FSBL对MIO的配置是否正确比如MIO14/MIO15是不是被正确配置成了UART1的TX和RX功能。第二VxWorks 7在Zynq平台上的串口驱动名称可能不是/tyCo/0有的版本是/tinyffs、/uart/0之类的路径这取决于你用的是哪个BSP包和哪个VxWorks版本号。不能拿老版本文档里的设备名硬套一定要在目标机上用devs命令实测确认。这个问题我见过太多人踩坑了。第三如果你是从别的RTOS往VxWorks迁移串口通信代码要注意VxWorks中select的语义与Linux在细节上的差异。尤其是fd_set的定义、超时参数的单位、以及错误码的含义建议以目标板上实际运行结果为准不要想当然。说回VxWorks串口通信本身这个东西的难处从来不在API本身而在于你面对的是“真实硬件 真实干扰 真实协议”的完整链路。把API背熟只是第一步学会用系统思维去排查问题学会用状态机去对抗不可靠数据这才是串口开发真正值钱的地方。我调过的VxWorks板子少说也有几十块每次遇到新问题最后靠的都是“分层定位、数据说话”这八个字。把这个思路用到串口通信上你也能少走不少弯路。本文还有配套的精品资源点击获取
