1. 為什么STM32FPGA成了工控與儀器項目里的“雙核”標配1.1 單芯片搞不定的兩類活協(xié)議棧與硬實時并行先說個結(jié)論STM32FPGA這套“雙核”組合本質(zhì)不是雙CPU而是異構(gòu)雙處理器。一個負責“管”一個負責“干”各干各擅長的事合起來才叫真正的雙核技術(shù)系統(tǒng)。STM32這類MCU優(yōu)勢在“生態(tài)”和“協(xié)議棧”。RCU、TCP/IP、USB、SDIO、文件系統(tǒng)、GUI一堆現(xiàn)成庫直接調(diào)跑個FreeRTOS做任務調(diào)度非常順。你要讓它去實時處理幾十路高速信號、精確輸出納秒級脈沖它就力不從心了。原因很簡單MCU是串行取指執(zhí)行中斷響應再快也架不住高頻事件源源不斷涌進來更別說還要同時維護通信協(xié)議棧。FPGA的優(yōu)勢在“并行”和“時序”。幾百個計數(shù)器可以同時跑邏輯門延遲決定了處理速度和軟件執(zhí)行完全兩個維度。但FPGA做復雜狀態(tài)機、跑通信協(xié)議棧就很痛苦寫一個TCP/IP協(xié)議棧試試光狀態(tài)機就能繞暈你。就算塞個軟核進去效率也遠不如ARM核。所以這兩個芯片湊在一起不是疊性能而是補短板。我在實際項目里的直觀感受是STM32FPGA技術(shù)系統(tǒng)基本覆蓋了從傳感器采集、實時控制到網(wǎng)絡(luò)協(xié)議上云的完整鏈路。誰在做這類東西搞儀器儀表、運動控制、機器視覺預處理、物聯(lián)網(wǎng)邊緣網(wǎng)關(guān)的工程師幾乎都會碰到這個架構(gòu)。1.2 從搜索熱度看大家的真實痛點我整理了一下去年年底到今年大家搜得多的關(guān)鍵詞很有參考價值FPGA側(cè)的頻率測量、串口發(fā)送ASCII字符串、圖像處理、LVDS接收、MIPI接口、進位鏈TDC測量時間、信號發(fā)生器、串口升級QSPI。STM32側(cè)的定時器捕獲測頻率、ADC切換通道、GBK轉(zhuǎn)UTF8、巴法云、FreeRTOS物聯(lián)網(wǎng)網(wǎng)關(guān)、LWIP協(xié)議棧、CAN通信連不上、ILI9341讀ID是a1a1、DWT、LD文件、J-Link下載環(huán)境?？闯鰜砹藛徇@些需求單獨看都很零散但拼起來其實就是一套典型的“STM32FPGA”系統(tǒng)零件FPGA負責高速采集和接口轉(zhuǎn)換STM32負責協(xié)議處理和上云。搜FPGA頻率測量的人很可能正在做一臺需要STM32讀取測量結(jié)果的頻率計搜LVDS接收和MIPI的人多半在給圖像傳感器做數(shù)據(jù)搬運搬完還是要交給ARM核跑算法或通訊。這篇文章就是按這套思路拆解的。不管你拿FPGA做數(shù)據(jù)采集、接口轉(zhuǎn)換還是實時控制也不管你用STM32做網(wǎng)關(guān)、顯示還是通訊下面這些設(shè)計取舍和調(diào)試鏈路應該都能對得上。2. 雙核系統(tǒng)的架構(gòu)分工先分活再選通信2.1 任務劃分的幾條硬規(guī)則不少初學者拿到STM32FPGA的開發(fā)板第一反應是“FPGA是不是搶STM32的活我全用STM32行不行”這個問題問得挺好答案也簡單先看你有沒有硬實時需求。我給自己定過幾條任務劃分規(guī)則用了幾年還沒出過錯**規(guī)則一超過幾十kHz的周期性信號處理交給FPGA。**比如PWM輸出20kHz以上的多路方波、高速ADC采樣、編碼器正交解碼STM32做起來要么占用大量CPU時間要么精度上不去。**規(guī)則二復雜但低頻的狀態(tài)邏輯留在STM32。**比如人機交互界面、報警狀態(tài)機、參數(shù)配置菜單、云端指令解析這種活讓FPGA做純屬折磨。**規(guī)則三對外通信協(xié)議統(tǒng)一由STM32接管。**串口、CAN、Ethernet、MQTT、HTTP都放STM32。理由很簡單MCU生態(tài)里有現(xiàn)成協(xié)議棧FPGA寫協(xié)議棧費時費力還容易出bug。**規(guī)則四硬實時閉環(huán)控制放FPGA。**比如電流環(huán)、位置環(huán)、需要固定延時的信號鏈一般放在FPGA里跑保證時鐘級確定性。STM32頂多算“閉環(huán)下位機”負責參數(shù)給定和狀態(tài)上報。搜“STM32控制伺服電機485”這類需求本質(zhì)就是STM32做主控下發(fā)參數(shù)FPGA做高速插補或脈沖輸出?？偨Y(jié)成一句話FPGA管“每個時鐘周期都在發(fā)生的細節(jié)”STM32管“需要長期權(quán)衡的事情和對外交流”。這套分工定下來系統(tǒng)架構(gòu)就自動清晰了。2.2 雙核之間的通信選型FSMC、SPI、UART怎么取舍分完活接下來最關(guān)鍵的是STM32和FPGA之間怎么通信。通信帶寬直接決定你能把多少數(shù)據(jù)從FPGA搬到STM32也決定延遲。常用三種方案直接上對比表格通信方式典型速率特點適合場景FSMC/可變靜態(tài)存儲控制器并行總線幾十MB/s以上受IO口和時序制約STM32把FPGA映射成外部SRAM讀寫像操作內(nèi)存一樣簡單占用IO多高速ADC采集、圖像數(shù)據(jù)搬運、大塊數(shù)據(jù)塊交換SPI從機模式1-10Mbps左右取決于分頻和從機能力引腳少實現(xiàn)簡單適合中低速數(shù)據(jù)塊溫度采樣、狀態(tài)寄存器輪詢、配置命令下發(fā)UART115200bps-1Mbps最簡單但速率低傳輸有波特率容錯問題調(diào)試鏈路、低頻率狀態(tài)上報我從項目實操角度說點文檔里不太會寫的體會FSMC這個名字聽起來高大上其實就是STM32片內(nèi)外設(shè)的一個接口控制器可以把外部器件當作內(nèi)存來訪問。FPGA端只需要實現(xiàn)一個“異步SRAM讀寫的狀態(tài)機”STM32這邊配好時序參數(shù)接下來用*(uint16_t *)0x64000000 data;這么一行代碼就能寫數(shù)據(jù)到FPGA。反過來讀也一樣。這是速度最快、代碼最干凈的方案。缺點也明顯要占用GPIO一大片對PCB布線要求高。SPI是我個人推薦的“起步方案”。STM32做主機FPGA做從機兩根數(shù)據(jù)線加一根時鐘線一版就能通。很多項目一輩子用SPI就夠了沒必要一上來就搞FSMC。需要注意SPI從機模式下FPGA的響應時機必須足夠快否則主機拉低片選后等不到數(shù)據(jù)就直接讀超時。早期建議在FPGA里做一個簡單的8位寄存器陣列把配置參數(shù)、狀態(tài)標志、測量結(jié)果都映射成寄存器STM32通過SPI讀寫寄存器邏輯清晰也不容易錯。UART只建議用在調(diào)試鏈路上。有個隱蔽的坑兩邊都是“近似波特率”哪怕誤差在±1%以內(nèi)長時間連續(xù)收發(fā)大數(shù)據(jù)包也可能偶發(fā)出錯。所以UART幀格式里一定要帶校驗一旦收到錯誤幀就重發(fā)別裸奔。2.3 握手協(xié)議與數(shù)據(jù)幀格式設(shè)計通信物理鏈路選好了還得定一套雙方都認的數(shù)據(jù)幀格式。我踩過的最痛的一個坑就是前期圖省事直接定義了一個固定長度的結(jié)構(gòu)體數(shù)組結(jié)果需求一改雙方同步改代碼改到后面版本錯亂簡直無法維護。后來我學乖了所有通信都走“統(tǒng)一幀格式”用最樸素的方案幀頭(0xA5) | 命令字 | 數(shù)據(jù)長度 | 數(shù)據(jù)區(qū) | 校驗和幀頭1字節(jié)命令字1字節(jié)長度2字節(jié)數(shù)據(jù)區(qū)最多4096字節(jié)校驗和用簡單的累加即可。FPGA收到幀后先解析幀頭和長度再接收數(shù)據(jù)區(qū)并計算校驗校驗通過就執(zhí)行命令不通過直接丟棄并回報錯誤標志。為什么這么做因為STM32和FPGA兩邊是不同的開發(fā)工具鏈調(diào)試時經(jīng)常一邊在改Verilog一邊在改C代碼。有了統(tǒng)一幀格式兩邊各自維護狀態(tài)機只要遵守幀格式這條“契約”各自內(nèi)部怎么改都不影響對面。這里再分享一個高級技巧可以把FPGA內(nèi)部所有寄存器設(shè)計成“地址映射表”STM32讀寫一個寄存器地址FPGA返回對應的狀態(tài)/數(shù)值。就像你訪問一條內(nèi)存地址一樣調(diào)試和維護都極其方便。尤其是搜“STM32 ADC切換通道”或者“FPGA信號發(fā)生器”這類項目有了寄存器映射STM32改頻率、切換通道、讀測量結(jié)果全部變成對某個地址的讀/寫操作代碼可讀性提升一個等級。3. FPGA端三個值得練手的模塊從頻率測量到高速接口3.1 頻率測量等精度測量原理與實現(xiàn)要點先說一個熱詞“FPGA實現(xiàn)頻率測量”這在項目里幾乎必做也是最容易理解FPGA并行優(yōu)勢的練手模塊。頻率測量主要有三種思路測頻法在固定閘門時間內(nèi)數(shù)被測信號的脈沖個數(shù)頻率脈沖數(shù)/時間。適合測高頻低頻測不準。測周法測量被測信號一個周期內(nèi)的高頻基準時鐘個數(shù)頻率基準頻率/計數(shù)。適合測低頻高頻反而測不準。等精度測量法把測頻法的閘門設(shè)計成“跟隨被測信號邊沿”的同步閘門。閘門開啟和關(guān)閉都自動對齊被測信號的邊沿同時計數(shù)被測脈沖數(shù)和基準時鐘數(shù)無論高頻率低頻率相對誤差都一樣而且只取決于基準時鐘的準確度。FPGA實現(xiàn)等精度測量非常自然因為里面對被測信號和基準時鐘各有一個計數(shù)器兩者并行跑閘門信號一拉高就開始計閘門結(jié)束同時鎖存兩個計數(shù)器的值。這個“同時鎖存”是FPGA的天然能力換成MCU需要精確的中斷配合很難做到。偽代碼層面長這樣// 等精度頻率計核心邏輯簡化 always (posedge clk_100m) begin gate_sync test_signal ? 1 : 0; // 閘門同步到被測信號 end // 基準計數(shù)器和被測計數(shù)器 always (posedge clk_100m) begin if (gate_sync !gate_sync_prev) cnt_ref 0; // 閘門打開開始計數(shù) else if (gate_sync) cnt_ref cnt_ref 1; end // 頻率結(jié)果 被測計數(shù) / 基準計數(shù) * 基準頻率實際項目里還要加幾個細節(jié)多次測量取平均消抖動、自動量程切換、防止計數(shù)溢出。代碼本身不難難的是理解“同時計數(shù)”背后對時序的要求。我見過不少初學者把這個邏輯寫成先數(shù)被測信號再數(shù)基準信號那就完全沒有并行意義了。你要想清楚FPGA讓你能同時干兩件事這才是價值所在。3.2 串口發(fā)送ASCII字符串一個看似簡單但容易踩坑的模塊搜“FPGA實現(xiàn)串口發(fā)送ASCII字符串”特別多原因很實在FPGA需要把測量結(jié)果發(fā)出去最簡單的就是通過串口用ASCII碼發(fā)出數(shù)字和字符。但真寫起來發(fā)現(xiàn)一堆細節(jié)。UART發(fā)送模塊的核心是波特率發(fā)生器。用一個計數(shù)器分頻出波特率時鐘比如100MHz系統(tǒng)時鐘要發(fā)115200bps計數(shù)器分頻系數(shù)大約是868在每個波特率時鐘沿按位發(fā)送。發(fā)送一幀的順序是起始位08位數(shù)據(jù)低位在前停止位1。這就是基礎(chǔ)。容易踩的坑有三個第一個坑是字符串狀態(tài)機。你設(shè)計了一個“發(fā)送字符串”的模塊但字符串不是一個字節(jié)你要用一個狀態(tài)機控制數(shù)據(jù)選擇、總線占用、字節(jié)間時間間隔。如果狀態(tài)機寫得不仔細很容易出現(xiàn)字節(jié)之間間隔太短或太長的問題。間隔太短接收方跟不上間隔太長又拉低整體效率。第二個坑是ASCII轉(zhuǎn)換。FPGA里沒有sprintf這個函數(shù)你要自己把二進制測量結(jié)果轉(zhuǎn)換成十進制的一串ASCII碼再發(fā)送?？梢詫懸粋€“除10取余”的轉(zhuǎn)換狀態(tài)機先用組合邏輯做除法取余再查表變成字符。這個過程占資源不大但是初學者容易寫錯順序。我自己習慣先在仿真里驗證一遍轉(zhuǎn)換結(jié)果再上板。第三個坑是不要為了追求簡潔而把發(fā)送邏輯全塞進一個always塊。拆分模塊是FPGA好習慣波特率發(fā)生器一個模塊ASCII轉(zhuǎn)換一個模塊發(fā)送狀態(tài)機一個模塊。每個模塊單獨測試出問題只改一小塊。很多FPGA項目后期的難易程度完全取決于前期模塊切分是否合理。3.3 進階TDC時間測量、LVDS接收與MIPI接口為什么只能靠FPGA如果頻率測量和串口讓你打好了基礎(chǔ)那該聊聊真正讓FPGA不可替代的東西了。搜“FPGA進位鏈TDC測量時間”“FPGA的LVDS接收”“FPGA實現(xiàn)MIPI”這些才是雙核系統(tǒng)里FPGA的核心價值所在。TDC即時間數(shù)字轉(zhuǎn)換器簡單說就是測量一個時間間隔有多長。用MCU實現(xiàn)分辨率基本在微秒級別靠定時器捕獲。而FPGA里可以利用進位鏈的延遲時間做TDC分辨率能達到幾十皮秒甚至更高。原理很簡單信號通過FPGA內(nèi)部的進位鏈CARRY4傳播每一級延遲在皮秒量級用D觸發(fā)器把傳播結(jié)果鎖存翻譯成二進制時間值就能測出信號到達的精確時刻。搜“使用FPGA進位鏈TDC測量時間”的人通常是在做激光雷達、超聲測距、粒子物理實驗這類對時間精度要求極高的項目用MCU根本不可能實現(xiàn)。LVDS接收屬于高速串行接口。LVDS信號是差分對速率經(jīng)常上百Mbps甚至更高需要用FPGA的專用收發(fā)引腳和高速時鐘管理模塊去做數(shù)據(jù)采樣恢復。STM32的IO基本不支持LVDS這種電平標準就算外接轉(zhuǎn)接芯片數(shù)據(jù)率也跟不上。所以只要你的系統(tǒng)需要接高速ADC、LVDS攝像頭或高速背板總線FPGA幾乎是唯一選擇。MIPI接口更典型。MIPI是移動設(shè)備攝像頭和顯示屏常用的高速串行接口D-PHY速率經(jīng)常到Gbps級別。FPGA需要做lane對齊、時鐘恢復、數(shù)據(jù)字節(jié)打包然后才把圖像數(shù)據(jù)交給STM32做處理或顯示。這塊邏輯復雜時序要求高但只要你跟著官方例程做一次D-PHY接收對FPGA高速設(shè)計的理解會立馬上一個臺階。我做這些模塊的一個重要心得是高速接口設(shè)計優(yōu)先看官方IP核和參考設(shè)計不要自己硬造輪子。Xilinx有MIPI CSI-2 IP核Altera有LVDS IP核先把官方demo跑通再逐步改成自己需要的接口參數(shù)能省掉至少兩周的調(diào)試時間。等你有經(jīng)驗了再去手寫協(xié)議邏輯也不遲。4. STM32端實現(xiàn)細節(jié)從HAL庫到物聯(lián)網(wǎng)網(wǎng)關(guān)4.1 時鐘樹、DWT和定時器捕獲測頻率/測脈寬的MCU方案把FPGA分了那么多活STM32這邊也不是沒事干。搜“STM32定時器捕獲測頻率”“STM32 DWT”這類關(guān)鍵詞的人說明很多人其實想在MCU側(cè)直接測頻率或者用DWT做精確計時。STM32定時器捕獲的原理是輸入引腳檢測到上升沿/下降沿時定時器計數(shù)器的當前值被自動鎖存到捕獲寄存器同時觸發(fā)中斷。連續(xù)兩次捕獲的計數(shù)值之差乘以定時器時鐘周期就是信號周期。測量低頻信號很準高頻信號會由于中斷響應時間抖動產(chǎn)生誤差。實操時HAL庫寫法很簡潔// 初始化定時器輸入捕獲以TIM2為例 TIM_IC_InitTypeDef sIC; sIC.ICPolarity TIM_ICPOLARITY_RISING; // 上升沿捕獲 sIC.ICSelection TIM_ICSELECTION_DIRECTTI; sIC.ICPrescaler TIM_ICPSC_DIV1; sIC.ICFilter 0; // 濾波可設(shè)為2-15以抗毛刺 HAL_TIM_IC_ConfigChannel(htim2, sIC, TIM_CHANNEL_1); HAL_TIM_IC_Start_IT(htim2, TIM_CHANNEL_1);然后在中斷回調(diào)里讀取兩次捕獲值求差即可。注意一個陷阱如果信號頻率很低定時器可能溢出需要加一個溢出計數(shù)器把溢出也計入周期。很多初學者漏掉這點低頻信號測出來是錯的。DWT則是一個容易被低估的工具。Cortex-M3/M4內(nèi)核自帶Data Watchpoint and Trace單元其中有一個32位周期計數(shù)器頻率等于內(nèi)核時鐘。用一行代碼就能啟動CoreDebug-DEMCR | CoreDebug_DEMCR_TRCENA_Msk; DWT-CYCCNT 0; DWT-CTRL | DWT_CTRL_CYCCNTENA_Msk;之后讀DWT-CYCCNT就可以獲得精確到周期的計時。我常用它來進行代碼片段耗時統(tǒng)計和分析比寫一堆GPIO翻轉(zhuǎn)測量準得多。做雙核系統(tǒng)聯(lián)調(diào)時用DWT測STM32讀寫FPGA某個寄存器整個流程耗時定位瓶頸非常有效。這里順便回應一個熱詞“STM32 HAL庫下載”。HAL庫其實就在STM32CubeMX的安裝包里不需要單獨下載。用CubeMX生成工程初始化代碼你會發(fā)現(xiàn)外設(shè)配置工作量直接減半。唯一的建議是生成代碼后自己手動添加的邏輯塊和生成區(qū)之間做主備版本管理避免CubeMX重新生成把代碼沖掉。4.2 ADC多通道切換與DMA以及ILI9341讀ID為a1a1這類“玄學”問題ADC多通道切換是STM32常見的需求。用HAL庫寫ADC時如果你的掃描模式?jīng)]有正確配置切換通道后第一次采樣值常常不準這是因為通道切換后需要穩(wěn)定時間。我當時解決方法是把每輪采樣的第一次結(jié)果丟棄從第二次開始使用或者干脆用DMA一直在循環(huán)采樣DMA緩沖區(qū)里的前幾個數(shù)據(jù)直接忽略。不要追求“一上電就采到完美值”工程上做“過濾掉暫態(tài)樣本”反而是最省事的。再吐槽一個經(jīng)典問題STM32使用ILI9341讀ID返回a1a1。搜這個詞的人基本都被這個坑絆過。a1a1這個值其實不是芯片壞了而是時序沒配對或者ILI9341的ID寄存器讀取方式不對。正常ILI9341讀ID應該返回0x93如果你讀回來全是0xA1A1多半是你在發(fā)“讀ID命令”前沒有先進入SPI正確的讀寫模式或者時鐘相位極性配錯了。換到雙核系統(tǒng)里這種“讀回來永遠是同一串值”的現(xiàn)象同樣常見——比如STM32通過SPI讀FPGA寄存器如果兩邊時鐘極性或相位不一致讀回來的數(shù)據(jù)永遠是0xFF或0x00看起來像“玄學”實際就是協(xié)議細節(jié)沒對齊。解決這類問題的通用思路用邏輯分析儀抓SPI的CS、SCK、MOSI、MISO四根線對比數(shù)據(jù)手冊時序圖。比起漫無目的地改軟件一次波形分析比什么都管用。4.3 FreeRTOSLWIP巴法云STM32端作為網(wǎng)關(guān)的實現(xiàn)思路雙核系統(tǒng)里STM32還有個重要身份物聯(lián)網(wǎng)網(wǎng)關(guān)。搜“FreeRTOS STM32物聯(lián)網(wǎng)網(wǎng)關(guān)”“STM32網(wǎng)關(guān)lwip協(xié)議棧”“STM32 巴法云”的用戶就是要把采集到的數(shù)據(jù)送上云同時接收云端的控制指令。我的標準框架是FreeRTOS做任務調(diào)度LWIP協(xié)議棧跑網(wǎng)絡(luò)巴法云或者自建MQTT服務器做上云通道。整體任務劃分可以做成三四個任務數(shù)據(jù)采集任務定期從FPGA那邊讀測量結(jié)果存到共享區(qū)。網(wǎng)絡(luò)任務運行MQTT客戶端周期發(fā)布數(shù)據(jù)到主題?？刂迫蝿沼嗛喸贫酥黝}收到指令后解析成參數(shù)再通過SPI/FSMC下發(fā)FPGA執(zhí)行。任務與任務之間用FreeRTOS隊列或者信號量傳遞避免裸機循環(huán)帶來的CPU浪費。這也是STM32相對于FPGA最大的優(yōu)勢所在你有完整的RTOS生態(tài)寫網(wǎng)絡(luò)應用和云端對接幾乎都是搭積木。這里提醒一個和云端交互直接相關(guān)的細節(jié)如果你設(shè)備需要處理云端下發(fā)的中文消息就繞不開編碼轉(zhuǎn)換。搜“STM32 GBK轉(zhuǎn)UTF8”的人多半是顯示用戶名稱或中文指令時出現(xiàn)了亂碼。云端消息基本都是UTF-8編碼而很多串口屏或文件系統(tǒng)用的是GBK。你沒做轉(zhuǎn)換就顯示必然亂碼。實現(xiàn)思路很簡單先查表記住GBK和UTF-8的對應關(guān)系按字節(jié)流判判斷當前是ASCII還是雙字節(jié)中文再做映射。這個表比較大可以放到外部Flash或SD卡里按需加載。5. 聯(lián)調(diào)階段最容易翻車的地方與排查鏈路5.1 電平與IO標準3.3V對3.3V也可能出問題很多人以為STM32和FPGA都是3.3V電平直接連就行了。實際上兩個芯片的IO電氣特性本質(zhì)上都是3.3V但驅(qū)動能力和灌電流能力差別很大。如果FPGA的IO管腳配置成1.8V的Bank電壓而你直接和3.3V的STM32引腳相連電流灌入可能導致芯片鎖死甚至燒毀。所以聯(lián)調(diào)第一件事確認FPGA各個Bank的VCCO電壓和STM32的電平標準匹配。FPGA里像LVDS這類高速接口需要專用差分引腳切記不能接到普通IO上那些普通IO不支持LVDS電氣標準。還有一點開發(fā)板上FPGA和STM32經(jīng)常分布在兩個區(qū)域走線經(jīng)過排針或轉(zhuǎn)接板。一旦信號質(zhì)量不佳現(xiàn)象就是“時好時壞”“高溫后頻繁出錯”。排查方式很簡單用示波器看波形上升沿是否光滑有沒有回溝?？吹交販蟽?yōu)先懷疑信號完整性問題而不是代碼問題。5.2 時序違例與毛刺用示波器和邏輯分析儀復現(xiàn)一次真實排查我印象最深的一次聯(lián)調(diào)問題現(xiàn)象是STM32讀FPGA的數(shù)據(jù)偶爾會讀到FF程序里怎么查都查不出原因。后來抓了CS信號和數(shù)據(jù)信號的波形發(fā)現(xiàn)FPGA發(fā)出的數(shù)據(jù)在CS拉低的時候還沒有完全穩(wěn)定STM32在CS下降沿一采就采到了中間狀態(tài)。這個問題的根因是FPGA端輸出的建立時間不夠。解決方式三種調(diào)整STM32側(cè)的讀寫時序參數(shù)在CubeMX的時序配置里把地址建立時間和數(shù)據(jù)建立時間適當放寬。FPGA側(cè)對輸出數(shù)據(jù)打一拍也就是加一個寄存器延遲輸出讓數(shù)據(jù)在CS有效前就已經(jīng)穩(wěn)定。換用更慢的時鐘或者下降沿采樣。排查鏈路清晰的話這類問題不超過半天就能定位。最怕的是直接懷疑“是不是硬件壞了”換芯片重焊問題依舊然后又回到軟件死循環(huán)。所以我強烈建議雙核聯(lián)調(diào)時示波器和邏輯分析儀必須配合使用尤其是看協(xié)議總線的時序一個邏輯分析儀能省幾倍的時間。5.3 從“STM32 CAN通信突然連不上”延伸的通信故障排查思想搜“STM32 CAN通信突然連不上”這項也很熱。CAN通信出問題的常見原因有波特率配置不匹配、總線缺少終端電阻、某個節(jié)點錯誤率過高導致總線被動關(guān)閉。排查順序通常也是先量總線波形再查配置再查節(jié)點狀態(tài)寄存器。我把這套排查思想推廣到雙核系統(tǒng)里特別適合任何莫名其妙的通信故障第一步隔離層。先把雙核通信斷開STM32自發(fā)自回環(huán)測試FPGA用仿真激勵測試分別確認兩端自身是否正常。第二步波形層。用示波器或邏輯分析儀抓通信引腳的電氣波形確認電平、時序、握手信號是否和協(xié)議一致。第三步協(xié)議層。加打印或者把FPGA收到的字節(jié)流回傳確認幀頭、長度、校驗每個字段是否變換。第四步環(huán)境層。排除干擾源檢查供電穩(wěn)定性確認沒有地電位差。這條排查鏈路我用了很多年幾乎通吃所有雙核通信問題。而不是一上來就盯著代碼反復看很多問題根本不在代碼里。6. 項目落地后的改進空間與我的個人體會6.1 可擴展方向從雙核到更復雜的異構(gòu)系統(tǒng)STM32FPGA雙核架構(gòu)用熟了以后你可以自然往兩個方向擴展。一是往“軟核SoC”方向走?，F(xiàn)在主流FPGA都支持在內(nèi)部例化ARM軟核或硬核處理器比如Zynq系列就是ARM核與FPGA在同一個芯片內(nèi)通信帶寬遠高于外部并口。如果你的項目需要更高速率的數(shù)據(jù)交換比如圖像處理流水線每秒傳輸幾百MB可以考慮直接上Zynq這類SoC FPGA。STM32FPGA是入門和中等成本的王道Zynq則是高性能擴展。二是往“多核分工”方向走。在雙核基礎(chǔ)上再加一顆DSP做音頻或振動信號處理或者加一顆NPU做AI推理FPGA仍然充當前端的接口匯聚和時序控制角色。搜“FPGA圖像處理”和“FPGA創(chuàng)新設(shè)計大賽選題”的人很多都會走向這種綜合異構(gòu)架構(gòu)。6.2 我做過的幾個坑位總結(jié)與給新手的建議最后說說我個人實際操作中的體會。如果讓我給剛接觸STM32FPGA雙核系統(tǒng)的人提幾條建議第一條是先把鏈路跑通再追求性能。很多人一上來就設(shè)計高深的DMA和并行總線結(jié)果基礎(chǔ)通信還沒通反而懷疑人生。我建議第一個demo就用UART或者SPIFPGA返回一個固定寄存器值STM32讀到就表示通信成功。在這個基礎(chǔ)上再逐步增加功能效率會高很多。第二條是FPGA邏輯一定要做仿真。哪怕是一個狀態(tài)機也值得在仿真里把波形看清楚了再上板。FPGA調(diào)試難度遠高于MCU因為內(nèi)部信號你看不到而仿真能讓你看到一切。我見過太多人直接上板信號出問題又不知道內(nèi)部狀態(tài)走到哪瞎猜半天。第三條是想清楚“哪些數(shù)據(jù)必須實時哪些可以緩存”。雙核系統(tǒng)的性能瓶頸經(jīng)常不在芯片本身而在通信鏈路的帶寬和延遲。一開始就把數(shù)據(jù)流分類高頻實時數(shù)據(jù)在FPGA內(nèi)部就地處理只把結(jié)果傳給STM32低頻狀態(tài)數(shù)據(jù)才走完整幀協(xié)議。這個設(shè)計的良好與否直接決定系統(tǒng)最終性能。最后一條版本管理一定從一開始就做。STM32代碼、FPGA工程、引腳約束文件、通信協(xié)議版本全部納入版本管理。兩個芯片的項目最怕的就是改了FPGA工程忘改STM32工程然后莫名其妙花了三天找“bug”結(jié)果發(fā)現(xiàn)協(xié)議字段錯位了。別問我怎么知道的這個坑我摔過不止一次。