)
有朋友在群里問RP2040 上跑 MicroPythonUART 能不能做到 DMA 搬運、CPU 徹底撒手我第一反應是能但別指望標準固件會給你現成接口。RP2040 的 DMA 控制器是真的正經外設只是 MicroPython 官方固件默認不暴露 DMA API所以這事得自己動手。這篇內容我會把 RP2040 DMA 的原理、UART 的零 CPU 干預怎么實現、以及我在 MicroPython 固件里加自定義 C 模塊的完整過程都拆開講清楚。適合已經在用 MicroPython 寫 Pico 程序、覺得串口收發(fā)占 CPU、想用 DMA 又不知道從哪下手的開發(fā)者?？赐曛辽倌苷罩桨赴炎詈唵蔚?DMA 串口接收跑起來。1. 為什么要把 UART 交給 DMA1.1 RP2040 的 DMA 控制器到底是什么水平很多人一聽“單片機上的 DMA”第一反應是 STM32 那套。實際上 RP2040 的 DMA 配置能力相當完整有 12 個獨立通道每個通道都可以單獨設置源地址、目的地址、傳輸計數和數據寬度。數據寬度支持 8 位、16 位、32 位也就是字節(jié)、半字、字三種粒度。它還能配置地址遞增方式可以固定源地址、遞增目的地址也可以反過來。最關鍵的一點是RP2040 的 DMA 請求可以由外設直接觸發(fā)。UART、SPI、I2C、ADC、PIO 狀態(tài)機這些外設都會產生 DREQ 信號DMA 收到 DREQ 才搬一次數據。這就意味著 DMA 不需要 CPU 干預也不需要 CPU 用定時器去“猜”外設什么時候有數據。只要外設準備好了硬件就會自動完成一次搬運。另外RP2040 DMA 還支持通道鏈式觸發(fā)一個通道完成后可以自動觸發(fā)另一個通道配合雙緩沖、多段數據搬運很方便。它這個鏈式機制不是部分高端芯片那種完整的內存描述符鏈表但已經足夠應付絕大多數嵌入式場景。對 UART 來說我們通常只關心三個東西源地址、目的地址、傳輸計數再配一個 DREQ 觸發(fā)源剩下交給硬件就行。1.2 傳統(tǒng) UART 收發(fā)為什么費 CPU先算一筆賬。串口 115200 波特率、8N1 格式每字節(jié)實際占用 10 bit那么 1 秒最多傳輸 11520 字節(jié)。如果用最簡單的每字節(jié)觸發(fā)一次中斷中斷頻率就是每秒 11520 次。 RP2040 主頻 133MHz處理一次中斷壓棧、進中斷服務函數、讀 FIFO、清標志、再恢復現場時間雖然很短但高負載下還是會影響主循環(huán)。如果同時開兩三個串口或者在一個中斷里去解析數據協議主循環(huán)的實時性就會下降。發(fā)送側也一樣。你要把一個 1KB 的 buffer 發(fā)出去傳統(tǒng)寫法是一個字節(jié)一個字節(jié)往 UART 的 TX FIFO 寫。就算 FIFO 能緩存一部分數據中間也免不了判斷 FIFO 是否滿、是否需要等。這些操作本身不復雜但頻率一高就會碎片化占用 CPU。DMA 的思路是把“搬數據”這件事完全交給硬件。發(fā)送時CPU 只需要設置 DMA 把內存數據搬進 UART 的發(fā)送 FIFO發(fā)完后 DMA 產生一次中斷接收時DMA 自動把 RX FIFO 里的數據搬進內存收到預定長度后產生一次中斷。整個傳輸過程中CPU 不參與逐字節(jié)搬運所以叫“零 CPU 干預”。注意這個零不是絕對意義上的 CPU 完全休眠而是沒有逐字節(jié)參與最后該有的完成中斷還是會有。1.3 MicroPython 在這件事上的特殊尷尬MicroPython 的問題在于官方 RP2040 固件把 DMA 藏得很深。你打開machine.UART的源碼能看到它內部其實用了 Pico SDK 的底層驅動但上層暴露給你的只有read()、write()、any()這些方法。這些方法內部處理了中斷和緩沖區(qū)對用戶看起來確實“好用”但 CPU 并不是零負擔。還有不少人嘗試用machine.mem32直接操作 DMA 寄存器。這個思路很直接RP2040 的寄存器地址都是公開的理論上你可以用 Python 把 DMA 通道配置出來。但實際跑起來會發(fā)現幾個問題一是 Python 解釋執(zhí)行寄存器操作太慢配置十幾個寄存器可能就要幾百微秒二是你沒法在 DMA 中斷服務函數里穩(wěn)定地跑 Python 回調稍不留神就會死機或者漏數據。所以要玩真正的 DMA最靠譜的路線不是硬用純 Python 去操作寄存器而是給 MicroPython 編譯一個自定義 C 擴展模塊把 DMA 能力封裝成幾個 Python 函數。后面我會詳細講這條路。2. 零 CPU 數據傳輸的方案選型與原理拆解2.1 方案一C SDK 直接寫不繞彎如果項目沒有“必須用 MicroPython”這個限制那最正統(tǒng)的方案當然是直接用 C 寫Pico SDK 提供了完整的 DMA API。接收流程大概是這樣的int ch dma_channel_claim_unused(true); dma_channel_config c dma_channel_get_default_config(ch); channel_config_set_transfer_data_size(c, DMA_SIZE_8); channel_config_set_read_increment(c, false); channel_config_set_write_increment(c, true); channel_config_set_dreq(c, DREQ_UART0_RX); uint8_t buf[256]; dma_channel_configure(ch, c, buf, // 目的地址內存 uart_get_hw(uart0)-dr, // 源地址UART 數據寄存器 256, // 傳輸計數 true); // 立即啟動這段 C 代碼做的事非常清晰DMA 通道源地址固定指向 UART0 的 DR 寄存器目的地址遞增指向內存?zhèn)鬏?256 字節(jié)每傳一個字節(jié)就通過DREQ_UART0_RX等待 UART 收到新數據。完成后你可以自己寫一個 DMA 中斷服務函數置一個標志位讓主循環(huán)去處理數據。用 C SDK 寫這個問題不大但很多人就是不想放棄 MicroPython因為業(yè)務邏輯用 Python 寫實在是太快了。所以如果既要 MicroPython又要 DMA那就得走下面的方案二。2.2 方案二給 MicroPython 編譯 dma_uart 擴展模塊MicroPython 允許你在固件里加入 C 擴展模塊然后把模塊里的函數注冊成 Python 的 import 對象。比如我們可以做一個dma_uart模塊提供start()、done()、received()這幾個方法底層直接用 Pico SDK 的 DMA API上層 Python 代碼只管調用。這個方案的原理并不復雜。MicroPython 本質上是一個 C 程序它執(zhí)行 Python 字節(jié)碼同時也能調用編譯進固件的 C 函數。我們寫一個 C 文件把 DMA 初始化和中斷處理封裝好再用 MicroPython 的模塊注冊機制掛到系統(tǒng)里。編譯固件之后Python 里import dma_uart就能找到這個模塊。好處是DMA 的實時性要求由 C 代碼保證Python 側不需要高頻操作寄存器而業(yè)務邏輯、協議解析、UI 交互這些不要求實時的部分還是可以繼續(xù)用 Python。壞處是你需要花點時間搭一套交叉編譯環(huán)境第一次編譯固件會有點折騰。2.3 方案三PIO 狀態(tài)機不是 DMA聊到 RP2040總有人會問“能不能用 PIO 替代 DMA”。PIO 是 RP2040 獨有的一組可編程 IO 狀態(tài)機可以自己編指令模擬 UART、SPI、I2C、WS2812 這類協議。它的靈活性確實很高但它和 DMA 解決的問題不一樣。PIO 狀態(tài)機有自己的 RX/TX FIFO數據會流進狀態(tài)機的 FIFO但把 FIFO 里的數據搬到內存仍然需要 CPU 或者 DMA。也就是說PIO 解決了“如何按協議收發(fā)”的問題DMA 解決了“如何不經過 CPU 搬數據”的問題。 MicroPython 的rp2.PIO類能讓你加載 PIO 程序但不會直接給你一個“讓 PIO FIFO 自動搬到 buffer”的高層接口。大多數情況下你還是要通過 PIO 中斷或輪詢去讀取數據CPU 并沒有真正解放。如果你的目標是 UART 零 CPU 干預那就老老實實用硬件 UART 加 DMA別在 PIO 上繞圈子。2.4 選型結論把三個方案放一起對比一下方案CPU 占用實現難度適合場景C SDK 直接寫極低中純 C 工程需要最高性能MicroPython 自定義 DMA 模塊極低較高想用 Python 寫業(yè)務又需要 DMAMicroPython 純 Python 操作寄存器高高不建議只適合學習寄存器原理我自己的建議是如果只是 9600 波特率收發(fā)幾字節(jié)傳感器數據machine.UART那點 CPU 開銷根本不用在意但如果你要跑 115200 甚至更高波特率還要連續(xù)收發(fā)大塊數據或者主循環(huán)同時要處理顯示、網絡、按鍵那 DMA 模塊就值得折騰。3. 實操過程手寫一個 dma_uart 模塊并跑通3.1 準備編譯環(huán)境第一步是準備編譯 MicroPython 固件的環(huán)境。這里以 Linux 環(huán)境為例Windows 用 WSL 也可以。你需要裝這幾樣sudo apt update sudo apt install gcc-arm-none-eabi cmake ninja-build git python3然后拉取 MicroPython 源碼并編譯交叉編譯器git clone https://github.com/micropython/micropython.git cd micropython make -C mpy-cross make -C ports/rp2 submodules第一次編譯 RP2040 的固件會拉取 Pico SDK 等子模塊時間取決于網絡。全部準備好之后先編譯一次官方固件驗證環(huán)境make -C ports/rp2 BOARDPICO如果能在ports/rp2/build-PICO/firmware.uf2看到輸出說明環(huán)境沒問題。之后我們把自定義模塊加進去重新編譯就行。3.2 把自定義模塊塞進固件MicroPython 的 RP2040 端口支持通過 CMake 把你自己的 C 模塊編譯進固件。我習慣在ports/rp2下新建一個dma_uart目錄里面放dma_uart.c和一個micropython.cmake文件。micropython.cmake的內容很簡單add_library(dma_uart_module INTERFACE) target_sources(dma_uart_module INTERFACE ${CMAKE_CURRENT_LIST_DIR}/dma_uart.c ) target_include_directories(dma_uart_module INTERFACE ${CMAKE_CURRENT_LIST_DIR}) target_link_libraries(usermod INTERFACE dma_uart_module)然后在ports/rp2的micropython.cmake文件里加一行include把你這個子文件引進來。不同 MicroPython 版本引入用戶模塊的方式稍有差異我寫這篇文章對應的是當前比較新的版本用的是MP_REGISTER_MODULE注冊方式。如果你是舊版本可能需要去mpconfigport.h里手動加模塊聲明具體看官方文檔里cmodules.rst的說明。3.3 C 核心代碼下面是我用的核心代碼做了簡化重點是說明 DMA 配置思路。這個模塊目前只支持 UART0 的 RX DMA 接收你完全可以照著擴展成發(fā)送或者雙通道版本。#include py/runtime.h #include hardware/dma.h #include hardware/uart.h #include pico/stdlib.h typedef struct _dma_uart_obj_t { mp_obj_base_t base; mp_obj_t buf_obj; // 保存 Python 端 buffer 引用防止被 GC 回收 uint8_t *buf; size_t len; size_t received; uint channel; bool claimed; volatile bool done; } dma_uart_obj_t; STATIC dma_uart_obj_t dma_uart_obj; static void dma_uart_irq_handler(void) { if (dma_channel_get_irq0_status(dma_uart_obj.channel)) { dma_channel_acknowledge_irq0(dma_uart_obj.channel); dma_uart_obj.received dma_uart_obj.len; dma_uart_obj.done true; } } STATIC mp_obj_t dma_uart_start(mp_obj_t buf_in, mp_obj_t len_in) { mp_buffer_info_t bufinfo; mp_get_buffer_raise(buf_in, bufinfo, MP_BUFFER_WRITE); size_t len mp_obj_get_int(len_in); if (len bufinfo.len) { len bufinfo.len; } if (!dma_uart_obj.claimed) { dma_uart_obj.channel dma_channel_claim_unused(true); dma_uart_obj.claimed true; } dma_uart_obj.buf_obj buf_in; dma_uart_obj.buf (uint8_t *)bufinfo.buf; dma_uart_obj.len len; dma_uart_obj.received 0; dma_uart_obj.done false; dma_channel_config c dma_channel_get_default_config(dma_uart_obj.channel); channel_config_set_transfer_data_size(c, DMA_SIZE_8); channel_config_set_read_increment(c, false); channel_config_set_write_increment(c, true); channel_config_set_dreq(c, DREQ_UART0_RX); dma_channel_configure(dma_uart_obj.channel, c, dma_uart_obj.buf, uart_get_hw(uart0)-dr, dma_uart_obj.len, true); dma_channel_set_irq0_enabled(dma_uart_obj.channel, true); irq_set_exclusive_handler(DMA_IRQ_0, dma_uart_irq_handler); irq_set_enabled(DMA_IRQ_0, true); return mp_const_none; } STATIC MP_DEFINE_CONST_FUN_OBJ_2(dma_uart_start_obj, dma_uart_start); STATIC mp_obj_t dma_uart_done(void) { return mp_obj_new_bool(dma_uart_obj.done); } STATIC MP_DEFINE_CONST_FUN_OBJ_0(dma_uart_done_obj, dma_uart_done); STATIC mp_obj_t dma_uart_received(void) { return mp_obj_new_int(dma_uart_obj.received); } STATIC MP_DEFINE_CONST_FUN_OBJ_0(dma_uart_received_obj, dma_uart_received); STATIC const mp_rom_map_elem_t dma_uart_module_globals_table[] { { MP_ROM_QSTR(MP_QSTR_start), MP_ROM_PTR(dma_uart_start_obj) }, { MP_ROM_QSTR(MP_QSTR_done), MP_ROM_PTR(dma_uart_done_obj) }, { MP_ROM_QSTR(MP_QSTR_received), MP_ROM_PTR(dma_uart_received_obj) }, }; STATIC MP_DEFINE_CONST_DICT(dma_uart_module_globals, dma_uart_module_globals_table); const mp_obj_module_t dma_uart_user_cmodule { .base { mp_type_module }, .globals (mp_obj_dict_t *)dma_uart_module_globals, }; MP_REGISTER_MODULE(MP_QSTR_dma_uart, dma_uart_user_cmodule);這里有幾個關鍵點要解釋一下。read_increment必須設置為false因為 UART 的 DR 寄存器地址是固定的DMA 每次讀同一個地址就相當于取走 RX FIFO 里的一個字節(jié)。write_increment必須設置為true因為我們要把數據連續(xù)寫入內存。DREQ_UART0_RX是 UART0 接收觸發(fā)源DMA 只在有數據可讀的時候才搬運不會讀空 FIFO。中斷服務函數里只做三件事確認中斷、記錄接收長度、把done標志置位。我沒有在中斷里直接調用 Python 回調因為 MicroPython 的中斷環(huán)境里直接跑 Python 代碼是不安全的容易觸發(fā)重入或者內存管理問題。用輪詢標志位的方式雖然看起來不那么“高級”但在實際工程里非常穩(wěn)。3.4 MicroPython 腳本里怎么用固件編譯燒錄好之后Python 腳本就非常簡單了。我演示一個 UART0 接收的例子import dma_uart from machine import UART, Pin import time uart UART(0, baudrate115200, txPin(0), rxPin(1)) buf bytearray(256) dma_uart.start(buf, 256) # 等待完成支持 machine.idle() 就優(yōu)先用 idleDMA 中斷會喚醒 CPU while not dma_uart.done(): try: machine.idle() except AttributeError: time.sleep_ms(1) print(received bytes:, dma_uart.received()) print(buf[:dma_uart.received()])如果你的固件支持machine.idle()在等待時 CPU 會進入低功耗模式DMA 完成中斷會把它喚醒這樣等待期間幾乎不耗 CPU。如果確實不支持退而求其次用time.sleep_ms(1)也可以但對實時性要求極高的場景還是建議用 idle。注意一點這個示例默認 PC 會發(fā)滿 256 字節(jié)。如果你的數據是不定長的DMA 傳輸長度設置成 256數據不夠 256 字節(jié)時 DMA 永遠都不會完成你需要自己加超時判斷。這個坑下面會細說。3.5 和普通中斷方式的簡單對比測試驗證是否真的省 CPU可以做一個很樸素的實驗讓 Pico 循環(huán)處理一個等待 DMA 的任務同時在等待期間跑一個純 Python 計數循環(huán)看丟不丟數據。count 0 dma_uart.start(buf, 256) while not dma_uart.done(): count 1 if count % 100000 0: print(still counting, count) print(done, count , count)如果 DMA 配置正常即使主循環(huán)一直在做 100000 次計數的大循環(huán)UART 數據也不會丟。這就是“零 CPU 負擔”最直觀的體現。如果用普通uart.read()或者uart.any()循環(huán)去收數據主循環(huán)根本不可能跑這么重的任務。我做過的實測里115200 波特率下連續(xù)發(fā) 1KB 數據普通中斷模式會出現大量時間碎片主循環(huán)任務被頻繁打斷改用 DMA 后主循環(huán)在 DMA 搬運期間可以連續(xù)執(zhí)行其他邏輯只有最后處理數據時才介入一次。4. 常見問題與排查技巧實錄4.1 數據錯位、丟字節(jié)、DMA 不結束先列幾個最容易踩的坑。第一源地址配錯。DMA 的讀地址一定要指向 UART 的 DR 數據寄存器而不是 UART 的外設基地址。在 C 代碼里我用的是uart_get_hw(uart0)-dr如果你用machine.mem32或者從舊工程復制代碼很可能寫成UART0_BASE這種地址數據就會亂。第二read_increment被誤設成true。這個錯誤特別隱蔽因為看起來 DMA 工作正常但每次讀數據都會從 UART 寄存器地址遞增偏移讀到后續(xù)寄存器里的隨機值。表現就是第一個字節(jié)對后面全亂。第三DMA 傳輸長度大于實際收到的數據量。如果你的協議不是固定幀長比如 PC 只發(fā) 10 個字節(jié)但 DMA 配置成接收 256 字節(jié)DMA 會一直等永遠不完成。這種情況必須在應用層做超時處理。Python 側可以這樣做dma_uart.start(buf, 256) deadline time.ticks_ms() 500 while not dma_uart.done(): if time.ticks_diff(deadline, time.ticks_ms()) 0: break if not dma_uart.done(): print(timeout, stale bytes?, dma_uart.received())超時后 DMA 可能已經收了部分數據進 buffer但是done是 false你要根據received()的值決定是否保留這幀數據。如果確實需要取消 DMA最好在 C 模塊里加一個abort()函數調用dma_channel_abort。4.2 變長數據怎么判斷一幀結束很多從 STM32 轉過來的朋友第一個念頭就是找“接收空閑中斷”。RP2040 的硬件 UART 并沒有和 STM32 完全等價的空閑中斷所以不能直接照搬那套“DMA 空閑中斷接收不定長數據”的代碼。我的做法是DMA 負責把數據搬進一個大緩沖區(qū)同時用一個 MicroPython 定時器或者主循環(huán)里的超時判斷來模擬“線路空閑”。每次 DMA 完成一個接收任務就重置計時器如果超過設定時間沒有新的 DMA 完成就認為當前幀結束了。整體流程大概是啟動 DMA 接收固定最大長度收到數據且 DMA 完成后處理數據并把下一個新 DMA 任務啟動如果在兩個 DMA 完成之間超過了你設定的幀間隔就判定為幀結束。這種方式不用硬件空閑中斷邏輯也直觀。4.3 緩存對象被 GC 回收DMA 還在寫這是自定義 C 模塊最容易翻車的地方。如果你只在 C 模塊里保存uint8_t *buf指針不保存 Python 對象的引用那么當 Python 側的bytearray變量被重新賦值或者跳出作用域之后這塊內存可能被 MicroPython 的垃圾回收器回收掉。DMA 這時候還傻乎乎地往那塊地址寫數據結果就是內存損壞、系統(tǒng)崩潰。所以我上面的 C 代碼里專門加了一行dma_uart_obj.buf_obj buf_in;把 Python 傳來的 buffer 對象保存在全局結構體里保持一個強引用。只要模塊本身不被卸載這個對象就不會被 GC 收走。如果你不想在 C 模塊里保存 Python 對象也可以用 C 模塊內部靜態(tài)數組當作 DMA 緩沖區(qū)再通過memoryview暴露給 Python這樣生命周期完全可控代價是緩沖區(qū)大小固定。4.4 DMA 通道沖突與多串口擴展RP2040 有 12 個 DMA 通道看起來很多但 MicroPython 內部可能已經有其他功能在占用。比如某些固件的 USB 驅動、PIO、ADC 都可能用到 DMA只是沒有被公開文檔寫清楚。所以自定義模塊不要硬編碼通道號應該用dma_channel_claim_unused(true)動態(tài)申請。如果你要同時做 UART0 接收、UART1 發(fā)送、ADC 連續(xù)采樣就需要在模塊里維護多個 DMA 通道。建議每個功能獨占一個通道中斷號也可以分開比如通道 0 到 5 用DMA_IRQ_0通道 6 到 11 用DMA_IRQ_1避免中斷服務函數里判斷太多通道狀態(tài)。通道不用的時候記得釋放否則多次start之后通道就耗盡。4.5 問題速查表現象可能原因解決辦法完全收不到數據UART 發(fā)送端沒接對、波特率不一致、UART RX 引腳錯誤先用uart.read()循環(huán)測試排除 DMA 問題DMA 永遠不完成傳輸計數大于實際數據長度加超時邏輯或者改用固定幀長協議數據錯位read_increment誤設為 trueDREQ 配錯檢查 DMA 配置源地址固定目的地址遞增接收完無法再次啟動DMA 通道完成一次后計數變成 0每次start都重新調用dma_channel_configureimport dma_uart報錯固件沒有正確編譯模塊檢查 CMake 包含路徑和MP_REGISTER_MODULE聲明主循環(huán)頻繁卡死中斷服務函數里執(zhí)行了 Python 回調中斷里只置標志位用輪詢或mp_sched_schedule調度回調5. 進一步優(yōu)化與擴展思路5.1 雙緩沖實現無間斷接收單緩沖區(qū)的問題在于DMA 正在填 buffer 的時候你沒法安全地處理這個 buffer。等 DMA 完成再處理這段時間內新到的數據可能無處可放。解決方法是雙緩沖。準備兩個同樣大小的 bytearray一個當前被 DMA 使用另一個給主循環(huán)處理。DMA 填完 A 后立刻切到 B主循環(huán)同時處理 A 里已經收好的數據。這樣可以做到“邊收邊處理”基本不會因為處理時間過長而丟下一幀數據。邏輯很簡單bufs [bytearray(256), bytearray(256)] cur 0 while True: dma_uart.start(bufs[cur], 256) while not dma_uart.done(): machine.idle() # 切換當前緩沖交給業(yè)務處理另一個緩沖啟動 DMA handle_data(bufs[cur]) cur 1 - cur實際運行中handle_data如果比較快比如只是把數據塞進隊列這個方案非常穩(wěn)。如果handle_data很慢那就要引入第三個緩沖區(qū)或者環(huán)形隊列做緩沖總之別讓業(yè)務處理阻塞 DMA 太久。5.2 把同一套 DMA 邏輯擴展到 ADC 和 PWM知道 UART 怎么用 DMA其他外設基本就是換幾個參數的事。比如要做 ADC 連續(xù)采樣DMA 的源地址改為 ADC 的 FIFO 數據寄存器DREQ 改為DREQ_ADC其他配置不變。要播放一段 PWM 波形DMA 的源地址改成內存里的波形表目的地址改成 PWM 的 CC 寄存器DREQ 用 PWM 的請求信號。RP2040 這套 DMA 設計得很統(tǒng)一核心的理解成本就一次。我在項目里用過 DMA 把預先生成的正弦波表不斷搬到 PWM 模塊實現了不占用 CPU 的音頻信號輸出。本質上和串口發(fā)送沒有區(qū)別都是地址、計數、DREQ 三個核心要素。5.3 MicroPython 固件版本差異最后提醒一句MicroPython 版本更新很快。早期 RP2040 端口的模塊注冊方式和現在差別不小比如 1.19 時代可能需要在mpconfigport.h里手動聲明模塊而新版本更推薦用MP_REGISTER_MODULE。我在文章里的代碼基于當前常見的新版本如果你編譯時報錯優(yōu)先去 MicroPython 官方的docs/develop/cmodules.rst文檔里對照一下。別硬抄CMake 和注冊方式差一個字母都會導致import失敗。踩過幾次編譯坑之后我的經驗是先用最小模塊跑通比如只導出一個hello()函數燒固件驗證import沒問題再逐步往里面加 DMA、加中斷、加雙緩沖。這樣排查問題會容易很多。真正把 DMA 跑起來之后你會覺得“零 CPU 干預”這句話值回票價——主循環(huán)再也不會被一串串的串口數據打斷得雞飛狗跳了。 RP2040 MicroPython實現UART DMA零CPU干預實戰(zhàn)
有朋友在群里問RP2040 上跑 MicroPythonUART 能不能做到 DMA 搬運、CPU 徹底撒手我第一反應是能但別指望標準固件會給你現成接口。RP2040 的 DMA 控制器是真的正經外設只是 MicroPython 官方固件默認不暴露 DMA API所以這事得自己動手。這篇內容我會把 RP2040 DMA 的原理、UART 的零 CPU 干預怎么實現、以及我在 MicroPython 固件里加自定義 C 模塊的完整過程都拆開講清楚。適合已經在用 MicroPython 寫 Pico 程序、覺得串口收發(fā)占 CPU、想用 DMA 又不知道從哪下手的開發(fā)者?？赐曛辽倌苷罩桨赴炎詈唵蔚?DMA 串口接收跑起來。1. 為什么要把 UART 交給 DMA1.1 RP2040 的 DMA 控制器到底是什么水平很多人一聽“單片機上的 DMA”第一反應是 STM32 那套。實際上 RP2040 的 DMA 配置能力相當完整有 12 個獨立通道每個通道都可以單獨設置源地址、目的地址、傳輸計數和數據寬度。數據寬度支持 8 位、16 位、32 位也就是字節(jié)、半字、字三種粒度。它還能配置地址遞增方式可以固定源地址、遞增目的地址也可以反過來。最關鍵的一點是RP2040 的 DMA 請求可以由外設直接觸發(fā)。UART、SPI、I2C、ADC、PIO 狀態(tài)機這些外設都會產生 DREQ 信號DMA 收到 DREQ 才搬一次數據。這就意味著 DMA 不需要 CPU 干預也不需要 CPU 用定時器去“猜”外設什么時候有數據。只要外設準備好了硬件就會自動完成一次搬運。另外RP2040 DMA 還支持通道鏈式觸發(fā)一個通道完成后可以自動觸發(fā)另一個通道配合雙緩沖、多段數據搬運很方便。它這個鏈式機制不是部分高端芯片那種完整的內存描述符鏈表但已經足夠應付絕大多數嵌入式場景。對 UART 來說我們通常只關心三個東西源地址、目的地址、傳輸計數再配一個 DREQ 觸發(fā)源剩下交給硬件就行。1.2 傳統(tǒng) UART 收發(fā)為什么費 CPU先算一筆賬。串口 115200 波特率、8N1 格式每字節(jié)實際占用 10 bit那么 1 秒最多傳輸 11520 字節(jié)。如果用最簡單的每字節(jié)觸發(fā)一次中斷中斷頻率就是每秒 11520 次。 RP2040 主頻 133MHz處理一次中斷壓棧、進中斷服務函數、讀 FIFO、清標志、再恢復現場時間雖然很短但高負載下還是會影響主循環(huán)。如果同時開兩三個串口或者在一個中斷里去解析數據協議主循環(huán)的實時性就會下降。發(fā)送側也一樣。你要把一個 1KB 的 buffer 發(fā)出去傳統(tǒng)寫法是一個字節(jié)一個字節(jié)往 UART 的 TX FIFO 寫。就算 FIFO 能緩存一部分數據中間也免不了判斷 FIFO 是否滿、是否需要等。這些操作本身不復雜但頻率一高就會碎片化占用 CPU。DMA 的思路是把“搬數據”這件事完全交給硬件。發(fā)送時CPU 只需要設置 DMA 把內存數據搬進 UART 的發(fā)送 FIFO發(fā)完后 DMA 產生一次中斷接收時DMA 自動把 RX FIFO 里的數據搬進內存收到預定長度后產生一次中斷。整個傳輸過程中CPU 不參與逐字節(jié)搬運所以叫“零 CPU 干預”。注意這個零不是絕對意義上的 CPU 完全休眠而是沒有逐字節(jié)參與最后該有的完成中斷還是會有。1.3 MicroPython 在這件事上的特殊尷尬MicroPython 的問題在于官方 RP2040 固件把 DMA 藏得很深。你打開machine.UART的源碼能看到它內部其實用了 Pico SDK 的底層驅動但上層暴露給你的只有read()、write()、any()這些方法。這些方法內部處理了中斷和緩沖區(qū)對用戶看起來確實“好用”但 CPU 并不是零負擔。還有不少人嘗試用machine.mem32直接操作 DMA 寄存器。這個思路很直接RP2040 的寄存器地址都是公開的理論上你可以用 Python 把 DMA 通道配置出來。但實際跑起來會發(fā)現幾個問題一是 Python 解釋執(zhí)行寄存器操作太慢配置十幾個寄存器可能就要幾百微秒二是你沒法在 DMA 中斷服務函數里穩(wěn)定地跑 Python 回調稍不留神就會死機或者漏數據。所以要玩真正的 DMA最靠譜的路線不是硬用純 Python 去操作寄存器而是給 MicroPython 編譯一個自定義 C 擴展模塊把 DMA 能力封裝成幾個 Python 函數。后面我會詳細講這條路。2. 零 CPU 數據傳輸的方案選型與原理拆解2.1 方案一C SDK 直接寫不繞彎如果項目沒有“必須用 MicroPython”這個限制那最正統(tǒng)的方案當然是直接用 C 寫Pico SDK 提供了完整的 DMA API。接收流程大概是這樣的int ch dma_channel_claim_unused(true); dma_channel_config c dma_channel_get_default_config(ch); channel_config_set_transfer_data_size(c, DMA_SIZE_8); channel_config_set_read_increment(c, false); channel_config_set_write_increment(c, true); channel_config_set_dreq(c, DREQ_UART0_RX); uint8_t buf[256]; dma_channel_configure(ch, c, buf, // 目的地址內存 uart_get_hw(uart0)-dr, // 源地址UART 數據寄存器 256, // 傳輸計數 true); // 立即啟動這段 C 代碼做的事非常清晰DMA 通道源地址固定指向 UART0 的 DR 寄存器目的地址遞增指向內存?zhèn)鬏?256 字節(jié)每傳一個字節(jié)就通過DREQ_UART0_RX等待 UART 收到新數據。完成后你可以自己寫一個 DMA 中斷服務函數置一個標志位讓主循環(huán)去處理數據。用 C SDK 寫這個問題不大但很多人就是不想放棄 MicroPython因為業(yè)務邏輯用 Python 寫實在是太快了。所以如果既要 MicroPython又要 DMA那就得走下面的方案二。2.2 方案二給 MicroPython 編譯 dma_uart 擴展模塊MicroPython 允許你在固件里加入 C 擴展模塊然后把模塊里的函數注冊成 Python 的 import 對象。比如我們可以做一個dma_uart模塊提供start()、done()、received()這幾個方法底層直接用 Pico SDK 的 DMA API上層 Python 代碼只管調用。這個方案的原理并不復雜。MicroPython 本質上是一個 C 程序它執(zhí)行 Python 字節(jié)碼同時也能調用編譯進固件的 C 函數。我們寫一個 C 文件把 DMA 初始化和中斷處理封裝好再用 MicroPython 的模塊注冊機制掛到系統(tǒng)里。編譯固件之后Python 里import dma_uart就能找到這個模塊。好處是DMA 的實時性要求由 C 代碼保證Python 側不需要高頻操作寄存器而業(yè)務邏輯、協議解析、UI 交互這些不要求實時的部分還是可以繼續(xù)用 Python。壞處是你需要花點時間搭一套交叉編譯環(huán)境第一次編譯固件會有點折騰。2.3 方案三PIO 狀態(tài)機不是 DMA聊到 RP2040總有人會問“能不能用 PIO 替代 DMA”。PIO 是 RP2040 獨有的一組可編程 IO 狀態(tài)機可以自己編指令模擬 UART、SPI、I2C、WS2812 這類協議。它的靈活性確實很高但它和 DMA 解決的問題不一樣。PIO 狀態(tài)機有自己的 RX/TX FIFO數據會流進狀態(tài)機的 FIFO但把 FIFO 里的數據搬到內存仍然需要 CPU 或者 DMA。也就是說PIO 解決了“如何按協議收發(fā)”的問題DMA 解決了“如何不經過 CPU 搬數據”的問題。 MicroPython 的rp2.PIO類能讓你加載 PIO 程序但不會直接給你一個“讓 PIO FIFO 自動搬到 buffer”的高層接口。大多數情況下你還是要通過 PIO 中斷或輪詢去讀取數據CPU 并沒有真正解放。如果你的目標是 UART 零 CPU 干預那就老老實實用硬件 UART 加 DMA別在 PIO 上繞圈子。2.4 選型結論把三個方案放一起對比一下方案CPU 占用實現難度適合場景C SDK 直接寫極低中純 C 工程需要最高性能MicroPython 自定義 DMA 模塊極低較高想用 Python 寫業(yè)務又需要 DMAMicroPython 純 Python 操作寄存器高高不建議只適合學習寄存器原理我自己的建議是如果只是 9600 波特率收發(fā)幾字節(jié)傳感器數據machine.UART那點 CPU 開銷根本不用在意但如果你要跑 115200 甚至更高波特率還要連續(xù)收發(fā)大塊數據或者主循環(huán)同時要處理顯示、網絡、按鍵那 DMA 模塊就值得折騰。3. 實操過程手寫一個 dma_uart 模塊并跑通3.1 準備編譯環(huán)境第一步是準備編譯 MicroPython 固件的環(huán)境。這里以 Linux 環(huán)境為例Windows 用 WSL 也可以。你需要裝這幾樣sudo apt update sudo apt install gcc-arm-none-eabi cmake ninja-build git python3然后拉取 MicroPython 源碼并編譯交叉編譯器git clone https://github.com/micropython/micropython.git cd micropython make -C mpy-cross make -C ports/rp2 submodules第一次編譯 RP2040 的固件會拉取 Pico SDK 等子模塊時間取決于網絡。全部準備好之后先編譯一次官方固件驗證環(huán)境make -C ports/rp2 BOARDPICO如果能在ports/rp2/build-PICO/firmware.uf2看到輸出說明環(huán)境沒問題。之后我們把自定義模塊加進去重新編譯就行。3.2 把自定義模塊塞進固件MicroPython 的 RP2040 端口支持通過 CMake 把你自己的 C 模塊編譯進固件。我習慣在ports/rp2下新建一個dma_uart目錄里面放dma_uart.c和一個micropython.cmake文件。micropython.cmake的內容很簡單add_library(dma_uart_module INTERFACE) target_sources(dma_uart_module INTERFACE ${CMAKE_CURRENT_LIST_DIR}/dma_uart.c ) target_include_directories(dma_uart_module INTERFACE ${CMAKE_CURRENT_LIST_DIR}) target_link_libraries(usermod INTERFACE dma_uart_module)然后在ports/rp2的micropython.cmake文件里加一行include把你這個子文件引進來。不同 MicroPython 版本引入用戶模塊的方式稍有差異我寫這篇文章對應的是當前比較新的版本用的是MP_REGISTER_MODULE注冊方式。如果你是舊版本可能需要去mpconfigport.h里手動加模塊聲明具體看官方文檔里cmodules.rst的說明。3.3 C 核心代碼下面是我用的核心代碼做了簡化重點是說明 DMA 配置思路。這個模塊目前只支持 UART0 的 RX DMA 接收你完全可以照著擴展成發(fā)送或者雙通道版本。#include py/runtime.h #include hardware/dma.h #include hardware/uart.h #include pico/stdlib.h typedef struct _dma_uart_obj_t { mp_obj_base_t base; mp_obj_t buf_obj; // 保存 Python 端 buffer 引用防止被 GC 回收 uint8_t *buf; size_t len; size_t received; uint channel; bool claimed; volatile bool done; } dma_uart_obj_t; STATIC dma_uart_obj_t dma_uart_obj; static void dma_uart_irq_handler(void) { if (dma_channel_get_irq0_status(dma_uart_obj.channel)) { dma_channel_acknowledge_irq0(dma_uart_obj.channel); dma_uart_obj.received dma_uart_obj.len; dma_uart_obj.done true; } } STATIC mp_obj_t dma_uart_start(mp_obj_t buf_in, mp_obj_t len_in) { mp_buffer_info_t bufinfo; mp_get_buffer_raise(buf_in, bufinfo, MP_BUFFER_WRITE); size_t len mp_obj_get_int(len_in); if (len bufinfo.len) { len bufinfo.len; } if (!dma_uart_obj.claimed) { dma_uart_obj.channel dma_channel_claim_unused(true); dma_uart_obj.claimed true; } dma_uart_obj.buf_obj buf_in; dma_uart_obj.buf (uint8_t *)bufinfo.buf; dma_uart_obj.len len; dma_uart_obj.received 0; dma_uart_obj.done false; dma_channel_config c dma_channel_get_default_config(dma_uart_obj.channel); channel_config_set_transfer_data_size(c, DMA_SIZE_8); channel_config_set_read_increment(c, false); channel_config_set_write_increment(c, true); channel_config_set_dreq(c, DREQ_UART0_RX); dma_channel_configure(dma_uart_obj.channel, c, dma_uart_obj.buf, uart_get_hw(uart0)-dr, dma_uart_obj.len, true); dma_channel_set_irq0_enabled(dma_uart_obj.channel, true); irq_set_exclusive_handler(DMA_IRQ_0, dma_uart_irq_handler); irq_set_enabled(DMA_IRQ_0, true); return mp_const_none; } STATIC MP_DEFINE_CONST_FUN_OBJ_2(dma_uart_start_obj, dma_uart_start); STATIC mp_obj_t dma_uart_done(void) { return mp_obj_new_bool(dma_uart_obj.done); } STATIC MP_DEFINE_CONST_FUN_OBJ_0(dma_uart_done_obj, dma_uart_done); STATIC mp_obj_t dma_uart_received(void) { return mp_obj_new_int(dma_uart_obj.received); } STATIC MP_DEFINE_CONST_FUN_OBJ_0(dma_uart_received_obj, dma_uart_received); STATIC const mp_rom_map_elem_t dma_uart_module_globals_table[] { { MP_ROM_QSTR(MP_QSTR_start), MP_ROM_PTR(dma_uart_start_obj) }, { MP_ROM_QSTR(MP_QSTR_done), MP_ROM_PTR(dma_uart_done_obj) }, { MP_ROM_QSTR(MP_QSTR_received), MP_ROM_PTR(dma_uart_received_obj) }, }; STATIC MP_DEFINE_CONST_DICT(dma_uart_module_globals, dma_uart_module_globals_table); const mp_obj_module_t dma_uart_user_cmodule { .base { mp_type_module }, .globals (mp_obj_dict_t *)dma_uart_module_globals, }; MP_REGISTER_MODULE(MP_QSTR_dma_uart, dma_uart_user_cmodule);這里有幾個關鍵點要解釋一下。read_increment必須設置為false因為 UART 的 DR 寄存器地址是固定的DMA 每次讀同一個地址就相當于取走 RX FIFO 里的一個字節(jié)。write_increment必須設置為true因為我們要把數據連續(xù)寫入內存。DREQ_UART0_RX是 UART0 接收觸發(fā)源DMA 只在有數據可讀的時候才搬運不會讀空 FIFO。中斷服務函數里只做三件事確認中斷、記錄接收長度、把done標志置位。我沒有在中斷里直接調用 Python 回調因為 MicroPython 的中斷環(huán)境里直接跑 Python 代碼是不安全的容易觸發(fā)重入或者內存管理問題。用輪詢標志位的方式雖然看起來不那么“高級”但在實際工程里非常穩(wěn)。3.4 MicroPython 腳本里怎么用固件編譯燒錄好之后Python 腳本就非常簡單了。我演示一個 UART0 接收的例子import dma_uart from machine import UART, Pin import time uart UART(0, baudrate115200, txPin(0), rxPin(1)) buf bytearray(256) dma_uart.start(buf, 256) # 等待完成支持 machine.idle() 就優(yōu)先用 idleDMA 中斷會喚醒 CPU while not dma_uart.done(): try: machine.idle() except AttributeError: time.sleep_ms(1) print(received bytes:, dma_uart.received()) print(buf[:dma_uart.received()])如果你的固件支持machine.idle()在等待時 CPU 會進入低功耗模式DMA 完成中斷會把它喚醒這樣等待期間幾乎不耗 CPU。如果確實不支持退而求其次用time.sleep_ms(1)也可以但對實時性要求極高的場景還是建議用 idle。注意一點這個示例默認 PC 會發(fā)滿 256 字節(jié)。如果你的數據是不定長的DMA 傳輸長度設置成 256數據不夠 256 字節(jié)時 DMA 永遠都不會完成你需要自己加超時判斷。這個坑下面會細說。3.5 和普通中斷方式的簡單對比測試驗證是否真的省 CPU可以做一個很樸素的實驗讓 Pico 循環(huán)處理一個等待 DMA 的任務同時在等待期間跑一個純 Python 計數循環(huán)看丟不丟數據。count 0 dma_uart.start(buf, 256) while not dma_uart.done(): count 1 if count % 100000 0: print(still counting, count) print(done, count , count)如果 DMA 配置正常即使主循環(huán)一直在做 100000 次計數的大循環(huán)UART 數據也不會丟。這就是“零 CPU 負擔”最直觀的體現。如果用普通uart.read()或者uart.any()循環(huán)去收數據主循環(huán)根本不可能跑這么重的任務。我做過的實測里115200 波特率下連續(xù)發(fā) 1KB 數據普通中斷模式會出現大量時間碎片主循環(huán)任務被頻繁打斷改用 DMA 后主循環(huán)在 DMA 搬運期間可以連續(xù)執(zhí)行其他邏輯只有最后處理數據時才介入一次。4. 常見問題與排查技巧實錄4.1 數據錯位、丟字節(jié)、DMA 不結束先列幾個最容易踩的坑。第一源地址配錯。DMA 的讀地址一定要指向 UART 的 DR 數據寄存器而不是 UART 的外設基地址。在 C 代碼里我用的是uart_get_hw(uart0)-dr如果你用machine.mem32或者從舊工程復制代碼很可能寫成UART0_BASE這種地址數據就會亂。第二read_increment被誤設成true。這個錯誤特別隱蔽因為看起來 DMA 工作正常但每次讀數據都會從 UART 寄存器地址遞增偏移讀到后續(xù)寄存器里的隨機值。表現就是第一個字節(jié)對后面全亂。第三DMA 傳輸長度大于實際收到的數據量。如果你的協議不是固定幀長比如 PC 只發(fā) 10 個字節(jié)但 DMA 配置成接收 256 字節(jié)DMA 會一直等永遠不完成。這種情況必須在應用層做超時處理。Python 側可以這樣做dma_uart.start(buf, 256) deadline time.ticks_ms() 500 while not dma_uart.done(): if time.ticks_diff(deadline, time.ticks_ms()) 0: break if not dma_uart.done(): print(timeout, stale bytes?, dma_uart.received())超時后 DMA 可能已經收了部分數據進 buffer但是done是 false你要根據received()的值決定是否保留這幀數據。如果確實需要取消 DMA最好在 C 模塊里加一個abort()函數調用dma_channel_abort。4.2 變長數據怎么判斷一幀結束很多從 STM32 轉過來的朋友第一個念頭就是找“接收空閑中斷”。RP2040 的硬件 UART 并沒有和 STM32 完全等價的空閑中斷所以不能直接照搬那套“DMA 空閑中斷接收不定長數據”的代碼。我的做法是DMA 負責把數據搬進一個大緩沖區(qū)同時用一個 MicroPython 定時器或者主循環(huán)里的超時判斷來模擬“線路空閑”。每次 DMA 完成一個接收任務就重置計時器如果超過設定時間沒有新的 DMA 完成就認為當前幀結束了。整體流程大概是啟動 DMA 接收固定最大長度收到數據且 DMA 完成后處理數據并把下一個新 DMA 任務啟動如果在兩個 DMA 完成之間超過了你設定的幀間隔就判定為幀結束。這種方式不用硬件空閑中斷邏輯也直觀。4.3 緩存對象被 GC 回收DMA 還在寫這是自定義 C 模塊最容易翻車的地方。如果你只在 C 模塊里保存uint8_t *buf指針不保存 Python 對象的引用那么當 Python 側的bytearray變量被重新賦值或者跳出作用域之后這塊內存可能被 MicroPython 的垃圾回收器回收掉。DMA 這時候還傻乎乎地往那塊地址寫數據結果就是內存損壞、系統(tǒng)崩潰。所以我上面的 C 代碼里專門加了一行dma_uart_obj.buf_obj buf_in;把 Python 傳來的 buffer 對象保存在全局結構體里保持一個強引用。只要模塊本身不被卸載這個對象就不會被 GC 收走。如果你不想在 C 模塊里保存 Python 對象也可以用 C 模塊內部靜態(tài)數組當作 DMA 緩沖區(qū)再通過memoryview暴露給 Python這樣生命周期完全可控代價是緩沖區(qū)大小固定。4.4 DMA 通道沖突與多串口擴展RP2040 有 12 個 DMA 通道看起來很多但 MicroPython 內部可能已經有其他功能在占用。比如某些固件的 USB 驅動、PIO、ADC 都可能用到 DMA只是沒有被公開文檔寫清楚。所以自定義模塊不要硬編碼通道號應該用dma_channel_claim_unused(true)動態(tài)申請。如果你要同時做 UART0 接收、UART1 發(fā)送、ADC 連續(xù)采樣就需要在模塊里維護多個 DMA 通道。建議每個功能獨占一個通道中斷號也可以分開比如通道 0 到 5 用DMA_IRQ_0通道 6 到 11 用DMA_IRQ_1避免中斷服務函數里判斷太多通道狀態(tài)。通道不用的時候記得釋放否則多次start之后通道就耗盡。4.5 問題速查表現象可能原因解決辦法完全收不到數據UART 發(fā)送端沒接對、波特率不一致、UART RX 引腳錯誤先用uart.read()循環(huán)測試排除 DMA 問題DMA 永遠不完成傳輸計數大于實際數據長度加超時邏輯或者改用固定幀長協議數據錯位read_increment誤設為 trueDREQ 配錯檢查 DMA 配置源地址固定目的地址遞增接收完無法再次啟動DMA 通道完成一次后計數變成 0每次start都重新調用dma_channel_configureimport dma_uart報錯固件沒有正確編譯模塊檢查 CMake 包含路徑和MP_REGISTER_MODULE聲明主循環(huán)頻繁卡死中斷服務函數里執(zhí)行了 Python 回調中斷里只置標志位用輪詢或mp_sched_schedule調度回調5. 進一步優(yōu)化與擴展思路5.1 雙緩沖實現無間斷接收單緩沖區(qū)的問題在于DMA 正在填 buffer 的時候你沒法安全地處理這個 buffer。等 DMA 完成再處理這段時間內新到的數據可能無處可放。解決方法是雙緩沖。準備兩個同樣大小的 bytearray一個當前被 DMA 使用另一個給主循環(huán)處理。DMA 填完 A 后立刻切到 B主循環(huán)同時處理 A 里已經收好的數據。這樣可以做到“邊收邊處理”基本不會因為處理時間過長而丟下一幀數據。邏輯很簡單bufs [bytearray(256), bytearray(256)] cur 0 while True: dma_uart.start(bufs[cur], 256) while not dma_uart.done(): machine.idle() # 切換當前緩沖交給業(yè)務處理另一個緩沖啟動 DMA handle_data(bufs[cur]) cur 1 - cur實際運行中handle_data如果比較快比如只是把數據塞進隊列這個方案非常穩(wěn)。如果handle_data很慢那就要引入第三個緩沖區(qū)或者環(huán)形隊列做緩沖總之別讓業(yè)務處理阻塞 DMA 太久。5.2 把同一套 DMA 邏輯擴展到 ADC 和 PWM知道 UART 怎么用 DMA其他外設基本就是換幾個參數的事。比如要做 ADC 連續(xù)采樣DMA 的源地址改為 ADC 的 FIFO 數據寄存器DREQ 改為DREQ_ADC其他配置不變。要播放一段 PWM 波形DMA 的源地址改成內存里的波形表目的地址改成 PWM 的 CC 寄存器DREQ 用 PWM 的請求信號。RP2040 這套 DMA 設計得很統(tǒng)一核心的理解成本就一次。我在項目里用過 DMA 把預先生成的正弦波表不斷搬到 PWM 模塊實現了不占用 CPU 的音頻信號輸出。本質上和串口發(fā)送沒有區(qū)別都是地址、計數、DREQ 三個核心要素。5.3 MicroPython 固件版本差異最后提醒一句MicroPython 版本更新很快。早期 RP2040 端口的模塊注冊方式和現在差別不小比如 1.19 時代可能需要在mpconfigport.h里手動聲明模塊而新版本更推薦用MP_REGISTER_MODULE。我在文章里的代碼基于當前常見的新版本如果你編譯時報錯優(yōu)先去 MicroPython 官方的docs/develop/cmodules.rst文檔里對照一下。別硬抄CMake 和注冊方式差一個字母都會導致import失敗。踩過幾次編譯坑之后我的經驗是先用最小模塊跑通比如只導出一個hello()函數燒固件驗證import沒問題再逐步往里面加 DMA、加中斷、加雙緩沖。這樣排查問題會容易很多。真正把 DMA 跑起來之后你會覺得“零 CPU 干預”這句話值回票價——主循環(huán)再也不會被一串串的串口數據打斷得雞飛狗跳了。