最近在樹莓派 Pico 上做一個小采集板串口數(shù)據(jù)一多MicroPython 的uart.read()就開始吃 CPU主循環(huán)明顯發(fā)卡。折騰了一天把 RP2040 的 DMA 接進(jìn) UART 鏈路之后才算真正體會到一個道理在 MicroPython 這種解釋型環(huán)境里能用外設(shè)硬件干掉的活千萬別讓 Python 循環(huán)去扛。這篇文章把我從踩坑到跑通的過程完整寫出來內(nèi)容包括 RP2040 DMA 的寄存器級原理、DREQ 觸發(fā)機(jī)制、UART 與 DMA 的握手方式、可復(fù)現(xiàn)的 MicroPython 配置代碼以及我在調(diào)試中遇到的典型問題和排查思路。涉及具體 API 的地方我會順帶提一下固件版本差異方便你用自己手上的 Pico 直接抄作業(yè)。如果你正在 MicroPython 下做串口數(shù)據(jù)采集、GPS 解析、傳感器數(shù)據(jù)流接收或者單純想讓 CPU 從逐字節(jié)搬運(yùn)中解放出來這篇內(nèi)容應(yīng)該對你有用。1. 整體設(shè)計思路拆解1.1 為什么要在 MicroPython 下折騰 DMA先說一個現(xiàn)實MicroPython 是解釋執(zhí)行的一條while循環(huán)里讀一串串口數(shù)據(jù)開銷比 C 語言大得多。RP2040 的 Cortex-M0 主頻最高也就 133MHz在沒有硬件浮點(diǎn)的情況下1200 行 Python 語句可能就跑掉好幾個毫秒。如果數(shù)據(jù)速率稍微上去比如 460800 或 921600 波特率輪詢模式基本是災(zāi)難。傳統(tǒng)做法有三種方案CPU 占用實時性實現(xiàn)難度適用場景輪詢read()極高數(shù)據(jù)密集時幾乎占滿差容易丟數(shù)據(jù)低低頻、零散串口數(shù)據(jù)中斷 緩沖區(qū)中等每字節(jié)都進(jìn)中斷較好但中斷頻繁中大多數(shù)通用串口場景DMA 自動搬運(yùn)極低搬運(yùn)由硬件完成好數(shù)據(jù)不丟中高大數(shù)據(jù)塊、高頻連續(xù)串口流DMA 的核心價值是把從外設(shè)寄存器把數(shù)據(jù)搬到內(nèi)存這件機(jī)械勞動交給硬件完成CPU 只需要在傳輸開始前配置好通道在傳輸結(jié)束后處理結(jié)果。MicroPython 下這個優(yōu)勢會被放大因為一條 Python 語句的解釋開銷本來就大把逐字節(jié)搬運(yùn)從 Python 代碼里拿掉等于直接把 CPU 釋放給了真正需要處理的業(yè)務(wù)邏輯。順帶說一句Pico 的第二個核心Core1如果跑著 MicroPython 固件本身也是共享同一塊 SRAM 的DMA 不會額外占用 CPU 對總線的訪問時間這對雙核應(yīng)用很友好。1.2 RP2040 DMA 的工作框架RP2040 的 DMA 控制器其實是掛在內(nèi)核總線上的一個獨(dú)立外設(shè)不在 Cortex-M0 處理器內(nèi)部。共有 12 個通道每個通道可以獨(dú)立配置源地址、目標(biāo)地址、傳輸長度、傳輸數(shù)據(jù)寬度、地址遞增策略以及觸發(fā)請求源DREQ。這里的關(guān)鍵是 DREQ 握手機(jī)制。UART、SPI、I2C、ADC 這些外設(shè)會主動向 DMA 控制器發(fā)出我有數(shù)據(jù)要給你或我需要數(shù)據(jù)的信號DMA 通道收到這個信號才開始搬運(yùn)一個數(shù)據(jù)單元。以 UART RX 為例當(dāng) UART 的接收 FIFO 里至少有一個數(shù)據(jù)時UART 就會持續(xù)拉高 DREQDMA 看到這個請求后完成一次讀 DR 寄存器并寫 RAM 的操作。這樣傳輸節(jié)奏完全由外設(shè)的數(shù)據(jù)流決定不會多搬也不會漏搬。在 MicroPython 下使用 DMA本質(zhì)上有兩條路線一是直接通過machine.mem32讀寫 DMA 寄存器二是使用較新固件v1.20 之后提供的rp2.DMA封裝類。無論走哪條路原理都是控制同一組寄存器所以接下來先把寄存器細(xì)節(jié)講透后面看代碼才能心里有數(shù)。2. 核心細(xì)節(jié)解析與實操要點(diǎn)2.1 DMA 通道寄存器地圖DMAC 控制器基地址是0x50000000。每個通道占0x40字節(jié)地址空間CH0 從0x50000000開始CH1 從0x50000040開始依次類推。我實際用到的寄存器主要是這幾個寄存器名相對 CHx 偏移作用READ_ADDR0x00源地址DMA 從這里讀數(shù)據(jù)WRITE_ADDR0x04目標(biāo)地址DMA 往這里寫數(shù)據(jù)TRANS_COUNT0x08待傳輸?shù)臄?shù)據(jù)單元個數(shù)遞減到 0 表示完成CTRL_TRIG0x0C控制位與觸發(fā)寫寫入即啟動傳輸CTRL0x10同 CTRL_TRIG 的控制位但不觸發(fā)啟動CTRL_TRIG 是整個 DMA 配置的核心我挑幾個最關(guān)鍵的位說明ENbit 0通道使能。DATA_SIZEbit 2 到 bit 30 表示按字節(jié)搬1 表示半字2 字節(jié)2 表示字4 字節(jié)。UART 的一次數(shù)據(jù)傳輸通常是 1 字節(jié)所以固定用 0。INCR_WRITEbit 4寫地址是否自動遞增。往 RAM 緩沖區(qū)寫時置 1往外設(shè)寄存器寫時清 0。INCR_READbit 5讀地址是否自動遞增。從 RAM 緩沖區(qū)讀時置 1從外設(shè)寄存器讀時清 0。CHAIN_TObit 15 到 bit 20傳輸結(jié)束后續(xù)接的通道可以實現(xiàn)鏈?zhǔn)絺鬏敗REQ_SELbit 21 到 bit 26選擇哪個外設(shè)的 DREQ 作為觸發(fā)源。BUSYbit 29只讀為 1 表示通道正在傳輸中。我在實際調(diào)試時最喜歡看 TRANS_COUNT因為它會從初始值遞減能直觀看到 DMA 有沒有在動。如果等了半天這個數(shù)沒變那問題多半出在觸發(fā)配置上而不是搬運(yùn)本身。2.2 DREQ 觸發(fā)源怎么選DREQ 編號不是亂來的RP2040 數(shù)據(jù)手冊里面有一張完整的表。和 UART 相關(guān)的部分如下DREQ 號含義0UART0 RX1UART0 TX2UART1 RX3UART1 TX比如我用 UART0 做接收TREQ_SEL 就填 0。使用 MicroPython 的rp2.DMA封裝時不同固件版本可能允許直接填這個數(shù)字也可能提供字符串形式的枚舉運(yùn)行時可以用help(DMA.config)查看現(xiàn)場固件的真實簽名。這里有個坑UART 的 DREQ 信號和 FIFO 深度是聯(lián)動的。UART0 RX 的 FIFO 深度是 16 字節(jié)只有當(dāng)系統(tǒng)時鐘使能了 FIFO 功能后DMA 請求才會按 FIFO 水位自動發(fā)出。如果初始化 UART 時沒有設(shè)置FENFIFO 使能位有些情況下 DREQ 行為會變得不可控。所以我的習(xí)慣是在寄存器初始化時明確把 UART 的 FIFO 打開避免后面排查半天。2.3 緩沖區(qū)管理MicroPython 最容易踩的隱形坑在 C 里用 DMA你拿著一個數(shù)組的地址直接填寄存器就行。但 MicroPython 里 Python 對象是被解釋器管理的GPIO、內(nèi)存分配、垃圾回收都可能影響緩沖區(qū)。最怕的是這樣兩個問題第一個是緩沖區(qū)被垃圾回收。MicroPython 不使用壓縮式 GC對象地址在存活期間不會移動但如果你把bytearray傳給 DMA 之后后續(xù)代碼里沒有變量再引用它GC 可能會回收這塊內(nèi)存DMA 還在后臺往里面寫輕則數(shù)據(jù)錯亂重則內(nèi)存越界導(dǎo)致 Reboot。對策是讓緩沖區(qū)對象活到 DMA 結(jié)束比如保存在全局變量或者用一個列表兜底引用。第二個是 CPU 與 DMA 并發(fā)訪問競爭。RP2040 的 Cortex-M0 沒有數(shù)據(jù) cache所以不存在緩存一致性問題但存在同一塊緩沖區(qū)DMA 正在寫入Python 循環(huán)也在讀的競爭。穩(wěn)妥做法是把 buffer 切成多塊一塊給 DMA 填另一塊給 Python 處理兩塊交替使用。后面我在不定長接收方案里會具體演示。2.4 MicroPython 下的兩種 DMA 操控姿勢如果你想快速實現(xiàn)功能優(yōu)先用rp2.DMA封裝類它會幫你處理對象到地址的轉(zhuǎn)換省去很多底層麻煩。示例大致是這樣from rp2 import DMA from machine import UART, mem32 UART0_BASE 0x40034000 UART_DR 0x40034000 # 數(shù)據(jù)寄存器 uart UART(0, 115200) rx_buf bytearray(128) dma DMA() dma.config( trigger0, # DREQ 編號0 對應(yīng) UART0_RX sourceUART_DR, # 固定讀 UART0 數(shù)據(jù)寄存器 destrx_buf, # 寫入字節(jié)數(shù)組 countlen(rx_buf), read_incrementFalse, write_incrementTrue, data_size0, # 8-bit 數(shù)據(jù)傳輸 ) dma.start()不同 MicroPython 版本的參數(shù)名可能有差異我在電腦上實測時發(fā)現(xiàn)有些版本把trigger寫成dreq有些版本count必須寫成關(guān)鍵字參數(shù)所以運(yùn)行前最好在 REPL 里執(zhí)行import rp2; help(rp2.DMA.config)看簽名。如果你要更精細(xì)地控制中斷、鏈?zhǔn)絺鬏敾蛘哒{(diào)試寄存器狀態(tài)那就直接上底層方式DMA_BASE 0x50000000 def ch_addr(ch, offset): return DMA_BASE ch * 0x40 offset # 配置 CH0 mem32[ch_addr(0, 0x00)] UART_DR # READ_ADDR mem32[ch_addr(0, 0x04)] buffer_addr # WRITE_ADDR mem32[ch_addr(0, 0x08)] 128 # TRANS_COUNT ctrl (1 0) | (0 2) | (1 4) | (1 21) # EN 8bit INCR_WRITE TREQ_SEL0 mem32[ch_addr(0, 0x0C)] ctrl # CTRL_TRIG 啟動不過底層方式會卡在如何拿到 MicroPython 字節(jié)數(shù)組的內(nèi)存地址這個問題上所以我還是更推薦優(yōu)先使用封裝類等你真正需要的時候再去看固件源碼了解它是怎么轉(zhuǎn)換的。3. 實操過程與核心環(huán)節(jié)實現(xiàn)3.1 第一步把 UART 初始化到可用狀態(tài)DMA 搬運(yùn)的目標(biāo)是外設(shè)寄存器但 UART 本身的波特率、FIFO 打開與否也得先準(zhǔn)備到位。直接用machine.UART類初始化有一個隱患這個類默認(rèn)會開接收中斷并向內(nèi)部緩沖區(qū)填充數(shù)據(jù)雖然不一定會和 DMA 打架但我更喜歡在 DMA 場景下用寄存器初始化把控制權(quán)完全握在自己手里。RP2040 的 UART0 基地址是0x40034000波特率分頻寄存器是IBRD偏移 0x24和FBRD偏移 0x28。計算公式是BRD PERCLK / (16 × baud)Pico 的默認(rèn)外設(shè)時鐘頻率是 125MHz。以 115200 波特率為例125000000 / (16 × 115200) 67.817整數(shù)部分 IBRD 67小數(shù)部分 0.817 乘 64 約等于 52所以 FBRD 52。如果用 921600125000000 / (16 × 921600) 8.477IBRD 8FBRD 30設(shè)置好分頻后再配置 LCR_H偏移 0x2C和 CR偏移 0x30。LCR_H 寫 0x60 就代表 8 位數(shù)據(jù)長度加 FIFO 使能CR 寫 0x301 是同時打開 UART、發(fā)送和接收。MicroPython 里的寄存器初始化片段from machine import mem32 UART0_BASE 0x40034000 UART0_DR 0x40034000 UART0_IBRD 0x40034024 UART0_FBRD 0x40034028 UART0_LCR_H 0x4003402C UART0_CR 0x40034030 baud 115200 ibrd 125000000 // (16 * baud) fbrd int(((125000000 / (16 * baud)) - ibrd) * 64 0.5) mem32[UART0_IBRD] ibrd mem32[UART0_FBRD] fbrd mem32[UART0_LCR_H] 0x60 # 8 位數(shù)據(jù) FIFO 使能 mem32[UART0_CR] 0x301 # UARTEN | TXE | RXE這里有個小技巧計算 FBRD 時加 0.5 再取整是避免浮點(diǎn)誤差導(dǎo)致最接近的分?jǐn)?shù)值偏差。實際使用中 115200 波特率下配置誤差遠(yuǎn)小于誤碼容限跑飛的可能性很低。3.2 第二步實現(xiàn) DMA 接收假設(shè)我要把 UART0 收到的一串固定長度數(shù)據(jù)比如 128 字節(jié)自動存進(jìn) RAM。用rp2.DMA封裝核心代碼就是配置好通道然后讓 DMA 在后臺干活。這里我用一個全局變量持住緩沖區(qū)防止 GC 回收from rp2 import DMA from machine import UART, mem32, Pin UART0_DR 0x40034000 rx_buf bytearray(128) dma None def setup_dma_rx(): global dma, rx_buf dma DMA() dma.config( trigger0, # UART0 RX sourceUART0_DR, destrx_buf, countlen(rx_buf), read_incrementFalse, write_incrementTrue, data_size0, ) dma.start()啟動之后UART 每收到一個字節(jié)DMA 就自動寫入rx_buf。當(dāng)rx_buf填滿 128 字節(jié)后TRANS_COUNT 會遞減到 0通道自動停止。如果后續(xù)還有數(shù)據(jù)需要重新配置 count 并再次start()。需要說明白的是這里說的零 CPU 干預(yù)更準(zhǔn)確的理解是數(shù)據(jù)搬運(yùn)過程零 CPU 干預(yù)啟動、處理和停止仍需要 CPU。真正的高負(fù)載場景下DMA 傳輸結(jié)束后應(yīng)該觸發(fā) IRQ讓 MicroPython 的回調(diào)函數(shù)在后臺把數(shù)據(jù)取走。如果對實時性要求不高也可以在主循環(huán)里輪詢 DMA 是否完成。輪詢版本也很簡潔while dma.active(): pass print(接收完成前 16 字節(jié):, rx_buf[:16])但我建議在正式產(chǎn)品中不要用這個忙等版本因為active()查詢語句本身也有開銷而且主循環(huán)會卡死。配合 IRQ 才是正路。3.3 第三步用 DMA 發(fā)送數(shù)據(jù)發(fā)送方向的結(jié)構(gòu)完全對稱但地址遞增方向反過來。我要把內(nèi)存里的一段數(shù)據(jù)從源地址連續(xù)遞增地讀到 UART 的 DR 寄存器源地址要遞增目標(biāo)地址是固定寄存器DREQ 選擇 UART0_TX。from rp2 import DMA from machine import UART, mem32 UART0_DR 0x40034000 tx_buf bytearray(bHello RP2040 DMA!\n) tx_dma DMA() tx_dma.config( trigger1, # UART0 TX sourcetx_buf, destUART0_DR, countlen(tx_buf), read_incrementTrue, write_incrementFalse, data_size0, ) tx_dma.start()發(fā)送完成后如果還想繼續(xù)用這個通道記得count重新賦值。RP2040 DMA 通道在 count 變?yōu)?0 后不會自動重置這是和某些 MCU 的循環(huán) DMA 模式不一樣的地方。如果數(shù)據(jù)長度變來變?nèi)ッ看伟l(fā)送前都要設(shè)置新的 count。這里還要注意UART 的發(fā)送是慢速設(shè)備而 DMA 是按 DREQ 節(jié)奏跑的所以不會出現(xiàn)DMA 一下子把 FIFO 塞爆的問題。FIFO 有空位UART 才拉高 DREQDMA 才搬一個數(shù)據(jù)過去天然形成背壓機(jī)制。3.4 不定長數(shù)據(jù)接收DMA 加空閑檢測的思路串口項目里最常見的需求其實是不定長數(shù)據(jù)幀處理。DMA 通道傻乎乎地只會搬固定長度怎么處理一幀長度可變的包我試過幾種思路最終覺得最可靠、也最省事的是DMA 持續(xù)接收 定時器判斷線路空閑。核心邏輯是這樣的DMA 配置成環(huán)形緩沖區(qū)或指定長度的大 buffer比如 512 字節(jié)。UART 每收到一個字節(jié)都會由 DMA 寫進(jìn) buffer。CPU 單獨(dú)跑一個定時器比如每 1ms 檢查一次 UART 的 FR 寄存器的 RXFE 位RX FIFO 空標(biāo)志并記錄當(dāng)前 DMA 的 TRANS_COUNT。如果連續(xù)幾個周期發(fā)現(xiàn) TRANS_COUNT 沒有變化說明線路已經(jīng)空閑這時把 DMA 已經(jīng)接收的數(shù)據(jù)一次性取出。這個方案不是零 CPU 干預(yù)的極致狀態(tài)但勝在實現(xiàn)簡單、容錯好。你也可以反過來用 UART 的空閑中斷某些 MCU 的 UART 有 RTO 或 IDLE 狀態(tài)但 RP2040 的 UART 沒有像 STM32 那樣的 IDLE 中斷所以我傾向于用定時器空閑判斷。在 MicroPython 里可以這樣實現(xiàn)初始化一個machine.Timer周期 1ms回調(diào)函數(shù)里讀取 DMA 當(dāng)前剩余計數(shù)字節(jié)dma.count()然后把偏移位置算出來把已收到的數(shù)據(jù)交給業(yè)務(wù)邏輯。注意定時器回調(diào)不要在中斷上下文里做重活用micropython.schedule()把數(shù)據(jù)處理放到主循環(huán)空閑時執(zhí)行。3.5 演示主程序把上面的模塊拼起來一個最簡單的 DMA 串口回顯程序長這樣from machine import UART, mem32, Pin, Timer from rp2 import DMA import micropython UART0_DR 0x40034000 rx_buf bytearray(128) rx_dma None def on_data_ready(): print(DMA 完成數(shù)據(jù):, bytes(rx_buf)) def setup(): global rx_dma # 寄存器方式初始化 UART0115200 8N1 mem32[0x40034024] 67 mem32[0x40034028] 52 mem32[0x4003402C] 0x60 mem32[0x40034030] 0x301 rx_dma DMA() rx_dma.config(trigger0, sourceUART0_DR, destrx_buf, countlen(rx_buf), read_incrementFalse, write_incrementTrue, data_size0) rx_dma.start() setup()跑這個程序然后用串口調(diào)試助手給 Pico 發(fā) 128 字節(jié)數(shù)據(jù)你會看到打印輸出。這個程序本身沒有太多實用性但它驗證了整條 DMA 通路是否正常。我建議所有剛接觸 DMA 的人都從這樣一個最小回顯開始不要一上來就搞環(huán)形緩沖加中斷鏈那樣出了問題反而不知道是哪一環(huán)壞了。4. 常見問題與排查技巧實錄4.1 五個最容易踩的坑我把自己實操中碰到的問題按頻率排了個序基本上能覆蓋新手階段的大多數(shù)翻車現(xiàn)場。問題一DMA 完全沒有觸發(fā)TRANS_COUNT 一直不遞減。八成是 DREQ 編號填錯或者 UART 的 FIFO 沒有使能。檢查 UART0 RX 對應(yīng)的是 TREQ_SEL 0UART0 TX 對應(yīng)的是 1不要和 UART1 混淆。再看 LCR_H 的 FEN 位是不是 1FIFO 關(guān)閉時有些 DREQ 行為不會按預(yù)期工作。問題二數(shù)據(jù)錯位或者每次接收都少幾個字節(jié)。最常見的原因是 DATA_SIZE 沒設(shè)對。UART 一幀傳 8 位數(shù)據(jù)DATA_SIZE 必須是 0按字節(jié)。如果設(shè)成 2按字搬每次 DMA 會從連續(xù)地址讀 4 字節(jié)結(jié)果就是數(shù)據(jù)前后錯位、長度也對不上。另一個原因是 INCR_WRITE 或 INCR_READ 方向搞反導(dǎo)致每次都把數(shù)據(jù)寫到同一個地址。問題三MicroPython 的 bytearray 被 GC 回收DMA 還在寫。表現(xiàn)為程序跑一會兒后死機(jī)或者打印出亂碼。檢查一下你是否在while之外的函數(shù)內(nèi)部創(chuàng)建了緩沖區(qū)函數(shù)返回后沒有全局變量引用它。解決方法是把rx_buf設(shè)置為全局變量或者用gc.mem_alloc()觀察內(nèi)存變化。如果你用rp2.DMA建議保持對dma對象的引用同樣重要。問題四DMA 傳輸完成后程序沒有反應(yīng)?？纯赐ǖ朗欠裾娴慕Y(jié)束輪詢dma.active()或者讀mem32[ch_addr(ch, 0x08)]的計數(shù)值是否為 0。也有可能是你反復(fù)start()但沒重新設(shè)置count導(dǎo)致第二次傳輸立即完成。RP2040 DMA 的 count 是遞減模式不會自動重置。問題五同時開多個 DMA 通道時通道互相干擾。RP2040 有 12 個通道rp2.DMA()不傳參時會自動分配空閑通道但如果你手動指定了固定通道號要避免兩個任務(wù)共用同一個通道。特別是在鏈?zhǔn)絺鬏敾蛘咧袛嗷卣{(diào)里創(chuàng)建 DMA 對象時生命周期管理一定要清楚。4.2 調(diào)試驗證手段沒有邏輯分析儀的情況下調(diào)試 DMA 也不是完全瞎猜。我在調(diào)試時最常用的三件套第一打印寄存器狀態(tài)。用machine.mem32直接讀 DMA 通道的 CTRL_TRIG 和 TRANS_COUNT輸入以下命令觀察是否變化from machine import mem32 mem32[0x50000000 0 * 0x40 0x08] # CH0 TRANS_COUNT第二用 Pico 板載 LED 做狀態(tài)指示。在 DMA 完成的回調(diào)里翻轉(zhuǎn) LED如果燈閃了說明 CM0 確實收到了 DMA 中斷或回調(diào)有被觸發(fā)可以快速區(qū)分是沒傳輸還是傳輸了但處理有問題。第三降低波特率測試。波特率降到 9600 后即使邏輯有問題單字節(jié)的時間很長字節(jié)能觀察得清楚排查錯位問題更容易。等低波特率完全正常再逐步提升。4.3 關(guān)于 MicroPython 固件版本的一點(diǎn)建議不同版本 MicroPython 對 RP2040 DMA 的支持變化挺大。較老的 1.19 版本里rp2.DMA可能還不完整我在 1.23 和 1.24 上測試是正常的。如果你拿到的是某個定制固件最好先跑一下import rp2 print(hasattr(rp2, DMA))如果返回 False要么更新固件要么就只能走machine.mem32寄存器直寫的底子。另一個經(jīng)驗是先讀固件源碼里的rp2_dma.c里面會說明config的每個參數(shù)對應(yīng)哪個寄存器位這個文件在 micropython 官方倉庫的ports/rp2目錄下。自己讀一遍源碼比在論壇里搜零散答案效率高得多。根據(jù)我的個人經(jīng)驗DMA 不是越底層越高級而是要結(jié)合你的固件能力選。MicroPython 的rp2.DMA封裝已經(jīng)封裝好了地址轉(zhuǎn)換和通道管理除非你有非常極端的性能或者中斷時序要求否則直接用它就是最省心、也最不容易翻車的方案。先跑通最小回顯再做環(huán)形緩沖和空閑檢測慢慢把對 DMA 的理解建立起來。這套思路放到后續(xù)改用 C SDK 開發(fā)時也同樣適用因為底層寄存器、DREQ 編號、緩沖區(qū)管理這些知識是相通的。