先楫hpm_sdk開發方式的優缺點 與單片機傳統開發方式的不同點

一、背景

最近在跟一些開發者交流過程中，或者開發者群里反饋，感覺先楫單片機開發方式不同于以往的單片機開發方式，或者開發方式沒接觸過導致無從下手，或者是覺得自己的APP需要嚴重依賴hpm_sdk等等。

在這些反饋當中，覺得有必要出個雜談文章，談一談hpm_sdk的開發方式的優缺點，以及相比以往的單片機傳統開發方式的不同點。以此可以帶給開發者一些啟發，更能方便開發者更快借助hpm_sdk進行開發自己的應用。

本文也會借助一些開發者分享過的開發經驗，感謝hpmicro開發者貢獻的文章。

二、開發差異

（一）IDE

先楫的目前通用MCU采用的內核架構都是riscv,這一點就不同于國內大同小異的各種arm的cortex-M系列的單片機，甚至可以B2B兼容STM32的單片機也一樣，不能夠支持ARM自己的平臺-Keil MDK。

對于嚴重依賴keil開發的工程師來說，特別目前國內的很多開發工程師來說，這確實是不夠友好的一個點。畢竟keil經過多年的發展，其傻瓜式的界面操作，網上豐富的踩坑記錄，都足夠讓一個沒接觸過單片機開發的都能輕松入門。

但是Keil這個本身不是免費的商用IDE，盡管國內很多cortex-M單片機的芯片廠家提供的類似STM32的Firmware_Library包，里面的工程都支持了keil，但是也沒說明對keil這個IDE進行了版權購買，這帶來的版權問題責任就分給了芯片開發者，雖然國內很多可以通過破解方式進行商用，但是畢竟在商用的過程中時時刻刻得注意著版權問題。

先楫開發雖然不支持keil，但是在提供的IDE上，使用segger（大名鼎鼎Jlink調試器的廠家）自己開發的IDE，也就是SEGGER Embedded Studio for RISC-V，這個同樣不是免費的商用IDE，但是先楫在版權上十分重視，購買了其芯片開發的商用版權，目前可以不限定于SEGGER Embedded Studio的版本，而且可以讓開發者直接商用開發，避免版權問題。這個IDE同樣跟keil操作類似，通過可視化操作進行配置即可，配合其Jlink更是能夠讓調試更加友好。

IDE的編譯鏈支持上，支持了segger自身的編譯鏈，也支持了gcc編譯鏈，同樣也支持andes編譯鏈。

SEGGER Embedded Studio 下載網頁

SEGGER Embedded Studio 先楫license注冊網頁

開發者文章: (SEGGER Embedded Studio for RISC-V，for HPMicro Devices 解決首次使用激活問題，提示無License ）

另外SEGGER Embedded Studio 也有對應user manual手冊，以便開發者查缺補漏。

（二）構建系統

對于國內的arm的cortex-m的單片機廠家來說，并沒有所謂的什么構建系統開發環境。但是對于有些開發者如果開發過樂鑫的產品，比如esp32，使用的esp-idf就是使用的cmake構建系統（早期的esp-idf還是makefile版本），還有樹莓派的rp2040的pico-sdk。這種構建系統入門有點門檻，需要有一定的cmake基礎(比如cmakelist語法)以及相關環境搭建經驗，但這也感覺是未來嵌入式發展的趨勢，通過cmakelists.txt管理配置生成各大跨平臺的工程(比如先楫開發中，生成SEGGER Embedded Studio 以及后續先楫支持的IDE)、生成的makefile文件可以給各大平臺編譯器解析，

對于芯片原廠和開發者來說，這種構建系統可以讓多種芯片系列，組件包等等只需要支持一套SDK，而不需要提供多種library芯片包，可以擴展構建多種IDE，比如命令或者可視化界面生成EGGER Embedded Studio工程；支持cmake構建的vscode,clion等等跨平臺開發。

三、開發優勢

項目工程依靠cmakelists.txt文件進行管理，這種管理方式類似在keil進行相關路徑加入或者加入自定義編譯宏定義等，比如：

1、設置一些自定義編譯宏定義開關

2、根據不同編譯類型配置不同的編譯選項和鏈接選項

3、添加頭文件路徑、編譯宏等常規操作

4、添加源碼編譯

5、添加extern組件等操作

以上是不是覺得這種開發方式，IDE比如keil在界面操作也有，但是對于cmake來說，單純一個cmakelist文件就可以操作完成，熟悉入門后也能大大提高開發效率。

本文以hpm_sdk1.2進行說明，簡單舉例一些常用的命令說明，一個cmakelist文件管理的方便好處。

更多的命令接口可以參考sdk中的sample的cmakelist，以及cmake文件夾里面的封裝的命令函數。不在本文闡述范圍內。

該版本已經支持在sdk以外創建自己的Board, 但在sdk以外開發自己的應用一直都是可以的。

（一）創建自己的AP應用文件夾

新建一個自己一個APP文件夾，里面放置一個Board-這里我使用的是hpm6750_rc，這里從hpm_sdk里面的board的hpm6750evkmini中提取，并把hpm6750evkmini.yaml改為hpm6750_rc.yaml，如下：

從hpm_sdk復制一個sample，比如hello_world。然后在自己創建的應用文件夾新建個build，進入到該build文件夾，這時候使用命令：

cmake -G Ninja -DBOARD=rc_hpm_evk -DBOARD_SEARCH_PATH=your custom/rcsn_project/board/  -DCMAKE_BUILD_TYPE=flash_xip ..

這時候打開build文件夾里面的segger_embedded_studio，打開ses這個IDE，可以看到boards已經變成自己項目上的Board,以及自己的application已經被添加上來。

（二）定義宏開關，預處理定義

在keil上，預處理定義在option上可以手動輸入定義

同樣在segger_embedded_studio中也有類似的定義。

但是hpm_sdk中，并不需要開發者自己手動去添加，在makelists使用命令: sdk_compile_definitions, 如此就可以進行定義預處理符號。

（三）頭文件路徑加入

比如在keil里面就有對應的控件操作

那么在segger_embedded_studio也有類似操作界面

在hpm_sdk的構建當中，同樣也不需要用戶自己去界面操作，直接可以在cmakelists通過sdk_inc 命令設置，比如自己的工程定義以下工程目錄，每個目錄里面有個inc，這個就是需要包含的頭文件路徑。

（四）加入源文件

像keil一樣，segger_embedded_studio也有自己的源文件目錄結構，比如需要添加上述所說的drivers里面的文件，可以通過使用sdk_app_src命令進行設置。比如：

（五）編譯相關

比如設置優化等級、GCC編譯參數、指令集選擇等等。都可以通過sdk_compile_options命令設置

設置O3優化可以使用：

sdk_compile_options("-O3")

設置gcc特定警告

sdk_compile_options("-Wall")

設置ABI和ISA

sdk_compile_options("-mabi=ilp32d")
sdk_compile_options("-march=rv32gc")

四、開發劣勢

（一）入門門檻相對高

目前來說，cmake構建方式在MCU開發上并不常見，也存在一定的入門門檻；

但對于項目的構建優化和管理是效率顯著的，比如引入一個第三方中間件，只需要在此中間件內部通過CMakelists管理好自身文件鏈接，項目通過條件包含，能夠最大減少中間件帶來的耦合度。

需要有一定的cmake基礎，也帶來一定的學習成本。

（二）工程管理相對約束

在傳統的MCU開發中，很多開發者都喜歡把MCU廠家自身的驅動和組件源碼都加入到自己的工程目錄下，這樣方便自己管理，甚至可以自己改動官方庫代碼（這點是極其不推薦的行為）。

但hpm_sdk更多傾向于開發者的APP應用與SDK分開，這種開發好比是上位機的QT開發，在QT開發中，通過pro/pri文件管理導入QT的官方庫使用，如果不想使用那就不開啟對應的庫，又好比python開發，通過Import方式自行選擇。

這種開發方式需要把hpm_sdk路徑放在對應的文件夾中，并把路徑添加到環境變量，這好比是軟件的安裝，先楫的所有芯片系列都依賴與這個hpm_sdk，用戶只需關心自己的應用開發路徑，在拷貝的過程中也只需要拷貝自身應用，但前提對方也得"安裝"了hpm_sdk。

這種約束方法對于有些開發者來說確實不夠友好，當然未來先楫也不排除支持把hpm_sdk所需要的文件能讓開發者自行導入到自己工程目錄的需求，比如類似stm32cubemx生成初始化外設工具，但hpm_sdk的cmake構建方式仍是主要開發方式。