在 ESP32-S3 上跑 MicroPython接一顆模擬氣壓傳感器只需要 1kHz 采樣按理說這點負載對雙核 240MHz 的芯片來說不算什么?？烧姘汛a跑起來就會發(fā)現(xiàn)主循環(huán)里的 OLED 刷新掉到每秒幾幀WiFi 偶爾直接斷連。問題不在傳感器也不在屏幕而是machine.ADC的阻塞式接口。每次read_u16()都是一個“啟動轉(zhuǎn)換 - 等結(jié)果 - 返回”的串行流程采樣期間 CPU 被死死摁住別的任務(wù)全部讓路。想在高采樣率下繼續(xù)干別的事就得把 ADC 從 CPU 手里摘出來讓 DMA 去當搬運工再用乒乓緩沖把“采集”和“處理”這兩件事重疊起來。這篇就圍繞這套方案展開適合正在被 MicroPython ADC 拖慢主循環(huán)卡脖子的開發(fā)者也適合想在嵌入式里把 DMA 和乒乓緩沖真正用明白的朋友。1. 先看問題阻塞式 ADC 到底在耗什么1.1 一段典型代碼的耗時拆解很多同學(xué)寫 ADC 讀取都是這種風格from machine import ADC, Pin import time adc ADC(Pin(35), attenADC.ATTN_11DB) samples [] while True: t0 time.ticks_us() for _ in range(100): samples.append(adc.read_u16()) dt time.ticks_diff(time.ticks_us(), t0) print(100 次采樣耗時:, dt, us) time.sleep_ms(500)這段代碼里read_u16()每一次返回一個 16 位整數(shù)看起來人畜無害。但如果在循環(huán)里把時間打出來100 次采樣在常見的 ESP32 MicroPython 固件上大約要 10~20ms。換算一下等效采樣率只有 5~10kHz而且在這 10~20ms 內(nèi)主循環(huán)幾乎什么都干不了不能刷屏、不能處理網(wǎng)絡(luò)、不能掃描按鍵。只要采樣率稍微提上去一點主循環(huán)就被 ADC 徹底綁架了。有人會說“我又不采音頻10Hz 慢采總行吧” 確實如果你只是測個電池電壓、環(huán)境溫度阻塞式采樣綽綽有余。但很多項目不是這樣的振動分析、電流波形、光電傳感器脈沖、音頻幅值檢測都需要幾 kHz 甚至幾十 kHz 的采樣率。這時候阻塞式 ADC 就成了整個系統(tǒng)最明顯的瓶頸而且這個瓶頸不是換一塊更快的 MCU 就能解決的因為問題出在軟件模型上。1.2 read_u16 背后到底發(fā)生了什么阻塞式 ADC 慢不能全賴 MicroPython底層硬件流程本身就不便宜。一次完整的read_u16()在硬件層面大致要經(jīng)歷這幾步配置 ADC 通道選擇要采的引腳、衰減系數(shù)、采樣時間這些寄存器每次都要重新寫。啟動單次轉(zhuǎn)換向 ADC 控制寄存器寫啟動位。等待轉(zhuǎn)換完成ADC 內(nèi)部逐次逼近寄存器SAR工作時CPU 要么輪詢狀態(tài)位要么干等中斷。讀取結(jié)果寄存器把 12 位或 16 位的轉(zhuǎn)換結(jié)果讀出來。返回給 MicroPython 虛擬機把 C 層的整數(shù)包裝成 Python 的int對象。中間還有 MicroPython 解釋器本身的開銷。每次調(diào)用read_u16()都要經(jīng)過 Python 虛擬機的函數(shù)調(diào)用分發(fā)、參數(shù)檢查、返回值封裝這些雖然只有幾微秒但累積起來相當可觀。更隱蔽的是某些固件為了讀數(shù)穩(wěn)定會對同一通道做多次采樣再取平均一次 API 調(diào)用可能內(nèi)部做了 8 次甚至 16 次轉(zhuǎn)換時間自然成倍上漲。所以阻塞式 ADC 的慢是“硬件轉(zhuǎn)換等待 寄存器操作 解釋器開銷”三者的疊加。CPU 在這個過程中全程在線等待沒有任何計算是有效的。1.3 實測多少采樣率會把主循環(huán)壓垮我手頭有一塊 ESP32-S3-DevKitC跑的是官方 MicroPython 固件測出來的典型數(shù)據(jù)大致如下單次采樣耗時參考采樣次數(shù)總耗時等效采樣率主循環(huán)狀態(tài)100 ~ 200 us101~2 ms5~10 kHz勉強能跑 UI100 ~ 200 us10010~20 ms5~10 kHz明顯卡頓100 ~ 200 us1000100~200 ms5~10 kHz幾乎死機不同固件、不同芯片差異很大但量級就在這。注意等效采樣率看起來不低但代價是 CPU 在這段時間內(nèi)完全不能做別的事。換句話說阻塞式 ADC 把“采樣”和“處理”強制變成了串行任務(wù)采一會、處理一會或者干脆把處理時間全部讓給采樣。這種設(shè)計在低頻慢采時沒問題一旦進入連續(xù)采集場景就必須換思路。2. 為什么 DMA 和乒乓緩沖能解這道題2.1 DMA 的定位只搬運不思考DMADirect Memory Access直譯過來就是“直接內(nèi)存訪問”。它的作用很簡單讓外設(shè)和內(nèi)存之間能直接傳數(shù)據(jù)不需要 CPU 一條一條地搬。ADC 連續(xù)采樣時每完成一次轉(zhuǎn)換結(jié)果可以自動寫入內(nèi)存里事先指定的地址。CPU 只需要在開始的時候配置好起始地址、要采多少個點、觸發(fā)源是什么然后就可以去干別的了。等 DMA 搬運完一整批數(shù)據(jù)再通過中斷通知 CPU 一聲。這個機制用生活里的事類比就是以前你去餐廳點了幾十道菜每上一道菜服務(wù)員都要跑到后廚催一遍你本人也一直盯著出菜口DMA 相當于在廚房和你的桌子之間裝了一條傳送帶所有菜做好之后自動送到指定位置全部到齊后按一次鈴你過去端菜就行。后廚忙著炒菜你忙著聊天互不干擾。需要澄清一點DMA 解放的是“搬運樣本”這個過程但樣本到了緩沖區(qū)之后后續(xù)的濾波、統(tǒng)計、顯示仍然要 CPU 處理。所謂“解放 CPU”不是說整個系統(tǒng)完全不需要 CPU而是 CPU 從“等待每個樣本”變成“批量處理一幀數(shù)據(jù)”從被采樣過程占死變成按塊接收任務(wù)。這個塊與塊之間的大段時間主循環(huán)可以自由支配。2.2 乒乓緩沖為什么必須給數(shù)據(jù)準備兩個家有了 DMA還要解決緩沖區(qū)競爭問題。假設(shè)只有一塊緩沖區(qū)DMA 往里面寫數(shù)據(jù)CPU 在另一個任務(wù)里讀這塊數(shù)據(jù)做處理會發(fā)生什么大概率是 CPU 剛讀到一半DMA 已經(jīng)把緩沖區(qū)后半段覆蓋了數(shù)據(jù)一塌糊涂。更麻煩的是CPU 處理完緩沖區(qū)后DMA 可能還在繼續(xù)寫你根本不知道它寫到哪了。乒乓緩沖Ping-Pong Buffer就是為這個問題設(shè)計的。它準備兩塊緩沖區(qū)比如 A 和 B規(guī)則如下DMA 當前只往 A 里寫當 A 寫滿觸發(fā)中斷程序把 DMA 的目標地址立刻切換到 BCPU 在此時開始處理 A 里的完整數(shù)據(jù)當 B 寫滿再次觸發(fā)中斷程序把 DMA 目標切回 ACPU 則處理 B。整個過程DMA 永遠有一塊“安全”的緩沖區(qū)可以寫CPU 也永遠有一塊“完整”的數(shù)據(jù)可以讀兩者通過角色互換避免了競爭。乒乓緩沖本質(zhì)上就是嵌入式里的“生產(chǎn)者-消費者”模型DMA 是生產(chǎn)者主循環(huán)是消費者兩塊緩沖區(qū)就是兩個交替流轉(zhuǎn)的倉庫。單一緩沖區(qū)等于只有一個箱子消費者搬貨時生產(chǎn)者必須停下乒乓緩沖給了兩個箱子你搬這箱我裝那箱誰也不用等誰。2.3 半傳輸中斷一塊緩沖也能模仿乒乓如果內(nèi)存非常緊張還有一個更省內(nèi)存的技巧利用 DMA 控制器的半傳輸中斷Half Transfer Interrupt。一塊緩沖區(qū)被 DMA 填充到一半時觸發(fā)一次中斷此時 CPU 處理前半段DMA 繼續(xù)往后寫等整個緩沖區(qū)寫滿再觸發(fā)一次完成中斷CPU 處理后半段。CPU 處理前半段時DMA 正在寫后半段兩者天然錯開。效果和乒乓緩沖幾乎一樣但只需要一半的內(nèi)存。代價是中斷頻率翻倍而且緩沖區(qū)長度必須能被“半滿”事件準確一分為二。實際項目中如果內(nèi)存允許我更推薦真正的乒乓雙緩沖邏輯更清晰不容易出錯只有你在內(nèi)存極其緊張的 MCU 上跑才考慮用半傳輸中斷省那幾 KB。3. MicroPython 沒有現(xiàn)成的 DMA API怎么把方案落地3.1 先接受一個事實內(nèi)置 machine.ADC 不開放 DMA這里要潑一盆冷水官方主線 MicroPython 的machine.ADC并沒有開放 DMA 相關(guān)參數(shù)你沒法在一個普通固件里直接寫adc ADC(...); adc.read_dma()這樣的代碼。這是 MicroPython 解釋器層面的設(shè)計取舍為了保持 API 簡潔犧牲了底層外設(shè)能力的暴露。但這不代表標題里的方案是空談。實際落地有幾種現(xiàn)實可行的路線核心思路都是既然 MicroPython 的 Python 層碰不到 DMA那就把 DMA 相關(guān)的底層邏輯用 C 擴展封裝起來給 Python 層留一個干凈接口。如果你完全不想碰 C也有繞開內(nèi)置 ADC 的外設(shè)替代方案。下面三條路線我都實測過或拆解過按推薦程度依次講。3.2 路線 ARP2040 上用 PIO 做采樣時鐘DMA 交給 C 擴展樹莓派 Pico 的 RP2040 有個很大的優(yōu)勢MicroPython 的rp2.PIO模塊可以直接編程序控制狀態(tài)機?？梢杂?PIO 產(chǎn)生穩(wěn)定的采樣觸發(fā)脈沖讓 ADC 按照精確的時間間隔采樣然后配置 DMA 從 ADC 結(jié)果寄存器把數(shù)據(jù)搬到內(nèi)存。PIO 部分可以完全用 Python 寫from rp2 import PIO, StateMachine, asm_pio from machine import Pin asm_pio(sideset_initPIO.OUT_LOW) def adc_clk(): # 每兩個時鐘周期輸出一個正脈沖觸發(fā) ADC 采樣 nop().side(1) nop().side(0) sm StateMachine(0, adc_clk, freq200_000, sideset_basePin(10)) sm.active(1)這個 PIO 狀態(tài)機只是產(chǎn)生采樣時鐘真正的 DMA 搬移還是需要 C 擴展來完成。RP2040 的 SDK 提供了dma_channel_configure、dma_channel_start這些函數(shù)在 C 擴展里配置 DMA 從 ADC FIFO 讀數(shù)據(jù)寫到乒乓緩沖區(qū)滿了以后切換目標并觸發(fā) Python 層可以輪詢的標志。整體思路不復(fù)雜但前提是你得接受寫一點 C 代碼。3.3 路線 BESP32 上寫 C 擴展把 ADC 連續(xù)模式封裝成模塊ESP32 系列最舒服的做法是走 ESP-IDF 的adc_continuous驅(qū)動。這個驅(qū)動底層就是 ADC DMA 連續(xù)采集支持多通道、可配置頻率、可配置幀大小。在 MicroPython 里通過 usermodule 機制寫一個 C 擴展把adc_continuous包裝成 Python 可調(diào)用的接口就能拿到完整的 DMA 采集能力。MicroPython 官方倉庫的examples/usercmodule目錄就是現(xiàn)成的工程模板。C 擴展的核心結(jié)構(gòu)大致如下// 偽代碼骨架ESP32-S3 ADC continuous MicroPython usermodule #include esp_adc/adc_continuous.h #include py/runtime.h static adc_continuous_handle_t adc_handle; static uint8_t pingpong_buf[2][4096]; static volatile int current_write 0; static volatile int ready_buf -1; static bool IRAM_ATTR adc_cb(adc_continuous_handle_t handle, const adc_continuous_data_t *data, size_t len, void *user_data) { // 在中斷回調(diào)里只標記數(shù)據(jù)就緒不做 Python 回調(diào) ready_buf current_write; current_write ^ 1; return true; } STATIC mp_obj_t myadc_start(mp_obj_t channel_in, mp_obj_t freq_in) { // 配置 adc_continuous_handle設(shè)置采樣頻率和幀大小 return mp_const_none; } STATIC mp_obj_t myadc_read(mp_obj_t self_in) { // 把 ready_buf 指向的數(shù)據(jù)以 bytes/bytearray 形式返回 // 注意這里要用 memcpy 拷出去避免 DMA 下一次寫入覆蓋 return mp_obj_new_bytes((const char *)pingpong_buf[ready_buf], 4096); }需要提醒的是ESP-IDF 版本不同adc_continuous的 API 略有差異。5.x 版本用adc_continuous_handle_cfg_t和adc_continuous_start老一點的 4.x 版本接口不一樣復(fù)制代碼前先確認自己的工具鏈版本。這個路線實現(xiàn)難度相對高但效果最直接采樣率上限也最高適合需要高頻連續(xù)采集的硬核項目。3.4 路線 C外接 I2S ADC用現(xiàn)成 machine.I2S 繞開內(nèi)置 ADC 瓶頸如果純粹不想碰 C還有一個“曲線救國”的方案外接一顆 I2S 接口的 ADC 芯片。很多音頻 ADC 芯片直接輸出 I2S 格式的數(shù)字信號而 MicroPython 自帶machine.I2S模塊底層驅(qū)動本身就用了 DMA。你只需要配置好引腳然后周期性調(diào)用readinto()把數(shù)據(jù)塊搬到字節(jié)數(shù)組里from machine import I2S, Pin import audio i2s I2S(0, sckPin(4), wsPin(5), sdPin(6), modeI2S.RX, bits16, formatI2S.MONO, rate16000, ibuf8192) buf bytearray(2048) while True: n i2s.readinto(buf) # 在這里處理 buf 里的采樣數(shù)據(jù)這個方案的優(yōu)點是非常省心不需要寫任何 C采樣數(shù)據(jù)由 I2S 外設(shè)的 DMA 自動搬運主循環(huán)只在一整塊數(shù)據(jù)準備好之后處理。缺點是必須加一顆外接芯片而且 I2S 采樣率通常面向音頻域做低速物理量采樣時要注意前端抗混疊濾波。如果項目本身就要采集音頻或者振動信號這是性價比最高的路線。3.5 三條路線怎么選一張表講清楚路線平臺實現(xiàn)難度采樣率上限典型場景是否需寫 CPIO DMA C 擴展RP2040中高中等連續(xù)塊采集、波形記錄需要C 擴展 adc_continuousESP32 系列高較高高頻多通道、FFT、時域分析需要machine.I2S 外接 ADC任意帶 I2S 的 MCU低中高音頻、振動、語音不需要我的個人選型習(xí)慣是信號帶寬在幾百 Hz 以內(nèi)用 ESP32 的 C 擴展方案最順手手上正好有 Pico又想順便研究 PIO就走路線 A一旦涉及到音頻或語音直接上 I2S別猶豫。三條路線沒有絕對優(yōu)劣只看你手里有什么板子、愿不愿意寫 C、系統(tǒng)對實時性的要求有多高。4. 乒乓緩沖工程落地的完整細節(jié)4.1 參數(shù)設(shè)計采樣率、緩沖長度、中斷頻率怎么配乒乓緩沖不是簡單申請兩塊內(nèi)存就完事參數(shù)設(shè)計直接決定系統(tǒng)能不能跑穩(wěn)。核心公式有三個每塊緩沖的數(shù)據(jù)量 緩沖長度 × 每個樣本的字節(jié)數(shù)緩沖填滿一次的時間 緩沖長度 / 采樣率中斷頻率 采樣率 / 緩沖長度舉個例子采樣率 10kHz緩沖長度 256 個樣本那么每塊緩沖填滿需要 25.6ms對應(yīng)大約 39 次中斷每秒。這個中斷頻率對主循環(huán)的壓力很小CPU 每 25.6ms 收到一塊 256 點的數(shù)據(jù)處理完再去忙別的。緩沖長度不能拍腦袋定要考慮三點。第一如果要做 FFT緩沖長度最好是 2 的冪比如 256、512、1024否則頻譜點數(shù)尷尬第二緩沖長度越小數(shù)據(jù)延遲越低但中斷越頻繁第三緩沖長度越大CPU 每次處理的數(shù)據(jù)塊越大單次處理時間也越長如果超過兩個緩沖周期就會丟數(shù)據(jù)。一般我會預(yù)留 2 倍余量把“單塊處理時間”壓在緩沖周期的 40% 以內(nèi)。4.2 DMA 中斷里的切換順序一步都不能錯乒乓切換最關(guān)鍵的代碼在 DMA 中斷里。很多第一次寫的人容易踩一個順序錯誤直接在 DMA 還在傳輸?shù)臅r候改目標地址結(jié)果寄存器寫入失敗或者半截數(shù)據(jù)落到錯誤位置。正確的順序應(yīng)該是static void IRAM_ATTR dma_done_isr(void *arg) { // 1. 停掉 DMA 通道 dma_channel_abort(ch); // 2. 標記當前 buffer 已經(jīng)就緒 current_ready current_dma_target; // 3. 切換 DMA 目標地址到另一塊 buffer current_dma_target ^ 1; dma_channel_set_trans_addr(ch, buffers[current_dma_target], BUFFER_SIZE); // 4. 重新啟動 DMA dma_channel_start(ch); }順序是先停、再標記、再切換、最后啟動。停掉 DMA 是為了保證目標地址切換時不會有正在進行的傳輸漏了這一步輕則丟一個樣本重則出現(xiàn)數(shù)據(jù)錯位。還有一種做法是配置 DMA 的自動重載功能讓每次傳輸結(jié)束自動重新加載同一個目標緩沖區(qū)但這只能實現(xiàn)單緩沖循環(huán)做不了乒乓切換。4.3 Python 層安全取數(shù)據(jù)就緒標志和內(nèi)存視圖C 擴展里 DMA 中斷只管標記就緒Python 層通過一個poll()函數(shù)取數(shù)據(jù)。關(guān)鍵原則是中斷回調(diào)里不能執(zhí)行 Python 回調(diào)否則 MicroPython 虛擬機還在處理別的事情時被硬件中斷插入輕則卡頓重則直接崩潰。正確的做法是中斷里只改一個 volatile 變量Python 層主動查詢。取數(shù)據(jù)時盡量用memoryview或者直接拷貝到預(yù)先分配的bytearray避免每次新建大對象。一個實用的接口設(shè)計是myadc MyADC() myadc.start(channel0, freq10000, block_size256) while True: if myadc.ready(): buf myadc.get_block() # 返回一個 memoryview process(buf)這里get_block()內(nèi)部把 C 層 buffer 的數(shù)據(jù)拷貝到 Python 層預(yù)先分配的內(nèi)存里雖然多一次 memcpy但內(nèi)存所有權(quán)清晰不會出現(xiàn) Python 對象被 DMA 后臺改掉的詭異問題。如果你對性能極其敏感也可以直接返回指向 C buffer 的memoryview但此時必須保證在處理完之前不調(diào)用poll()去切換緩沖區(qū)。4.4 數(shù)據(jù)拼接塊與塊之間真的沒有縫隙嗎很多做波形分析的人會問DMA 乒乓切換的瞬間會不會丟幾個樣本答案是只要 DMA 切換順序正確數(shù)據(jù)流是連續(xù)無縫隙的。ADC 在后臺持續(xù)轉(zhuǎn)換DMA 目標地址哪怕在切換期間也能保證下一批數(shù)據(jù)寫到另一塊 buffer中間不會漏點。但要注意另一個問題塊與塊之間的處理時間間隔。CPU 正在處理 A 塊時DMA 在填 B 塊如果 CPU 處理 A 塊耗時超過兩個緩沖周期DMA 填滿 B 塊后會再次切回 A 塊而此時 CPU 可能還在處理 A于是數(shù)據(jù)就被覆蓋了。這本質(zhì)上是處理速度跟不上采樣速度不是乒乓機制本身的問題。解決辦法有三個加大緩沖深度從 2 塊增加到 4 塊、8 塊變成環(huán)形緩沖、降低采樣率、或者把部分計算下沉到 C 層。做 FFT 頻譜分析時還經(jīng)常需要重疊幀每次保留上一幀末尾的一部分拼接到當前幀前面這在 Python 層做會有一些拷貝開銷建議直接在 C 層完成。5. 實測效果與我踩過的五個坑5.1 對比數(shù)據(jù)主循環(huán)終于“活”過來了在同樣的 ESP32-S3 板子上同樣的 10kHz 采樣需求我用兩種方式做了對比。阻塞式 ADC 的主循環(huán)里只有兩個任務(wù)刷一塊小 OLED 和做 10Hz 的軟按鍵掃描結(jié)果刷屏幀率掉到個位數(shù)換成 C 擴展 DMA 乒乓緩沖后采樣任務(wù)變成每 25.6ms 處理一塊 256 點數(shù)據(jù)單塊處理耗時大約 2ms簡單的峰值檢測和均值計算主循環(huán)剩余時間幾乎全部釋放出來OLED 刷新恢復(fù)滿速WiFi 也不斷了。指標阻塞式 ADCDMA 乒乓緩沖10kHz 采樣對主循環(huán)占用幾乎 100%約 8%24ms 中 2ms 處理OLED 刷新率數(shù)幀/秒滿速WiFi 穩(wěn)定性時斷時續(xù)穩(wěn)定代碼復(fù)雜度低中高數(shù)據(jù)本身不意外但第一次看到主循環(huán)時間線從“全紅”變成“偶爾一個短脈沖”時還是會覺得這套方案值回成本。5.2 坑一帶 Cache 的 MCU數(shù)據(jù)會“隱身”很多帶高速緩存Cache的 MCU比如某些基于 Cortex-M7 或帶 L1 Cache 的芯片DMA 寫入的內(nèi)存區(qū)域?qū)?CPU 是不可見的。原因是 DMA 直接寫物理內(nèi)存但 CPU 讀的是 Cache 里的舊副本兩邊看到的不是同一份數(shù)據(jù)表現(xiàn)就是 pingpong buffer 里的數(shù)據(jù)時而正常時而亂碼調(diào)試時非常詭異。解決思路有兩個一是把 DMA buffer 定義在不可緩存non-cacheable的內(nèi)存區(qū)域很多 MCU 的 linker script 里可以直接指定 section二是在 DMA 完成中斷里對 buffer 地址執(zhí)行 Cache 無效化操作例如cache_invalidate_addr強制 CPU 下次讀取時從物理內(nèi)存拉新數(shù)據(jù)。這個問題只在帶 Cache 的平臺上出現(xiàn)Cortex-M0/M4 這類不帶 Cache 的入門內(nèi)核一般不用操心。5.3 坑二ADC 上電穩(wěn)定時間第一批數(shù)據(jù)不能信ADC 模塊上電或切換通道后輸入采樣電容需要時間充放電轉(zhuǎn)換結(jié)果在一段時間內(nèi)是不穩(wěn)定的。DMA 連續(xù)采樣的第一批數(shù)據(jù)往往整體偏大或偏小如果直接拿去做校準或者顯示會出現(xiàn)一個明顯的“臺階”。最省事的辦法是在啟動 DMA 后先丟棄前 16~64 個樣本等 ADC 穩(wěn)定了再開始真正的數(shù)據(jù)采集。在 C 擴展里可以在啟動時先讓 DMA 空轉(zhuǎn)一段或者在前處理邏輯里加一個丟棄計數(shù)別把這段不穩(wěn)定數(shù)據(jù)當成真實現(xiàn)象去排查半天。5.4 坑三MicroPython 的 GC 會讓主循環(huán)周期性“僵住”MicroPython 的垃圾回收器GC在主線程運行觸發(fā)時可能暫停幾毫秒。這段暫停本身不算長但如果恰好發(fā)生在 pingpong buffer 就緒需要被處理的時候就會延遲取數(shù)據(jù)累積下來可能導(dǎo)致緩沖超時。尤其是在 Python 層頻繁創(chuàng)建臨時字節(jié)數(shù)組、列表時GC 會更頻繁。對策有三個一是把所有可能反復(fù)用到的對象預(yù)先分配不要在采集循環(huán)里頻繁創(chuàng)建二是在主循環(huán)空閑時主動調(diào)用gc.collect()把 GC 時間挪到不重要的時段三是最徹底的辦法把逐樣本處理下沉到 C 層Python 層只接收 C 層算好的統(tǒng)計結(jié)果。經(jīng)歷過一次被 GC 坑掉整幀數(shù)據(jù)之后我現(xiàn)在寫采集代碼都會習(xí)慣性檢查有沒有在循環(huán)里產(chǎn)生臨時對象。5.5 坑四乒乓緩沖本身不丟數(shù)據(jù)但處理超時會丟乒乓緩沖能保證 DMA 寫入不中斷但它并不能保證數(shù)據(jù)在“處理”側(cè)不丟。如果 Python 層處理一塊數(shù)據(jù)耗時超過兩個緩沖周期DMA 填滿當前塊后切回前一塊而此時前一塊還沒處理完新數(shù)據(jù)就會覆蓋舊數(shù)據(jù)。處理超時的本質(zhì)是消費者速度跟不上生產(chǎn)者。我的處理思路是這樣的先用一個計數(shù)器統(tǒng)計丟塊次數(shù)如果丟塊率持續(xù)不為零說明得優(yōu)化處理算法而不是單純加大緩沖。算法優(yōu)化不動的時候就把緩沖從 2 塊加到 4 塊相當于給消費者更多緩沖時間。注意乒乓緩沖的“兩倍安全時間”是指從 DMA 完成 A 塊到 DMA 再次寫完 A 塊之間你有多長時間去處理 A4 塊環(huán)形緩沖則把這個時間放大到約三倍緩沖周期。加深度是最后手段不是第一手段。5.6 坑五Python 層的浮點計算會吃光 DMA 省下來的時間DMA 把 CPU 從“采樣等待”里解放出來但如果 Python 層用浮點去逐點處理那么省下來的時間會被加倍吃回去。MicroPython 的浮點運算比 C 慢一到兩個數(shù)量級256 點數(shù)據(jù)做一次浮點 FIR 濾波可能在 Python 層要幾十毫秒比阻塞式 ADC 還糟。一個典型的反面例子是每個樣本乘一個浮點系數(shù)再累加# 慢浮點乘加 out sum(buf[i] * kernel[j] for i in range(256) for j in range(8))如果濾波器系數(shù)恰好可以設(shè)計成整數(shù)近似比如 8 點移動平均直接用移位操作就能完成# 快整數(shù)移位平均 avg (buf[0] buf[1] buf[2] buf[3] buf[4] buf[5] buf[6] buf[7]) 3后者在 MicroPython 里幾乎是瞬時完成。原則很簡單Python 層只做輕量判斷、顯示、統(tǒng)計濾波、FFT 這一類重計算要么用定點整數(shù)要么下沉到 C 擴展。6. 什么情況下別讓 MicroPython 硬扛6.1 高采樣率與硬實時需求的分界線DMA 乒乓緩沖解決了“采樣拖慢主循環(huán)”的問題但 MicroPython 作為解釋型語言本身的執(zhí)行時間是不確定的。如果項目要求采樣率超過 100kHz或者對樣本間隔的抖動有嚴格規(guī)定比如音頻合成、電機 FOC 控制那就不適合在 Python 層做核心實時邏輯。這時候更合理的做法是底層 C 負責全部采樣和實時處理MicroPython 只負責配置參數(shù)、顯示結(jié)果、聯(lián)網(wǎng)上傳。把實時性要求高的部分放到硬件層把業(yè)務(wù)靈活性放到解釋層兩邊各取所長。6.2 混合架構(gòu)是我現(xiàn)在最推薦的形態(tài)我最初也想在純 Python 層模擬 DMA 的效果折騰了幾天最終放棄了老老實實寫 C 擴展。第一次把adc_continuous封裝成 usermodule 跑通時我才意識到MicroPython 的強項從來不是高實時性而是開發(fā)效率。它在采集任務(wù)里最適合扮演“上層大腦”而不是“底層肌肉”?，F(xiàn)在我的項目凡是涉及連續(xù)采集默認架構(gòu)都是C 擴展負責 ADC DMA 乒乓緩沖 必要的信號處理MicroPython 負責界面、網(wǎng)絡(luò)、參數(shù)調(diào)節(jié)和業(yè)務(wù)邏輯。這套組合既有開發(fā)速度又有實時性也正好回答了標題里那個問題——ADC 采樣確實不用拖慢主循環(huán)關(guān)鍵是你得把 DMA 這顆棋子放到 MicroPython 夠得著的位置。最后再說一個我自己的小習(xí)慣新項目上 MicroPython 做采集第一版我總會把 DMA 緩沖和乒乓參數(shù)寫死預(yù)留二倍余量跑通功能和數(shù)據(jù)流之后再回過頭來優(yōu)化內(nèi)存和延遲。很多看起來復(fù)雜的高頻采集問題其實不是芯片不夠快而是最初的設(shè)計沒有給 CPU 留出喘息的空間。乒乓緩沖聽起來高大上拆開就是兩塊內(nèi)存加一個切換動作把這一步做好了后面的路就順了。