1. 馮·諾依曼架構(gòu)與哈佛架構(gòu)從指令流和數(shù)據(jù)流走哪條路說(shuō)起如果你在嵌入式這行干過(guò)一段時(shí)間一定遇到過(guò)這類問(wèn)題為什么 STM32 上把一個(gè)大的查表數(shù)組加個(gè)const就能塞進(jìn) Flash、不加就把 RAM 吃光為什么 Bootloader 擦寫 Flash 的時(shí)候代碼必須搬到 RAM 里跑為什么 DMA 搬一塊放在 CCM RAM 里的緩沖區(qū)永遠(yuǎn)搬不動(dòng)這些問(wèn)題表面上看是鏈接腳本、是寄存器配置往下挖一層全都指向同一個(gè)底層話題——馮·諾依曼架構(gòu)和哈佛架構(gòu)。很多朋友初學(xué)嵌入式的時(shí)候把這兩個(gè)名詞當(dāng)成純背誦的八股考試完就扔了。但我自己的體會(huì)是這兩個(gè)架構(gòu)決定的是「CPU 在一個(gè)機(jī)器周期里到底能同時(shí)干幾件事」它直接決定了你寫出來(lái)的代碼跑多快、內(nèi)存怎么分、DMA 能不能用、程序在板子上會(huì)不會(huì)莫名其妙跑飛。不管你是剛點(diǎn)亮第一顆 LED 的新手還是已經(jīng)在做嵌入式 Linux、做基于 Simulink 自動(dòng)代碼生成的工程化項(xiàng)目這套底層認(rèn)知都繞不開(kāi)。這篇東西我打算按從業(yè)者的思路來(lái)講先把兩種架構(gòu)的本質(zhì)差異拆開(kāi)再落到 51、AVR、STM32、DSP 這些真實(shí)芯片上看它們各站哪一邊然后講清楚架構(gòu)差異是怎么一層層影響到你寫的每一行 C 代碼的最后給一套可以自己動(dòng)手復(fù)現(xiàn)的驗(yàn)證流程和排錯(cuò)清單。文中涉及的具體參數(shù)和實(shí)測(cè)數(shù)據(jù)我都會(huì)說(shuō)明來(lái)源和前提方便你拿自己的板子對(duì)照。1.1 馮·諾依曼架構(gòu)一條總線走天下代價(jià)在哪馮·諾依曼架構(gòu)的核心思想叫「存儲(chǔ)程序」最早在 1945 年那份著名的報(bào)告草案里被系統(tǒng)提出。它的關(guān)鍵特征是指令和數(shù)據(jù)存放在同一個(gè)存儲(chǔ)器里共用同一套地址總線和數(shù)據(jù)總線。CPU 要執(zhí)行一條指令先從內(nèi)存里把指令取出來(lái)取指再去內(nèi)存里取操作數(shù)取數(shù)算完了再把結(jié)果寫回去寫回。這幾次內(nèi)存訪問(wèn)走的是同一條路只能排隊(duì)不能并行。這個(gè)「排隊(duì)」就是后來(lái)大家常說(shuō)的馮·諾依曼瓶頸。打個(gè)比方一家只有一扇門的倉(cāng)庫(kù)工人要進(jìn)去拿圖紙指令又要進(jìn)去拿原料數(shù)據(jù)一次只能進(jìn)一個(gè)人。CPU 主頻越跑越高存儲(chǔ)器速度跟不上瓶頸就越明顯。現(xiàn)代通用處理器靠多級(jí)緩存、指令預(yù)取、亂序執(zhí)行去緩解它但邏輯模型上還是馮·諾依曼的那一套。它的好處也很實(shí)在。第一結(jié)構(gòu)簡(jiǎn)單布線少芯片面積和成本低。第二靈活性極高——程序本身可以被當(dāng)成數(shù)據(jù)來(lái)處理所以動(dòng)態(tài)加載、自修改代碼、JIT 編譯這些玩法在馮·諾依曼體系里是天然成立的。你在 PC 上雙擊一個(gè)可執(zhí)行文件操作系統(tǒng)把它當(dāng)數(shù)據(jù)讀進(jìn)內(nèi)存然后跳過(guò)去執(zhí)行這就是「程序即數(shù)據(jù)」的直接體現(xiàn)。代價(jià)則集中在帶寬上。取指和取數(shù)爭(zhēng)搶同一條總線流水線設(shè)計(jì)里必須處理「結(jié)構(gòu)冒險(xiǎn)」一旦發(fā)生就只能插入流水線氣泡性能打折。對(duì)于需要大量數(shù)據(jù)吞吐的場(chǎng)合這種架構(gòu)會(huì)比較吃力。1.2 哈佛架構(gòu)指令和數(shù)據(jù)各走各的路快在哪哈佛架構(gòu)的名字來(lái)自馬克一號(hào)計(jì)算機(jī)它的做法很直接指令存儲(chǔ)器和數(shù)據(jù)存儲(chǔ)器物理分開(kāi)各自擁有獨(dú)立的地址總線和數(shù)據(jù)總線。這樣一來(lái)CPU 在一個(gè)機(jī)器周期里可以一邊從程序存儲(chǔ)器取指令一邊從數(shù)據(jù)存儲(chǔ)器讀操作數(shù)兩件事真正并行不再排隊(duì)。主流單片機(jī)和 DSP 大多是哈佛或它的變體。AVR、PIC、8051、絕大多數(shù) DSP 內(nèi)核都是這個(gè)路子。它帶來(lái)的收益有幾個(gè)層面。性能層面最直觀。取指和取數(shù)不沖突流水線更容易填滿指令吞吐量上去了。而且指令字長(zhǎng)可以獨(dú)立設(shè)計(jì)不必受數(shù)據(jù)字長(zhǎng)約束對(duì)定長(zhǎng)指令編碼很友好?？煽啃詫用娉１缓鲆暤珜?duì)嵌入式非常重要。程序存儲(chǔ)器通常只能通過(guò)專門的取指通道讀取普通的數(shù)據(jù)寫指令根本改不了它。這意味著跑飛的指針很難把代碼段寫壞天然的防誤寫保護(hù)。做功能安全、做長(zhǎng)期無(wú)人值守的設(shè)備時(shí)這一點(diǎn)值不少錢。第三個(gè)層面是總線結(jié)構(gòu)可以做得更寬。DSP 里常見(jiàn)的多總線哈佛結(jié)構(gòu)一個(gè)周期內(nèi)能完成「取一條指令 讀兩個(gè)操作數(shù) 寫一個(gè)結(jié)果」配合硬件乘法累加器FIR 濾波、FFT 這類算法的效率能拉開(kāi)很大差距。它的問(wèn)題也很清楚。硬件成本上去了兩套總線、兩塊存儲(chǔ)器面積和引腳都增加。地址空間不統(tǒng)一訪問(wèn)放在程序存儲(chǔ)器里的常量表需要專門指令——AVR 用LPM8051 用MOVCPIC 用TBLRD。寫 C 代碼時(shí)要額外加修飾符比如 AVR 的PROGMEM、8051 的code。至于自修改代碼、動(dòng)態(tài)加載這類玩法在純哈佛結(jié)構(gòu)上基本免談。1.3 改進(jìn)型哈佛ARM Cortex-M 實(shí)際采用的做法真正有意思的地方來(lái)了。ARM Cortex-M 系列既不是純馮·諾依曼也不是教科書上的純哈佛而是改進(jìn)型哈佛從程序員視角看它是一套統(tǒng)一的 4GB 地址空間代碼和數(shù)據(jù)都在里面排布看起來(lái)像馮·諾依曼但從總線層面看取指和數(shù)據(jù)訪問(wèn)走的是不同的通道又帶有哈佛的味道。具體來(lái)說(shuō)Cortex-M3/M4 內(nèi)核對(duì)外引出三條總線ICode 總線負(fù)責(zé)從0x0000_0000到0x1FFF_FFFF區(qū)間取指令DCode 總線負(fù)責(zé)從同一區(qū)間取常量數(shù)據(jù)比如const數(shù)組System 總線負(fù)責(zé)訪問(wèn)0x2000_0000以上的 SRAM 和外設(shè)。這三條總線在總線矩陣?yán)锝徊嬷噶詈蛿?shù)據(jù)可以同時(shí)奔向不同的目標(biāo)互不阻塞。但這里有個(gè)很關(guān)鍵的細(xì)節(jié)容易被忽略ICode 和 DCode 雖然邏輯上是兩條總線但通常接到同一片 Flash 的物理接口上。如果 CPU 一邊從 Flash 取指一邊又要從 Flash 讀常量表兩者最終還是要在這個(gè)接口處仲裁、排隊(duì)。這就是為什么在 Flash 上跑代碼、同時(shí)頻繁讀 Flash 里的查表數(shù)組性能往往不如把這張表搬到 SRAM 里去讀。還有個(gè)冷門但實(shí)用的知識(shí)點(diǎn)Cortex-M0/M0 只有一條 AHB-Lite 總線取指和取數(shù)分時(shí)復(fù)用本質(zhì)上更接近馮·諾依曼式的結(jié)構(gòu)。而 M3/M4 才是前面說(shuō)的三條總線。M7 更復(fù)雜帶 I-Cache、D-Cache、ITCM、DTCM屬于典型的哈佛緩存結(jié)構(gòu)。所以如果有人問(wèn)你「STM32 是不是哈佛架構(gòu)」正確回答是看具體型號(hào)M3/M4 是改進(jìn)型哈佛M0 的總線結(jié)構(gòu)更接近馮·諾依曼。2. 落到真實(shí)芯片上51、AVR、STM32、DSP 各站哪一邊光講概念容易飄我們把鏡頭拉近看幾種大家天天打交道的芯片到底怎么實(shí)現(xiàn)的。2.1 8051藏在存儲(chǔ)類型關(guān)鍵字里的哈佛結(jié)構(gòu)8051 是很多人入門的第一顆芯片它其實(shí)是相當(dāng)標(biāo)準(zhǔn)的哈佛結(jié)構(gòu)。程序存儲(chǔ)器和數(shù)據(jù)存儲(chǔ)器在物理上分開(kāi)地址都從 0 開(kāi)始編。這種分離直接體現(xiàn)在 C 語(yǔ)言的存儲(chǔ)類型修飾符上這些關(guān)鍵字看著莫名其妙背后全是架構(gòu)決定的。存儲(chǔ)類型所在空間尋址方式典型用途code程序存儲(chǔ)器MOVC指令常量表、字庫(kù)、算法系數(shù)data片內(nèi) RAM 低 128 字節(jié)直接尋址頻繁訪問(wèn)的小變量idata片內(nèi) RAM 全部 256 字節(jié)間址尋址需要間接訪問(wèn)的變量xdata片外數(shù)據(jù)存儲(chǔ)器MOVXDPTR大緩沖區(qū)pdata分頁(yè)片外存儲(chǔ)器MOVXR0/R1小容量外擴(kuò)你看code這個(gè)關(guān)鍵字的存在本身就是哈佛架構(gòu)的證據(jù)。寫unsigned char code table[]的時(shí)候編譯器知道要把表放進(jìn)程序存儲(chǔ)器讀取時(shí)生成MOVC A,ADPTR如果你忘了加code表就落到data或xdata里小芯片上 RAM 瞬間告急。用 Keil C51 編譯時(shí)經(jīng)常遇到的DATA SEGMENT TOO LARGE報(bào)錯(cuò)本質(zhì)上就是「片內(nèi) RAM 只有 128 字節(jié)你還往里面塞大數(shù)組」的問(wèn)題。2.2 ARM7 與 ARM9同一門派的兩條技術(shù)路線理解 ARM 的歷史演進(jìn)對(duì)搞清架構(gòu)差異特別有幫助。ARM7TDMI 是馮·諾依曼結(jié)構(gòu)一條 32 位數(shù)據(jù)總線指令和數(shù)據(jù)共用取指和取數(shù)不能同時(shí)進(jìn)行所以在高主頻下性能受限。ARM9TDMI 換成了 5 級(jí)流水線并且引入分離的指令緩存和數(shù)據(jù)緩存也就是哈佛緩存結(jié)構(gòu)指令和數(shù)據(jù)的訪問(wèn)可以并行性能明顯提升。這個(gè)脈絡(luò)往下延伸就是今天Cortex-M0 走的是精簡(jiǎn)的單總線路線成本優(yōu)先Cortex-M3/M4 用三條總線做改進(jìn)型哈佛Cortex-M7 加上真正的 I-Cache/D-Cache 和緊耦合內(nèi)存。我記得早期做項(xiàng)目從 ARM7 平臺(tái)遷到 Cortex-M3 平臺(tái)時(shí)同樣主頻下跑同樣的算法性能提升相當(dāng)可觀很大一部分就來(lái)自取指和數(shù)據(jù)訪問(wèn)的解耦。面試?yán)镞@類演進(jìn)問(wèn)題出現(xiàn)頻率極高光背「馮·諾依曼慢、哈佛快」是不夠的能說(shuō)清楚「ARM7 是馮·諾依曼ARM9 開(kāi)始用哈佛緩存Cortex-M3/M4 用改進(jìn)型哈佛」這條線基本就能把面試官穩(wěn)住了。2.3 DSP 與多總線哈佛架構(gòu)的極致形態(tài)如果把哈佛架構(gòu)做到極致就是 DSP 的樣子。以 TI 的 TMS320C54x 為例它內(nèi)部有 1 條程序總線和 3 條數(shù)據(jù)總線一個(gè)機(jī)器周期內(nèi)可以取一條指令同時(shí)讀兩個(gè)操作數(shù)、寫一個(gè)結(jié)果。再配合硬件乘法累加器、循環(huán)尋址、位反轉(zhuǎn)尋址這些專門為信號(hào)處理設(shè)計(jì)的硬件做 FIR 濾波和 FFT 的時(shí)候效率比通用 MCU 高出一大截。這類架構(gòu)里還有個(gè)值得注意的設(shè)計(jì)雙訪問(wèn) RAM。CPU 可以在一個(gè)周期里對(duì)同一塊內(nèi)存做兩次訪問(wèn)進(jìn)一步減少總線沖突。如果你在做音頻處理、電機(jī)控制里的坐標(biāo)變換或者用 Simulink 自動(dòng)生成代碼后跑在 DSP 上會(huì)明顯感覺(jué)到這套總線結(jié)構(gòu)帶來(lái)的差異——同樣的算法在 DSP 上跑得又穩(wěn)又順在通用 MCU 上就得多花心思優(yōu)化。3. 架構(gòu)差異是怎么影響你寫的每一行 C 代碼的到這一節(jié)才是真正的干貨區(qū)。很多人學(xué)架構(gòu)學(xué)完之后感覺(jué)跟實(shí)際寫代碼沒(méi)有關(guān)系那是沒(méi)找對(duì)切入點(diǎn)。下面這六個(gè)影響全是我在實(shí)際項(xiàng)目里踩過(guò)或者被卡過(guò)的。3.1 const 到底把變量放哪了這是最基礎(chǔ)也最容易出問(wèn)題的一點(diǎn)。以 GCC ARM Cortex-M 為例一個(gè)全局變量到底進(jìn)哪個(gè)段取決于你有沒(méi)有加const加了const的全局?jǐn)?shù)組進(jìn).rodata段鏈接時(shí)被分配到Flash。讀取它走 DCode 總線。不加const的全局?jǐn)?shù)組進(jìn).data段有初值或.bss段初值為零被分配到SRAM。讀寫走 System 總線。這個(gè)規(guī)則看著簡(jiǎn)單實(shí)際影響巨大。你在 STM32F103C8 上寫代碼芯片只有 20KB SRAM 和 128KB Flash。一張 8KB 的漢字字庫(kù)表不加const直接把 RAM 干掉小一半加const放進(jìn) Flash 只占 8KB 空間RAM 一點(diǎn)不占。我見(jiàn)過(guò)不止一個(gè)新手因?yàn)橥思觕onst在鏈接階段報(bào)region RAM overflowed然后一臉茫然地來(lái)問(wèn)「我的代碼明明很小」。反過(guò)來(lái)的坑也存在。STM32F4 上有塊 64KB 的 CCM RAM只能被 CPU 通過(guò) D 總線訪問(wèn)DMA 完全碰不到。有人為了性能把 DMA 緩沖區(qū)塞進(jìn) CCM結(jié)果 DMA 傳輸永遠(yuǎn)不結(jié)束查了半天才發(fā)現(xiàn)是內(nèi)存放錯(cuò)了地方。H7 上的 DTCM/ITCM 也是同樣的性質(zhì)。所以「這塊內(nèi)存該放哪」不是一個(gè)可以隨便拍腦袋的決定得先看它由誰(shuí)訪問(wèn)。3.2 為什么在 Flash 上跑代碼會(huì)變慢等待周期和預(yù)取Flash 的工藝決定了它有訪問(wèn)速度上限。STM32F103 跑到 72MHz 的時(shí)候Flash 取指需要插入2 個(gè)等待周期F407 跑到 168MHz 需要5 個(gè)等待周期。如果不做任何優(yōu)化每取一條指令白白等 5 個(gè)周期CPU 的實(shí)際效能大打折扣。廠商的應(yīng)對(duì)方案就是各種加速器。F4 系列有 ART Accelerator自適應(yīng)實(shí)時(shí)加速器內(nèi)部包含指令緩存、分支預(yù)測(cè)和指令預(yù)取F7/H7 更是上了真正的 I-Cache 和 D-Cache也就是前面說(shuō)的哈佛緩存。開(kāi)啟這些機(jī)制以后代碼在 Flash 上跑和搬到 RAM 上跑的差距會(huì)明顯縮小但在緊密循環(huán)、頻繁訪問(wèn)常量表這類場(chǎng)景下差距依然存在。這也是為什么很多 Bootloader、算法熱點(diǎn)函數(shù)會(huì)主動(dòng)搬到 RAM 執(zhí)行。你可以在鏈接腳本里開(kāi)一個(gè).RamFunc段啟動(dòng)時(shí)用memcpy把這段代碼從 Flash 拷到 RAM運(yùn)行時(shí)跳進(jìn)去執(zhí)行。具體有多快后面第 4 節(jié)我會(huì)給一套自己動(dòng)手測(cè)的辦法。3.3 XIP、RAM 函數(shù)與 IAP 的硬性約束XIP 就是 Execute In Place代碼直接在 Flash 里原地執(zhí)行不需要搬運(yùn)省 RAM是絕大多數(shù) MCU 的默認(rèn)做法。但有一種場(chǎng)合是被逼著必須搬在應(yīng)用內(nèi)編程也就是 IAP。道理是這樣——你的擦寫例程本身也存放在 Flash 里當(dāng)你要擦除或?qū)懭?Flash 的時(shí)候如果 CPU 還在同一片 Flash 上取指就會(huì)出現(xiàn)「一邊讀代碼一邊改代碼」的訪問(wèn)沖突結(jié)果要么寫入失敗要么直接跑飛。所以所有成熟的 Bootloader 都會(huì)把 Flash 擦寫例程放到 RAM 里執(zhí)行。這個(gè)要求在編程手冊(cè)里通常寫得很清楚但初做 Bootloader 的人極易忽略。寫這段代碼要注意幾個(gè)細(xì)節(jié)函數(shù)體本身要放進(jìn).RamFunc段被這個(gè)函數(shù)調(diào)用的所有子函數(shù)也要一起搬否則子函數(shù)還在 Flash 里等于白搬搬運(yùn)時(shí)機(jī)必須在進(jìn)入 IAP 之前通常是main里較早的位置還要注意搬運(yùn)完成后刷新指令流水線ARM 平臺(tái)一般用__DSB()加__ISB()保證。3.4 DMA 與 CPU 搶總線CCM/TCM 的坑總線分離帶來(lái)并行也帶來(lái)仲裁。當(dāng) CPU 正在通過(guò) D 總線讀寫 SRAMDMA 也在通過(guò)總線矩陣搬運(yùn)同一片 SRAM 的數(shù)據(jù)時(shí)兩者會(huì)在總線矩陣?yán)锱抨?duì)仲裁。設(shè)計(jì)良好的芯片會(huì)盡量讓它們錯(cuò)開(kāi)但爭(zhēng)用不可避免。更麻煩的是那些「掛在 CPU 私有總線上的內(nèi)存」。STM32F4 的 CCM RAM 只連在 CPU 的 D 總線上DMA 的 AHB 主設(shè)備根本走不到那里。STM32H7 的 DTCM 和 ITCM 也是同樣的性質(zhì)。這類內(nèi)存的好處是 CPU 訪問(wèn)延遲極低、不受 DMA 干擾非常適合放堆棧、放算法中間變量壞處就是外設(shè)搬不動(dòng)它。我在一個(gè)項(xiàng)目里就吃過(guò)這個(gè)虧為了把 FFT 中間結(jié)果放得快一點(diǎn)把緩沖區(qū)定義到了 CCM結(jié)果 SPI 的 DMA 讀取一直超時(shí)。最后排查路線是「懷疑 DMA 配置 → 懷疑時(shí)鐘 → 懷疑中斷優(yōu)先級(jí) → 最后查鏈接腳本發(fā)現(xiàn)段給錯(cuò)了」繞了一大圈。所以給你一條經(jīng)驗(yàn)凡是任何外設(shè)會(huì)碰的內(nèi)存一律不要放進(jìn) CPU 私有內(nèi)存區(qū)。3.5 中斷向量表要在跳轉(zhuǎn)時(shí)重定位這條和架構(gòu)的關(guān)系稍微隱蔽一點(diǎn)但邏輯很硬。Cortex-M 復(fù)位時(shí)CPU 從0x0000_0000處讀取棧頂?shù)刂泛蛷?fù)位入口這是通過(guò)指令通道完成的初始取指。當(dāng)你的 Bootloader 要跳轉(zhuǎn)到 App 的時(shí)候App 的向量表在自己的 Flash 起始地址上如果還讓 CPU 去0x0000_0000找向量中斷就會(huì)跳到 Bootloader 的向量表里。解決辦法是寫SCB-VTOR APP_BASE_ADDR;重新告訴硬件「向量表在這兒」。做 OTA 升級(jí)、雙區(qū)備份方案的這一句幾乎必寫。有時(shí)候還會(huì)配合__DSB()和__ISB()保證寫寄存器的效果在后續(xù)取指之前生效。3.6 緩存一致性與 DMAH7 和 Cortex-A 上繞不開(kāi)一旦引入 D-Cache問(wèn)題就多了一層。DMA 直接寫內(nèi)存繞過(guò)緩存CPU 讀的是緩存里的舊值就會(huì)出現(xiàn)「數(shù)據(jù)明明搬過(guò)來(lái)了CPU 看到的還是老數(shù)據(jù)」。反過(guò)來(lái) CPU 寫了數(shù)據(jù)但還在緩存里沒(méi)落盤DMA 讀到的也是舊值。標(biāo)準(zhǔn)做法是發(fā)送 DMA 之前對(duì)發(fā)送緩沖區(qū)做Clean接收完成之后對(duì)接收緩沖區(qū)做Invalidate。H7 上對(duì)應(yīng)SCB_CleanDCache_by_Addr()和SCB_InvalidateDCache_by_Addr()。更穩(wěn)妥的做法是把 DMA 緩沖區(qū)放到 MPU 配置為不可緩存的內(nèi)存區(qū)域或者 TCM 里從根上避開(kāi)一致性問(wèn)題。這也是為什么高端的多核平臺(tái)里「內(nèi)存分區(qū)策略」是一門專門的學(xué)問(wèn)。4. 動(dòng)手實(shí)測(cè)用反匯編、map 文件和 DWT 計(jì)數(shù)器驗(yàn)證架構(gòu)差異前面講了這么多影響光看文字不如自己驗(yàn)證一遍。這一節(jié)給一套可以照著做的流程我用的工具鏈?zhǔn)莂rm-none-eabi-gcc系列STM32 平臺(tái)其他平臺(tái)思路一致。4.1 工具鏈和最小工程準(zhǔn)備需要的工具其實(shí)很少編譯器套件自帶arm-none-eabi-objdump、arm-none-eabi-nm、arm-none-eabi-size、arm-none-eabi-readelf。如果你想在 VSCode 里看反匯編裝個(gè) Cortex-Debug 插件加上反匯編視圖就夠了。先準(zhǔn)備一個(gè)最小工程里面明確放三種變量/* 放在 Flash 的常量表 */ const uint16_t sin_table[64] { /* ... */ }; /* 放在 SRAM 的普通數(shù)組 */ uint16_t work_buf[64]; /* 未初始化的全局緩沖 */ uint8_t rx_buffer[256];編譯完成之后重點(diǎn)看編譯輸出的.map文件和.elf。4.2 從 map 文件里看清代碼和數(shù)據(jù)的落點(diǎn)打開(kāi).map文件搜索段名你會(huì)看到類似這樣的內(nèi)容數(shù)值以實(shí)際工程為準(zhǔn).rodata 0x08002a10 0x80 table.o .data 0x20000000 0x10 main.o .bss 0x20000010 0x100 main.o這段信息說(shuō)明三件事sin_table落在了0x0800開(kāi)頭的 Flash 區(qū)域work_buf落在了0x2000開(kāi)頭的 SRAMrx_buffer在 SRAM 里但只占運(yùn)行時(shí)空間、不占 Flash 空間。這就是哈佛結(jié)構(gòu)在工程文件里的直接投影兩塊內(nèi)存兩個(gè)地址區(qū)間兩條訪問(wèn)通道。如果你把自己的const去掉再編譯一次會(huì)發(fā)現(xiàn)sin_table從.rodata挪到了.dataFlash 占用減少SRAM 占用猛增。這一進(jìn)一出比任何教科書描述都直觀。4.3 反匯編里看兩條通道的痕跡用arm-none-eabi-objdump -d your.elf dis.txt導(dǎo)出反匯編然后搜你的函數(shù)名。你會(huì)看到訪問(wèn) Flash 常量表和訪問(wèn) SRAM 變量生成的指令形態(tài)是不一樣的。訪問(wèn) Flash 里的常量編譯器通常用 PC 相對(duì)尋址的加載指令ldr r3, [pc, #16] ; 從 Flash 的常量池加載地址 ldrh r0, [r3, r1, lsl #1]訪問(wèn) SRAM 變量則是指令里直接給出基址寄存器加偏移ldr r2, [r7, #4] ; 從 SRAM 加載 str r2, [r7, #4] ; 寫回 SRAM再看 AVR 平臺(tái)的反匯編從 Flash 讀常量必須用LPM指令和讀 SRAM 的LDS是兩條完全不同的指令8051 上就是MOVC對(duì)MOVX。這些指令層面的差異就是哈佛架構(gòu)留下來(lái)的指紋?？炊@些再回頭看那些「PROGMEM 宏是干嘛的」這類問(wèn)題答案自己就浮出來(lái)了。4.4 用 DWT 周期計(jì)數(shù)器實(shí)測(cè) Flash 執(zhí)行和 RAM 執(zhí)行Cortex-M3/M4/M7 內(nèi)核帶一個(gè) DWT 單元里面有周期計(jì)數(shù)器 CYCCNT精度是單周期。用它測(cè)耗時(shí)比用定時(shí)器還準(zhǔn)。初始化三步CoreDebug-DEMCR | CoreDebug_DEMCR_TRCENA_Msk; DWT-CYCCNT 0; DWT-CTRL | DWT_CTRL_CYCCNTENA_Msk;然后準(zhǔn)備兩個(gè)功能完全一樣、只是落點(diǎn)不同的函數(shù)__attribute__((section(.RamFunc), noinline)) void hot_loop_ram(uint32_t n) { volatile uint32_t acc 0; for (uint32_t i 0; i n; i) { acc i * 3 1; } } __attribute__((noinline)) void hot_loop_flash(uint32_t n) { volatile uint32_t acc 0; for (uint32_t i 0; i n; i) { acc i * 3 1; } }測(cè)的時(shí)候前后各讀一次DWT-CYCCNT做差就是周期數(shù)。順手再測(cè)一下「在 Flash 執(zhí)行 同時(shí)讀 Flash 常量表」的組合復(fù)現(xiàn) ICode 和 DCode 在 Flash 接口上的爭(zhēng)用。關(guān)于結(jié)果我自己的板子上觀察到的規(guī)律是這樣的你可以對(duì)照自己的實(shí)驗(yàn)在 Flash 有等待周期、且沒(méi)有開(kāi)啟指令緩存的條件下緊密循環(huán)放在 RAM 里執(zhí)行通常能比放在 Flash 里快兩到四成循環(huán)體里內(nèi)存訪問(wèn)越密集或者常量表越大這個(gè)差距越明顯一旦芯片啟用了 I-Cache 和分支預(yù)測(cè)純計(jì)算型循環(huán)的差距會(huì)大幅收窄但「Flash 取指 Flash 取表」這種雙重訪問(wèn)的差距依然存在。這些數(shù)字和主頻、等待周期配置、優(yōu)化等級(jí)都強(qiáng)相關(guān)所以別記死數(shù)要記住的是「怎么測(cè)」和「看到差距該往哪個(gè)方向優(yōu)化」。4.5 鏈接腳本里分配段的實(shí)操要讓.RamFunc真正生效鏈接腳本必須配合。典型的寫法是這樣MEMORY { FLASH (rx) : ORIGIN 0x08000000, LENGTH 512K RAM (rwx) : ORIGIN 0x20000000, LENGTH 128K CCMRAM (rwx) : ORIGIN 0x10000000, LENGTH 64K } SECTIONS { .text : { *(.isr_vector) *(.text*) } FLASH .RamFunc : { . ALIGN(4); *(.RamFunc) . ALIGN(4); } RAM AT FLASH .ccmram : { *(.ccmram*) } CCMRAM }關(guān)鍵點(diǎn)是 RAM AT FLASH這句段的運(yùn)行地址是 RAM加載地址是 Flash。程序啟動(dòng)時(shí)C 運(yùn)行時(shí)會(huì)把這段從 Flash 拷到 RAM拷完跳過(guò)去執(zhí)行。之后要用的變量定義可以用__attribute__((section(.ccmram)))指定到 CCM前面提醒過(guò)放這里的變量一定不能被 DMA 訪問(wèn)。5. 面試高頻問(wèn)題與排錯(cuò)實(shí)錄到最后一節(jié)了把前面所有內(nèi)容收攏成兩塊能直接用的東西一張面試速查表一張故障排查表。5.1 那些年被問(wèn)爛的架構(gòu)問(wèn)題與回答要點(diǎn)問(wèn)題回答要點(diǎn)馮·諾依曼和哈佛架構(gòu)的核心區(qū)別指令和數(shù)據(jù)是否共用存儲(chǔ)器與總線。共用為馮·諾依曼分離為哈佛哈佛可并行取指與取數(shù)STM32 屬于哪種架構(gòu)看型號(hào)。Cortex-M0/M0 單 AHB-Lite 總線偏馮·諾依曼M3/M4 為改進(jìn)型哈佛ICode/DCode/System 三條總線M7 帶 I-Cache/D-Cache 與 TCM哈佛架構(gòu)為什么快取指與取數(shù)使用獨(dú)立通道流水線不因結(jié)構(gòu)冒險(xiǎn)停頓一個(gè)周期可并行完成8051 為什么是哈佛結(jié)構(gòu)程序存儲(chǔ)器與數(shù)據(jù)存儲(chǔ)器獨(dú)立編址附加MOVC專門訪問(wèn)程序空間C 語(yǔ)言里用code修飾符體現(xiàn)哈佛架構(gòu)的缺點(diǎn)硬件成本高、地址空間不統(tǒng)一、訪問(wèn)程序區(qū)常量需要專用指令、不支持自修改代碼與動(dòng)態(tài)加載為什么有些代碼要搬到 RAM 執(zhí)行繞過(guò) Flash 等待周期提升速度IAP 擦寫 Flash 時(shí)避免同片 Flash 取指沖突為什么 DMA 搬不了 CCM RAMCCM 只掛在 CPU 私有 D 總線上DMA 主設(shè)備無(wú)法通過(guò)總線矩陣訪問(wèn)到回答這類問(wèn)題光說(shuō)概念容易顯得空洞最好帶上一句自己的項(xiàng)目經(jīng)歷比如「我在做 OTA 的時(shí)候把 Flash 操作函數(shù)搬到 RAM否則一擦寫就掛」可信度立刻不一樣。5.2 常見(jiàn)問(wèn)題速查表現(xiàn)象可能原因排查與解決鏈接報(bào) RAM 溢出Flash 還大量空閑大數(shù)組、字庫(kù)、常量表未加const加const讓編譯器歸入.rodata或用section屬性顯式指定段DMA 傳輸不完成或數(shù)據(jù)全為 0緩沖區(qū)被分配到 CCM/DTCM/ITCM 等 CPU 私有內(nèi)存檢查鏈接腳本把 DMA 緩沖區(qū)改到普通 SRAM 區(qū)加const后程序跑飛常量地址超出鏈接腳本中 Flash 區(qū)域邊界或向量表未重定位檢查.ld的 MEMORY 長(zhǎng)度確認(rèn) VTOR 設(shè)置正確代碼搬 RAM 后執(zhí)行異?？截愰L(zhǎng)度或地址對(duì)齊有誤被調(diào)用的子函數(shù)沒(méi)一起搬用ALIGN(4)保證對(duì)齊把所有相關(guān)函數(shù)放進(jìn)同一段搬完加__DSB/__ISBFlash 上跑算法明顯比 RAM 慢Flash 等待周期、無(wú)指令緩存、取指與讀常量爭(zhēng)用接口開(kāi)啟預(yù)取與緩存熱點(diǎn)函數(shù)搬 RAM常量表視情況搬 SRAM中斷跳到了錯(cuò)誤的處理函數(shù)Bootloader 跳 App 時(shí)未重定位向量表寫SCB-VTOR APP_BASE_ADDR庫(kù)函數(shù)里的常量訪問(wèn)異常平臺(tái)相關(guān)的修飾符缺失如 AVR 的PROGMEM、8051 的code按平臺(tái)補(bǔ)上對(duì)應(yīng)修飾符配套使用專用讀取函數(shù)這張表里的每一條我基本都在不同項(xiàng)目里遇到過(guò)至少一次。第一條和第二條出現(xiàn)的頻率最高尤其是剛從 PC 端開(kāi)發(fā)轉(zhuǎn)到嵌入式的朋友很容易默認(rèn)「所有內(nèi)存都是一樣的」。5.3 關(guān)于學(xué)習(xí)路線的幾句實(shí)話經(jīng)常有人問(wèn)學(xué)嵌入式要不要先把架構(gòu)這些底層?xùn)|西啃透。我的看法是不用一開(kāi)始就抱著體系結(jié)構(gòu)的教材硬啃但一定要在動(dòng)手的過(guò)程中反復(fù)回頭理解它。你點(diǎn)燈的時(shí)候不需要知道哈佛是什么但你做 DMA 搬運(yùn)、做 Bootloader、做性能優(yōu)化的時(shí)候不懂它就會(huì)一直踩坑。比較舒服的路徑是先跑通基礎(chǔ)外設(shè)建立對(duì) Flash 和 SRAM 的直覺(jué)然后回頭把這兩種架構(gòu)弄明白同時(shí)對(duì)照你手上的芯片手冊(cè)看總線結(jié)構(gòu)再往后做一兩個(gè)帶 DMA、帶 Bootloader、帶實(shí)時(shí)性要求的完整項(xiàng)目把認(rèn)知落到實(shí)處。至于工具用 Keil、IAR 還是 VSCode 加開(kāi)源工具鏈其實(shí)和架構(gòu)無(wú)關(guān)。甚至有人問(wèn)用很老的開(kāi)發(fā)工具能不能做嵌入式硬件編程——能不能編是一回事編出來(lái)的東西合不合理是另一回事編譯器優(yōu)化、段分配、棧使用這些東西換什么工具都躲不開(kāi)。手上有什么就用什么把注意力放在內(nèi)存布局、總線結(jié)構(gòu)、時(shí)序分析上回報(bào)率高得多。最后分享一個(gè)小習(xí)慣每次新建工程我都會(huì)先看一眼編譯出來(lái)的.map文件確認(rèn)關(guān)鍵緩沖區(qū)落在哪個(gè)地址區(qū)間、RAM 還剩多少、有沒(méi)有意料之外的段膨脹。養(yǎng)成這個(gè)動(dòng)作很多問(wèn)題在寫代碼階段就能提前發(fā)現(xiàn)不用等到板子跑飛了再通宵查。