但凡用Pico做過一點點嵌入式開發(fā)串口通信都是繞不開的能力。打印調試日志要串口接GPS模塊要串口讓PC和單片機之間互相對話最直接的方式還是串口。我最早接觸Pico時以為串口就是兩根線把TX和RX一連、收發(fā)數據就完事了實際折騰起來才發(fā)現電平標準、引腳映射、波特率、REPL占用、調試工具選擇任何一個環(huán)節(jié)沒弄明白數據就是出不來而且你根本不知道問題卡在哪一步。這篇內容是我把樹莓派Pico串口通信從硬件特性到MicroPython編程再到調試工具完整梳理之后的總結目的就是讓你少走我走過的彎路。不管你是想讓Pico往PC發(fā)一行日志還是想實現PC與Pico之間的雙向指令控制又或者是用串口讀取傳感器數據這篇文章都盡量給你最直接的做法和避坑清單。內容不挑基礎剛拿到板子的小白可以照著接線調用例已經有經驗的開發(fā)者也能在部分細節(jié)里找到被忽略的坑。1. Pico串口通信的整體認知它解決什么問題1.1 串口在Pico開發(fā)中的真實地位樹莓派Pico用的是RP2040芯片雙核Cortex-M0頻率可以跑到133MHz兩塊錢的U盤大小價格卻只要十幾塊錢可以說是近幾年最熱門的低成本MCU開發(fā)板。但很多初學者拿到板子之后第一步接觸的往往是點燈第二步是MicroPython交互第三步就發(fā)現想跟電腦、傳感器、其他單片機互相傳數據繞不開UART串口通信。串口通信在嵌入式系統(tǒng)里有個特別樸素的外號叫“調試者的嘴”。單片機出了故障、傳感器讀不到數據、外設沒初始化成功這些東西在沒有屏幕和網絡的情況下怎么知道內部發(fā)生了什么答案就是通過串口把狀態(tài)打印出來連到電腦上看。Pico同樣如此而且因為Pico的硬件資源相對簡單串口往往是性價比最高的通信途徑不需要額外協議棧不需要網線兩根線加上公共地就能通信尤其是與PC上的串口調試軟件配合時可以說零門檻。1.2 串口通信適合哪些場景從我實際用下來的情況看Pico串口通信主要在三個場景里出現第一個是程序日志輸出。固件跑起來后把關鍵變量、運行狀態(tài)通過串口持續(xù)發(fā)出來PC端用串口調試助手查看相當于給MCU裝了塊“屏幕”。第二個是設備交互控制。PC發(fā)送指令Pico解析后執(zhí)行動作比如控制舵機、點亮LED、啟動某個任務這種一對一的主從模式非常適合串口。第三個是連接外部串口設備比如GPS模塊、藍牙串口透傳模塊、RS485傳感器等這些設備多數以UART為對外接口Pico只需要把對應的TX、RX接好就能解析數據。適合參考這篇內容的人我總結下來大概分三類剛入門Pico但搞不清GPIO上哪根是TX/RX的初學者已經在MicroPython里寫過循環(huán)點燈但沒系統(tǒng)性處理過串口收發(fā)的人以及想用串口做PC與Pico通訊但被波特率、補碼、緩沖區(qū)這些細節(jié)卡住的經驗開發(fā)者。2. Pico串口硬件特性拆解先搞清RP2040給了什么2.1 RP2040的UART外設與引腳映射很多朋友可能習慣了STM32或者51單片機的串口配置方式芯片上有幾個UART引腳基本固定想換引腳還要查重映射表。RP2040在這方面稍微人性化一些但也因為靈活第一次接觸容易懵。RP2040內部一共有兩個UART外設官方叫UART0和UART1。每個UART都是完整獨立的可以同時工作互不干擾。關鍵是它們的引腳不是寫死的而是可以映射到多個GPIO上也就是說你可以根據布線需要靈活選擇一個最方便的位置。從我整理的官方數據來看UART0和UART1的引腳映射關系如下UART外設可選TX引腳可選RX引腳UART0GP0、GP12、GP16GP1、GP13、GP17UART1GP4、GP8、GP20GP5、GP9、GP21這個表格非常重要建議直接存下來。因為在實際項目中GP0和GP1有時候會被其他功能占用比如I2C、SPI、PWM等這時候就可以改用其他引腳組合。我在一個項目里就把UART1映射到了GP8和GP9因為GP4和GP5正好被I2C占用了。如果不是RP2040這種靈活的映射機制這種沖突處理起來要麻煩得多。需要注意一個細節(jié)UART0和UART1提供的可選引腳是獨立的但同一個GPIO不能同時給兩個UART用也不能讓一個UART的TX和RX映射到同一個不可用的沖突引腳上。MicroPython在初始化UART的時候會做引腳占用檢查如果引腳已經被復用會直接報錯。所以在畫PCB或者用杜邦線連接時最好先規(guī)劃好整個板子的引腳資源。2.2 電平標準、接線規(guī)范與外圍電路Pico的UART接口電平是3.3V TTL這個必須牢記。也就是說TX引腳在空閑時輸出3.3V高電平發(fā)送數據時在0V和3.3V之間跳變。和Pico直接對接的設備比如USB轉TTL模塊、GPS模塊、藍牙串口模塊電平標準也必須是3.3V或者兼容3.3V。最常見的坑是把3.3V的UART直接接到5V的串口設備上。比如有些老式傳感器模塊或者5V Arduino開發(fā)板的串口是5V TTL電平如果直接和Pico的GPIO相連輕則通信不穩(wěn)定重則燒壞Pico引腳。解決辦法是用邏輯電平轉換模塊或者選擇帶3.3V輸出的USB轉TTL模塊。接線規(guī)則其實非常固定我每次接的時候都會默念三遍TX接RX、RX接TX、GND要與共地。也就是說Pico的TX要接到對端設備的RXPico的RX要接到對端設備的TX兩邊GND必須連在一起。很多新手第一次調串口兩根數據線接好了但沒共地結果數據完全亂碼或者干脆沒反應這就是因為TTL信號需要共地作為電壓參考基準。另外串口線盡量短一些特別是在115200甚至更高波特率下。線太長、線材質量差、或者裸露杜邦線在桌面上扭來扭去都會引入干擾。我以前用一根30cm的杜邦線跑1M波特率偶爾就會出現錯誤字節(jié)后來把線縮短到10cm以內問題就沒再出現過。2.3 物理UART和USB CDC串口的本質區(qū)別這個點我覺得必須單獨拿出來講因為太多人在這一步迷惑了。樹莓派Pico板子上只有一個MicroUSB口把它插到電腦上設備管理器里會出現一個COM口。很多教程告訴你“打開串口助手連上這個COM口”于是你以為UART通信已經在工作了。實際上這個COM口是RP2040內部USB控制器虛擬出來的CDC串口走的完全是USB協議和GPIO上的物理UART沒有關系。物理UART是RP2040內部的外設通過GPIO引腳如GP0、GP1輸出信號需要外接USB轉TTL模塊才能在電腦上看到對應的COM口。USB CDC則是芯片直接和PC通過USB線通信在PC上模擬出一個COM口不需要額外的芯片但信號走的是USB線。怎么區(qū)分自己接的是哪種串口呢很簡單如果你只是用一根USB線把Pico和電腦連起來那打開的是USB CDC串口如果你用USB轉TTL模塊接Pico的GP0和GP1再通過USB線把模塊連到電腦那打開的是物理UART對應串口。MicroPython的REPL默認就是走USB CDC的所以你會看到Thonny可以連上但物理UART上其實沒有任何數據。理清這一點之后很多問題就迎刃而解了。比如有人在USB CDC串口里發(fā)數據卻發(fā)現GP0上什么都沒有輸出這是因為走的是兩條完全不同的通道。我做PC與Pico串口通信時一般更愿意用物理UART加USB轉TTL模塊原因后面在調試工具章節(jié)再展開。3. MicroPython下的UART編程實操3.1 開發(fā)環(huán)境與固件準備Pico下玩串口首選的開發(fā)環(huán)境還是MicroPython。理由很直接Python語法簡單調試方便REPL可以實時執(zhí)行不需要交叉編譯。你只需要去樹莓派官方或MicroPython官網下載對應Pico的UF2固件按住板子上的BOOTSEL按鈕把板子插到電腦會出現一個名為RPI-RP2的U盤把UF2文件拖進去板子會自動重啟并進入MicroPython模式。之后用Thonny或者mpremote連接板子就可以寫Python腳本了。我個人的習慣是寫一個main.py放在板子里上電自動運行。調試階段用Thonny寫腳本單獨跑跑通了再把代碼整理進main.py。這樣既能用REPL現場測又能保證最終上電自動執(zhí)行。需要提醒的是MicroPython固件版本會影響部分UART功能比如uart.irq中斷機制在早期固件上支持不完整。如果你要用中斷接收這種比較進階的功能建議把固件升級到當前最新的穩(wěn)定版并且在代碼里做好功能測試。3.2 UART核心API與關鍵參數解析MicroPython的machine模塊提供了UART類用法和標準Python的串口庫有點相似但底層是直接對接硬件的。創(chuàng)建UART對象最完備的寫法如下from machine import Pin, UART uart UART( 0, # UART外設編號Pico上有UART0和UART1 baudrate115200, # 波特率通信雙方必須一致 txPin(0), # TX引腳 rxPin(1), # RX引腳 bits8, # 數據位常用8 parityNone, # 校驗位None表示無校驗 stop1, # 停止位常用1 timeout50, # 讀取超時時間單位毫秒 rxbuf256 # 接收緩沖區(qū)大小單位字節(jié) )這些參數里最需要理解的是波特率、bits、parity、stop這一組參數它們共同決定了一個串口幀的格式。通信雙方必須設置完全一致才能正確解析數據。波特率就是每秒傳輸的比特數常見的有9600、57600、115200等Pico跑115200非常穩(wěn)定。bits是數據位一般是8因為一個字節(jié)正好8位。parity是校驗位簡單通信場景用None就行。stop是停止位一般選1。如果通信雙方配置不一致最常見的現象就是收到亂碼或者完全沒數據。比如一邊是115200、8N1另一邊是9600、8N1收回來就是一堆無法解析的字節(jié)。下面這兩個方法在收發(fā)中會經常用到uart.write(bhello\r\n) # 發(fā)送字節(jié)數據返回發(fā)送的字節(jié)數 data uart.read(16) # 最多讀取16個字節(jié)返回bytes對象read()不帶參數時會讀取所有可用的字節(jié)但可能包含半包數據所以解析協議時最好自己按幀處理。readline()則會讀取到換行符為止適合逐行傳輸的簡單協議。3.3 最簡單的收發(fā)示例為了讓你快速驗證通信鏈路通不通我給一個最簡示例。Pico端代碼from machine import Pin, UART import time uart UART(0, baudrate115200, txPin(0), rxPin(1)) uart.init(rxbuf128) while True: uart.write(bpico alive\r\n) time.sleep(1) if uart.any(): data uart.readline() if data: uart.write(becho: ) uart.write(data)這段代碼做了什么每秒鐘主動發(fā)一條pico alive消息同時檢查接收緩沖區(qū)收到什么就原樣回顯。你用USB轉TTL模塊連接Pico的GP0和GP1在電腦串口助手里就能看到每秒一條的pico alive你發(fā)送hello立刻會收到echo: hello。uart.any()返回當前接收緩沖區(qū)里可讀的字節(jié)數是判斷串口是否有數據的關鍵方法。很多人第一次寫串口接收喜歡用readline硬等結果程序卡住。更好的習慣其實是主循環(huán)里先檢查any()有數據再去讀沒數據就干別的事這樣程序不會因為串口沒消息而假死。3.4 緩沖區(qū)、超時與中斷接收串口數據是字節(jié)流不是帶邊界的數據包。這句話我反復跟身邊的開發(fā)者強調很多通信異常都出在“把串口當協議用”上。MicroPython的UART內部有一個接收緩沖區(qū)由rxbuf參數指定大小默認可能只有幾十字節(jié)我習慣把它設置成256甚至更大。當緩沖區(qū)滿了還沒被程序讀走新到的數據就會丟失。高波特率、大流量數據、或者主循環(huán)處理太慢的時候丟數問題會非常明顯。應對丟數最直接的辦法是使用中斷接收。Pico的MicroPython支持uart.irq可以在有數據到達時立刻觸發(fā)回調把數據搬進自己的全局緩沖主循環(huán)只負責解析from machine import Pin, UART rx_data bytearray() def uart_callback(u): if u.any(): buf u.read(u.any()) rx_data.extend(buf) uart UART(0, baudrate115200, txPin(0), rxPin(1), rxbuf512) uart.irq(handleruart_callback, triggerUART.RX_ANY)這樣主循環(huán)不需要頻繁查詢串口數據到達時自動進入rx_data解析函數可以從rx_data里按協議取幀。但要注意中斷回調里盡量不要做耗時操作比如不要直接print不要做復雜協議解析只管把數據快速搬走否則會影響主程序的實時性。4. 調試工具的選型與使用實戰(zhàn)4.1 常用串口調試工具橫向對比串口調試工具直接決定了你調試效率是高一倍還是原地打轉。我這些年用過的工具不少各個平臺的都有簡單列個對比表工具名稱平臺優(yōu)勢適合場景SSCOMWindows經典穩(wěn)定支持多串口同時打開、時間戳、保存日志傳統(tǒng)嵌入式調試工位XCOMWindows界面干凈支持定時發(fā)送、波形顯示查看連續(xù)數據和波形PuTTY跨平臺極其輕量配置簡單可保存會話快速測試串口是否正常minicomLinux功能全面支持腳本和日志Linux下命令行調試picocomLinux輕量依賴少參數清晰快速連接、臨時使用VSCode Serial MonitorWindows/Linux/macOS和編碼環(huán)境集成支持保存輸出邊寫代碼邊看日志Python pyserial跨平臺靈活可編程可做自動化測試和自定義協議PC端上位機開發(fā)我的習慣是這樣的Windows下臨時驗證首選XCOM因為它發(fā)送十六進制和ASCII都比較方便界面不花哨正式調試協議時用SSCOM因為它的日志保存和時間戳功能非常穩(wěn)定如果整個開發(fā)都在VSCode里進行那我直接在擴展商店裝Serial Monitor插件一邊改代碼一邊看串口輸出非常順手在Linux服務器上用minicom不過每次的配置步驟有點啰嗦臨時用一次的話picocom更干脆——一條命令就搞定。4.2 USB轉TTL模塊的選擇與接線如果你要調試Pico的物理UARTUSB轉TTL模塊幾乎是必需品。市面上最常見的芯片有CH340、CP2102、FT232RL。CH340便宜幾塊錢就能買到Win系統(tǒng)驅動容易裝CP2102穩(wěn)定性好一點兼容性不錯FT232是工業(yè)級品質價格偏高適合長期做專業(yè)調試。選模塊時重點看是否支持3.3V電平切換。很多USB轉TTL模塊上有跳線或者撥碼開關可以在5V和3.3V之間切換接Pico時必須切到3.3V。有些模塊的TX、RX引腳上直接標了電平范圍購買時注意看參數。接線如下USB轉TTL模塊PicoTXGP1RXRXGP0TXGNDGND3.3V可選VSYS或3V3這里再次提醒TX、RX交叉連接。模塊的TX是發(fā)送端要接Pico的接收端GP1模塊的RX是接收端要接Pico的發(fā)送端GP0。很多新手第一次接反結果模塊發(fā)數據時Pico根本沒接住還以為是代碼出了問題。4.3 從接線到出數據的完整調試流程我總結了一套非常固定的調試流程每次都能快速定位問題第一步把USB轉TTL模塊插到電腦打開設備管理器確認COM口號。Windows下會顯示“USB-SERIAL CH340 (COM3)”之類的名字記下這個COM號。第二步用杜邦線把模塊和Pico接好通電。先在Pico上跑一個最簡單的測試程序比如每秒循環(huán)發(fā)送一段固定字符串。這樣做的目的是先確認Pico這邊能不能主動發(fā)數據不用管接收。第三步打開串口調試工具選中對應的COM口設置波特率115200、數據位8、停止位1、無校驗點擊打開。如果一切正常串口助手界面上應該能持續(xù)看到Pico發(fā)來的字符串。第四步如果看到數據說明發(fā)送鏈路OK。接下來測試接收在串口助手的發(fā)送框里輸入一段內容點擊發(fā)送觀察Pico有沒有收到。Pico端代碼可以在收到數據后回發(fā)一條確認消息這樣整個雙向鏈路就完整了。這個流程最大的好處是一步一步隔離問題。發(fā)送不通就只查發(fā)送鏈路接收不通就只查接收鏈路不需要同時排查七八個因素。4.4 Windows宿主機與虛擬機Linux間的串口透傳補充有些開發(fā)場景里你可能會在Windows宿主機上用VMware跑Linux而Pico的串口又想在Linux側訪問。這種情況下需要在虛擬機設置里把物理串口添加給虛擬機Linux里就能看到對應的串口設備文件比如/dev/ttyS0如果是USB轉TTL設備則可能是/dev/ttyUSB0。然后你就可以在Linux里用minicom或者picocom打開設備進行操作。要注意的是同一個串口同一時刻只能被一個系統(tǒng)打開。如果Windows宿主機里的串口助手正占著COM口虛擬機Linux就訪問不了必須先釋放。這點很容易被忽略經常導致虛擬機里明明看到了設備卻報“Permission denied”。minicom第一次使用時需要配置串口設備名和波特率啟動后先執(zhí)行sudo minicom -s進入配置界面選擇Serial port setup修改A選項為/dev/ttyUSB0E選項為115200保存并退出然后就能正常收發(fā)數據了。picocom就簡單得多一條命令搞定sudo picocom -b 115200 /dev/ttyUSB0如果你使用的是非圖形化的遠程終端這種命令行工具可能比Windows圖形化串口助手更順手。5. 實戰(zhàn)案例PC串口指令控制Pico驅動舵機5.1 需求與協議設計思路單純的收發(fā)測試跑通只是開始我更想用一個實際案例把整個串口通信串起來。這里我選擇一個很常見的場景PC通過串口發(fā)送角度指令Pico解析之后控制舵機轉動到指定角度。這個案例適合第一次做PC和單片機交互的人因為邏輯鏈路短、反饋直觀你在PC上輸入sv_90舵機立刻轉到90度。這個過程中涉及到串口協議設計、舵機PWM控制、解析容錯等幾個關鍵點全都能在幾分鐘內看到效果。協議設計我按最簡單可靠的方式來做PC發(fā)送一行文本指令格式是sv_角度\n比如sv_0、sv_90、sv_180。Pico按行讀取解析出數字部分轉換成舵機PWM脈寬同時回傳一條ok消息。用文本協議而不是二進制協議的好處是便于人工調試人在串口助手里敲一眼就能明白壞處是效率略低但在這種控制類場景里完全夠用。5.2 硬件接線清單樹莓派Pico一塊USB轉TTL模塊一個SG90舵機一個杜邦線若干外接5V電源給舵機供電Pico和USB轉TTL共地接線如下設備引腳接到PicoGP0UART0 TXUSB轉TTL RXPicoGP1UART0 RXUSB轉TTL TXPicoGNDUSB轉TTL GND、舵機GND、5V電源GNDPicoGP15PWM舵機信號線5V電源5V舵機紅線SG90舵機工作電流不小尤其是啟動瞬間可能到幾百毫安接在Pico的3V3引腳上會把板載LDO拖垮嚴重時直接復位重啟。所以舵機電源一定要單獨從5V電源取只把GND與Pico共地。這個接線習慣在電機、舵機、繼電器的場景里都是通用規(guī)則。5.3 Pico端MicroPython完整代碼from machine import Pin, PWM, UART servo PWM(Pin(15)) servo.freq(50) def set_angle(angle): angle max(0, min(180, int(angle))) pulse_us 500 angle / 180 * 2000 duty int(pulse_us / 20000 * 65535) servo.duty_u16(duty) return duty uart UART(0, baudrate115200, txPin(0), rxPin(1), rxbuf256) while True: if uart.any(): data uart.readline() if data: cmd data.strip() try: if cmd.startswith(bsv_): angle int(cmd[3:]) duty set_angle(angle) uart.write(bok duty str(duty).encode() b\n) else: uart.write(bunknown: cmd b\n) except Exception: uart.write(berror\n)這里有幾個細節(jié)值得說明。首先是PWM頻率設為50Hz也就是20ms周期這是SG90這類標準模擬舵機的典型工作頻率。然后是脈寬映射0度對應0.5ms脈寬180度對應2.5ms脈寬中間線性映射。因為Pico的PWM占空比是16位分辨率所以計算時把脈寬除以20ms再乘以65535就是實際寫進duty_u16的值。我用data.strip()把首尾空白字符去掉再判斷是不是sv_開頭角度部分用int()轉換。這樣即使PC端發(fā)送時帶著\r\n等隱形字符也不會影響解析。5.4 PC端Python控制腳本PC端我用Python的pyserial庫來發(fā)指令。如果沒有安裝先執(zhí)行pip install pyserial。控制腳本非常簡單import serial import time ser serial.Serial(COM3, 115200, timeout0.5) for angle in [0, 90, 180, 90, 0]: cmd fsv_{angle}\n.encode() ser.write(cmd) resp ser.readline().decode().strip() print(fangle{angle}, resp{resp}) time.sleep(1) ser.close()只要把串口號改成你自己的COM口運行腳本就可以看到舵機依次轉到0度、90度、180度、90度、0度Pico也會回傳對應的duty值。如果你沒有Python環(huán)境也可以直接用串口調試助手手動輸入sv_90然后發(fā)送效果完全一樣。這個方案的實用價值在于協議一旦固定下來你后續(xù)可以很輕松地把PC端換成任何語言實現比如C#的WinForm、Qt、網頁的Web Serial API甚至手機上的藍牙調試工具。因為底層都是同一套文本指令協議。5.5 實測效果與常見抖動實際運行的時候SG90在轉到目標角度后會輕微抖動這是模擬舵機的固有特性和串口通信無關。如果觀察到舵機完全不轉先檢查5V電源有沒有接對信號線有沒有接在GP15上PWM頻率是不是50Hz。如果舵機抖動特別厲害則很可能是電源供電不足換一個功率大一點的電源或者在舵機電源兩端并聯一個100uF左右的電容。串口控制過程中我還遇到過一種情況角度命令連續(xù)發(fā)得太快Pico的解析跟不上緩沖區(qū)滿了之后丟命令。解決方法是PC端每次發(fā)送后等待Pico回傳的ok消息再發(fā)下一條。如果不需要精確同步也可以在PC端加一點延時比如time.sleep(0.05)。6. 串口通信常見問題排查與避坑清單6.1 高頻故障速查表現象可能原因解決辦法完全收不到數據TX/RX接反Pico TX接模塊RXPico RX接模塊TX完全收不到數據未共地兩邊GND必須連在一起完全收不到數據串口被其他程序占用關閉串口助手、Thonny等占用程序收不到數據但發(fā)送正常接收程序里沒用uart.any()檢查先查緩沖區(qū)再讀取或者用中斷接收收到亂碼波特率不一致兩端全部統(tǒng)一成115200或9600收到亂碼電平不匹配3.3V設備不要直接接5V TTL收到亂碼線太長或干擾嚴重縮短杜邦線用屏蔽線降低波特率數據丟幀接收緩沖區(qū)太小rxbuf調大到512或1024數據丟幀主循環(huán)處理太慢改中斷接收數據到了立刻搬走只能收到一次數據程序在readline處阻塞設置timeout用any()輪詢舵機不轉舵機供電不足單獨5V電源勿從Pico 3V3取電Pico反復重啟大負載從板載LDO取電外接電源共地即可6.2 三個值得寫進筆記的排查思路第一個是“分段隔離”思路。通信鏈路出問題先區(qū)分是Pico發(fā)送出了問題還是PC發(fā)送出了問題最簡單的方法是Pico里只寫發(fā)送代碼、PC端只開串口助手觀察然后再反過來測。一段一段驗證永遠比從頭到尾瞎猜靠譜。第二個是“看二進制”思路。ASCII文本亂碼時把接收顯示模式切換成HEX看十六進制字節(jié)。比如你發(fā)的是0x31 0x32 0x33顯示出來就是313233如果看到的是亂七八糟的十六進制基本就是波特率不對如果字節(jié)本身對但文本亂碼那就是編碼問題或者幀格式參數不一致。這個思路排查亂碼特別有效。第三個是“別忘回顯”思路。在協議設計里收到指令后一定要回一條響應消息哪怕是簡單的一個ok或一個字節(jié)。這樣調試的時候你能立刻知道對方收到沒有。如果沒有回顯機制通信中你根本分不清是發(fā)送端沒發(fā)出、接收端沒收到還是收到了但處理邏輯出錯。6.3 我的工具鏈與習慣沉淀做了這么多串口項目之后我沉淀下來的習慣是這樣的硬件上常備一兩個CH340和CP2102的USB轉TTL模塊哪個順手用哪個軟件上Windows里固定用XCOM快速測試SSCOM做長時間日志記錄VSCode里用Serial Monitor插件配合編碼協議上通信開始前先定好幀格式盡量用帶換行符的ASCII文本協議起步等業(yè)務穩(wěn)定了再視需求改成更緊湊的二進制協議。還有一個非常實用的經驗給連接線做標記。我用不同顏色的杜邦線區(qū)分TX和RX紅色固定接電源黑色固定接地黃色固定接數據線。杜邦線顏色一亂接線時極容易看錯特別是一堆線纏在一起的時候。現在的項目里我都直接買一小包彩色杜邦線把顏色約定寫進工程筆記省了非常多追線時間。再補充一點調試Pico串口時程序里適當加print輸出會很有幫助。因為Pico的REPL走USB CDC物理UART不受影響所以你的UART收發(fā)數據的同時還可以用print在Thonny的Shell里看內部狀態(tài)。這個組合在我調試協議的時候幫了大忙相當于既能看到物理串口收到的原始數據又能看到程序卡在哪個分支邏輯里。最后說一句我自己的體會串口通信真不是造火箭的技術但它就像基本功里的馬步所有復雜通信協議、云平臺接入、工業(yè)總線應用底層都離不開這一套“TX接RX、波特率一致、按協議解析”的基礎邏輯。把Pico這套串口玩熟練之后再去看STM32、ESP32、Linux串口編程很多東西都是相通的只是換了個殼。這篇內容里的經驗和坑都是我在實際項目里一趟一趟踩出來的希望能幫你省下一點本不該浪費的時間。