本文為RISC-V嵌入式開發準備篇2：嵌入式開發的特點介紹。

本文的目的是對嵌入式開發的特點進行簡單的科普與回顧，為后續詳細介紹“RISC-V GCC工具鏈”和“RISC-V匯編語言程序設計”打下基礎。注：本文力求通俗易懂，主要面向初學者，對嵌入式開發有所了解的讀者可以忽略此文。

在本號上次發表的文章《編譯過程簡介》中介紹過，嵌入式系統的程序編譯過程和開發有其特殊性，譬如：

嵌入式系統需要使用交叉編譯與遠程調試的方法進行開發。

需要自己定義引導程序。

需要注意減少代碼體積（Code Size）。

需要移植printf從而使得嵌入式系統也能夠打印輸入。

使用Newlib作為C運行庫。

每個特定的嵌入式系統都需要配套的板級支持包。

下文將分別予以介紹。

1 交叉編譯和遠程調試

在本號上次發表的文章《編譯過程簡介》中介紹了如何在Linux系統的PC電腦上開發一個Hello World程序，對其進行編譯，然后運行在此電腦上。在這種方式下，我們使用PC電腦上的編譯器編譯出該PC電腦本身可執行的程序，這種編譯方式稱之為本地編譯。

嵌入式平臺上往往資源有限，嵌入式系統（譬如常見ARM MCU或8051單片機）的存儲器容量通常只在幾KB到幾MB之間，且只有閃存而沒有硬盤這種大容量存儲設備，在這種資源有限的環境中，不可能將編譯器等開發工具安裝在嵌入式設備中，所以無法直接在嵌入式設備中進行軟件開發。因此，嵌入式平臺的軟件一般在主機PC上進行開發和編譯，然后將編譯好的二進制代碼下載至目標嵌入式系統平臺上運行，這種編譯方式屬于交叉編譯。

交叉編譯可以簡單理解為，在當前編譯平臺下，編譯出來的程序能運行在體系結構不同的另一種目標平臺上，但是編譯平臺本身卻不能運行該程序，譬如，在x86平臺的PC電腦上編寫程序并編譯成能運行在ARM平臺的程序，編譯得到的程序在x86平臺上不能運行，必須放到ARM平臺上才能運行。

與交叉編譯同理，在嵌入式平臺上往往也無法運行完整的調試器，因此當運行于嵌入式平臺上的程序出現問題時，需要借助主機PC平臺上的調試器來對嵌入式平臺進行調試。這種調試方式屬于遠程調試。

常見的交叉編譯和遠程調試工具是GCC和GDB。在本號上次發表的文章《編譯過程簡介》中介紹了如何使用Linux自帶的GCC本地編譯一個Hello World程序并運行。但是，GCC不僅能作為本地編譯器，還能作為交叉編譯器；同理GDB不僅可以作為本地調試器，還可以作為遠程調試器。

當作為交叉編譯器之時，GCC通常有不同的命名，譬如：

arm-none-eabi-gcc和arm-none-eabi-gdb是面向裸機（Bare-Metal）ARM平臺的交叉編譯器和遠程調試器。

所謂裸機（Bare-Metal）是嵌入式領域的一個常見形態，表示不運行操作系統的系統

而riscv-none-embed-gcc和riscv-none-embed-gdb是面向裸機RISC-V平臺的交叉編譯器和遠程調試器。

本號后續發文《RISC-V GCC工具鏈的介紹》將介紹RISC-V GCC工具鏈的更多信息。

2 移植newlib或newlib-nano作為C運行庫

newlib是一個面向嵌入式系統的C運行庫。相對于本號上次發表的文章《編譯過程簡介》中介紹的glibc，newlib實現了大部分的功能函數，但體積卻小很多。newlib獨特的體系結構將功能實現與具體的操作系統分層，使之能夠很好地進行配置以滿足嵌入式系統的要求。由于專為嵌入式系統設計，newlib具有可移植性強、輕量級、速度快、功能完備等特點，已廣泛應用于各種嵌入式系統中。

由于嵌入式操作系統和底層硬件的多樣性，為了能夠將C/C++語言所需要的庫函數實現與具體的操作系統和底層硬件進行分層，newlib的所有庫函數都建立在20個樁函數的基礎上，這20個樁函數完成具體操作系統和底層硬件相關的功能：

I/O和文件系統訪問（open、close、read、write、lseek、stat、fstat、fcntl、link、unlink、rename）；

擴大內存堆的需求（sbrk）；

獲得當前系統的日期和時間（gettimeofday、times）；

各種類型的任務管理函數（execve、fork、getpid、kill、wait、_exit）；

這20個樁函數在語義、語法上與POSIX（Portable Operating System Interface of UNIX）標準下對應的20個同名系統調用完全兼容。

所以，如果需要移植newlib至某個目標嵌入式平臺，成功移植的關鍵是在目標平臺下找到能夠與newlib樁函數銜接的功能函數或者實現這些樁函數。本號后續發文《基于HBird-E-SDK平臺的軟件開發與運行》將介紹蜂鳥E200的HBird-E-SDK平臺如何實現移植實現newlib的樁函數。

注意：newlib的一個特殊版本newlib-nano版本進一步為嵌入式平臺減少了代碼體積（Code Size），因為newlib-nano提供了更加精簡版本的malloc和printf函數的實現，并且對庫函數使用GCC的-Os（側重代碼體積的優化）選項進行編譯優化。

3 嵌入式引導程序和中斷異常處理

在本號上次發表的文章《編譯過程簡介》中介紹了如何在Linux系統的PC電腦上開發一個Hello World程序，對其進行編譯，然后運行在此電腦上。在這種方式下，程序員僅僅只需要關注Hello World程序本身，程序的主體由main函數組織而成，程序員可以無需關注Linux操作系統在運行該程序的main函數之前和之后需要做什么。事實上，在Linux操作系統中運行應用程序（譬如簡單的Hello World）時，操作系統需要動態地創建一個進程、為其分配內存空間、創建并運行該進程的引導程序，然后才會開始執行該程序的main函數，待其運行結束之后，操作系統還要清除并釋放其內存空間、注銷該進程等。

從上述過程中可以看出，程序的引導和清除這些“臟活累活”都是由Linux這樣的操作系統來負責進行。但是在嵌入式系統中，程序員除了開發以main函數為主體的功能程序之外，還需要關注如下兩個方面：

引導程序：

嵌入式系統上電后需要對系統硬件和軟件運行環境進行初始化，這些工作往往由用匯編語言編寫的引導程序完成。

引導程序是嵌入式系統上電后運行的第一段軟件代碼。引導程序對于嵌入式系統非常關鍵，引導程序所執行的操作依賴于所開發的嵌入式系統的軟硬件特性，一般流程包括：初始化硬件、設置異常和中斷向量表、把程序拷貝到片上SRAM中、完成代碼的重映射等，最后跳轉到main函數入口。

本號后續發文《基于HBird-E-SDK平臺的軟件開發與運行》將結合HBird-E-SDK平臺的引導程序實例了解引導程序的更多細節。

中斷異常處理

中斷和異常是嵌入式系統非常重要的一個環節，因此，嵌入式系統軟件還必須正確地配置中斷和異常處理函數。有關RISC-V架構的中斷和異常的詳細信息，請參見RISC-V中文書籍《手把手教你設計CPU——RISC-V處理器篇》 中第13章內容《不得不說的故事——中斷和異常》。

本號后續發文《基于HBird-E-SDK平臺的軟件開發與運行》將結合HBird-E-SDK程序實例了解如何配置中斷和異常處理函數。

4 嵌入式系統鏈接腳本

在本號上次發表的文章《編譯過程簡介》中介紹了如何在Linux系統的PC電腦上開發一個Hello World程序，對其進行編譯，然后運行在此電腦上。在這種方式下，程序員也無需關心編譯過程中的“鏈接”這一步驟所使用的鏈接腳本，無需為程序分配具體的內存空間。

但是在嵌入式系統中，程序員除了開發以main函數為主體的功能程序之外，還需要關注“鏈接腳本”為程序分配合適的存儲器空間，譬如程序段放在什么區間、數據段放在什么區間等等。

本號后續發文《基于HBird-E-SDK平臺的軟件開發與運行》將結合HBird-E-SDK的“鏈接腳本”實例了解更多細節。

5 減少代碼體積

嵌入式平臺上往往存儲器資源有限，嵌入式系統（譬如常見的ARM MCU或8051單片機）的存儲器容量通常只在幾KB到幾MB之間，且只有閃存而沒有硬盤這種大容量存儲設備，在這種資源有限的環境中，程序的代碼體積（Code Size）顯得尤其重要，因此，有效地降低降低代碼體積（Code Size）是嵌入式軟件開發必須要考慮的問題，常見的方法如：

使用newlib-nano作為C運行庫以取得較小代碼體積（Code Size）的C庫函數。

盡量少使用C語言的大型庫函數，譬如在正式發行版本的程序中避免使用printf和scanf等函數。

如果在開發的過程中一定需要使用printf函數，可以使用某些自己實現的閹割版printf函數（而不是C運行庫中提供的printf函數）以生成較小的代碼體積。

除此之外，在C/C++語言的語法和程序開發方面也有眾多技巧以取得更小的代碼體積（Code Size）。

本號后續發文《基于HBird-E-SDK平臺的軟件開發與運行》將結合HBird-E-SDK平臺實例了解更多“減少代碼體積”的實現細節。減小代碼體積（Code Size）的方法很多，本文在此不做一一贅述，請初學的讀者自行查閱相關資料進行學習。

6 支持printf函數

在本號上次發表的文章《編譯過程簡介 》中介紹了如何在Linux系統的PC電腦上開發一個Hello World程序，程序中使用C語言的標準庫函數printf打印了一個“Hello World”字符串。該程序在Linux系統里面運行的時候字符串被成功的輸出到了Linux的終端界面上。在這個過程中，程序員無需關心Linux系統到底是如何將printf函數的字符串輸出到Linux終端上的。事實上，如《編譯過程簡介》中所述，在Linux本地編譯的程序會鏈接使用Linux系統的C運行庫glibc，而glibc充當了應用程序和Linux操作系統之間的接口，glibc提供的 printf 函數就會調用如sys_write等操作系統的底層系統調用函數，從而能夠將“字符串”輸出到Linux終端上。

從上述過程中可以看出，由于有glibc的支持，所以printf函數能夠在Linux系統中正確的進行輸出。但是在嵌入式系統中，printf的輸出卻不那么容易了，基于如下幾個原因：

嵌入式系統使用newlib作為C運行庫，而newlib的C運行庫所提供的printf函數最終依賴于如本文中所介紹的newlib樁函數write，因此必須實現此write函數才能夠正確的執行printf函數。

嵌入式系統往往沒有“顯示終端”存在，譬如常見的單片機其作為一個黑盒子一般的芯片，根本沒有顯示終端。因此，為了能夠支持顯示輸出，通常需要借助單片機芯片的UART接口將printf函數的輸出重新定向到主機PC的COM口上，然后借助主機PC的串口調試助手顯示出輸出信息。同理，對于scanf輸入函數，也需要通過主機PC的串口調試助手獲取輸入然后通過主機PC的COM口發送給單片機芯片的UART接口。

從以上兩點可以看出，嵌入式平臺的UART接口非常重要，往往扮演了輸出管道的角色，為了能夠將printf函數的輸出定向到UART接口，需要實現newlib的樁函數write，使其通過編程UART的相關寄存器將字符通過UART接口輸出。本號后續發文《基于HBird-E-SDK平臺的軟件開發與運行》將結合HBird-E-SDK平臺移植printf函數的實例了解更多細節。

7 提供板級支持包

對于特定的嵌入式硬件平臺，為了方便用戶在硬件平臺上開發嵌入式程序，硬件平臺一般會提供板級支持包（Board Support Package，BSP）。板級支持包所包含的內容沒有絕對的標準，通常說來，其必須包含如下內容：

底層硬件設備的地址分配信息

底層硬件設備的驅動函數

系統的引導程序

中斷和異常處理服務程序

系統的鏈接腳本

如果使用newlib作為C運行庫，一般還提供newlib樁函數的實現。

由于板級支持包往往會將很多底層的基礎設施和移植工作搭建好，因此應用程序開發人員通常都無需關心本文第1.2節至第1.6節中描述的內容，能夠從底層細節中被解放出來避免重復建設而出錯。本號后續發文《基于HBird-E-SDK平臺的軟件開發與運行》將結合HBird-E-SDK平臺的BSP實例了解更多細節。