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