先楫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构建方式仍是主要开发方式。