簡介VxWorks廣泛部署于航空航天、通信、工業自動化等實時性要求極高的場景串口通信則是設備交互與調試環節中最常用也最基礎的手段之一。這份示例程序以TestUart項目為載體面向嵌入式初學者與工程開發人員重點演示VxWorks標準串口驅動API的完整調用流程包括端口打開、波特率及數據位/校驗位/停止位配置、數據收發、中斷服務注冊、任務同步與異常返回處理等關鍵分支。壓縮包共25個文件整體僅26KB以main.c、usart.c等C源碼為核心同時附有Tornado環境下的.mcp工程文件、.map鏈接映射、.hex燒寫文件以及.lst、.sym等調試文件便于從源碼到運行鏡像逐層對照。目前該資源已有762人學習使用。通過研讀并調試這些代碼讀者能掌握serialOpen、serialWrite、serialRead等接口的實際用法理解VxWorks串口驅動在中斷與多線程環境中的配合要點進而快速移植到自己的硬件平臺或應用項目中提升嵌入式系統開發效率。1. 項目概述與核心思路拆解1.1 這個示例到底解決什么問題搞過嵌入式開發的朋友都清楚VxWorks作為一款硬實時操作系統在航空、航天、工業控制、高端裝備這些領域里依然是難以替代的存在。而串口通信恰恰是嵌入式系統里最基礎、最常用的調試和數據交互手段——小到啟動時的控制臺輸出大到設備間的指令下發、狀態回傳串口幾乎貫穿整個產品生命周期。我接觸VxWorks有幾年時間從最開始在模擬器上跑通一個Hello World到后來在真實板卡上調試驅動踩過的坑不少。其中串口通信這塊網上資料不算少但大多停留在調用open/read/write這種API層面的簡單示范真正涉及VxWorks特有的設備驅動框架、串口參數配置細節、以及多任務環境下串口使用的注意事項講清楚的并不多。這篇博文就基于一個實際可運行的VxWorks串口通信示例程序展開核心目標有三個第一講清楚VxWorks下串口設備從打開、配置到讀寫關閉的完整流程第二把容易踩坑的細節和背后的原理說透比如波特率配置為什么有的板子不生效、中斷模式下read返回時機怎么控制第三給出一份能直接編譯運行的參考代碼讓初學者能快速搭建起自己的串口通信測試環境。1.2 為什么選擇標準串口驅動框架而不是直接操作寄存器有個常見誤區很多從裸機開發轉過來的工程師習慣直接讀寄存器。在VxWorks上這么做短期看好像效率很高實際上代價很大。VxWorks的設備驅動架構里串口被抽象成了標準的tty設備通過tyCoDrv、uart驅動層和具體芯片驅動三層結構來管理。應用層只需要用open/read/write/ioctl這套POSIX接口操作設備文件即可完全不用關心底層是16550還是Zynq上的UART控制器。選擇這套標準框架的好處很明顯。首先是可移植性同一份應用層代碼從x86平臺換到ARM平臺只需要改驅動配置應用層一行不用動。其次是系統級的資源管理中斷處理、環形緩沖區、任務調度這些事情驅動層已經處理好了應用層介入過多反而容易引入競態問題。還有一點VxWorks的調試工具和可視化工具對標準設備節點的支持更友好用i命令可以快速查看設備列表排查問題方便很多。當然這也不是說寄存器操作就一無是處比如在啟動早期、驅動還沒有加載完成的時候通過串口輸出啟動日志確實需要直接在BSP層操作寄存器。但那屬于系統移植范疇和本文討論的應用層通信不是一回事。應用層開發老老實實走標準驅動框架才是投入產出比最高的選擇。2. 串口通信的關鍵API與參數配置詳解2.1 設備節點與open操作的正確理解在VxWorks里串口設備節點一般默認叫/tyCo/0、/tyCo/1這樣對應系統的第0個、第1個串口。這里容易有個混淆點VxWorks控制臺串口console用的也是這個設備節點如果在目標機上把控制臺重定向到了/tyCo/0那再打開/tyCo/0做數據通信就可能會和shell輸出打架。所以實際項目里有個約定俗成的做法調試串口和業務串口分開業務串口用/tyCo/1或更高編號。如果一定要用同一個串口就需要把控制臺重定向到其他設備比如網絡虛擬控制臺或者干脆關掉shell對串口的占用。代碼層面open操作很直觀int fd; fd open(/tyCo/1, O_RDWR | O_NOCTTY, 0); if (fd ERROR) { perror(open /tyCo/1 fail); return -1; }這里O_NOCTTY標志在VxWorks里并非所有版本都強制需要但加上是良好習慣——防止該串口成為控制終端后受到shell信號干擾。我在一次實際調試中就遇到過不加O_NOCTTY程序跑一段時間后莫名其妙收到SIGINT終止排查半天才發現是控制終端信號問題。2.2 串口參數配置波特率、數據位、停止位、校驗位open之后第一件事就是配置參數。VxWorks里最常用的是ioctl配合FIOBAUD設置波特率或者用tcsetattr配合termios結構體做完整配置。后者更標準可配置項更多我建議統一用termios方式。一個完整配置的代碼片段如下#include termios.h struct termios tty; int baudrate B115200; memset(tty, 0, sizeof(tty)); if (tcgetattr(fd, tty) ! OK) { perror(tcgetattr fail); close(fd); return -1; } tty.c_cflag CLOCAL | CREAD | CS8; tty.c_cflag ~PARENB; // 無校驗 tty.c_cflag ~CSTOPB; // 1位停止位 tty.c_cflag ~CRTSCTS; // 禁用硬件流控 tty.c_iflag ~(IXON | IXOFF | IXANY); // 禁用軟件流控 tty.c_iflag ~(ICRNL | INLCR | IGNCR); // 不做回車換行轉換 tty.c_oflag ~OPOST; // 原始輸出模式不做換行轉換 tty.c_lflag ~(ICANON | ECHO | ECHOE | ISIG); // 原始輸入模式 cfsetispeed(tty, baudrate); cfsetospeed(tty, baudrate); tcsetattr(fd, TCSANOW, tty);這里特別強調一下c_lflag里的ICANON。很多新手在這塊翻車不關閉ICANONread會工作在線路緩沖模式必須等收到換行符才會返回導致明明設備發來了數據程序卻一直阻塞。我在Zynq平臺上調一個傳感器數據采集時就因為這個參數沒配置對浪費了一整天。關閉ICANON后read就能立刻返回當前緩沖區已有的數據。2.3 非阻塞模式與超時控制串口通信場景里阻塞式read一把梭能應付簡單需求但real-world里的設備往往不是有問必答對端可能宕機、可能沒上電、可能協議交互有延遲。如果read無限期阻塞整個任務就卡死了。解決思路有兩種第一種是設置非阻塞模式。用fcntl或者VxWorks的ioctl(fd, FIONBIO, on)來開啟之后read會立即返回如果沒有數據就返回ERROR然后查errno去判斷是EAGAIN還是其他錯誤。這種方式需要自己在循環里做輪詢或配合select使用。第二種是termios里的VTIME和VMIN組合。VMIN表示最少讀取字節數VTIME表示超時時間單位是0.1秒。比如設置tty.c_cc[VTIME] 10tty.c_cc[VMIN] 0read會在收到任何數據字節后等待1秒沒有新數據到來就返回實現讀完當前數據就超時返回的效果。這在處理變長幀、不定長響應時非常好用。從實際經驗看select加非阻塞是最穩妥的方案尤其在多任務環境下既能保證及時響應又不會忙等消耗CPU。VxWorks的select實現和POSIX標準兼容性很好代碼寫法和Linux下幾乎一致。3. 完整的串口通信示例程序3.1 程序功能設定和文件組織為了讓示例有實際參考價值我把它設計成這樣一個場景目標板通過串口外接一個溫度傳感器模塊傳感器上電后每2秒主動上報一幀數據幀格式是幀頭0xAA 0x55加1字節溫度值加1字節校驗和。程序要做的是打開串口配置好參數循環接收數據幀解析出溫度值同時支持用戶通過控制臺輸入命令主動發送查詢指令。整個程序分成三個文件uart_demo.h定義接口和常量uart_demo.c是核心實現uart_demo_main.c是入口任務代碼。這樣組織方便后續擴展——如果要把接收到的數據轉發到網絡只需要在解析回調里加邏輯核心串口代碼不用動。3.2 核心代碼實現先看頭文件/* uart_demo.h */ #ifndef __UART_DEMO_H__ #define __UART_DEMO_H__ #include vxWorks.h #include stdio.h #include stdlib.h #include string.h #include fcntl.h #include unistd.h #include errno.h #include termios.h #include ioLib.h #define UART_DEVICE /tyCo/1 #define UART_BAUDRATE B115200 #define FRAME_HEAD0 0xAA #define FRAME_HEAD1 0x55 typedef struct { char devName[32]; int baudrate; int isOpen; } UartConfig; int uart_open(const char *dev, int baudrate); int uart_config(int fd, int baudrate); int uart_send(int fd, const char *buf, int len); int uart_recv(int fd, char *buf, int maxLen, int timeoutMs); void uart_close(int fd); void uart_demo_task(void); #endif再是核心實現文件。這里重點展示打開、配置、發送和帶超時接收的邏輯/* uart_demo.c */ #include uart_demo.h int uart_open(const char *dev, int baudrate) { int fd; fd open(dev, O_RDWR | O_NOCTTY, 0); if (fd ERROR) { printf([UART] open %s failed, errno 0x%x\n, dev, errno); return ERROR; } if (uart_config(fd, baudrate) ! OK) { printf([UART] config %s failed\n, dev); close(fd); return ERROR; } printf([UART] open and config %s success\n, dev); return fd; } int uart_config(int fd, int baudrate) { struct termios tty; int speed; switch (baudrate) { case 9600: speed B9600; break; case 19200: speed B19200; break; case 38400: speed B38400; break; case 115200: speed B115200; break; default: speed B115200; break; } memset(tty, 0, sizeof(tty)); if (tcgetattr(fd, tty) ! OK) { return ERROR; } tty.c_cflag CLOCAL | CREAD | CS8; tty.c_cflag ~PARENB; tty.c_cflag ~CSTOPB; tty.c_cflag ~CRTSCTS; tty.c_iflag ~(IXON | IXOFF | IXANY); tty.c_iflag ~(ICRNL | INLCR | IGNCR); tty.c_oflag ~OPOST; tty.c_lflag ~(ICANON | ECHO | ECHOE | ISIG); tty.c_cc[VMIN] 0; tty.c_cc[VTIME] 1; cfsetispeed(tty, speed); cfsetospeed(tty, speed); if (tcsetattr(fd, TCSANOW, tty) ! OK) { return ERROR; } tcflush(fd, TCIOFLUSH); return OK; } int uart_send(int fd, const char *buf, int len) { int written 0; int ret; while (written len) { ret write(fd, buf written, len - written); if (ret ERROR) { printf([UART] write error, errno 0x%x\n, errno); return ERROR; } written ret; } return written; } int uart_recv(int fd, char *buf, int maxLen, int timeoutMs) { fd_set rfds; struct timeval tv; int ret; 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([UART] select error, errno 0x%x\n, errno); return ERROR; } if (ret 0) { return 0; // 超時無數據 } ret read(fd, buf, maxLen); return ret; }我在uart_recv里用了select加非阻塞思維的超時控制而不是直接依賴VTIME/VMIN。原因是這樣更靈活VTIME的最小粒度是0.1秒如果調用方想設置50ms超時termios方式就做不到。而select的時間粒度更細配合循環還能實現每次最多等N毫秒這種更復雜的邏輯。代碼中uart_send做了寫滿才算完的處理這也是實際項目中容易忽略的。寫串口不一定一次write就能把整個緩沖區寫出去尤其底層緩沖區剩余空間不足時write會返回部分寫入字節數。不做循環處理的話發送長幀可能出現數據截斷。3.3 應用入口任務和數據幀解析看入口任務怎么組織/* uart_demo_main.c */ #include uart_demo.h #define RECV_BUF_LEN 256 void uart_demo_task(void) { int fd; char recvBuf[RECV_BUF_LEN]; int recvLen; int i; char tempRaw; char checksum; char sum; float temperature; char cmd[16]; fd uart_open(UART_DEVICE, UART_BAUDRATE); if (fd ERROR) { return; } while (1) { recvLen uart_recv(fd, recvBuf, RECV_BUF_LEN, 1000); if (recvLen 0) { /* 簡單幀解析找幀頭0xAA 0x55 */ if (recvLen 4) { for (i 0; i recvLen - 3; i) { if ((unsigned char)recvBuf[i] FRAME_HEAD0 (unsigned char)recvBuf[i1] FRAME_HEAD1) { tempRaw recvBuf[i2]; checksum recvBuf[i3]; sum (char)(FRAME_HEAD0 FRAME_HEAD1 tempRaw); if (sum checksum) { temperature (float)tempRaw; printf([UART] temperature report: %.1f C\n, temperature); } else { printf([UART] checksum error\n); } break; } } } } /* 檢測控制臺是否有輸入支持發送查詢指令 */ if (fgets(cmd, sizeof(cmd), stdin) ! NULL) { cmd[strcspn(cmd, \n)] \0; if (strlen(cmd) 0) { uart_send(fd, cmd, strlen(cmd)); } } taskDelay(10); } uart_close(fd); }入口任務做了三件事接收數據、解析幀、檢查控制臺輸入并發送指令。需要注意fgets在VxWorks的shell環境下讀的是標準輸入這里在循環里調用如果shell沒有給這個任務分配標準輸入fgets會阻塞。實際調試中更常見的做法是把指令下發做成單獨的命令函數在shell里直接敲命令觸發發送。幀解析上這個示例用了最樸素的遍歷查找幀頭方式。真實項目里如果數據量很大、波特率很高這種逐字節遍歷的方式可能有性能問題更好的做法是維護一個環形緩沖區或者狀態機逐字節解析。但作為示例思路表達清楚就行了——核心是想說明收到的是字節流不是完整幀一定要自己做幀邊界識別和校驗。4. 常見問題與排查技巧實錄4.1 read一直阻塞不返回怎么辦這應該是VxWorks串口開發里最高頻的問題。前面在配置部分其實已經埋了伏筆絕大多數情況是termios里c_lflag沒有關閉ICANON。最佳排除順序是先用tcgetattr把當前配置打出來確認ICANON、ECHO這些位的狀態再確認是否設置了VTIME/VMIN如果兩個參數都是0非阻塞模式下read會立即返回而阻塞模式下則永遠等待最后確認是不是底層驅動本身的配置有問題這種一般發生在自己修改過BSP串口驅動的情況下。我曾經在一個項目里遇到非常隱蔽的情況板子上電后串口工作正常但只要運行過一段網絡相關的初始化代碼串口read就再也不返回了。后來排查發現是網絡初始化時修改了全局中斷優先級和CPU中斷使能狀態影響了串口接收中斷。這類問題已經超出應用層范圍只能通過查看中斷狀態寄存器定位。但這也提醒我們遇到詭異現象時不要只盯著應用層代碼多想想周圍環境的變化。4.2 數據接收內容是亂碼亂碼問題一般集中在波特率、電平、數據格式三個層面。先排除波特率不匹配這是最常見的原因比如傳感器默認9600而程序配了115200。其次是線路電平問題RS232和TTL電平不能直接對接中間要有電平轉換芯片工業現場還要考慮地線是否共地。最后是數據格式比如設備是8位數據位1位停止位程序配置成了7位數據位接收自然錯亂。有一個實用排查技巧把示波器接到TX/RX線上直接看波形。從起始位和停止位的寬度能夠反推實際波特率用1個數據位的寬度算一下這樣就能確定是配置問題還是硬件問題不用猜。我在現場調試時經常用這個辦法區分程序沒配對和線接錯了往往就在一瞬間。4.3 串口發送出去了但對端沒反應先確認數據真的從引腳上發出去了示波器一量就能驗證。如果量不到信號說明程序可能根本沒執行到write或者設備文件打開失敗。如果量到了波形但對端沒反應重點查對端設備的手冊確認它的通信方式——有的設備是先聽后說必須收到特定指令才上報數據有的設備是純主動上報不需要任何指令還有的設備用的是RS485需要控制方向引腳單純發數據不夠還得把收發方向切換成發送模式這個在很多串口轉RS485的硬件上是個隱蔽的坑。VxWorks下還有一種特殊情況如果串口被系統控制臺占用了應用層可以正常write但數據可能被控制臺相關的處理邏輯干擾。比如你printf輸出調試信息也走這個串口那應用數據和控制臺輸出就混在一起了。這就是我在前文強調為什么業務串口要和調試串口分開的原因。4.4 高頻收發時丟數據高頻收發場景下丟數據通常是接收緩沖區溢出或者中斷響應不及時。VxWorks的串口驅動內部有緩沖區但如果應用層讀取不夠頻繁、處理耗時太長數據就會在驅動緩沖區里堆積溢出。關鍵在于調整調度策略讓接收任務有足夠的優先級縮短從中斷產生到應用層read之間的時間。還有一個容易忽視的點應用層處理完一幀數據后最好不要在任務上下文里做大量計算和打印操作打印耗時會拉低整體接收吞吐正確做法是先把數據拷貝到自己的接收隊列交給低優先級任務慢慢處理接收任務繼續保持高速。我在Zynq平臺上遇到過莫名其妙丟開頭幾個字節的情況后來發現是DMA配置問題——DMA接收模式和串口中斷模式配合不良。如果程序需要高可靠性收發建議認真閱讀芯片的UART控制器手冊確認DMA描述符長度和中斷觸發閾值設置合理。4.5 常見問題速查表為了方便以后排查我把自己遇到過的典型問題整理成一張速查表基本覆蓋了串口開發90%的坑現象可能原因排查方法read一直阻塞未關閉ICANONVTIME/VMIN配置不對tcgetattr打印配置檢查c_lflag數據亂碼波特率不匹配電平不對數據位格式錯誤示波器量波形核對設備手冊發送無反應設備文件打開失敗RS485方向未控制對端需指令觸發示波器確認輸出檢查ioctl方向控制高頻收發丟數據緩沖區溢出任務調度不及時打印耗時太長提高接收任務優先級減少打印開銷打開設備失敗設備節點不存在驅動未加載設備被占用i命令查看設備列表檢查BSP配置打印和業務數據混在一起控制臺復用同一串口shell重定向控制臺換成獨立業務串口偶發幀校驗錯誤線路干擾地電位差波特率微小偏差加屏蔽線共地處理降低波特率驗證5. 進階實踐與部署建議5.1 如何把示例程序部署到VxWorks鏡像里示例代碼寫好后很多人卡在怎么把它編譯進VxWorks工程。這里補充一個最小操作路徑在VxWorks Workbench里創建或者打開一個bootable工程把三個源文件加進工程源碼目錄然后通過Workbench的構建配置把源文件編譯進vxWorks鏡像的usrAppInit或自定義啟動任務里。具體路徑不同版本略有差異但思路一樣——把uart_demo_task掛到系統啟動任務序列中。如果是VxWorks 7底層是基于Yocto的VSBVxWorks Source Build和VIPVxWorks Image Project兩層構建方式。VSB里需要確保包含了串口驅動組件比如IPNET_UART或DRV_SIO這類組件不同BSP的名字可能不同。確認方法是在VSB配置界面里搜16550或uart關鍵字。IP組件配置不對是最常見的啟動后串口無輸出的原因之一。5.2 與Zynq平臺相關的特殊性熱詞里出現了不少vxworks移植到正點原子zynq 7100之類的內容。Zynq系列是Xilinx現在是AMD的異構SoC內部是ARM Cortex-A9雙核加FPGA架構。VxWorks跑在ARM核上串口硬核用的是Zynq的UART控制器在VxWorks的BSP里已經有對應驅動支持。實際上手時有一點和純粹ARM平臺不同——Zynq的UART時鐘由PS側的時鐘配置決定如果FSBL或者引導程序里設置的UART時鐘和VxWorks BSP編譯時的默認時鐘不一致就會出現波特率偏移。有次我們的板子串口輸出全是亂碼查了很久最后發現是FSBL里改了UART時鐘頻率VxWorks BSP里卻是按另一個頻率計算的。這類問題的排查方法也很直接量波形確認實際波特率然后去改BSP里的時鐘宏定義重新編譯VSB。5.3 多任務環境下串口使用的設計模式VxWorks的多任務環境是它的核心優勢但也是串口程序設計的難點所在。如果多個任務同時對一個串口做read/write沒有協調機制的話會出現嚴重的資源競爭問題。我常用的設計模式是單讀寫任務消息隊列分發一個專門的串口接收任務負責read和解析解析出來的數據通過消息隊列發給各個業務任務發送方向則是所有任務都把要發的數據放入發送隊列由串口發送任務統一write。這樣做的好處是串口只有一個任務在操作天然避免了競態而且接收任務優先級可以設得較高保證不丟數據的同時其他任務不會被長時間打斷。如果系統里有強實時性要求可以在接收任務里直接做信號量同步中斷服務程序收到一幀數據就釋放信號量接收任務立刻被喚醒去處理。這種中斷信號量任務的組合拳是VxWorks下比較高效的模式比裸輪詢省電比純中斷上下文處理安全中斷上下文里不允許調用printf這類非中斷安全的操作。5.4 收尾經驗上值得留意的幾點最后補充幾個我實際項目中沉淀下來的小習慣雖然不能保證每個項目都適用但多數情況下能幫你少走彎路第一收到數據先存后解析不要把解析邏輯直接寫在read返回后的處理里尤其是涉及浮點運算、打印格式化這些耗時操作時盡量和接收路徑解耦。第二串口配置做完后一定要調用tcflush清空緩沖區否則上電殘留的臟數據會影響第一幀的解析。第三程序的異常分支一定要打印errnoVxWorks的errno能直接反映底層錯誤類型比返回-1這種信息有價值得多。第四多留調試接口比如通過shell命令動態修改波特率、打開或關閉幀解析的時間統計這些看似多余的功能在現場問題上能省下大量時間。我始終覺得串口通信在嵌入式開發里不算高深技術但恰恰是這種基礎模塊最考驗工程師對系統的整體把握能力。一個小小串口牽扯到BSP、設備驅動、中斷機制、任務調度、應用層邏輯每一層都可能出問題。把這份示例程序跑通只是第一步更重要的是理解每一層之間的關系這樣就算以后遇到復雜問題也能順著這條技術鏈路一步步定位到根因。希望這篇內容對正打算在VxWorks上做串口開發的你有所幫助。本文還有配套的精品資源點擊獲取