把開發(fā)板接到Ubuntu主機上插上USB線打開串口調試助手結果發(fā)現(xiàn)/dev下面壓根沒有ttyUSB0連個影子都找不到。剛接觸嵌入式Linux的朋友十有八九會在這個環(huán)節(jié)卡住我自己也在這上面折騰過不少時間。這個問題的根源通常不是板子壞了而是USB轉串口芯片的驅動、內核枚舉或者權限配置出了岔子。這篇就是針對“開發(fā)板串口連上Ubuntu后找不到設備文件”這件事把排查思路和解決方案從頭到尾捋一遍適合正在用STM32、全志T113、i.MX6ULL這類開發(fā)板做開發(fā)卻卡在串口識別這一步的讀者。1. 先搞清楚“設備文件”到底是怎么來的1.1 一根USB線背后的角色分工很多新手容易把“開發(fā)板和電腦用USB線連起來”理解成插上就能通實際上這里面有一個容易被忽略的中間環(huán)節(jié)。絕大多數(shù)開發(fā)板上自帶的串口物理電平是TTL電平通常是3.3V或5V而電腦主板的USB口是USB差分信號兩者根本不能直接對話。所以板子上通常會有一顆USB轉串口芯片常見的型號包括CH340、CH341、CP2102、CP210x系列、FT232等也有不少新板子用CH9102這類高速型號。這顆芯片的作用就是把板子的UART TX/RX信號轉換成USB協(xié)議再通過USB線送到電腦。換句話說電腦識別到的不是“開發(fā)板”而是這顆USB轉串口芯片。系統(tǒng)在枚舉USB設備時會根據(jù)芯片的VID廠商ID和PID產品ID去匹配對應的驅動程序匹配成功后再注冊一個字符設備節(jié)點也就是我們常說的/dev/ttyUSB0或者/dev/ttyACM0。如果這一步某個環(huán)節(jié)沒接通那你在/dev下自然看不到設備文件。1.2 為什么偏偏是ttyUSB0和ttyACM0這里順便把設備名的命名規(guī)則說清楚因為很多人拿到設備后第一反應是找ttyS0那是錯的。ttyS是主板原生串口也就是物理COM口對應的設備節(jié)點和USB轉出來的串口是兩套體系。USB轉串口芯片在Linux內核里走的通常是USB子系統(tǒng)注冊出來的設備名是ttyUSB比如ttyUSB0、ttyUSB1對應的驅動框架是usb-serial。而ttyACM*則是另一種情況它走的是內核里的USB ACMAbstract Control Model驅動。這個驅動最開始主要是為USB Modem設計的但很多單片機開發(fā)板用USB直接虛擬串口時比如STM32的USB CDC類也會被識別成ttyACM0。所以判斷設備屬于哪一類直接看設備名就能猜個大概ttyUSB開頭基本都是外置USB轉串口芯片ttyACM開頭往往是芯片內置USB控制器虛擬出來的串口。這兩種設備在權限配置和驅動處理上略有差別后面會具體說。2. 三步定位到底是哪一層斷了2.1 第一步看USB總線上的枚舉結果設備文件沒出現(xiàn)先別急著裝驅動第一步應該先確認USB總線層面有沒有認出這顆芯片。把板子通過USB線接到電腦后在終端執(zhí)行l(wèi)susb這個命令會列出當前USB總線上所有設備的VID和PID信息以及廠商名稱如果能識別的話。正常情況下的輸出大概是這個樣子$ lsusb Bus 001 Device 008: ID 1a86:7523 QinHeng Electronics CH340 serial converter看到1a86:7523這行說明USB枚舉已經(jīng)成功CH340芯片被系統(tǒng)正常識別了。1a86就是沁恒的廠商ID7523對應CH340這個型號。如果輸出里壓根沒有新設備出現(xiàn)那就說明USB物理鏈路有問題需要去排查線材、USB口或者芯片供電。如果lsusb能看到設備但/dev下沒有ttyUSB節(jié)點問題基本就鎖定在驅動匹配環(huán)節(jié)。如果lsusb連設備都看不到則要從硬件連接開始查起。很多時候是數(shù)據(jù)線的問題——有些MicroUSB線只能充電不能傳數(shù)據(jù)這種線在開發(fā)板上非常常見換根線往往就好了。2.2 第二步確認內核驅動與設備名lsusb正常之后下一步用dmesg查看內核日志。執(zhí)行$ dmesg | tail -n 30插入板子后如果驅動加載成功日志里會出現(xiàn)類似下面的內容usb 1-2: new full-speed USB device number 8 using xhci_hcd usb 1-2: New USB device found, idVendor1a86, idProduct7523, ... usb 1-2: New USB device strings: Mfr1, Product2, SerialNumber3 usbcore: registered new interface driver ch341 usbserial: USB Serial support registered for ch341-uart ch341-uart now attached to ttyUSB0倒數(shù)第二行的ch341就是內核為這顆芯片加載的驅動模塊名最后一行清楚標明了設備節(jié)點注冊到了ttyUSB0。如果你的日志里有類似信息那設備文件其實已經(jīng)生成了問題大概率出在權限或者你查看的時機不對。如果lsusb能看到設備但dmesg里沒有任何與usbserial、ch341、cp210x、ftdi相關的輸出說明內核沒有加載對應的驅動模塊。這時候可以手動嘗試$ sudo modprobe ch341加載完再執(zhí)行dmesg看有沒有新日志或者直接ls /dev/ttyUSB*確認節(jié)點是否出現(xiàn)。不同芯片對應模塊名不一樣這個下一節(jié)詳細列個對照表。2.3 第三步檢查串口占用與權限/dev/ttyUSB0已經(jīng)存在但串口工具打不開或者打開后一片空白這種情況多半是權限或占用問題。先看設備節(jié)點權限$ ls -l /dev/ttyUSB0 crw-rw---- 1 root dialout 188, 0 5月 30 10:23 /dev/ttyUSB0默認屬主是root組是dialout普通用戶沒有讀寫權限。如果不加sudo直接打開串口就會提示Permission denied。解決辦法是把當前用戶加進dialout組$ sudo usermod -aG dialout $USER執(zhí)行完后需要重新登錄一次才能生效。注意這個操作在Ubuntu 20.04及之后幾乎所有版本上通用但如果你用的是其他發(fā)行版組名可能不一樣比如有些發(fā)行版用的是uucp或者lock組。Ubuntu桌面版和服務器版的默認組策略也有些細微差異但dialout是主流選擇。另外還有一種情況就是串口被別的進程占用了。用sudo lsof /dev/ttyUSB0或者sudo fuser /dev/ttyUSB0查一下誰在占用然后把進程關掉再試。3. 驅動不是萬能的但缺了它真不行3.1 主流USB轉串口芯片與內核模塊對照市面上常見的USB轉串口芯片就那么幾種Linux內核從4.x時代開始基本就全部內置了對應的驅動模塊。我整理了一張表覆蓋了主流芯片對應的模塊名和典型VID方便排查時對照芯片型號內核模塊典型VID:PID備注CH340 / CH341ch3411a86:7523最常見的國產芯片CH9102ch3411a86:55d4高速版本CP2102 / CP210xcp210x10c4:ea60硅谷老牌方案FT232 / FT2232ftdi_sio0403:6001FTDI經(jīng)典款PL2303pl2303067b:2303老芯片內核版本兼容性一般CH9350ch93501a86:e010帶HID功能需要單獨處理STM32 USB CDCcdc_acm0483:5740設備是ttyACM*排查時直接用lsusb對照這張表就能知道系統(tǒng)是否識別到了芯片以及該用哪個模塊去驗證。3.2 手動加載模塊與內核編譯的取舍在絕大多數(shù)情況下Ubuntu自帶的官方內核已經(jīng)包含了上述所有模塊不需要額外安裝驅動。這也和Windows平臺不一樣——Windows上裝CH340驅動是常規(guī)操作但Linux上通常免驅因為驅動都在內核里了。不過有兩個例外情況需要手動介入。第一種情況是內核模塊雖然存在但因為某種原因沒有被自動加載。這時候手動modprobe即可。但要注意modprobe只能解決“模塊存在但未加載”的問題。如果模塊本身就不存在比如你用的內核是裁剪過的嵌入式板載系統(tǒng)、或者自己編譯內核時沒勾選USB串口支持那就需要重新編譯內核或者單獨編譯驅動模塊。第二種情況就是前面提到過的高通、瑞芯微等平臺方案中有些自定義USB轉串口芯片并不在標準內核驅動列表里這時候需要到廠商官網(wǎng)找驅動源碼自行編譯。比如某些國產開發(fā)板附帶的USB轉串口工具芯片是定制版CH340雖然VID還是1a86但PID可能不在驅動默認支持列表里這時候不能直接modprobe ch341而要在ch341.c源碼里把對應的PID添加進去重新編譯模塊。這里額外提一個編譯驅動的經(jīng)驗內核模塊編譯非常依賴內核頭文件版本編譯前一定要確保uname -r輸出的版本和/usr/src/linux-headers-$(uname -r)目錄存在且匹配。很多人在Ubuntu上編譯驅動失敗原因就是提前裝了linux-headers-generic但版本和當前內核不一致。3.3 權限與udev規(guī)則一次配到位前面提到的usermod -aG dialout是臨時解法換個電腦或換用戶又要重新設置。對于團隊共用開發(fā)機、或者頻繁插拔不同開發(fā)板的場景更推薦寫一條udev規(guī)則來固定設備權限和名稱。在/etc/udev/rules.d/下新建一個規(guī)則文件比如99-usb-serial.rules內容如下KERNELttyUSB[0-9]*, MODE0666保存后執(zhí)行$ sudo udevadm control --reload-rules $ sudo udevadm trigger這樣做的效果是所有ttyUSB設備節(jié)點權限自動變成666任何用戶都能直接讀寫不用每次sudo。但要注意這個規(guī)則沒有限制具體設備如果你電腦上同時插著多個USB轉串口設備它們都會獲得這個權限。如果你希望只對特定設備生效可以按VID過濾比如SUBSYSTEMtty, ATTRS{idVendor}1a86, ATTRS{idProduct}7523, MODE0666另外還可以用udev規(guī)則給設備創(chuàng)建一個固定別名。比如多個開發(fā)板同時插著ttyUSB0和ttyUSB1的順序可能隨插拔順序變化這對自動化腳本來說非常痛苦。通過udev規(guī)則根據(jù)設備序列號創(chuàng)建軟鏈接可以解決這個問題SUBSYSTEMtty, ATTRS{idVendor}1a86, ATTRS{serial}0001, SYMLINKttyBoardA, MODE0666之后在腳本里直接用/dev/ttyBoardA訪問再也不擔心節(jié)點漂移。4. 虛擬機、開發(fā)板端配置與進階坑點4.1 虛擬機USB直通的三個細節(jié)如果你的Ubuntu是跑在VMware或者VirtualBox里的虛擬機問題會多一層。虛擬機的USB直通有幾處容易踩坑的地方。第一確認虛擬機設置里USB控制器啟用了哪個版本。很多開發(fā)板是USB 2.0全速設備但虛擬機默認可能只開啟USB 3.0控制器導致設備識別異常。建議同時勾選USB 2.0和USB 3.0控制器。VMware Workstation里依次點擊“虛擬機設置”-“USB控制器”把“USB兼容性”設為USB 2.0甚至更低的兼容模式很多時候問題直接解決。第二插上板子后會彈窗問你是連接到主機還是連接到虛擬機一定要選虛擬機。如果不小心點了“連接到主機”那設備就被宿主機占用了。第三連接成功后在虛擬機里執(zhí)行l(wèi)susb確認設備是否在虛擬機內可見。如果lsusb里能看到設備但/dev下沒有節(jié)點回到前面第2節(jié)的驅動排查流程。如果lsusb里看不到多半是直通沒生效重新插拔USB線、或者重置一下虛擬機的USB控制器驅動多數(shù)能解決。4.2 開發(fā)板端的設備樹與串口節(jié)點這個問題排查到一定深度之后有些讀者可能會把“Ubuntu主機找不到ttyUSB”和“開發(fā)板啟動后串口沒有輸出”混為一談這兩個其實是完全不同的鏈路。前者是主機側的問題后者則涉及開發(fā)板端的設備樹Device Tree配置以及U-Boot的啟動參數(shù)。如果你是“開發(fā)板上電后串口終端完全無輸出”那需要檢查的是開發(fā)板端的設備樹文件里UART節(jié)點是否被正確使能以及U-Boot的console參數(shù)是否指向了正確的串口。比如i.MX6ULL這類板子U-Boot環(huán)境變量里的consolettymxc0,115200就對應著板子上的UART1。如果這個參數(shù)和實際接線不一致或者設備樹里該UART節(jié)點被disable那終端就什么都看不到。常見的一個坑是板卡廠商提供的設備樹文件配置完整但你自己改了設備樹之后UART節(jié)點引腳被復用成了GPIO導致串口物理上不通。排查方法很簡單恢復到出廠設備樹文件試一次能通就說明是你的配置問題慢慢對比差異即可。4.3 那些讓人崩潰的“假·串口”最后分享幾個我實際工作中遇到的“看似驅動沒問題但死活不出設備節(jié)點”的特殊場景給讀者提個醒。第一個是供電不足。有些開發(fā)板USB轉串口芯片的供電和板子主控共用板子功耗大、供電電流不夠的時候USB芯片會反復復位表現(xiàn)就是lsusb能看到設備一閃一閃的或者頻繁掉線。用外部電源給板子獨立供電往往能解決。第二個是劣質USB hub。帶供電的劣質hub在傳輸USB信號時可能會有電平畸變串口芯片偶爾能被枚舉到但dmesg里伴隨大量的usb 1-1: device descriptor read/64, error -110這類報錯。這種報錯高度疑似hub或者線材問題而不是驅動問題。直接把板子插到主機背后的USB口上繞開hub再試是最快的驗證方法。第三個是內核版本與芯片兼容性的問題。比如PL2303這顆老芯片內核從5.x開始對部分TA即早期版本芯片進行了更嚴格的校驗導致某些芯片被拒絕識別dmesg里會明確提示PL2303: unknown chip, please report。這屬于芯片本身的克隆問題無解只能換芯片。第四個是串口工具本身的問題。如果lsusb、dmesg、/dev節(jié)點全部正常但minicom或者串口助手打開后沒有任何反應檢查一下工具的波特率、數(shù)據(jù)位、停止位、流控配置是否匹配開發(fā)板的默認串口參數(shù)。很多開發(fā)板默認是115200/8N1但流控是否開啟要看具體板子有一些板子在出廠Bootloader階段會開啟硬件流控導致半雙工通信不正常。還有一個非常容易忽略的細節(jié)如果你用的是Windows和Ubuntu雙系統(tǒng)在Windows下安裝過廠商提供的驅動那么重啟到Ubuntu后某些國產USB轉串口芯片會殘留D2XX驅動模式FTDI的D2XX模式就經(jīng)常這樣。這種模式下芯片不會注冊為ttyUSB設備。解決辦法是把芯片切回VCP模式通常需要用到廠商的配置工具或者在Windows下卸載驅動后重新在Ubuntu里插拔。這些年遇到類似問題的板子不少提醒讀者留意。在我實際調試過的項目里大概有七成“找不到設備文件”的情況是出在物理鏈路或者權限配置上真正的驅動缺失反而少見。所以排查的時候建議按照本文的順序來先看lsusb確認USB枚舉再看dmesg確認驅動加載最后檢查/dev節(jié)點權限。一步一步來不要第一步就鉆進驅動源碼里出不來了。