企业官网建设流程全解析

简介：面向嵌入式开发者的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, errno=0x%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”的语义，但为了可移植性，大家一般还是会传fd+1。如果你同时监听多个串口或者网络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 高频问题的现象、原因与解决办法

下面这张表是我在实际项目里总结的串口问题速查表，几乎每个问题我都亲手踩过：

这里面最容易被卡住的一类问题就是“能发不能收”。有一次我调试一块Zynq平台的板子，串口发数据完全正常，但就是收不到外部设备发来的数据。折腾了很久，后来发现是外部设备默认用的3.3V TTL电平，而板卡串口脚被复用成了别的功能，BSP初始化的时候根本没有把该引脚的UART接收功能使能。这种问题光靠软件查是查不出来的，必须回头查原理图和BSP的引脚配置。所以在VxWorks下做串口开发，我强烈建议大家手里随时准备一份板卡的硬件原理图和BSP源码，软件查不下去的时候，一定要敢往硬件方向想。

5.3 几个值得养成的编程习惯

顺着上面的问题，我想分享几条基于个人经验的开发习惯，非常适合VxWorks下的串口应用开发：

第一，所有对串口的操作都要检查返回值。open失败要打印errno，read/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控制器默认走的是PS（Processing System）侧，不属于PL（Programmable Logic）侧逻辑。也就是说，串口驱动的初始化通常依赖FSBL（First 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板子少说也有几十块，每次遇到新问题，最后靠的都是“分层定位、数据说话”这八个字。把这个思路用到串口通信上，你也能少走不少弯路。

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