搞嵌入式這些年DMA算是我又愛又恨的一個外設。愛的是它真能把CPU從重復的數(shù)據(jù)搬運里解放出來UART收發(fā)、ADC采樣、SPI刷屏這些高頻操作配置好DMA之后CPU幾乎可以撒手不管恨的是DMA一旦出問題排查起來往往比常規(guī)中斷要難得多數(shù)據(jù)錯位、傳輸不完整、標志位不清、模式配置錯誤各種疑難雜癥見一次頭大一次。這次借著一篇匯總筆記的契機我把DMA的工作流程、傳輸模式、典型應用場景和自己實際調試中踩過的坑一起梳理一遍覆蓋串口DMA不定長接收、ADC多通道采樣、FreeModbus移植、UFS DMA、分布式DMA等話題希望能給正在調DMA或者準備入坑DMA的朋友一點參考。文章里的內(nèi)容既包含原理層面的拆解也有可以直接抄作業(yè)的代碼示例和避坑經(jīng)驗。如果你只是剛接觸DMA建議從頭順序讀一遍如果已經(jīng)在項目里被某個DMA問題卡住了可以直接跳到對應章節(jié)查問題每一部分都盡量做到了獨立成文。1. DMA到底在解決什么問題1.1 沒有DMA之前CPU在干什么在講DMA之前先說一個反常識的場景一個波特率115200的串口滿載接收數(shù)據(jù)每秒大約能收到11520字節(jié)。如果用傳統(tǒng)中斷方式逐字節(jié)接收每來一個字節(jié)CPU就要進一次中斷把數(shù)據(jù)從數(shù)據(jù)寄存器搬到內(nèi)存緩沖區(qū)。11520次中斷/秒看起來不多但每次中斷都要壓棧、跳轉、處理、出棧還要處理各種標志位整體開銷至少上百個CPU周期。如果這個系統(tǒng)里同時還有CAN總線通信、ADC連續(xù)采樣、PWM波形控制、顯示刷新、Modbus協(xié)議解析你會發(fā)現(xiàn)CPU大部分時間都花在把數(shù)據(jù)從A搬到B這種毫無技術含量的操作上。真正需要CPU做的數(shù)據(jù)處理、狀態(tài)機切換、控制算法反而被擠占了運行時間。中斷方式的另外一個問題在于實時性。高頻率的數(shù)據(jù)流到達時如果中斷響應不及時數(shù)據(jù)寄存器可能會被新數(shù)據(jù)覆蓋造成丟字節(jié)。為了不丟數(shù)據(jù)工程師只能把中斷優(yōu)先級調高、關掉其他中斷或者把緩沖區(qū)做得很大這又引入了資源浪費和系統(tǒng)響應變慢的問題。1.2 DMA的核心思路搬運由專用硬件完成DMADirect Memory Access直接存儲器訪問的思路很簡單數(shù)據(jù)搬運這件事交給一塊專門的硬件電路去做。CPU只需要告訴DMA從哪里搬、搬到哪、搬多少、什么時候搬然后就可以去忙別的。數(shù)據(jù)搬運完成后DMA會通過中斷等方式通知CPU處理結果。這個設計思路跟公司里請行政專員幫忙跑腿一樣。你不需要自己下樓去取快遞、打印文件、寄郵件只需要在OA系統(tǒng)里提交一個流程行政專員會替你把事情辦完辦完后再通知你結果。你在這段時間里可以繼續(xù)做自己的核心工作。放到嵌入式系統(tǒng)里DMA要處理的事情通常分為三類外設到內(nèi)存串口收到數(shù)據(jù)、ADC轉換完成、SPI從機收到數(shù)據(jù)DMA自動把這些數(shù)據(jù)存進指定的RAM緩沖區(qū)。內(nèi)存到外設需要發(fā)送的數(shù)據(jù)提前放到RAM里DMA自動把數(shù)據(jù)搬到串口/SPI/I2C的數(shù)據(jù)寄存器由外設發(fā)送出去。內(nèi)存到內(nèi)存把RAM里的一塊數(shù)據(jù)復制到另一塊地址比如圖像數(shù)據(jù)搬移、協(xié)議數(shù)據(jù)組裝。無論是哪一類DMA的參與方式都是配置好后自動運行CPU只需要在啟動時設置一次參數(shù)剩下的搬運工作完全由硬件完成。這也是DMA和中斷之間最本質的區(qū)別中斷模式里CPU是搬運工DMA模式里CPU是管理者。2. DMA工作流程拆解一次傳輸?shù)娜芷?.1 一次DMA傳輸?shù)乃膫€階段以串口接收為例一次完整的DMA傳輸分為四個階段配置階段CPU設置DMA通道、選擇數(shù)據(jù)方向外設到內(nèi)存、設定外設地址和內(nèi)存地址、搬運數(shù)據(jù)長度、數(shù)據(jù)寬度以及傳輸模式單次/循環(huán)。以STM32 HAL庫為例使用HAL_UART_Receive_DMA(huart1, rx_buffer, RX_BUFFER_SIZE)啟動一次串口DMA接收。觸發(fā)階段DMA的搬運由外設請求信號觸發(fā)。當串口收到一個字節(jié)數(shù)據(jù)寄存器有數(shù)據(jù)時硬件會產(chǎn)生一個DMA請求信號。DMA控制器接收到請求后開始執(zhí)行一次搬運。這個過程完全由硬件完成不需要CPU干預。搬運階段DMA從外設數(shù)據(jù)寄存器讀取數(shù)據(jù)外設地址寫入內(nèi)存緩沖區(qū)內(nèi)存地址。每搬運一個數(shù)據(jù)單元內(nèi)部的計數(shù)寄存器NDTR/CNDTR減一。當計數(shù)不為0且外設繼續(xù)產(chǎn)生請求時DMA會一直搬運下去。結束階段當計數(shù)寄存器遞減到0說明本次配置的所有數(shù)據(jù)搬運完成DMA會置位傳輸完成標志如果使能了中斷還會觸發(fā)DMA傳輸完成中斷。CPU在中斷回調里可以進行數(shù)據(jù)處理或者重新啟動下一次傳輸。這個流程里有一個容易被忽略的規(guī)定轉運次數(shù)必須事先設置好。DMA不是一直搬到緩沖區(qū)滿為止而是搬夠指定數(shù)量就停下來。2.2 請求與響應DMA如何感知外設有數(shù)據(jù)了DMA和外設之間打通數(shù)據(jù)通路的關鍵在于請求信號。不同外設的DMA請求來源不同但機制類似串口USART/UART接收時RXNE接收數(shù)據(jù)寄存器非空置位時產(chǎn)生DMA請求發(fā)送時TXE發(fā)送數(shù)據(jù)寄存器空置位時產(chǎn)生DMA請求。ADC每次轉換完成數(shù)據(jù)寄存器有效時產(chǎn)生DMA請求。SPI接收緩沖區(qū)非空或者發(fā)送緩沖區(qū)為空時產(chǎn)生請求。定時器定時器更新事件、比較事件可以觸發(fā)DMA請求。正是因為DMA由外設請求驅動所以天然適合外設隨時產(chǎn)生數(shù)據(jù)、DMA隨時搬運的場景。CPU不需要輪詢外設狀態(tài)數(shù)據(jù)到了硬件會自動搬走。需要注意的是DMA請求和中斷請求是兩個獨立通路。外設產(chǎn)生DMA請求時不一定產(chǎn)生中斷反過來也是。實際項目中經(jīng)常外設中斷關閉、DMA中斷打開依靠DMA完成中斷來通知CPU。這種組合的優(yōu)點是每個數(shù)據(jù)單元搬運不打斷CPU只有整批數(shù)據(jù)搬運完成時才通知CPU處理。2.3 聊聊連續(xù)請求和大塊搬運我在搜索引擎的聯(lián)想詞里看到了dma continuous requests這個關鍵詞實際調試中經(jīng)常遇到的外設連續(xù)產(chǎn)生DMA請求本質上是外設持續(xù)產(chǎn)生數(shù)據(jù)DMA要不停搬運。串口全雙工高速收發(fā)、ADC連續(xù)采樣、麥克風音頻采集都屬于這種場景。連續(xù)請求場景下有兩個配置細節(jié)內(nèi)存地址要開啟遞增Memory Increment否則每次搬運都覆蓋同一個地址。多數(shù)項目會使用循環(huán)模式Circular Mode這樣DMA緩沖區(qū)轉滿后自動從頭開始持續(xù)搬運最新數(shù)據(jù)CPU可以隨時從緩沖區(qū)讀取數(shù)據(jù)。大塊搬運時還要注意數(shù)據(jù)寬度匹配。外設數(shù)據(jù)寄存器的寬度和內(nèi)存數(shù)據(jù)寬度最好一致。串口數(shù)據(jù)寄存器通常是8位ADC數(shù)據(jù)寄存器是16位或32位如果外設和內(nèi)存數(shù)據(jù)寬度不一致DMA控制器會做字節(jié)/半字/字的拼接或拆分效率會下降有些DMA甚至不支持不匹配的寬度配置。實測下來固定使用相同寬度是最省心的做法。3. 傳輸模式與配置選型別只會用默認值3.1 按數(shù)據(jù)方向分外設到內(nèi)存、內(nèi)存到外設、內(nèi)存到內(nèi)存DMA的數(shù)據(jù)方向決定了外設地址、內(nèi)存地址如何遞增以及誰作為請求源外設到內(nèi)存Peripheral-to-MemoryP2M典型場景是串口接收、ADC采樣、SPI接收。外設地址固定數(shù)據(jù)寄存器內(nèi)存地址遞增。內(nèi)存到外設Memory-to-PeripheralM2P典型場景是串口發(fā)送、SPI發(fā)送、DAC輸出。內(nèi)存地址遞增外設地址固定。內(nèi)存到內(nèi)存Memory-to-MemoryM2M典型場景是RAM內(nèi)數(shù)據(jù)塊復制。源地址和目的地址都遞增方向設置為內(nèi)存到內(nèi)存。注意M2M模式下DMA不需要外設請求配置完成后立即開始搬運直到搬完為止。選擇方向時最容易犯的錯是把外設地址配反。比如串口接收時外設地址寫成發(fā)送數(shù)據(jù)寄存器數(shù)據(jù)根本進不了緩沖區(qū)。建議每次配置后都打印一次寄存器狀態(tài)確認PeriphBaseAddress指向的是外設的數(shù)據(jù)寄存器而不是控制狀態(tài)寄存器。HAL庫中__HAL_LINKDMA宏綁定外設句柄的DMA通道時也要確認綁定的方向對應的handle字段如hdmarx和hdmatx沒有搞混。3.2 按搬運行為分單次、循環(huán)、突發(fā)與散聚DMA的行為模式直接決定數(shù)據(jù)到達緩沖區(qū)后的表現(xiàn)單次模式Normal Mode搬運完配置的數(shù)據(jù)個數(shù)后停止。適用于一幀一幀的不定長數(shù)據(jù)處理每幀數(shù)據(jù)搬運完成后必須重新啟動。循環(huán)模式Circular Mode搬完后自動重新從緩沖區(qū)頭開始持續(xù)搬運。適用于音頻流、連續(xù)采樣的數(shù)據(jù)采集CPU可以從緩沖區(qū)任意偏移取數(shù)。突發(fā)模式Burst Mode一次DMA請求搬運連續(xù)多個數(shù)據(jù)如4個、8個、16個。突發(fā)模式可以提高總線利用率適合大數(shù)據(jù)塊搬運。但配置突發(fā)模式時內(nèi)存地址、數(shù)據(jù)寬度必須滿足對齊要求否則會產(chǎn)生總線錯誤。散聚模式Scatter-Gather通過鏈表描述符描述多塊不連續(xù)內(nèi)存一次DMA傳輸可以依次搬運多塊數(shù)據(jù)。常見于高性能DMA控制器和Linux DMA引擎框架MCU中較少但在UFS/網(wǎng)絡控制器中很常見。實際選型建議確定性通信如Modbus RTU幀、傳感器上報用單次模式連續(xù)采集如音頻、電機電流采樣用循環(huán)模式需要極致性能時再考慮突發(fā)和散聚。不要一上來就配置循環(huán)模式雖然循環(huán)模式寫起來方便但如果CPU處理速度跟不上可能出現(xiàn)緩沖區(qū)被新數(shù)據(jù)覆蓋的問題。3.3 DMA中斷半傳輸中斷、全傳輸中斷、錯誤中斷DMA中斷里最有用的三個標志位分別對應三個時機半傳輸中斷Half Transfer搬運到一半時觸發(fā)。常用于雙緩沖處理前半緩沖區(qū)被DMA填充時CPU可以處理后一半緩沖區(qū)里的舊數(shù)據(jù)反之亦然。全傳輸中斷Transfer Complete全部搬運完成時觸發(fā)。單次模式下表示一幀數(shù)據(jù)完整到達可以開始解析。傳輸錯誤中斷Transfer Error總線錯誤、配置錯誤時觸發(fā)。調試時非常重要建議開發(fā)階段始終打開。在STM32 HAL庫中對應的是HAL_DMA_IRQHandler分發(fā)的三個回調void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart); void HAL_UART_RxHalfCpltCallback(UART_HandleTypeDef *huart); void HAL_UART_ErrorCallback(UART_HandleTypeDef *huart);實際項目中如果同時使用DMA半滿和全滿中斷要特別小心回調函數(shù)里的重入問題。中斷里不要做耗時操作只做數(shù)據(jù)標記和輕量邏輯處理具體解析放到主循環(huán)里完成。4. 串口DMA實操不定長接收、發(fā)送等待與FreeModbus移植4.1 串口DMA接收不定長數(shù)據(jù)的正確姿勢空閑中斷串口DMA接收的經(jīng)典難題不是定長數(shù)據(jù)而是不定長數(shù)據(jù)。DMA搬運的前提是知道要搬多少可實際通信中一幀數(shù)據(jù)長度通常是未知的。這時候最常用的方案是DMA負責把所有收到的數(shù)據(jù)存進緩沖區(qū)真正負責幀結束判斷的是串口空閑中斷IDLE Line Interrupt?？臻e中斷的作用是當串口接收線上持續(xù)一段時間沒有新數(shù)據(jù)到達就觸發(fā)一次中斷。這個空閑時間通常是一個字節(jié)的傳輸時間正好用來判斷一幀數(shù)據(jù)可能結束了。實現(xiàn)思路DMA始終開啟接收模式緩沖區(qū)設置為足夠大的固定長度比如256字節(jié)或512字節(jié)。串口空閑中斷打開一旦觸發(fā)說明一幀數(shù)據(jù)結束。在空閑中斷處理函數(shù)里讀取DMA計數(shù)寄存器CNDTR用緩沖區(qū)長度 - 剩余計數(shù)算出當前實際收到了多少字節(jié)。重置DMA計數(shù)準備接收下一幀。以STM32 HAL庫為例配置步驟// 啟動DMA接收緩沖區(qū)255字節(jié) HAL_UART_Receive_DMA(huart1, rx_buffer, RX_BUFFER_SIZE); // 使能空閑中斷 __HAL_UART_ENABLE_IT(huart1, UART_IT_IDLE);中斷處理void USART1_IRQHandler(void) { if (__HAL_UART_GET_FLAG(huart1, UART_FLAG_IDLE)) { __HAL_UART_CLEAR_IDLEFLAG(huart1); uint16_t len RX_BUFFER_SIZE - __HAL_DMA_GET_COUNTER(hdma_usart1_rx); if (len 0) { frame_len len; frame_ready 1; } HAL_UART_Receive_DMA(huart1, rx_buffer, RX_BUFFER_SIZE); } HAL_UART_IRQHandler(huart1); }這里有幾個細節(jié)必須注意第一__HAL_UART_CLEAR_IDLEFLAG在部分HAL版本中是通過讀SR再讀DR來清除的。如果在中斷里先清標志再使用__HAL_DMA_GET_COUNTER讀取的是當前實時計數(shù)值沒有問題。但如果代碼寫成先讀計數(shù)再清標志期間又來了新數(shù)據(jù)計數(shù)就會不對。第二調用HAL_UART_Receive_DMA重新啟動時如果上一次DMA已經(jīng)傳輸完成緩沖區(qū)填滿直接調用可能會因為DMA通道還在忙碌狀態(tài)而失敗。穩(wěn)妥的做法是先調用一次HAL_UART_AbortReceive或者先HAL_DMA_Abort再重新啟動。第三空閑中斷觸發(fā)的時機比真實幀間隔略晚但只要DMA一直開著數(shù)據(jù)不會丟。所以解析協(xié)議時可以在幀尾追加一個超時校驗避免把連續(xù)的半幀誤判成一幀。4.2 串口DMA發(fā)送需要等待上一輪發(fā)完嗎這個問題是我在搜索聯(lián)想詞里見到的說明很多工程師在實際使用中都被這個細節(jié)困擾過。直接給結論在單次模式下DMA發(fā)送必須等待上一輪傳輸完成才能啟動下一輪。原理很簡單。DMA控制器里的NDTR/CNDTR寄存器是每次配置后遞減的計數(shù)器。如果上一次傳輸還沒結束數(shù)據(jù)還沒搬完你直接修改NDTR寄存器的值DMA控制器會把當前剩余計數(shù)覆蓋成新長度。后果就是舊數(shù)據(jù)搬運到一半突然改變目標長度新數(shù)據(jù)和舊數(shù)據(jù)混在一起線上發(fā)出的是完全錯亂的內(nèi)容。正確做法有三種方法一輪詢DMA狀態(tài)。while (__HAL_DMA_GET_FLAG(hdma_usart1_tx, DMA_FLAG_TC1) RESET) { // 等待傳輸完成 } HAL_UART_Transmit_DMA(huart1, tx_buffer, len);方法二在DMA發(fā)送完成中斷里置標志位主函數(shù)發(fā)送前檢查標志位。方法三使用HAL庫的狀態(tài)查詢。if (HAL_UART_GetState(huart1) HAL_UART_STATE_READY) { HAL_UART_Transmit_DMA(huart1, tx_buffer, len); }除了DMA自身的傳輸完成串口發(fā)送還要特別看另外一個標志USART的TC位發(fā)送完成位。DMA把數(shù)據(jù)搬到串口數(shù)據(jù)寄存器后串口移位寄存器還要把數(shù)據(jù)一位一位地發(fā)出去。DMA的傳輸完成和線上真正發(fā)完不是同一個時刻。如果使用RS485之類的半雙工總線需要等串口TC置位后才能把發(fā)送模式切換成接收模式否則最后一個字節(jié)會被切掉一半。所以RS485場景的正確順序是HAL_UART_Transmit_DMA(huart1, tx_buffer, len); // 在UART TC中斷里而非DMA完成中斷里切換485方向 void USART1_IRQHandler(void) { if (__HAL_UART_GET_FLAG(huart1, UART_FLAG_TC)) { __HAL_UART_CLEAR_TCFLAG(huart1); RS485_DIR_RX(); } }這套流程我在多個項目里驗證過能可靠避免最后一個字節(jié)被截斷的問題。4.3 PY32F003使用串口DMA接收通訊數(shù)據(jù)的參考實現(xiàn)有朋友在搜索里提到PY32F003的串口DMA接收我基于STM32 HAL庫風格整理了一份最小參考實現(xiàn)。PY32F003是M0內(nèi)核外設結構和STM32F0系列很接近所以這份代碼稍作修改即可移植到其他F0/M0系列。關鍵初始化代碼// 串口句柄和DMA句柄 UART_HandleTypeDef huart1; DMA_HandleTypeDef hdma_usart1_rx; uint8_t uart1_rx_buf[128]; volatile uint8_t uart1_frame_ok 0; volatile uint16_t uart1_frame_len 0; void MX_USART1_UART_Init(void) { huart1.Instance USART1; huart1.Init.BaudRate 115200; huart1.Init.WordLength UART_WORDLENGTH_8B; huart1.Init.StopBits UART_STOPBITS_1; huart1.Init.Parity UART_PARITY_NONE; huart1.Init.Mode UART_MODE_TX_RX; huart1.Init.HwFlowCtl UART_HWCONTROL_NONE; HAL_UART_Init(huart1); } void HAL_UART_MspInit(UART_HandleTypeDef* uartHandle) { GPIO_InitTypeDef GPIO_InitStruct {0}; if (uartHandle-Instance USART1) { __HAL_RCC_USART1_CLK_ENABLE(); __HAL_RCC_GPIOA_CLK_ENABLE(); __HAL_RCC_DMA_CLK_ENABLE(); // PA2 TX, PA3 RX按原理圖調整 GPIO_InitStruct.Pin GPIO_PIN_2; GPIO_InitStruct.Mode GPIO_MODE_AF_PP; GPIO_InitStruct.Speed GPIO_SPEED_FREQ_HIGH; HAL_GPIO_Init(GPIOA, GPIO_InitStruct); GPIO_InitStruct.Pin GPIO_PIN_3; GPIO_InitStruct.Mode GPIO_MODE_INPUT; GPIO_InitStruct.Pull GPIO_NOPULL; HAL_GPIO_Init(GPIOA, GPIO_InitStruct); // DMA接收通道 hdma_usart1_rx.Instance DMA1_Channel1; hdma_usart1_rx.Init.Direction DMA_PERIPH_TO_MEMORY; hdma_usart1_rx.Init.PeriphInc DMA_PINC_DISABLE; hdma_usart1_rx.Init.MemInc DMA_MINC_ENABLE; hdma_usart1_rx.Init.PeriphDataAlignment DMA_PDATAALIGN_BYTE; hdma_usart1_rx.Init.MemDataAlignment DMA_MDATAALIGN_BYTE; hdma_usart1_rx.Init.Mode DMA_NORMAL; hdma_usart1_rx.Init.Priority DMA_PRIORITY_HIGH; HAL_DMA_Init(hdma_usart1_rx); __HAL_LINKDMA(uartHandle, hdmarx, hdma_usart1_rx); HAL_NVIC_SetPriority(USART1_IRQn, 0, 0); HAL_NVIC_EnableIRQ(USART1_IRQn); // 注意M0系列DMA中斷向量可能合并 HAL_NVIC_SetPriority(DMA1_Channel1_IRQn, 0, 0); HAL_NVIC_EnableIRQ(DMA1_Channel1_IRQn); } }接收啟動和中斷處理void uart1_rx_dma_start(void) { uart1_frame_ok 0; uart1_frame_len 0; HAL_UART_Receive_DMA(huart1, uart1_rx_buf, sizeof(uart1_rx_buf)); __HAL_UART_ENABLE_IT(huart1, UART_IT_IDLE); } void USART1_IRQHandler(void) { if (__HAL_UART_GET_FLAG(huart1, UART_FLAG_IDLE)) { __HAL_UART_CLEAR_IDLEFLAG(huart1); uart1_frame_len sizeof(uart1_rx_buf) - __HAL_DMA_GET_COUNTER(hdma_usart1_rx); if (uart1_frame_len 0) { uart1_frame_ok 1; } HAL_UART_Receive_DMA(huart1, uart1_rx_buf, sizeof(uart1_rx_buf)); __HAL_UART_ENABLE_IT(huart1, UART_IT_IDLE); } HAL_UART_IRQHandler(huart1); } void DMA1_Channel1_IRQHandler(void) { HAL_DMA_IRQHandler(hdma_usart1_rx); }主循環(huán)里處理if (uart1_frame_ok) { uart1_frame_ok 0; process_uart1_frame(uart1_rx_buf, uart1_frame_len); }PY32F003的DMA中斷向量要注意不同型號可能把多個通道的中斷合并到一個入口。用CubeMX生成工程時會自動處理好手寫代碼時需要查閱數(shù)據(jù)手冊確認中斷服務函數(shù)名。4.4 FreeModbus DMA移植中必須處理的三個問題把FreeModbus協(xié)議棧和DMA結合起來使用是很多工業(yè)設備的常見需求。FreeModbus默認的串口移植是逐字節(jié)中斷換成DMA后主要需要處理三個問題。問題一幀結束判斷。Modbus RTU協(xié)議要求幀與幀之間至少有3.5個字符時間的靜默間隔。逐字節(jié)中斷模式里FreeModbus用定時器T35來判斷幀是否結束改用DMA接收后UART空閑中斷可以承擔這個職責。但要注意空閑中斷的觸發(fā)時間通常大于3.5字符時間在高速率如115200以上下某些硬件空閑中斷的響應可能不夠精準。穩(wěn)妥的做法是保留T35定時器在空閑中斷觸發(fā)后啟動T35定時定時超時后再認為幀結束。問題二接收數(shù)據(jù)如何交給協(xié)議棧。FreeModbus在eMBPortSerialInit里注冊了接收回調pvMBFrameStartCur和prvvUARTRxISR。使用DMA時不再逐字節(jié)觸發(fā)prvvUARTRxISR而是在DMA空閑中斷判斷幀結束后直接把緩沖區(qū)數(shù)據(jù)和長度交給pvMBFrameStartCur對應的處理函數(shù)。這樣協(xié)議棧的解析邏輯不需要改動只是數(shù)據(jù)來源從逐字節(jié)中斷變成了DMA整幀交付。問題三發(fā)送方向切換。如果硬件使用RS485發(fā)送完成后必須切換為接收模式。前面說過一定要在USART的TC標志置位后再切換方向而不能在DMA完成中斷里切換。FreeModbus的xMBPortSerialPutByte和發(fā)送完成的處理邏輯需要同步修改否則會出現(xiàn)發(fā)完最后一個字節(jié)后總線方向還停留在發(fā)送模式導致收不到從站回復或者總線沖突。5. ADC多通道DMA采樣與數(shù)據(jù)對齊5.1 STM32 HAL庫ADC單通道DMA多次采樣配置ADC連續(xù)采樣配合DMA的使用頻率非常高比如電機電流檢測、電池電壓監(jiān)測、傳感器數(shù)據(jù)采集。用HAL庫配置ADC單通道DMA多次采樣的核心代碼如下ADC_HandleTypeDef hadc1; DMA_HandleTypeDef hdma_adc1; uint16_t adc_buf[128]; void MX_ADC1_Init(void) { hadc1.Instance ADC1; hadc1.Init.ClockPrescaler ADC_CLOCK_SYNC_PCLK_DIV4; hadc1.Init.Resolution ADC_RESOLUTION_12B; hadc1.Init.ScanConvMode DISABLE; hadc1.Init.ContinuousConvMode ENABLE; hadc1.Init.DiscontinuousConvMode DISABLE; hadc1.Init.ExternalTrigConv ADC_SOFTWARE_START; hadc1.Init.DataAlign ADC_DATAALIGN_RIGHT; hadc1.Init.NbrOfConversion 1; HAL_ADC_Init(hadc1); ADC_ChannelConfTypeDef sConfig {0}; sConfig.Channel ADC_CHANNEL_0; sConfig.Rank 1; sConfig.SamplingTime ADC_SAMPLETIME_239CYCLES_5; HAL_ADC_ConfigChannel(hadc1, sConfig); hdma_adc1.Instance DMA1_Channel1; hdma_adc1.Init.Direction DMA_PERIPH_TO_MEMORY; hdma_adc1.Init.PeriphInc DMA_PINC_DISABLE; hdma_adc1.Init.MemInc DMA_MINC_ENABLE; hdma_adc1.Init.PeriphDataAlignment DMA_PDATAALIGN_HALFWORD; hdma_adc1.Init.MemDataAlignment DMA_MDATAALIGN_HALFWORD; hdma_adc1.Init.Mode DMA_CIRCULAR; hdma_adc1.Init.Priority DMA_PRIORITY_HIGH; HAL_DMA_Init(hdma_adc1); __HAL_LINKDMA(hadc1, DMA_Handle, hdma_adc1); } void adc_start_dma(uint16_t *buffer, uint16_t length) { HAL_ADC_Start_DMA(hadc1, (uint32_t *)buffer, length); }啟動后ADC會按照配置的采樣周期持續(xù)轉換DMA自動把每次轉換結果依次寫入adc_buf。寫入128個數(shù)據(jù)后DMA會循環(huán)回到緩沖區(qū)開頭繼續(xù)覆蓋寫入。使用循環(huán)模式時CPU可以通過DMA半滿/全滿中斷分批讀取void HAL_ADC_ConvCpltCallback(ADC_HandleTypeDef* hadc) { // 后64個數(shù)據(jù)已經(jīng)就緒可以在這里做均值濾波 process_adc_data(adc_buf[64], 64); } void HAL_ADC_ConvHalfCpltCallback(ADC_HandleTypeDef* hadc) { // 前64個數(shù)據(jù)已經(jīng)就緒 process_adc_data(adc_buf[0], 64); }這樣CPU和DMA可以并行工作DMA往緩沖區(qū)后半段寫數(shù)據(jù)時CPU處理前半段DMA寫前半段時CPU處理后半段。這個機制就是常說的雙緩沖Ping-Pong思想。5.2 多通道掃描模式下數(shù)據(jù)錯位的坑ADC多通道DMA采樣比單通道復雜最常見的問題是數(shù)據(jù)錯位。比如配置了CH0、CH1、CH2三個通道按順序掃描DMA緩沖區(qū)里期望的是CH0數(shù)據(jù)、CH1數(shù)據(jù)、CH2數(shù)據(jù)、CH0數(shù)據(jù)、CH1數(shù)據(jù)、CH2數(shù)據(jù)……這樣循環(huán)排列但實測讀出來可能是CH2數(shù)據(jù)、CH0數(shù)據(jù)、CH1數(shù)據(jù)CH2數(shù)據(jù)……。造成錯位的原因通常是啟動時序問題。ADC在上電瞬間或者某個通道轉換尚未結束時DMA已經(jīng)開始搬運或者DMA緩沖區(qū)的起始位置和ADC序列的起始通道沒有對齊。解決辦法保證DMA緩沖區(qū)長度是通道數(shù)的整數(shù)倍。比如3通道掃描緩沖區(qū)長度必須是3的倍數(shù)如300、600否則數(shù)據(jù)序列會在緩沖區(qū)末尾和開頭之間錯位。開啟掃描模式后等待啟動穩(wěn)定再讀取首包數(shù)據(jù)。某些芯片上剛啟動掃描時第一次轉換結果不可靠。使用序列序號定位起點。在DMA完成中斷里通過當前緩沖區(qū)索引對通道數(shù)取模來確定哪個數(shù)據(jù)對應哪個通道不要把通道順序寫死。還有一點多通道掃描時關閉連續(xù)轉換和循環(huán)組合不當也會出問題。如果使用連續(xù)轉換 循環(huán)模式必須確認掃描序列和DMA緩沖區(qū)對齊否則CH0可能不是從索引0開始。調試時最有效的辦法是給CH0接一個固定電壓然后看緩沖區(qū)里哪個位置的數(shù)據(jù)始終等于該電壓值通過這個方式確定通道映射關系。6. DMA性能測速與進階應用6.1 嵌入式里怎么給DMA測速DMA測速這個詞有兩種理解一是測試DMA搬運數(shù)據(jù)的實際吞吐量二是測試有DMA參與的整條數(shù)據(jù)鏈路如存儲、網(wǎng)卡的性能。嵌入式MCU里前者可以通過內(nèi)存到內(nèi)存搬運來測試。測試思路把一塊固定大小的數(shù)據(jù)從源地址搬運到目的地址用SysTick或DWT時基統(tǒng)計搬運耗時然后計算帶寬。以STM32為例#define TEST_SIZE (32 * 1024) // 32KB uint32_t src_buf[TEST_SIZE / 4]; uint32_t dst_buf[TEST_SIZE / 4]; void dma_bandwidth_test(void) { // 使用DMA內(nèi)存到內(nèi)存模式搬運32KB HAL_DMA_Start(hdma_mem2mem, (uint32_t)src_buf, (uint32_t)dst_buf, TEST_SIZE / 4); DWT-CYCCNT 0; // 輪詢等待傳輸完成 while (__HAL_DMA_GET_FLAG(hdma_mem2mem, DMA_FLAG_TC1) RESET) {} uint32_t cycles DWT-CYCCNT; float time_us (float)cycles / HAL_RCC_GetSysClockFreq() * 1000000.0f; float bandwidth TEST_SIZE / time_us; // MB/s }實測下來不同芯片DMA帶寬差異很大。一個72MHz主頻的M3內(nèi)核內(nèi)存到內(nèi)存DMA搬運32KB數(shù)據(jù)耗時大約幾十微秒到上百微秒帶寬在幾十MB/s量級。如果發(fā)現(xiàn)帶寬明顯偏低先檢查DMA時鐘配置是否開啟、總線是否被頻繁搶占、數(shù)據(jù)寬度是否按32位配置。測速還有一個實用場景驗證不同緩沖區(qū)大小下的DMA效率。DMA批量搬運比逐字節(jié)搬效率高緩沖區(qū)越大啟動DMA的固定開銷占比越低。實際項目中如果需要頻繁發(fā)送小數(shù)據(jù)包可以考慮把多個小數(shù)據(jù)包拼接到一個大緩沖區(qū)再統(tǒng)一發(fā)送能明顯降低DMA啟動次數(shù)。6.2 UFS DMA從MCU到高性能存儲UFSUniversal Flash Storage通用閃存存儲是目前主流智能手機、平板電腦使用的高性能存儲接口標準。UFS主機控制器內(nèi)部有一個專門的DMA引擎負責在主機內(nèi)存和UFS設備之間搬運數(shù)據(jù)。UFS DMA的核心機制是PRDTPhysical Region Descriptor Table物理區(qū)域描述符表。主機內(nèi)存中的數(shù)據(jù)緩沖區(qū)不一定連續(xù)可能是分散在多個物理頁里。DMA引擎通過PRDT把這些分散的區(qū)域串聯(lián)起來一次命令就能完成整塊數(shù)據(jù)的搬運不需要CPU逐個區(qū)域復制。這和MCU里Scatter-Gather的思想完全一致只是規(guī)模更大、性能要求更高。在Linux的UFS驅動中SCSI命令和UFS命令如READ/WRITE通過UTP描述符組織DMA引擎負責將命令描述符、PRDT、數(shù)據(jù)緩沖區(qū)的內(nèi)容按協(xié)議格式搬運到UFS控制器。大文件讀寫時CPU占用率很低就是因為數(shù)據(jù)搬運全部由UFS DMA完成。UFS DMA對我們嵌入式工程師的啟發(fā)是如果遇到性能瓶頸優(yōu)先考慮用硬件描述符鏈表組織內(nèi)存而不是手動拼包。如果能用DMA的多緩沖區(qū)鏈表功能把分散數(shù)據(jù)一次性搬運比CPU逐塊拼包高效得多。6.3 分布式DMA多核時代的思路分布式DMA也是搜索詞里的一個方向。傳統(tǒng)的MCU方案中整個芯片通常只有一個DMA控制器所有外設共用。外設多了以后DMA通道資源會變得緊張高優(yōu)先級外設長時間占用通道會阻塞低優(yōu)先級外設。多核SoC和高端處理器上的做法是分布式DMA每個子系統(tǒng)、每個外設集群都有自己的DMA引擎各自獨立處理本區(qū)域的數(shù)據(jù)搬運。比如網(wǎng)卡發(fā)一個隊列一個DMA存儲控制器一個DMA顯示控制器一個DMA彼此不搶占。這樣設計的好處是擴展性好外設增加時不必擔心中央DMA通道不夠。隔離性好某個DMA引擎出錯不影響其他引擎。功耗管理靈活不用的DMA引擎可以單獨關電。在嵌入式項目里即使是單核MCU也可以借鑒分布式DMA的思路把高頻的外設如UART、ADC、定時器分別綁定到固定DMA通道低頻外設共享剩余通道避免通道互相搶占導致的數(shù)據(jù)延遲。7. DMA疑難雜癥速查表這里整理了一些我實際項目中踩過、也在社區(qū)里反復看到的DMA問題方便按圖索驥排查?，F(xiàn)象可能原因排查/解決DMA傳輸完成后數(shù)據(jù)不完整配置的傳輸長度比實際數(shù)據(jù)短緩沖區(qū)被其他代碼覆蓋核對NDTR初始值檢查緩沖區(qū)是否溢出、是否有指針越界串口DMA接收的數(shù)據(jù)全為0外設地址配成狀態(tài)寄存器DMA方向配反打印DMA通道寄存器確認外設地址指向數(shù)據(jù)寄存器檢查方向配置DMA發(fā)送數(shù)據(jù)卡住不再發(fā)送上一輪傳輸未完成就重新配置UART TC標志未清發(fā)送前查詢DMA狀態(tài)或等TC標志置位后再啟動緩沖區(qū)數(shù)據(jù)被新數(shù)據(jù)覆蓋循環(huán)模式下CPU處理速度跟不上改用雙緩沖半滿中斷增大緩沖區(qū)ADC多通道數(shù)據(jù)錯位緩沖區(qū)長度不是通道數(shù)整數(shù)倍啟動時序問題緩沖區(qū)長度取通道數(shù)公倍數(shù)首包丟棄用固定電壓定位通道DMA傳輸?shù)揭话胗|發(fā)錯誤中斷總線對齊問題內(nèi)存地址無效外設時鐘未開啟檢查突發(fā)模式下地址對齊檢查DMA和外設時鐘使能使用HAL_UART_Receive_DMA返回HAL_BUSY上一次DMA傳輸還未完成或狀態(tài)未復位調用HAL_UART_AbortReceive后再重新啟動FreeModbus用DMA后協(xié)議解析一幀拆成多段空閑中斷判斷幀結束時機不對配合T35定時器在空閑中斷后再等一段穩(wěn)定時間確認幀結束額外分享兩個比較玄學但真實存在的坑第一個是緩沖區(qū)地址對齊問題。部分DMA控制器對內(nèi)存地址有對齊要求如4字節(jié)、8字節(jié)對齊配置緩沖區(qū)時如果不注意DMA訪問會出現(xiàn)總線錯誤或性能嚴重下降。定義全局數(shù)組時可以使用__attribute__((aligned(4)))來保證對齊。第二個是緩存一致性問題。在帶D-Cache的高性能MCU如帶Cortex-M7或A系列核上CPU寫入DMA緩沖區(qū)后數(shù)據(jù)可能還停留在Cache里沒有寫回內(nèi)存此時啟動DMA發(fā)送發(fā)送出去的是舊數(shù)據(jù)。解決方法是使用SCB_CleanDCache_by_Addr清理Cache或者在配置DMA時使用非Cacheable內(nèi)存區(qū)域。這個坑在沒有Cache的M0/M3上不會出現(xiàn)但一旦換到M7核平臺幾乎必然遇到。我個人的經(jīng)驗是DMA出問題的時候別急著懷疑DMA本身。先確認外設是否真的產(chǎn)生了DMA請求再確認DMA通道是否使能再檢查地址和長度配置最后才去深挖中斷回調的時序邏輯。大部分問題都出在外設與DMA的配合細節(jié)上而不是DMA核心邏輯本身。希望這篇匯總筆記能幫各位少走一些彎路。