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