NearLink学习笔记（一）——开发环境的使用与功能模块管理

本文链接：https://blog.csdn.net/jingjitidu/article/details/141597131

最近打算研究点感兴趣的东西，就开了个新坑。看到了网上有卖海思星闪SOC开发板的，本身个人就想玩一玩操作系统，所做的工作也跟通信有关，能用来做星闪通信的SOC，自然是感兴趣。我购买的开发板是小熊派WS63，相信也有不少玩家也看到了相关信息，这里我就不放连接了，感兴趣的玩家在某宝自行搜索就可以获取相关资料。由于星闪设备只能跟星闪设备进行交互，所以必须要购买一对。

一、开发环境的使用

根据开发论坛里面介绍的步骤，很快就可以安装好开发环境，所使用的IDE是海思公司的HiSpark，界面很简洁，对于上手使用来说操作起来并不复杂，当然要深入研究就另外说。风格比较像VScode，个人还是挺喜欢的。这里也是按照教程创建了工程。值得注意的是，工程必须要包含对应的软件包，用户工程也会跟包含的软件包存在关联目录下。如果导入的是小熊派的工程，旧同事包含软件包和开发板的相关资源模块，这些资源的应用，都可以通过IDE的系统配置开启和关闭。如果使能了对应外设，开发板就会按照功能程序运行录入过关闭了所有外设，这个工程就相当于一个包含了底层驱动没有应用层的空白工程。

图1 HiSpark编译器界面

初次安装完毕IDE后，会遇到一个问题。按照使用教程，打开系统配置界面，在右下角会弹出如图2 所示信息。这里其实是缺少一个whl运行文件，按照第一个提示，打开详细信息，里面有一个下载链接，通过这个链接将该文件下载到本地，位置任意。

图2 缺少运行文件报错

将文件下载到本地后，从文件管理器来到该文件存储路径下，鼠标点击路径栏，编程蓝色全选状态后，直接输入：“CMD”打开命令窗，此时就是在当前路径下打开命令窗。接着按照IDE刚才展开的错误信息栏内的后续提示，复制安装指令并粘贴到命令窗内回车运行，即可在使用的电脑内安装whl运行文件。此后在打开系统配置就不会报错。

图3 在实际路径下打开CMD命令窗

如果此时按照教程使能对应外设功能后直接重编译，可能会遇见编译时间超长的问题。个人在使用过程中就遇到。点击重编译按钮后，移植提示“building”，但是没有任何编译过程信息，也不会转到最终结果，就一直转圈圈。此时只需要重启IDE即可，怀疑是IDE找到了刚才的whl文件但是并未激活，需要IDE重启后校验激活才能使用。

这里按照例程通过系统配置使能LED blinky功能，编译后下载。下载时必须先按一次板子复位按键，IDE才会下载程序，个人经验，下载方式不是类似MCU那种通过仿真口烧写，更像是重启后通过boot烧写。下载完毕后如果设置了“烧写完毕后重启”，那么程序就会自动运行，就可以看到板子上的蓝色LED在以500ms的频率闪烁。

图4 相关外设功能开关

二、功能模块的管理

由系统配置开启和关闭某些外设运行这个功能我有了一个疑问，为什么这里设置就能管理了？我找到了LED blinky功能的源文件，先开启功能再关闭功能，分别查看源文件有什么区别。按照开发MCU的相关经验，要控制某些代码运行不运行，可以使用宏来注释或解注释来实现；或者想STM32CUBE IDE 那样进行代码生成管理。可是这里既没有宏规划，也没有代码发生变化，就很奇怪。

这时，我打开系统配置界面，翻看使能、失能控制的相关提示信息，看到了一些大写文字，很像宏定义的书写方式。根据文件路径包含，找到了相关的KConfig文件。

图5 宏定义信息与文件所在位置

这个KConfig文件内，记录了与该外设相关的信息。这里可以看到，源文件内使用的宏，跟KConfig中大写内容很相似，指示前面多了一个CONFIG_。跳转到具体定义，也能看得见后后面跟随的数值也跟KConfig内default的数值相同。那么有理由认为，代码内使用的宏内容与KConfig内存放的内容有某些关联。

图6 宏定义内容与应用

然而此时仍然没有彻底弄明白是如何管理的，也只是知道有关联。紧接着按照教程进行第一次创建用户demo，在这一步教程里可以看到，在添加用户代码源文件与头文件的同时，还要创建一个CMakeList文件和一个KConfig文件，并且要将两个文件分别添加到上层路径的CMakeList与KConfig文件中。进行完两步后，用户demo也可以使用系统配置的方式去开启和关闭。

那么此时就知道，IDE通过用书书写的CMakeList与KConfig文件，来实现对不同功能模块间的管理。其中CMakeList文件描述的是配套功能代码所在文件的路径；KConfig文件描述的是功能代码所使用的宏，这些宏将有系统配置来管理。

以历程中LED Blinky demo来讲解，Blinky功能有其源文件，源文件包含了初始化与线程运行函数；包含一个CMakeList文件来说明文件路径；包含一个KConfig文件说明使用的两个宏：引脚号与运行间隔。

图7 CMakeList文件与KConfig文件

此后将两部分内容在添加到上层CMakeList与KConfig文件中。这里可以看到，上层CMakeList文件使用了一个“CONFIG_SAMPLE_SUPPORT_BLINKY”的宏来约束blinky功能的路径包含。这个宏是哪里来的呢？注意看上层KConfig文件的结构：config SAMPLE_SUPPORT_BLINKY。通过这段话的描述，将CONFIG_SAMPLE_SUPPORT_BLINKY宏雨系统配置界面连接，在配置界面内使能，这个宏的值为true；配置界面失能，这个宏的值为false。由此来打开和关闭源代码的路径包含。包含了路径，可以找到模块运行函数，模块就可以运行；不包含路径，找不到运行函数，模块就不会运行。

图8 上层CMakeList文件与KConfig文件

与此同时，上层KConfig文件通过父级与子级的包含关系，在开启模块时，通过模块KConfig文件内的描述，在mconfig.h内生成模块所需的宏；在关闭模块时删除掉使用的宏。以此，编译器读取这些描述文件，通过包含或不包含路径与生成或删除宏的方式来实现一个工程中若干功能模块的使用规划，后续用户创建的所有模块，都可以使用此方式进行集中管理，仅需在系统配置内管理不同模块的开启与关闭，就可以实现设备在不同工作任务内转换。