簡介這份資源是一套基于STM32F103ARM Cortex-M3內核的匯編點燈例程工程面向已具備C語言基礎、希望深入理解微控制器底層運行機制的嵌入式學習者與工程師。壓縮包共19個文件、約28KB以Keil5工程文件uvprojx、uvoptx為核心配合匯編源文件與啟動文件startup_stm32f10x_md.s、編譯產物axf、o、lst、map、sct、JLink調試配置與日志以及keilkilll.bat清理腳本等構成可直接打開、編譯、下載與在線調試的完整工程鏈路。程序圍繞GPIO配置與寄存器操作展開涉及R0-R15通用寄存器與SP、LR、PC的使用LDR、STR、MOV、B等指令的加載存儲與分支流程以及GPIOx_MODER、OTYPER、OSPEEDR、PUPDR等寄存器的直接寫入可用于觀察點燈與閃爍循環(huán)的指令級執(zhí)行過程。已有1653人學習下載適合作為匯編入門的第一個可運行樣例也可作為調試與寄存器驗證的參考工程。1. 從一份純匯編的 STM32F103 工程說起為什么還要碰匯編拿到一份純匯編的 STM32F103 工程很多人的第一反應是這年頭誰還寫匯編我第一次拆的時候也是這個心態(tài)直到要做一個 2KB 以內的最小固件C 編譯出來怎么都塞不下才回頭去啃那份 .s 文件。它用 Keil5 的 armasm 手寫啟動代碼、直接懟寄存器點燈、用 SysTick 搭節(jié)拍一行 C 都沒有卻把 Cortex-M3 從上電到跑起來的路子完整走了一遍。這份東西適合兩類人想搞明白向量表、棧頂、分散加載這些“黑匣子”到底怎么排布的底層愛好者以及需要在現(xiàn)成的 C 工程里插一段匯編、做混合編程的開發(fā)者。看懂它再回頭看 C 工程的啟動流程很多玄學問題會一下子變得可解釋。2. 工程骨架拆解從復位向量表到主循環(huán)的完整鏈路一個純匯編工程看著文件少其實坑全在“哪些文件是必須的、哪些是 Keil5 自動生成的”這件事上。先把骨架摸清楚后面編譯報錯才不至于抓瞎。這個工程的結構大致是這樣文件來源作用startup_stm32f103.s手寫向量表、棧堆定義、Reset_Handlermain.s手寫入口 main、主循環(huán)、業(yè)務邏輯gpio.s/delay.s手寫GPIO 初始化、延時函數(shù)可拆可合systick.s手寫SysTick 初始化與中斷服務程序target.sct手寫或自動分散加載決定 Flash/RAM 怎么切project.uvprojx生成工程文件記錄器件型號、文件分組、編譯選項Objects/*.o、*.hex、*.map生成目標文件、固件、地址映射表手寫的那四個.s加一個.sct才是工程的“源碼”剩下的都是構建產物刪掉不影響編譯。很多人拿到工程第一眼看到一堆.o、.crf、.uvguix以為都是必需品結果往 git 里一提交倉庫直接膨脹好幾倍。2.1 啟動文件Cortex-M3 上電后的第一段代碼Cortex-M3 復位后的行為是硬件寫死的從地址0x08000000取第一個字裝載 MSP取第二個字裝載 PC。所以啟動文件干的第一件事就是把這張表擺到 Flash 的最前面。; startup_stm32f103.s —— 純匯編工程的最小啟動文件 Stack_Size EQU 0x00000400 ; 1KB 棧夠用但不鋪張 AREA STACK, NOINIT, READWRITE, ALIGN3 Stack_Mem SPACE Stack_Size __initial_sp ; 標簽落在棧的高地址端 PRESERVE8 ; 強制 8 字節(jié)棧對齊 THUMB ; 后續(xù)代碼按 Thumb 編碼 AREA RESET, DATA, READONLY EXPORT __Vectors __Vectors DCD __initial_sp ; 0x00 初始 MSP DCD Reset_Handler ; 0x04 復位入口 DCD NMI_Handler ; 0x08 DCD HardFault_Handler ; 0x0C ; ... 中間省略若干系統(tǒng)異常 DCD SysTick_Handler ; 0x3C 系統(tǒng)節(jié)拍 ; ... 后面接外設中斷本工程只用了 SysTick這里有幾個點必須理解透否則后面調試會很痛苦。DCD是“分配一個字并填入數(shù)值”它在 Flash 里連續(xù)排布形成的就是那張向量表SPACE只是保留空間不賦初值所以Stack_Mem在鏡像里不占 Flash。__initial_sp這個標簽之所以放在SPACE之后是因為 Cortex-M3 的棧是“滿遞減”的MSP 必須指向棧的最高地址壓棧時先減后寫。PRESERVE8容易被忽略——它告訴匯編器在函數(shù)入口保持 8 字節(jié)對齊AAPCS 要求棧指針在任何函數(shù)調用邊界都是 8 的倍數(shù)少了這句調用 C 函數(shù)時可能在某些浮點或結構體拷貝場景直接掛掉。接著是復位的跳轉邏輯AREA |.text|, CODE, READONLY EXPORT Reset_Handler IMPORT main Reset_Handler PROC LDR R0, main BLX R0 ; 跳進 main不回來 B . ; 萬一返回就地死循環(huán)方便掛調試器 ENDPLDR R0, main不是一條真實指令匯編器會把它變成從字面量池literal pool取地址再把 main 的絕對地址裝進 R0所以這里必須用BLX而不是BL——BL的相對跳轉范圍只有 ±16MB跨段調用不可靠。B .這個自跳轉看著像湊數(shù)其實是血淚經驗一旦 main 意外返回程序停在這里而不是跑飛到隨機地址調試器一暫停就能看到 PC 卡在這一行比對著 HardFault 猜半天強得多。2.2 分散加載文件Flash 和 RAM 的邊界到底誰說了算Keil5 在“Use Memory Layout from Target Dialog”勾選時會自動生成.sct但純匯編工程最好手寫一份因為向量表必須被強制放到鏡像開頭。; target.sct —— STM32F103C8 的典型布局 LR_IROM1 0x08000000 0x00010000 { ; 加載域64KB Flash ER_IROM1 0x08000000 0x00010000 { ; 執(zhí)行域與加載域同址 *.o (RESET, First) ; 向量表強制排最前 *(InRoot$$Sections) .ANY (RO) ; 其余只讀代碼、常量 } RW_IRAM1 0x20000000 0x00005000 { ; 20KB SRAM .ANY (RW ZI) ; 已初始化變量 零初始化 } }*.o (RESET, First)這一行是整個文件的核心。它按“段名”而不是文件名來匹配凡是AREA RESET定義的內容都會被拎到最前面所以啟動文件里的段名必須寫成RESET寫成RESET_DATA就對不上。First保證它排在所有內容之前這樣0x08000000上一定是棧頂0x08000004上一定是Reset_Handler。RW_IRAM1里的RW ZI決定了兩類數(shù)據(jù)帶初值的全局變量以及需要清零的 BSS 段。這里埋了個坑——純匯編工程如果不調用__mainKeil 的 C 庫初始化流程不會執(zhí)行RW 段的初值根本不會從 Flash 搬到 RAM變量上電就是隨機值。工程里如果只寫寄存器、不用帶初值的全局變量那沒事一旦用了就得自己寫一段搬運循環(huán)或者老老實實把__main引進來。這個問題在第 5 章會展開說。2.3 Reset_Handler 到 main 之間還差什么C 工程的Reset_Handler里通常是一句LDR R0, __main由 C 庫接管棧初始化、RW 搬運、BSS 清零最后才BL main。純匯編工程把這套省略了換來的是啟動時間從幾百個周期降到十幾個周期代價是所有初始化都得自己負責。我給這個工程的定位是“最小可用”所以跳過 C 庫是有意的所有全局狀態(tài)都用寄存器或絕對地址維護不給搬運環(huán)節(jié)留機會。如果要改成能跑 C 的混合工程正確做法是把Reset_Handler改回LDR R0, __main然后在工程里加上 C 庫的啟動文件這一改動在最后一章會具體演示。3. Keil5 環(huán)境搭建把 .s 文件變成能燒進片子的固件工程能打開不等于能編譯能編譯不等于能跑。這一章按“裝—配—編—驗”的順序走一遍每一步都標清楚失敗時看哪里。3.1 器件支持包與工程選項Device 選錯一切白搭Keil5 裝好之后第一件事是裝器件支持包Device Family Pack在 Pack Installer 里找到 Cortex-M3 內核對應的 STM32F1 系列裝完重啟 IDE。新建工程時選STM32F103C8或你手上芯片的具體型號這一步會影響三樣東西啟動文件的默認模板、Flash 算法、調試時的寄存器視圖。選錯了不會立刻報錯而是燒寫時提示“Cannot access target”或者擦除失敗非常容易誤判成硬件問題。工程建好后要手動確認幾個選項這幾項在純匯編工程里尤其關鍵選項位置設置項純匯編工程該選什么Target 頁Use MicroLIB不勾沒有 C 庫依賴Target 頁Use Memory Layout from Target Dialog取消勾選改用手寫 .sctOutput 頁Create HEX File勾上方便脫機燒寫Listing 頁Assembler Listing勾上排查地址問題全靠它C/C 頁不需要配置全空Use Memory Layout from Target Dialog取消勾選之后下面的 Scatter File 輸入框才會激活把target.sct填進去。這一步如果漏了Keil 會按默認布局把向量表隨便放0x08000000上就可能不是棧頂程序一上電直接跑飛。3.2 匯編器選項armasm 與 armclang 的語法分水嶺Keil5 從某個版本開始把默認匯編器從 armasm 換成了 armclang 的 GNU 語法前端這直接決定了你手里的.s文件能不能編譯通過。老工程的寫法是AREA、EXPORT、PROC/ENDP新匯編器認的是.section、.global、.thumb兩套語法完全不兼容。在 Options for Target → Asm 頁里有一個Assembler Option下拉選armasm就沿用經典語法選armclang就得改源碼。我一般這么做老工程保持 armasm 不動省得逐個文件改新起的工程直接在文件開頭寫.syntax unified走 GNU 路線因為新版本工具鏈對 armasm 的支持只會越來越弱。如果編譯時出現(xiàn)A1137E: Unexpected characters at end of line或者A1586E: Bad symbol八成就是語法對不上。判斷方法很簡單打開.s文件看第一行是;注釋還是注釋;是 armasm和//是 GNU 風格。3.3 編譯、下載與在線調試編譯輸出里最該看的不是 “0 Error(s)”而是最后那行Program Size: Codexxxx RO-dataxxxx RW-dataxxxx ZI-dataxxxx。純匯編點燈工程Code 通常在幾百字節(jié)到 1KB 之間如果突然漲到 4KB 以上說明鏈接器把不該進來的東西拉進來了多半是.sct里的.ANY匹配范圍太寬。下載配置在 Options → Debug 頁選ST-Link Debugger或CMSIS-DAP點 Settings 進 Flash Download 頁確認Programming Algorithm里加的是STM32F10x Med-density Flash對應 64KB/128KB 型號勾上Reset and Run。這一步翻車最多算法選成 High-density燒寫會報 “Flash Download failed”因為擦除命令的地址范圍對不上。調試階段我習慣開兩個窗口——Registers 窗口盯 R13(SP)、R15(PC) 和 xPSRDisassembly 窗口看反匯編。上電復位后立刻暫停PC 應該停在0x08000004附近的Reset_HandlerSP 應該是個0x2000xxxx的值。這兩個數(shù)不對后面的代碼寫得再對也沒用。3.4 用 map 文件核對固件真的對編譯完在Objects/或工程根目錄會生成.map文件這是驗證布局的唯一可靠依據(jù)。打開搜Image Entry point應該指向Reset_Handler搜__initial_sp應該是個 RAM 高地址搜Execution Region ER_IROM1Base 必須是0x08000000。Image Entry point : 0x08000009 ... __initial_sp 0x20000400 Data 4 startup_stm32f103.o(STACK)0x08000009這個奇數(shù)不是筆誤而是 Thumb 狀態(tài)的標志位——Cortex-M3 只支持 Thumb 指令集函數(shù)指針的最低位必須置 1硬件跳轉時會自動清掉。如果 map 里看到入口地址是0x08000008這種偶數(shù)說明某處丟了THUMB屬性跳過去必然進 HardFault。我第一次遇到時對著代碼看了兩小時最后在 map 文件里找到答案從那以后每次編譯完都先掃一眼這個值。4. 核心模塊拆解寄存器、延時與節(jié)拍的三件套骨架搭好之后真正干活的就是三個模塊GPIO、延時、SysTick。這三個加起來不到 100 行匯編但每一條指令的意圖都值得說清楚。4.1 GPIO 直接操作三行代碼點亮一個 LED用 C 的時候 HAL 庫把寄存器包裝得嚴嚴實實寫匯編就沒這層遮羞布了每個地址都得自己查手冊。; gpio.s —— PB0 推挽輸出初始化 GPIOB_BASE EQU 0x40010C00 GPIOB_CRL EQU GPIOB_BASE 0x00 ; 端口配置低寄存器 GPIOB_BSRR EQU GPIOB_BASE 0x10 ; 置位/復位寄存器 RCC_APB2ENR EQU 0x40021018 ; APB2 外設時鐘使能 AREA |.text|, CODE, READONLY EXPORT GPIOB_Init THUMB GPIOB_Init PROC LDR R0, RCC_APB2ENR LDR R1, [R0] ORR R1, R1, #(1 3) ; bit3 IOPBEN開 GPIOB 時鐘 STR R1, [R0] LDR R0, GPIOB_CRL LDR R1, [R0] BIC R1, R1, #0x0000000F ; 清掉 PB0 的 4 位配置 ORR R1, R1, #0x00000003 ; MODE11 輸出 50MHz, CNF00 推挽 STR R1, [R0] BX LR ENDP這里的關鍵是BICORR這個組合而不是直接STR一個常量。GPIOB_CRL一個寄存器管 8 個引腳每個引腳 4 位直接寫常量會把其他引腳的配置一起沖掉。先BIC清零目標位、再ORR置位是寄存器編程的標準做法C 里的 ~mask; | value;編譯出來也是這兩條。時鐘使能必須放在配置之前這個順序不能反。RCC_APB2ENR的 bit3 對應 GPIOB寫 1 之后外設才有時鐘此前的任何寫操作都是無效的。我見過有人把時鐘使能寫在初始化函數(shù)末尾結果引腳就是不響應查了半天以為是硬件虛焊。點亮 LED 用 BSRR 而不是 ODR因為 BSRR 是原子操作低 16 位寫 1 置位、高 16 位寫 1 復位寫 0 的位不受影響。用 ODR 做“讀—改—寫”在中斷環(huán)境下會被打斷BSRR 不存在這個問題。; 主循環(huán)里翻轉 PB0 Loop LDR R0, GPIOB_BSRR LDR R1, 0x00000001 ; BS0置位 PB0 STR R1, [R0] LDR R0, 500 BL Delay_ms LDR R0, GPIOB_BSRR LDR R1, 0x00010000 ; BR0復位 PB0 STR R1, [R0] LDR R0, 500 BL Delay_ms B Loop注意每次BL之前都要重新LDR R0, 500因為按 AAPCS 規(guī)定 R0~R3 是調用者保存寄存器被調函數(shù)可以隨意改寫。這一點在匯編里沒有任何保護忘了就等著看 LED 閃得莫名其妙。4.2 軟件延時一個雙層循環(huán)的時序估算沒有定時器的時候延時只能靠空轉。這段代碼簡單但估算方法值得說清楚。; delay.s —— 粗略毫秒延時入?yún)?R0 毫秒數(shù) Delay_ms PROC PUSH {R1, R2} ; 保存將被改寫的寄存器 LDR R1, 7200 ; 內層計數(shù)見下方估算 Outer MOV R2, R1 Inner SUBS R2, R2, #1 BNE Inner SUBS R0, R0, #1 BNE Outer POP {R1, R2} BX LR ENDP估算邏輯是這樣的72MHz 主頻下SUBSBNE這兩條指令在 Flash 里執(zhí)行約 3~4 個周期流水線有分支開銷所以要湊 1ms 的 72000 個周期內層計數(shù)取 7200 左右。這個數(shù)字是拍腦袋出來的實際誤差可能到 ±20%因為 Flash 等待周期、流水線狀態(tài)、中斷搶占都會影響。想要更準把內層計數(shù)值調到 9000 再實測一次——用示波器量一個 100ms 的方波周期反推出實際系數(shù)。我一般會在注釋里寫上“實測 72MHz / 等待周期 2 時取 9000”這種具體條件因為換個主頻、改個 Flash 等待配置這個數(shù)字就全變了不寫清楚下次自己都看不懂。PUSH {R1, R2}這兩行不能省。雖然在這個工程里調用者恰好沒用到 R1、R2但只要函數(shù)被復用就可能踩到“被調函數(shù)悄悄改了寄存器”的坑而這種 bug 往往在改了幾十行之后才爆發(fā)定位成本極高。4.3 SysTick 與中斷向量把節(jié)拍交給硬件軟件延時占著 CPU 空轉想要一邊閃燈一邊干別的就得用 SysTick。; systick.s —— 1ms 系統(tǒng)節(jié)拍 SYST_CSR EQU 0xE000E010 SYST_RVR EQU 0xE000E014 SYST_CVR EQU 0xE000E018 AREA |.text|, CODE, READONLY EXPORT SysTick_Init EXPORT SysTick_Handler IMPORT Tick_Count SysTick_Init PROC LDR R0, SYST_RVR LDR R1, 71999 ; 72MHz / 1000 - 1 STR R1, [R0] LDR R0, SYST_CVR MOV R1, #0 STR R1, [R0] ; 清計數(shù)器避免首拍不準 LDR R0, SYST_CSR MOV R1, #0x07 ; CLKSOURCE|TICKINT|ENABLE STR R1, [R0] BX LR ENDP SysTick_Handler PROC LDR R0, Tick_Count LDR R1, [R0] ADDS R1, R1, #1 STR R1, [R0] BX LR ENDP0x07這三個位分別是bit0 使能計數(shù)器、bit1 使能中斷、bit2 選擇內核時鐘不選的話走 HCLK/8。LOAD值等于重裝載值計數(shù)器從 LOAD 遞減到 0 觸發(fā)中斷所以 1ms 要填 71999 而不是 72000。SysTick_Handler這個名字必須和向量表里DCD的那一項完全一致而且必須EXPORT否則鏈接器看不到向量表里那一項會被填成 0中斷一觸發(fā)就跳進 HardFault。這是純匯編工程最常見的問題之一比 C 工程更容易犯因為 C 里通常有統(tǒng)一的stm32f1xx_it.c兜底匯編里沒有。中斷服務程序的返回值必須用BX LR不能用POP {PC}或者B回跳。異常返回時硬件會從棧里恢復 R0~R3、R12、LR、PC、xPSRBX LR里那個特殊值0xFFFFFFF9就是告訴內核“走異常返回流程”。5. 避坑與排查匯編工程里最容易翻車的五處匯編不像 C編譯器不會幫你兜任何東西錯了就是錯了而且錯誤現(xiàn)象往往離真正的原因很遠。下面五條都是我在實際調試中撞過的按“現(xiàn)象—原因—解決”整理。5.1 編譯報 Undefined symbol但函數(shù)明明寫了現(xiàn)象編譯時報A1137E: Undefined symbol SysTick_Handler可文件里確實有SysTick_Handler PROC。原因PROC/ENDP只是標記函數(shù)邊界不改變符號的可見性跨文件引用必須顯式EXPORT。反過來的情況也常見——在本文件里用IMPORT聲明的符號如果實際定義處沒EXPORT鏈接一樣失敗。解決所有會被向量表DCD引用、或者被其他.s文件BL的函數(shù)一律加EXPORT 函數(shù)名。習慣做法是在每個.s文件頭部集中放一組EXPORT比散落在函數(shù)前面更容易查。5.2 燒寫成功但不運行PC 停在莫名其妙的地方現(xiàn)象Flash 下載顯示成功按復位鍵什么都沒發(fā)生調試器暫停后 PC 指向0x08000000或者某個非法地址。原因向量表沒被放到鏡像開頭。要么.sct里漏了*.o (RESET, First)要么啟動文件里的AREA段名寫成了別的比如RESET_DATA導致鏈接器匹配不上向量表被當成普通只讀數(shù)據(jù)排到了后面。解決打開.map文件搜Image Entry point正常應該是0x08000009這種奇數(shù)。如果 Base 不是0x08000000回到.sct逐字核對段名。另外確認 Options 里Use Memory Layout from Target Dialog已取消勾選否則手寫.sct根本不生效。5.3 全局變量上電是隨機值現(xiàn)象定義了一個帶初值的全局計數(shù)變量期望上電從 0 開始實際讀到的是亂碼。原因純匯編工程沒有調用__mainKeil 的 C 庫初始化流程沒跑RW 段的初值還在 Flash 里躺著沒被搬進 RAM。.sct寫的RW只是告訴鏈接器“這塊地址歸你”不代表會有人去搬運。解決要么在Reset_Handler里手寫一段搬運循環(huán)從Load$$RW_IRAM1$$Base拷到Image$$RW_IRAM1$$Base長度取Image$$RW_IRAM1$$Length要么干脆不用帶初值的全局變量全部用寄存器傳參。我選后者因為純匯編工程的定位就是“極簡”為了一個變量引入散加載搬運不劃算。5.4 LDR 偽指令編譯報錯或取到錯誤地址現(xiàn)象LDR R0, 0x40021018報A1516E: Immediate too large或者編譯通過了但取到的值不對。原因LDR Rd, expr是偽指令匯編器會把它變成 PC 相對的字面量加載。字面量池默認放在當前段末尾或者下一個LTORG處如果池子距離指令超過 4KBThumb 的 PC 相對尋址范圍匯編器就報錯。解決在兩個函數(shù)之間手動插一行LTORG強制在此處傾倒字面量池。大段代碼中間隔幾百行就補一個不要指望匯編器自動處理。另一個辦法是用MOVW/MOVT組合直接構造 32 位常量不依賴字面量池代價是占兩條指令。5.5 單步調試時一進中斷就掉 HardFault現(xiàn)象主循環(huán)跑得好好的一開中斷立刻進 HardFault棧里翻出來的 PC 指向向量表某個空項。原因中斷服務程序沒EXPORT或者名字和向量表里的DCD不一致鏈接器把這個符號當成未定義向量表對應位置填了 0。還有一種情況是處理函數(shù)里用了 R4~R11 卻沒PUSH異常返回后主流程的寄存器被改壞。解決把所有中斷處理函數(shù)集中在一個文件里向量表的DCD列表和函數(shù)定義一一對照著看。處理函數(shù)里只碰 R0~R3 和 R12硬件自動保存要用 R4 以上必須PUSH {R4, LR}、結尾POP {R4, PC}用POP {PC}一樣能觸發(fā)異常返回還省一條指令。6. 二次開發(fā)把匯編模塊掛進 C 工程純匯編跑通了實際項目里更常見的是反過來——主體用 C只有某幾個對時序或體積極其敏感的函數(shù)用匯編寫。這時候要做的是混合編程關鍵是守住 AAPCS 那套調用約定。最省事的做法是保留 C 工程的啟動文件和__main把匯編文件當成一個普通模塊加進分組。匯編側要做的就兩件事EXPORT出去給 C 調IMPORT進來調 C。; crc16.s —— 給 C 工程提供 CRC16 查表加速函數(shù) AREA |.text|, CODE, READONLY EXPORT crc16_asm ; C 側聲明 extern uint16_t crc16_asm(...) THUMB ; uint16_t crc16_asm(uint16_t crc, const uint8_t *buf, uint32_t len) ; 入?yún)0crc, R1buf, R2len 返回R0 crc16_asm PROC PUSH {R4, LR} ; 只用到 R4順手把 LR 也壓了 CMP R2, #0 BEQ done loop LDRB R3, [R1], #1 ; 取一字節(jié)并后自增 EOR R3, R3, R0, LSR #8 LDR R4, crc_table ; 表在 C 側定義并 extern LDRH R3, [R4, R3, LSL #1] ; 半字索引偏移 idx*2 EOR R0, R3, R0, LSL #8 SUBS R2, R2, #1 BNE loop done UXTH R0, R0 ; 只保留低 16 位 POP {R4, PC} ENDP這段代碼里幾個點必須對上入?yún)㈨樞蚴?R0、R1、R2返回值放 R0PUSH {R4, LR}保證 8 字節(jié)對齊兩條寄存器正好 8 字節(jié)同時保住 R4 和返回地址POP {R4, PC}一次完成恢復和返回。C 側只需要一句extern uint16_t crc16_asm(uint16_t crc, const uint8_t *buf, uint32_t len);鏈接時把.s和.c一起編進去就行。驗證方法我固定用三步先用 C 寫一份參考實現(xiàn)跑同一組測試向量對比結果再用調試器看匯編函數(shù)的入口處 R0~R2 是否等于 C 傳進來的值不等就是參數(shù)傳遞出了問題最后在函數(shù)返回后檢查 R4 有沒有被改回去寄存器窗口里對比調用前后的值。這三步走完混合編程基本不會再出問題。從那以后我每次往 C 工程里塞匯編函數(shù)都會先在注釋里把入?yún)⒓拇嫫鳌⒎祷刂导拇嫫?、會破壞哪些寄存器寫清楚再?C 側調用一次并對比參考實現(xiàn)——省下的這點時間遠不如后面定位一個“R4 被悄悄改掉導致主流程跑飛”的代價。希望幫到你。本文還有配套的精品資源點擊獲取 STM32F103純匯編工程拆解：從啟動文件到混合編程
簡介這份資源是一套基于STM32F103ARM Cortex-M3內核的匯編點燈例程工程面向已具備C語言基礎、希望深入理解微控制器底層運行機制的嵌入式學習者與工程師。壓縮包共19個文件、約28KB以Keil5工程文件uvprojx、uvoptx為核心配合匯編源文件與啟動文件startup_stm32f10x_md.s、編譯產物axf、o、lst、map、sct、JLink調試配置與日志以及keilkilll.bat清理腳本等構成可直接打開、編譯、下載與在線調試的完整工程鏈路。程序圍繞GPIO配置與寄存器操作展開涉及R0-R15通用寄存器與SP、LR、PC的使用LDR、STR、MOV、B等指令的加載存儲與分支流程以及GPIOx_MODER、OTYPER、OSPEEDR、PUPDR等寄存器的直接寫入可用于觀察點燈與閃爍循環(huán)的指令級執(zhí)行過程。已有1653人學習下載適合作為匯編入門的第一個可運行樣例也可作為調試與寄存器驗證的參考工程。1. 從一份純匯編的 STM32F103 工程說起為什么還要碰匯編拿到一份純匯編的 STM32F103 工程很多人的第一反應是這年頭誰還寫匯編我第一次拆的時候也是這個心態(tài)直到要做一個 2KB 以內的最小固件C 編譯出來怎么都塞不下才回頭去啃那份 .s 文件。它用 Keil5 的 armasm 手寫啟動代碼、直接懟寄存器點燈、用 SysTick 搭節(jié)拍一行 C 都沒有卻把 Cortex-M3 從上電到跑起來的路子完整走了一遍。這份東西適合兩類人想搞明白向量表、棧頂、分散加載這些“黑匣子”到底怎么排布的底層愛好者以及需要在現(xiàn)成的 C 工程里插一段匯編、做混合編程的開發(fā)者。看懂它再回頭看 C 工程的啟動流程很多玄學問題會一下子變得可解釋。2. 工程骨架拆解從復位向量表到主循環(huán)的完整鏈路一個純匯編工程看著文件少其實坑全在“哪些文件是必須的、哪些是 Keil5 自動生成的”這件事上。先把骨架摸清楚后面編譯報錯才不至于抓瞎。這個工程的結構大致是這樣文件來源作用startup_stm32f103.s手寫向量表、棧堆定義、Reset_Handlermain.s手寫入口 main、主循環(huán)、業(yè)務邏輯gpio.s/delay.s手寫GPIO 初始化、延時函數(shù)可拆可合systick.s手寫SysTick 初始化與中斷服務程序target.sct手寫或自動分散加載決定 Flash/RAM 怎么切project.uvprojx生成工程文件記錄器件型號、文件分組、編譯選項Objects/*.o、*.hex、*.map生成目標文件、固件、地址映射表手寫的那四個.s加一個.sct才是工程的“源碼”剩下的都是構建產物刪掉不影響編譯。很多人拿到工程第一眼看到一堆.o、.crf、.uvguix以為都是必需品結果往 git 里一提交倉庫直接膨脹好幾倍。2.1 啟動文件Cortex-M3 上電后的第一段代碼Cortex-M3 復位后的行為是硬件寫死的從地址0x08000000取第一個字裝載 MSP取第二個字裝載 PC。所以啟動文件干的第一件事就是把這張表擺到 Flash 的最前面。; startup_stm32f103.s —— 純匯編工程的最小啟動文件 Stack_Size EQU 0x00000400 ; 1KB 棧夠用但不鋪張 AREA STACK, NOINIT, READWRITE, ALIGN3 Stack_Mem SPACE Stack_Size __initial_sp ; 標簽落在棧的高地址端 PRESERVE8 ; 強制 8 字節(jié)棧對齊 THUMB ; 后續(xù)代碼按 Thumb 編碼 AREA RESET, DATA, READONLY EXPORT __Vectors __Vectors DCD __initial_sp ; 0x00 初始 MSP DCD Reset_Handler ; 0x04 復位入口 DCD NMI_Handler ; 0x08 DCD HardFault_Handler ; 0x0C ; ... 中間省略若干系統(tǒng)異常 DCD SysTick_Handler ; 0x3C 系統(tǒng)節(jié)拍 ; ... 后面接外設中斷本工程只用了 SysTick這里有幾個點必須理解透否則后面調試會很痛苦。DCD是“分配一個字并填入數(shù)值”它在 Flash 里連續(xù)排布形成的就是那張向量表SPACE只是保留空間不賦初值所以Stack_Mem在鏡像里不占 Flash。__initial_sp這個標簽之所以放在SPACE之后是因為 Cortex-M3 的棧是“滿遞減”的MSP 必須指向棧的最高地址壓棧時先減后寫。PRESERVE8容易被忽略——它告訴匯編器在函數(shù)入口保持 8 字節(jié)對齊AAPCS 要求棧指針在任何函數(shù)調用邊界都是 8 的倍數(shù)少了這句調用 C 函數(shù)時可能在某些浮點或結構體拷貝場景直接掛掉。接著是復位的跳轉邏輯AREA |.text|, CODE, READONLY EXPORT Reset_Handler IMPORT main Reset_Handler PROC LDR R0, main BLX R0 ; 跳進 main不回來 B . ; 萬一返回就地死循環(huán)方便掛調試器 ENDPLDR R0, main不是一條真實指令匯編器會把它變成從字面量池literal pool取地址再把 main 的絕對地址裝進 R0所以這里必須用BLX而不是BL——BL的相對跳轉范圍只有 ±16MB跨段調用不可靠。B .這個自跳轉看著像湊數(shù)其實是血淚經驗一旦 main 意外返回程序停在這里而不是跑飛到隨機地址調試器一暫停就能看到 PC 卡在這一行比對著 HardFault 猜半天強得多。2.2 分散加載文件Flash 和 RAM 的邊界到底誰說了算Keil5 在“Use Memory Layout from Target Dialog”勾選時會自動生成.sct但純匯編工程最好手寫一份因為向量表必須被強制放到鏡像開頭。; target.sct —— STM32F103C8 的典型布局 LR_IROM1 0x08000000 0x00010000 { ; 加載域64KB Flash ER_IROM1 0x08000000 0x00010000 { ; 執(zhí)行域與加載域同址 *.o (RESET, First) ; 向量表強制排最前 *(InRoot$$Sections) .ANY (RO) ; 其余只讀代碼、常量 } RW_IRAM1 0x20000000 0x00005000 { ; 20KB SRAM .ANY (RW ZI) ; 已初始化變量 零初始化 } }*.o (RESET, First)這一行是整個文件的核心。它按“段名”而不是文件名來匹配凡是AREA RESET定義的內容都會被拎到最前面所以啟動文件里的段名必須寫成RESET寫成RESET_DATA就對不上。First保證它排在所有內容之前這樣0x08000000上一定是棧頂0x08000004上一定是Reset_Handler。RW_IRAM1里的RW ZI決定了兩類數(shù)據(jù)帶初值的全局變量以及需要清零的 BSS 段。這里埋了個坑——純匯編工程如果不調用__mainKeil 的 C 庫初始化流程不會執(zhí)行RW 段的初值根本不會從 Flash 搬到 RAM變量上電就是隨機值。工程里如果只寫寄存器、不用帶初值的全局變量那沒事一旦用了就得自己寫一段搬運循環(huán)或者老老實實把__main引進來。這個問題在第 5 章會展開說。2.3 Reset_Handler 到 main 之間還差什么C 工程的Reset_Handler里通常是一句LDR R0, __main由 C 庫接管棧初始化、RW 搬運、BSS 清零最后才BL main。純匯編工程把這套省略了換來的是啟動時間從幾百個周期降到十幾個周期代價是所有初始化都得自己負責。我給這個工程的定位是“最小可用”所以跳過 C 庫是有意的所有全局狀態(tài)都用寄存器或絕對地址維護不給搬運環(huán)節(jié)留機會。如果要改成能跑 C 的混合工程正確做法是把Reset_Handler改回LDR R0, __main然后在工程里加上 C 庫的啟動文件這一改動在最后一章會具體演示。3. Keil5 環(huán)境搭建把 .s 文件變成能燒進片子的固件工程能打開不等于能編譯能編譯不等于能跑。這一章按“裝—配—編—驗”的順序走一遍每一步都標清楚失敗時看哪里。3.1 器件支持包與工程選項Device 選錯一切白搭Keil5 裝好之后第一件事是裝器件支持包Device Family Pack在 Pack Installer 里找到 Cortex-M3 內核對應的 STM32F1 系列裝完重啟 IDE。新建工程時選STM32F103C8或你手上芯片的具體型號這一步會影響三樣東西啟動文件的默認模板、Flash 算法、調試時的寄存器視圖。選錯了不會立刻報錯而是燒寫時提示“Cannot access target”或者擦除失敗非常容易誤判成硬件問題。工程建好后要手動確認幾個選項這幾項在純匯編工程里尤其關鍵選項位置設置項純匯編工程該選什么Target 頁Use MicroLIB不勾沒有 C 庫依賴Target 頁Use Memory Layout from Target Dialog取消勾選改用手寫 .sctOutput 頁Create HEX File勾上方便脫機燒寫Listing 頁Assembler Listing勾上排查地址問題全靠它C/C 頁不需要配置全空Use Memory Layout from Target Dialog取消勾選之后下面的 Scatter File 輸入框才會激活把target.sct填進去。這一步如果漏了Keil 會按默認布局把向量表隨便放0x08000000上就可能不是棧頂程序一上電直接跑飛。3.2 匯編器選項armasm 與 armclang 的語法分水嶺Keil5 從某個版本開始把默認匯編器從 armasm 換成了 armclang 的 GNU 語法前端這直接決定了你手里的.s文件能不能編譯通過。老工程的寫法是AREA、EXPORT、PROC/ENDP新匯編器認的是.section、.global、.thumb兩套語法完全不兼容。在 Options for Target → Asm 頁里有一個Assembler Option下拉選armasm就沿用經典語法選armclang就得改源碼。我一般這么做老工程保持 armasm 不動省得逐個文件改新起的工程直接在文件開頭寫.syntax unified走 GNU 路線因為新版本工具鏈對 armasm 的支持只會越來越弱。如果編譯時出現(xiàn)A1137E: Unexpected characters at end of line或者A1586E: Bad symbol八成就是語法對不上。判斷方法很簡單打開.s文件看第一行是;注釋還是注釋;是 armasm和//是 GNU 風格。3.3 編譯、下載與在線調試編譯輸出里最該看的不是 “0 Error(s)”而是最后那行Program Size: Codexxxx RO-dataxxxx RW-dataxxxx ZI-dataxxxx。純匯編點燈工程Code 通常在幾百字節(jié)到 1KB 之間如果突然漲到 4KB 以上說明鏈接器把不該進來的東西拉進來了多半是.sct里的.ANY匹配范圍太寬。下載配置在 Options → Debug 頁選ST-Link Debugger或CMSIS-DAP點 Settings 進 Flash Download 頁確認Programming Algorithm里加的是STM32F10x Med-density Flash對應 64KB/128KB 型號勾上Reset and Run。這一步翻車最多算法選成 High-density燒寫會報 “Flash Download failed”因為擦除命令的地址范圍對不上。調試階段我習慣開兩個窗口——Registers 窗口盯 R13(SP)、R15(PC) 和 xPSRDisassembly 窗口看反匯編。上電復位后立刻暫停PC 應該停在0x08000004附近的Reset_HandlerSP 應該是個0x2000xxxx的值。這兩個數(shù)不對后面的代碼寫得再對也沒用。3.4 用 map 文件核對固件真的對編譯完在Objects/或工程根目錄會生成.map文件這是驗證布局的唯一可靠依據(jù)。打開搜Image Entry point應該指向Reset_Handler搜__initial_sp應該是個 RAM 高地址搜Execution Region ER_IROM1Base 必須是0x08000000。Image Entry point : 0x08000009 ... __initial_sp 0x20000400 Data 4 startup_stm32f103.o(STACK)0x08000009這個奇數(shù)不是筆誤而是 Thumb 狀態(tài)的標志位——Cortex-M3 只支持 Thumb 指令集函數(shù)指針的最低位必須置 1硬件跳轉時會自動清掉。如果 map 里看到入口地址是0x08000008這種偶數(shù)說明某處丟了THUMB屬性跳過去必然進 HardFault。我第一次遇到時對著代碼看了兩小時最后在 map 文件里找到答案從那以后每次編譯完都先掃一眼這個值。4. 核心模塊拆解寄存器、延時與節(jié)拍的三件套骨架搭好之后真正干活的就是三個模塊GPIO、延時、SysTick。這三個加起來不到 100 行匯編但每一條指令的意圖都值得說清楚。4.1 GPIO 直接操作三行代碼點亮一個 LED用 C 的時候 HAL 庫把寄存器包裝得嚴嚴實實寫匯編就沒這層遮羞布了每個地址都得自己查手冊。; gpio.s —— PB0 推挽輸出初始化 GPIOB_BASE EQU 0x40010C00 GPIOB_CRL EQU GPIOB_BASE 0x00 ; 端口配置低寄存器 GPIOB_BSRR EQU GPIOB_BASE 0x10 ; 置位/復位寄存器 RCC_APB2ENR EQU 0x40021018 ; APB2 外設時鐘使能 AREA |.text|, CODE, READONLY EXPORT GPIOB_Init THUMB GPIOB_Init PROC LDR R0, RCC_APB2ENR LDR R1, [R0] ORR R1, R1, #(1 3) ; bit3 IOPBEN開 GPIOB 時鐘 STR R1, [R0] LDR R0, GPIOB_CRL LDR R1, [R0] BIC R1, R1, #0x0000000F ; 清掉 PB0 的 4 位配置 ORR R1, R1, #0x00000003 ; MODE11 輸出 50MHz, CNF00 推挽 STR R1, [R0] BX LR ENDP這里的關鍵是BICORR這個組合而不是直接STR一個常量。GPIOB_CRL一個寄存器管 8 個引腳每個引腳 4 位直接寫常量會把其他引腳的配置一起沖掉。先BIC清零目標位、再ORR置位是寄存器編程的標準做法C 里的 ~mask; | value;編譯出來也是這兩條。時鐘使能必須放在配置之前這個順序不能反。RCC_APB2ENR的 bit3 對應 GPIOB寫 1 之后外設才有時鐘此前的任何寫操作都是無效的。我見過有人把時鐘使能寫在初始化函數(shù)末尾結果引腳就是不響應查了半天以為是硬件虛焊。點亮 LED 用 BSRR 而不是 ODR因為 BSRR 是原子操作低 16 位寫 1 置位、高 16 位寫 1 復位寫 0 的位不受影響。用 ODR 做“讀—改—寫”在中斷環(huán)境下會被打斷BSRR 不存在這個問題。; 主循環(huán)里翻轉 PB0 Loop LDR R0, GPIOB_BSRR LDR R1, 0x00000001 ; BS0置位 PB0 STR R1, [R0] LDR R0, 500 BL Delay_ms LDR R0, GPIOB_BSRR LDR R1, 0x00010000 ; BR0復位 PB0 STR R1, [R0] LDR R0, 500 BL Delay_ms B Loop注意每次BL之前都要重新LDR R0, 500因為按 AAPCS 規(guī)定 R0~R3 是調用者保存寄存器被調函數(shù)可以隨意改寫。這一點在匯編里沒有任何保護忘了就等著看 LED 閃得莫名其妙。4.2 軟件延時一個雙層循環(huán)的時序估算沒有定時器的時候延時只能靠空轉。這段代碼簡單但估算方法值得說清楚。; delay.s —— 粗略毫秒延時入?yún)?R0 毫秒數(shù) Delay_ms PROC PUSH {R1, R2} ; 保存將被改寫的寄存器 LDR R1, 7200 ; 內層計數(shù)見下方估算 Outer MOV R2, R1 Inner SUBS R2, R2, #1 BNE Inner SUBS R0, R0, #1 BNE Outer POP {R1, R2} BX LR ENDP估算邏輯是這樣的72MHz 主頻下SUBSBNE這兩條指令在 Flash 里執(zhí)行約 3~4 個周期流水線有分支開銷所以要湊 1ms 的 72000 個周期內層計數(shù)取 7200 左右。這個數(shù)字是拍腦袋出來的實際誤差可能到 ±20%因為 Flash 等待周期、流水線狀態(tài)、中斷搶占都會影響。想要更準把內層計數(shù)值調到 9000 再實測一次——用示波器量一個 100ms 的方波周期反推出實際系數(shù)。我一般會在注釋里寫上“實測 72MHz / 等待周期 2 時取 9000”這種具體條件因為換個主頻、改個 Flash 等待配置這個數(shù)字就全變了不寫清楚下次自己都看不懂。PUSH {R1, R2}這兩行不能省。雖然在這個工程里調用者恰好沒用到 R1、R2但只要函數(shù)被復用就可能踩到“被調函數(shù)悄悄改了寄存器”的坑而這種 bug 往往在改了幾十行之后才爆發(fā)定位成本極高。4.3 SysTick 與中斷向量把節(jié)拍交給硬件軟件延時占著 CPU 空轉想要一邊閃燈一邊干別的就得用 SysTick。; systick.s —— 1ms 系統(tǒng)節(jié)拍 SYST_CSR EQU 0xE000E010 SYST_RVR EQU 0xE000E014 SYST_CVR EQU 0xE000E018 AREA |.text|, CODE, READONLY EXPORT SysTick_Init EXPORT SysTick_Handler IMPORT Tick_Count SysTick_Init PROC LDR R0, SYST_RVR LDR R1, 71999 ; 72MHz / 1000 - 1 STR R1, [R0] LDR R0, SYST_CVR MOV R1, #0 STR R1, [R0] ; 清計數(shù)器避免首拍不準 LDR R0, SYST_CSR MOV R1, #0x07 ; CLKSOURCE|TICKINT|ENABLE STR R1, [R0] BX LR ENDP SysTick_Handler PROC LDR R0, Tick_Count LDR R1, [R0] ADDS R1, R1, #1 STR R1, [R0] BX LR ENDP0x07這三個位分別是bit0 使能計數(shù)器、bit1 使能中斷、bit2 選擇內核時鐘不選的話走 HCLK/8。LOAD值等于重裝載值計數(shù)器從 LOAD 遞減到 0 觸發(fā)中斷所以 1ms 要填 71999 而不是 72000。SysTick_Handler這個名字必須和向量表里DCD的那一項完全一致而且必須EXPORT否則鏈接器看不到向量表里那一項會被填成 0中斷一觸發(fā)就跳進 HardFault。這是純匯編工程最常見的問題之一比 C 工程更容易犯因為 C 里通常有統(tǒng)一的stm32f1xx_it.c兜底匯編里沒有。中斷服務程序的返回值必須用BX LR不能用POP {PC}或者B回跳。異常返回時硬件會從棧里恢復 R0~R3、R12、LR、PC、xPSRBX LR里那個特殊值0xFFFFFFF9就是告訴內核“走異常返回流程”。5. 避坑與排查匯編工程里最容易翻車的五處匯編不像 C編譯器不會幫你兜任何東西錯了就是錯了而且錯誤現(xiàn)象往往離真正的原因很遠。下面五條都是我在實際調試中撞過的按“現(xiàn)象—原因—解決”整理。5.1 編譯報 Undefined symbol但函數(shù)明明寫了現(xiàn)象編譯時報A1137E: Undefined symbol SysTick_Handler可文件里確實有SysTick_Handler PROC。原因PROC/ENDP只是標記函數(shù)邊界不改變符號的可見性跨文件引用必須顯式EXPORT。反過來的情況也常見——在本文件里用IMPORT聲明的符號如果實際定義處沒EXPORT鏈接一樣失敗。解決所有會被向量表DCD引用、或者被其他.s文件BL的函數(shù)一律加EXPORT 函數(shù)名。習慣做法是在每個.s文件頭部集中放一組EXPORT比散落在函數(shù)前面更容易查。5.2 燒寫成功但不運行PC 停在莫名其妙的地方現(xiàn)象Flash 下載顯示成功按復位鍵什么都沒發(fā)生調試器暫停后 PC 指向0x08000000或者某個非法地址。原因向量表沒被放到鏡像開頭。要么.sct里漏了*.o (RESET, First)要么啟動文件里的AREA段名寫成了別的比如RESET_DATA導致鏈接器匹配不上向量表被當成普通只讀數(shù)據(jù)排到了后面。解決打開.map文件搜Image Entry point正常應該是0x08000009這種奇數(shù)。如果 Base 不是0x08000000回到.sct逐字核對段名。另外確認 Options 里Use Memory Layout from Target Dialog已取消勾選否則手寫.sct根本不生效。5.3 全局變量上電是隨機值現(xiàn)象定義了一個帶初值的全局計數(shù)變量期望上電從 0 開始實際讀到的是亂碼。原因純匯編工程沒有調用__mainKeil 的 C 庫初始化流程沒跑RW 段的初值還在 Flash 里躺著沒被搬進 RAM。.sct寫的RW只是告訴鏈接器“這塊地址歸你”不代表會有人去搬運。解決要么在Reset_Handler里手寫一段搬運循環(huán)從Load$$RW_IRAM1$$Base拷到Image$$RW_IRAM1$$Base長度取Image$$RW_IRAM1$$Length要么干脆不用帶初值的全局變量全部用寄存器傳參。我選后者因為純匯編工程的定位就是“極簡”為了一個變量引入散加載搬運不劃算。5.4 LDR 偽指令編譯報錯或取到錯誤地址現(xiàn)象LDR R0, 0x40021018報A1516E: Immediate too large或者編譯通過了但取到的值不對。原因LDR Rd, expr是偽指令匯編器會把它變成 PC 相對的字面量加載。字面量池默認放在當前段末尾或者下一個LTORG處如果池子距離指令超過 4KBThumb 的 PC 相對尋址范圍匯編器就報錯。解決在兩個函數(shù)之間手動插一行LTORG強制在此處傾倒字面量池。大段代碼中間隔幾百行就補一個不要指望匯編器自動處理。另一個辦法是用MOVW/MOVT組合直接構造 32 位常量不依賴字面量池代價是占兩條指令。5.5 單步調試時一進中斷就掉 HardFault現(xiàn)象主循環(huán)跑得好好的一開中斷立刻進 HardFault棧里翻出來的 PC 指向向量表某個空項。原因中斷服務程序沒EXPORT或者名字和向量表里的DCD不一致鏈接器把這個符號當成未定義向量表對應位置填了 0。還有一種情況是處理函數(shù)里用了 R4~R11 卻沒PUSH異常返回后主流程的寄存器被改壞。解決把所有中斷處理函數(shù)集中在一個文件里向量表的DCD列表和函數(shù)定義一一對照著看。處理函數(shù)里只碰 R0~R3 和 R12硬件自動保存要用 R4 以上必須PUSH {R4, LR}、結尾POP {R4, PC}用POP {PC}一樣能觸發(fā)異常返回還省一條指令。6. 二次開發(fā)把匯編模塊掛進 C 工程純匯編跑通了實際項目里更常見的是反過來——主體用 C只有某幾個對時序或體積極其敏感的函數(shù)用匯編寫。這時候要做的是混合編程關鍵是守住 AAPCS 那套調用約定。最省事的做法是保留 C 工程的啟動文件和__main把匯編文件當成一個普通模塊加進分組。匯編側要做的就兩件事EXPORT出去給 C 調IMPORT進來調 C。; crc16.s —— 給 C 工程提供 CRC16 查表加速函數(shù) AREA |.text|, CODE, READONLY EXPORT crc16_asm ; C 側聲明 extern uint16_t crc16_asm(...) THUMB ; uint16_t crc16_asm(uint16_t crc, const uint8_t *buf, uint32_t len) ; 入?yún)0crc, R1buf, R2len 返回R0 crc16_asm PROC PUSH {R4, LR} ; 只用到 R4順手把 LR 也壓了 CMP R2, #0 BEQ done loop LDRB R3, [R1], #1 ; 取一字節(jié)并后自增 EOR R3, R3, R0, LSR #8 LDR R4, crc_table ; 表在 C 側定義并 extern LDRH R3, [R4, R3, LSL #1] ; 半字索引偏移 idx*2 EOR R0, R3, R0, LSL #8 SUBS R2, R2, #1 BNE loop done UXTH R0, R0 ; 只保留低 16 位 POP {R4, PC} ENDP這段代碼里幾個點必須對上入?yún)㈨樞蚴?R0、R1、R2返回值放 R0PUSH {R4, LR}保證 8 字節(jié)對齊兩條寄存器正好 8 字節(jié)同時保住 R4 和返回地址POP {R4, PC}一次完成恢復和返回。C 側只需要一句extern uint16_t crc16_asm(uint16_t crc, const uint8_t *buf, uint32_t len);鏈接時把.s和.c一起編進去就行。驗證方法我固定用三步先用 C 寫一份參考實現(xiàn)跑同一組測試向量對比結果再用調試器看匯編函數(shù)的入口處 R0~R2 是否等于 C 傳進來的值不等就是參數(shù)傳遞出了問題最后在函數(shù)返回后檢查 R4 有沒有被改回去寄存器窗口里對比調用前后的值。這三步走完混合編程基本不會再出問題。從那以后我每次往 C 工程里塞匯編函數(shù)都會先在注釋里把入?yún)⒓拇嫫鳌⒎祷刂导拇嫫?、會破壞哪些寄存器寫清楚再?C 側調用一次并對比參考實現(xiàn)——省下的這點時間遠不如后面定位一個“R4 被悄悄改掉導致主流程跑飛”的代價。希望幫到你。本文還有配套的精品資源點擊獲取