前陣子把一塊 7 寸串口觸摸屏接到 ARM Linux 主板上時我以為這個活半小時就能搞定。畢竟板子內(nèi)核里已經(jīng)帶了 8250 串口驅(qū)動屏幕模塊自己也有觸摸功能接上 UART 之后無非就是在應(yīng)用層發(fā)指令、讀坐標(biāo)。結(jié)果真正調(diào)起來才發(fā)現(xiàn)Linux 下做串口屏和單片機(jī)上完全是兩碼事。設(shè)備樹里串口引腳的 pinctrl 沒配好觸摸坐標(biāo)上報到 Linux 輸入子系統(tǒng)之后的映射關(guān)系也是錯的跑一會兒還會丟字節(jié)。折騰了兩三天最后問題基本都在內(nèi)核配置和輸入子系統(tǒng)接入方式上反而屏幕本身沒出什么幺蛾子。這次就把我做 Linux 串口觸摸屏的完整設(shè)計和排錯過程總結(jié)一下給后面要做類似方案的朋友一個參考。主題圍繞 Linux 內(nèi)核如何正確支持串口屏、串口觸摸數(shù)據(jù)怎么變成標(biāo)準(zhǔn) Linux 輸入事件以及這個過程中容易踩到的各種坑。1. 串口屏項目的技術(shù)邊界Linux下不是“接上就能用”1.1 串口屏與普通LCD的本質(zhì)差異很多人剛接觸串口屏?xí)r會有一個思維慣性覺得屏幕就是顯示設(shè)備要么走 HDMI、要么走 RGB/MIPI最多再加個 I2C 觸摸芯片。但串口屏的原理完全不同。它本身就是一塊帶 MCU 的獨立顯示模組內(nèi)部有自己的顯存、字庫和控件庫主控只需要通過串口發(fā)一條“顯示一張圖”“設(shè)置某個文本控件”之類的指令剩下的渲染工作全部在屏幕內(nèi)部完成。這帶來一個非常大的好處Linux 側(cè)不需要維護(hù) framebuffer也不需要關(guān)心分辨率、刷新率、圖層疊加這些復(fù)雜功能。整個過程看起來就是“打開一個串口設(shè)備往里寫指令再讀取返回”。但也正因為如此Linux 內(nèi)核側(cè)的工作邊界變得很微妙。你不需要去寫一個 LCD 控制器驅(qū)動但你必須保證串口設(shè)備穩(wěn)定可用、數(shù)據(jù)不丟、觸摸事件能進(jìn)入 Linux 標(biāo)準(zhǔn)的輸入子系統(tǒng)。否則就會出現(xiàn)“屏幕顯示正常但觸摸點了沒反應(yīng)”這種最尷尬的局面。1.2 Linux側(cè)要解決的三層問題接串口屏?xí)r我習(xí)慣把問題拆成三層來看。第一層是硬件載體層。串口屏一般走 TTL 電平的 UART少數(shù)工業(yè)場景會轉(zhuǎn) RS232 或者 RS485。這一層要做的事情包括確認(rèn) SoC 的 UART 引腳是否被其他外設(shè)占用、設(shè)備樹里的串口節(jié)點是否使能、波特率和校驗位是否和屏幕一致。內(nèi)核側(cè)主要涉及 pinctrl、串口驅(qū)動、設(shè)備樹 aliases。第二層是數(shù)據(jù)通道層。串口屏的通訊協(xié)議通常是一幀一幀的里面可能有幀頭、命令字、長度、負(fù)載、校驗和、幀尾。Linux 的read()是流式讀取不保證一次拿到完整的一幀所以需要一個狀態(tài)機(jī)或者緩沖機(jī)制來拼包。這一層可以在用戶態(tài)做也可以寫一個內(nèi)核模塊做 line discipline。第三層是輸入事件層。這是 Linux 串口屏和單片機(jī)串口屏最大的區(qū)別。單片機(jī)可以直接把觸摸坐標(biāo)拿去用但 Linux 下各種圖形框架Qt、GTK、Flutter默認(rèn)從/dev/input/eventX讀取輸入事件所以串口屏上報的觸摸數(shù)據(jù)必須轉(zhuǎn)換成標(biāo)準(zhǔn)的input_event結(jié)構(gòu)。要么通過 uinput 從用戶態(tài)注入要么在內(nèi)核里注冊一個 input device 驅(qū)動。這三層只要有一層沒做對整個系統(tǒng)用起來就會很別扭。2. 內(nèi)核側(cè)支持串口屏UART設(shè)備樹、驅(qū)動與DMA配置2.1 先讓tty節(jié)點穩(wěn)定可用的關(guān)鍵配置內(nèi)核對串口屏的支持核心其實就是“把串口這個基礎(chǔ)外設(shè)整利索”。以 ARM Linux 上常用的設(shè)備樹為例一個串口節(jié)點往往要打開兩樣?xùn)|西status okay和對應(yīng)的pinctrl。uart3 { pinctrl-0 uart3_tx_pins uart3_rx_pins; pinctrl-names default; status okay; };看起來簡單但實際板卡上會有很多隱性沖突。最常見的是這個串口被內(nèi)核 console 占用了。很多 BSP 默認(rèn)把consolettyS0,115200寫在內(nèi)核啟動參數(shù)里而ttyS0恰好就是要接串口屏的串口。這時候即使你的應(yīng)用能打開/dev/ttyS0內(nèi)核日志也會時不時地往這個串口上吐數(shù)據(jù)屏幕就會間歇性亂碼。解決方式有三個換一個不沖突的串口節(jié)點比如把串口屏接到ttyS1。修改console啟動參數(shù)讓內(nèi)核日志輸出到別的串口。用earlycon或者獨立調(diào)試串口把普通串口完全釋放給業(yè)務(wù)。另一個我踩過的坑是設(shè)備樹里串口的時鐘和別名。有些平臺需要配置clocks屬性否則串口波特率計算會偏差很大例如 115200 實際跑出來是 110000 左右屏幕端就會一直亂碼。調(diào)試時可以先在內(nèi)核 dmesg 里看串口驅(qū)動的初始化信息確認(rèn)最終的波特率分頻系數(shù)是否符合預(yù)期。2.2 串口驅(qū)動選型與調(diào)度依賴Linux 下最常見的串口驅(qū)動是 8250 系列和 PL011 系列。8250 通常對應(yīng)兼容 16550A 的 UART很多 x86 板卡和部分 ARM SoC 都走這一套PL011 則是 ARM 平臺常見的驅(qū)動比如樹莓派和一些基于 AMBA 總線的 SoC。這兩個驅(qū)動在內(nèi)核 config 里的選項不一樣CONFIG_SERIAL_8250y CONFIG_SERIAL_8250_CONSOLEy CONFIG_SERIAL_AMBA_PL011y CONFIG_SERIAL_AMBA_PL011_CONSOLEy如果裁剪內(nèi)核的時候漏掉了對應(yīng)選項系統(tǒng)可能連/dev/ttyS0或/dev/ttyAMA0都不會出現(xiàn)。檢查的時候不要光看有沒有這個設(shè)備節(jié)點還要確認(rèn)驅(qū)動有沒有真正 probe 成功。串口屏對實時性的要求其實不高但觸摸體驗對“連續(xù)上報”很敏感。如果系統(tǒng)負(fù)載高用戶態(tài)讀串口的線程被調(diào)度器長時間掛起觸摸事件就會一陣一陣地卡。比較好的做法是把讀取線程設(shè)置成高優(yōu)先級實時線程或者用poll/select加超時的阻塞式讀取不要用忙等循環(huán)。Linux 的串口驅(qū)動內(nèi)部有等待隊列機(jī)制poll會在數(shù)據(jù)到達(dá)時喚醒進(jìn)程這對觸摸讀取已經(jīng)足夠。2.3 DMA/FIFO的取舍與實測效果內(nèi)核里的串口驅(qū)動為了降低中斷頻率一般都會打開 FIFO常見 16550A 的 FIFO 是 64 字節(jié)。但串口屏的數(shù)據(jù)量其實很小觸摸坐標(biāo)動靜也就幾十個字節(jié)顯示指令一般也不會超過幾百字節(jié)所以 FIFO 溢出風(fēng)險并不高。另外很多 BSP 會默認(rèn)給串口打開 DMA 支持。DMA 能夠把數(shù)據(jù)從 UART FIFO 搬到內(nèi)存減少 CPU 中斷但在某些平臺上反而會帶來問題DMA 描述符分配失敗、緩存一致性問題、或者 DMA 通道和別的驅(qū)動沖突。實際測試下來如果只是接一塊串口觸摸屏關(guān)閉 DMA 讓數(shù)據(jù)走傳統(tǒng)中斷FIFO系統(tǒng)更穩(wěn)。關(guān)閉方式因平臺而異有一些是在設(shè)備樹里配置dmas屬性為空或去掉dma-names有些是內(nèi)核 config 里關(guān)閉CONFIG_SERIAL_8250_DMA。關(guān)鍵判斷依據(jù)是看實測是否丟字節(jié)。我曾經(jīng)遇到一個平臺開著 DMA 時串口屏的觸摸坐標(biāo)偶爾多出幾個 FF 字節(jié)關(guān)了 DMA 之后連續(xù)點了半個小時都沒出現(xiàn)異常。這種問題排查起來很耗費時間不如一開始就按“數(shù)據(jù)量小就關(guān) DMA”的原則處理。3. 串口協(xié)議解析策略內(nèi)核處理還是用戶態(tài)處理3.1 串口屏通信數(shù)據(jù)幀的基本模樣串口屏品牌很多協(xié)議也各不相同但常見協(xié)議的結(jié)構(gòu)往往差不太多。拿市面上主流的幾類串口屏來說發(fā)送指令一般是“幀頭 命令 參數(shù) 幀尾”觸摸上報則是“幀頭 觸摸狀態(tài) X坐標(biāo) Y坐標(biāo) 幀尾”。假設(shè)某串口屏的觸摸包格式是這樣0xAA 0x01 0x00 0x80 0x01 0x2C 0x00 0xFF 0xFF 0xFF其中0xAA是幀頭0x01表示觸摸按下后面0x0080是 X 坐標(biāo)大端0x012C是 Y 坐標(biāo)0xFF 0xFF 0xFF是結(jié)束標(biāo)志。不同品牌會有不同設(shè)計有的用長度字段有的用 CRC16 校驗有的用累加和校驗。解析時務(wù)必先看明白兩個問題這條協(xié)議是定長的還是變長的有沒有校驗字段定長協(xié)議解析最簡單每次讀到固定字節(jié)數(shù)就能處理變長協(xié)議需要根據(jù)長度字段來循環(huán)讀。校驗字段也不能忽略工業(yè)環(huán)境下的串口線經(jīng)常會受干擾沒有校驗的協(xié)議很容易出現(xiàn)“觸摸亂跳”。3.2 兩種解析路線的對比這里有一個經(jīng)常被問到的選擇串口協(xié)議解析到底放在內(nèi)核里還是用戶態(tài)我的回答是默認(rèn)放用戶態(tài)。理由有三個調(diào)試方便。用戶態(tài)程序可以隨便printf可以用腳本模擬串口屏回包不用反復(fù)重新編譯內(nèi)核。協(xié)議迭代快。串口屏廠商偶爾會出固件升級波協(xié)議微調(diào)用戶態(tài)改起來成本低。內(nèi)核社區(qū)不建議在驅(qū)動里維護(hù)業(yè)務(wù)協(xié)議。內(nèi)核自帶的大量串口驅(qū)動只負(fù)責(zé)數(shù)據(jù)搬運(yùn)不解析業(yè)務(wù)幀。但有一種情況我會考慮寫內(nèi)核模塊屏幕觸摸事件需要參與系統(tǒng)的休眠喚醒策略。比如系統(tǒng)休眠后串口屏來觸摸事件要喚醒系統(tǒng)這時候用戶態(tài)進(jìn)程已經(jīng)被凍結(jié)無法及時處理就必須在中斷/驅(qū)動層做事件檢測。另一個場景是觸摸數(shù)據(jù)量極大用戶態(tài) read 已經(jīng)成了性能瓶頸雖然這種情況在串口屏項目里很少出現(xiàn)。同時也要提醒一點有一些想“玩得高級”的人會試圖動態(tài) hook tty 設(shè)備的file_operations攔截read和write來實現(xiàn)串口數(shù)據(jù)過濾甚至透明加密。這種思路確實能解決問題但風(fēng)險很高。內(nèi)核里隨便替換file_operations很容易造成引用計數(shù)混亂而且不同內(nèi)核版本的tty_operations結(jié)構(gòu)體定義不一致升級一次內(nèi)核就要重新適配。與其這樣還不如正兒八經(jīng)注冊一個 line discipline把串口數(shù)據(jù)流在鏈路層做自定義處理。3.3 粘包、斷包與狀態(tài)機(jī)解析串口本身是字節(jié)流不是“一包一包”的。用戶態(tài)調(diào)用read()時有可能一次拿到半包數(shù)據(jù)也有可能一次拿到兩包數(shù)據(jù)。這就叫斷包和粘包。很多初次做串口屏的人吃了這個虧——以為read()返回多少字節(jié)就是完整的一幀結(jié)果發(fā)現(xiàn)坐標(biāo)偶爾錯亂。正確做法是引入一個簡單的狀態(tài)機(jī)逐字節(jié)處理enum parse_state { ST_IDLE, ST_HEAD, ST_CMD, ST_LEN, ST_DATA, ST_TAIL }; for (size_t i 0; i len; i) { switch (state) { case ST_IDLE: if (buf[i] FRAME_HEAD) state ST_HEAD; break; case ST_HEAD: if (buf[i] FRAME_HEAD) // 連續(xù)兩個幀頭按協(xié)議處理 continue; cmd buf[i]; state ST_CMD; break; // ... 其余狀態(tài)處理 } }另外還需要一個超時機(jī)制。如果收到半個包之后就再也沒有后續(xù)字節(jié)一定要在超時后復(fù)位狀態(tài)機(jī)否則下一個幀頭到來之前會一直卡在中間狀態(tài)。這個超時的經(jīng)驗值一般取“若干個字節(jié)間隔”串口波特率 115200 時5~10ms 超時就已經(jīng)足夠。解析完成之后還可以順便在/proc或/sys下導(dǎo)出一些統(tǒng)計信息比如收了多少幀、校驗錯誤多少次、解析成功多少次。這樣在客戶現(xiàn)場出了問題時能快速判斷是協(xié)議解析問題還是電磁干擾問題。4. 從觸摸數(shù)據(jù)到標(biāo)準(zhǔn)input事件串口觸摸屏接入Linux輸入子系統(tǒng)4.1 evdev/input子系統(tǒng)的基礎(chǔ)Linux 下幾乎所有輸入設(shè)備——鍵盤、鼠標(biāo)、觸摸屏、遙控器——最終都會通過 input 子系統(tǒng)向上層報事件。用戶空間的圖形庫經(jīng)常監(jiān)聽/dev/input/eventXevdev就是這一層的內(nèi)核驅(qū)動。串口屏的觸摸功能要跟 Linux 生態(tài)無縫配合就得把坐標(biāo)上報到 evdev。接入方式有兩種用戶態(tài)通過 uinput 模擬輸入設(shè)備或者內(nèi)核態(tài)寫一個 input driver。uinput 的優(yōu)點是極其靈活int fd open(/dev/uinput, O_WRONLY | O_NONBLOCK); ioctl(fd, UI_SET_EVBIT, EV_KEY); ioctl(fd, UI_SET_KEYBIT, BTN_TOUCH); ioctl(fd, UI_SET_EVBIT, EV_ABS); ioctl(fd, UI_SET_ABSBIT, ABS_X); ioctl(fd, UI_SET_ABSBIT, ABS_Y); ioctl(fd, UI_DEV_CREATE); struct input_event ev {0}; ev.type EV_ABS; ev.code ABS_X; ev.value x; write(fd, ev, sizeof(ev)); ev.type EV_SYN; ev.code SYN_REPORT; ev.value 0; write(fd, ev, sizeof(ev));用 uinput 時核心邏輯就是解析串口幀 → 算出真實坐標(biāo) → 寫一個input_event→ 發(fā)送SYN_REPORT。這個鏈路非常清晰而且不用改內(nèi)核、不用重新編譯設(shè)備樹適合大多數(shù)商業(yè)項目。內(nèi)核態(tài)的 input driver 適合對延遲極其敏感、或者需要深度休眠喚醒的場景。實現(xiàn)上大致是注冊一個input_allocate_device()創(chuàng)建的設(shè)備設(shè)置好ABS_X/ABS_Y的最小值和最大值然后在一個內(nèi)核線程或中斷上下文里調(diào)input_report_abs()和input_sync()。這種方法要求你對內(nèi)核模塊開發(fā)有足夠的把握否則一個空指針就能讓整個系統(tǒng) panic。4.2 坐標(biāo)換算與校準(zhǔn)串口屏返回的坐標(biāo)值取決于屏幕內(nèi)部觸摸面板的 ADC 采樣范圍。有些屏幕的 X 范圍是 0~4095有些是 0~1023Y 范圍也可能和屏幕分辨率不是嚴(yán)格對應(yīng)。但 Linux 輸入子系統(tǒng)上報的坐標(biāo)范圍必須是設(shè)備描述里聲明的absmax否則用戶態(tài)拿到之后還要二次換算。通常做法是把串口屏上報的原始值線性映射到屏幕的實際分辨率linux_x (raw_x - x_min) * (screen_width - 1) / (x_max - x_min) linux_y (raw_y - y_min) * (screen_height - 1) / (y_max - y_min)這里最容易忽略的一點是觸摸面板的零點方向。有些屏幕的 X 坐標(biāo)從左往右增加有些卻是反的Y 軸也是一樣。如果映射之后觸摸點和顯示點仍然是鏡像的就要對坐標(biāo)做反轉(zhuǎn)。校準(zhǔn)也不能只做一次。實際項目里屏幕可能被更換、屏幕玻璃面板存在裝配誤差、或者貼了不同厚度的保護(hù)膜都會導(dǎo)致觸摸坐標(biāo)漂移。Linux 桌面環(huán)境一般用 libinput 的校準(zhǔn)矩陣嵌入式 Qt 環(huán)境可以用 tslib 的ts_calibrate生成校準(zhǔn)參數(shù)按映射公式寫進(jìn)應(yīng)用配置即可。經(jīng)驗上在顯示畫面正確的前提下先用evtest查看上報值再用一個小畫布程序驗證“按下位置和光標(biāo)位置”是否一致是最快的校準(zhǔn)方法。4.3 多點觸摸和按鍵組合上報常見串口屏里帶多點觸摸的型號也不在少數(shù)。Linux 內(nèi)部對多點觸摸使用 MT 協(xié)議Type B 是比較主流的實現(xiàn)方式需要用到input_mt_slot和input_mt_report_slot_state。假設(shè)屏幕支持兩個觸摸點上報邏輯大概是input_mt_slot(dev, 0); input_mt_report_slot_state(dev, MT_TOOL_FINGER, true); input_report_abs(dev, ABS_MT_POSITION_X, x0); input_report_abs(dev, ABS_MT_POSITION_Y, y0); input_mt_slot(dev, 1); input_mt_report_slot_state(dev, MT_TOOL_FINGER, true); input_report_abs(dev, ABS_MT_POSITION_X, x1); input_report_abs(dev, ABS_MT_POSITION_Y, y1); input_mt_report_slot_state(dev, MT_TOOL_FINGER, false); input_sync(dev);注意協(xié)議解析層要怎么區(qū)分“多點”與“單點”。很多串口屏的觸摸協(xié)議在單點觸摸和多點觸摸下走的是不同的命令字不能混用。如果協(xié)議文檔不夠詳細(xì)可以在屏幕上放兩個手指慢慢移動直接打印收到的十六進(jìn)制原始數(shù)據(jù)來反推。還有一類串口屏是做“控件跳轉(zhuǎn)”的屏幕上的按鈕會主動上報“按鍵編號”而不是絕對坐標(biāo)。這種場景下更簡單——直接把按鍵編號映射成EV_KEY事件交給上層應(yīng)用處理。但要注意區(qū)分觸摸類是單擊還是長按否則上層會收到一大批重復(fù)按鍵事件。5. 實測中的問題清單亂碼、丟幀、漂移與開機(jī)時序5.1 亂碼和串口參數(shù)不一致亂碼是最容易定位、也最常見的問題。大部分串口屏出廠默認(rèn)波特率是 9600 或者 115200如果你的應(yīng)用stty設(shè)置成了 57600或者內(nèi)核 console 啟動參數(shù)里用了別的串口參數(shù)就會出現(xiàn)一堆亂碼。排錯時先做三件事stty -F /dev/ttyS3 115200 raw -echo cat /dev/ttyS3第一確認(rèn)內(nèi)核啟動階段沒有往這個串口打印日志第二確認(rèn)上位機(jī)的波特率和屏幕固件一致第三確認(rèn)串口電平匹配。TTL 串口屏接 RS232 電平轉(zhuǎn)換器或者在相反方向接板載 RS232 口都會出現(xiàn)不穩(wěn)定亂碼。這里再順便提一個容易忽略的校驗位問題。很多串口屏默認(rèn)是8N1也就是 8 個數(shù)據(jù)位、無校驗、1 個停止位。但用老款迪文屏或某些工業(yè)屏?xí)r可能會是8E1或8O1。如果應(yīng)用層一直用 8N1 去讀偶校驗的屏幕偶爾能收到正確數(shù)據(jù)但整體上是隔三差五亂碼。5.2 丟幀與緩沖區(qū)配置“丟幀”從表面看是觸摸卡頓、指令沒反應(yīng)但底層原因往往在 Linux 的數(shù)據(jù)鏈路里。一個常見原因是用戶態(tài)讀取線程被高負(fù)載任務(wù)拖住串口接收緩沖區(qū)溢出后新來的數(shù)據(jù)被丟棄。Linux tty 驅(qū)動本身有接收緩沖區(qū)但默認(rèn)大小有限。如果你確定某路串口數(shù)據(jù)量比較大或者讀取線程確實響應(yīng)不及時可以嘗試調(diào)大 tty 的 flip buffer 或者使用TIOCVHANGUP清理緩沖。更常見的做法是提高讀取線程優(yōu)先級struct sched_param param { .sched_priority 50 }; pthread_setschedparam(thread_id, SCHED_FIFO, param);如果平臺支持把當(dāng)前線程綁到和 UART 中斷親和性一致的 CPU 核上也能減少調(diào)度延遲。另外一個容易造成“數(shù)據(jù)看起來丟了”的原因是 DMA 未配置好卻開著 DMA。DMA 描述符不夠時UART 收到的數(shù)據(jù)沒有及時搬到內(nèi)存硬件 FIFO 一旦溢出就會丟字節(jié)。遇到這種情況直接看/proc/interrupts里對應(yīng)串口的中斷計數(shù)增長是否正常和dmesg里有沒有報DMA timeout之類的錯誤。5.3 觸摸漂移與坐標(biāo)零點錯誤觸摸漂移最典型的癥狀是“點擊屏幕右上角光標(biāo)卻出現(xiàn)在左上角附近”。除了第 4 章說的坐標(biāo)映射和零點方向問題之外還有一種漂移是“越往邊緣越偏”這通常說明屏幕觸摸面板本身不是線性的。很多串口屏支持在屏幕內(nèi)部做觸摸校準(zhǔn)你可以在屏的工程配置里手動校準(zhǔn)一次之后再往 Linux 側(cè)輸出坐標(biāo)。這種二次校準(zhǔn)的效果往往比純線性映射更準(zhǔn)因為屏幕內(nèi)部的校準(zhǔn)固件能修正非線性誤差。如果換了不同批次、不同尺寸的串口屏校準(zhǔn)參數(shù)務(wù)必要重新做一遍。不要為了圖省事把上一塊屏的校準(zhǔn)文件直接拷貝到新設(shè)備里尤其是從老型號屏幕換到新型號屏幕時坐標(biāo)范圍可能完全不一樣。5.4 上電時序與串口屏的“假故障”最后說一下上電時序。很多工控板是 Linux 系統(tǒng)和串口屏同時上電串口屏內(nèi)部 MCU 啟動可能需要幾百毫秒甚至一秒而 Linux 用戶態(tài)程序可能更早地嘗試向串口屏發(fā)初始化指令。這時候屏幕還沒就緒程序等不到應(yīng)答就會誤判為“串口屏壞了”。解決方式是加一個初始化握手機(jī)制。程序打開串口節(jié)點后不急著發(fā)業(yè)務(wù)數(shù)據(jù)先發(fā)送一條查詢指令等待屏幕返回確定應(yīng)答連續(xù)重試幾次都失敗才報錯。同樣如果系統(tǒng)里有獨立看門狗喂狗線程應(yīng)該和串口讀取線程分開。因為讀串口偶爾會阻塞如果讓同一個線程既讀串口又喂狗一旦串口屏瞬時無響應(yīng)看門狗可能先超時復(fù)位整個系統(tǒng)造成更嚴(yán)重的問題。6. 選型與工程落地建議從STM32到Linux的遷移經(jīng)驗6.1 串口屏品牌選型時的內(nèi)核視角市面上常見的串口屏品牌比如淘晶馳、迪文、大彩都有各自的開發(fā)生態(tài)。選型時除了看屏幕分辨率、色深、UI 組態(tài)軟件好不好用之外還要特別關(guān)注兩點。第一串口協(xié)議是否公開、文檔是否完整。有的屏幕協(xié)議只在廠商的組態(tài)軟件里封裝不提供公開指令表這種就很難在 Linux 下穩(wěn)定擴(kuò)展。第二觸摸上報是否走同一路串口。有些屏幕支持觸摸數(shù)據(jù)通過單獨引腳輸出有些必須和顯示指令共用同一路 UART這會直接影響你的串口資源配置。另外新舊型號切換也要留個心眼。某些品牌的老型號屏幕固件和新型號使用不同的協(xié)議格式代碼里最好不要把協(xié)議解析寫死在業(yè)務(wù)邏輯里而是單獨抽象一層方便后面換屏?xí)r只改協(xié)議適配。6.2 內(nèi)核裁剪與系統(tǒng)打包時的注意事項如果產(chǎn)品要量產(chǎn)內(nèi)核裁剪是繞不開的一步。裁剪時最容易犯的錯誤就是把“看起來沒用”的輸入子系統(tǒng)給裁掉了。串口屏雖然不走 I2C 觸摸芯片但它一旦通過 uinput 注入輸入事件就需要CONFIG_INPUT_UINPUT上層圖形庫讀取觸摸點則需要CONFIG_INPUT_EVDEV。CONFIG_INPUTy CONFIG_INPUT_EVDEVy CONFIG_INPUT_UINPUTy CONFIG_SERIAL_8250y CONFIG_SERIAL_COREy這幾個選項建議直接編進(jìn)內(nèi)核而不是編譯成模塊否則系統(tǒng)啟動時如果沒有提前insmod/dev/input目錄下就會少設(shè)備節(jié)點。同時還要注意 udev 規(guī)則。串口屏設(shè)備節(jié)點權(quán)限如果不做處理普通用戶態(tài)程序可能打不開/dev/ttySx。在開發(fā)板階段直接跑 root 可能沒感覺到了產(chǎn)品要做降權(quán)運(yùn)行時節(jié)點權(quán)限就會變成一個問題。KERNELttyS[0-9]*, MODE0660, GROUPdialout KERNELuinput, MODE0660, GROUPinput6.3 和裸機(jī)開發(fā)不同的幾個思維轉(zhuǎn)變從 STM32 裸機(jī)方案遷移到 Linux最大的差異是多任務(wù)環(huán)境。裸機(jī)里你可以寫一個while(1)循環(huán)原地等待串口數(shù)據(jù)完全可控但在 Linux 里會有藍(lán)牙、WiFi、看門狗、業(yè)務(wù)線程等一大堆進(jìn)程搶 CPU 和中斷資源串口讀取線程必須用阻塞式 IO 加超時而不是忙等。另一個差異是調(diào)試方式。裸機(jī)可以直接用 JTAG 打斷點看寄存器Linux 下判斷串口問題就應(yīng)該先用evtest、stty、dmesg、/proc/tty/driver/serial這些工具和接口做快速定位而不是一上來就改內(nèi)核代碼。串口屏項目里絕大多數(shù)問題都出在配置不在驅(qū)動本身。最后分享一個小經(jīng)驗如果串口屏在開發(fā)板上工作正常換到量產(chǎn)主板上出現(xiàn)觸摸漂移或亂碼先別急著懷疑代碼優(yōu)先檢查主板串口電平參考電壓和信號完整性。很多小批量主板會把 UART 走線拉得太長又沒加 ESD 防護(hù)和上拉電阻干擾引起的丟幀比軟件問題更難查。在硬件端正、協(xié)議解析正確的基礎(chǔ)上內(nèi)核和用戶態(tài)的配置只要按我前面說的幾個原則去處理這套方案基本能穩(wěn)定跑很久。