阿里云IOT-C-SDK系列（5）：进一步理解SDK的移植使用方式

阿里云IOT-C-SDK系列（1）概述：移植流程、程序框架、代码目录
阿里云IOT-C-SDK系列（2）快速体验：移植+示例C代码
阿里云IOT-C-SDK系列（3）快速体验：不使用SDK自带编译系统进行移植示例及Makefile的编写示范
阿里云IOT-C-SDK系列（4）SDK配置选项理解

  在系列（1）中简单的描述了SDK的两种移植方式：

（1）基于SDK自带的编译系统，通过修改HAL层的函数，编译生成SDK库和HAL库。然后我们基于静态库来开发应用程序。

（2）使用SDK的功能代码抽取工具，将所需功能代码抽取，然后将抽取出的代码添加到我们自己的工程中，进行应用开发。

  经过系列的测试和与阿里的技术沟通，现在对这两种方式做进一步的解释和总结：

（1）“代码抽取”移植方式理论上是推荐的一种移植方式，尤其是我们使用IAR和Keil等IDE开发环境时，没得选，只能采用这种方式。 当然，对于嵌入式Linux的开发环境，也是支持这种移植方式的，这一点在系列（3）中已经做了移植实例。但是要注意的是，到目前为止软件版本（v3.0.1），SDK的代码抽取功能做的不够完善，代码抽取功能对于单设备的上云支持的比较好，而对于网关设备的支持反倒不太好，举一个简单的例子，如果我们要开发的应用是嵌入式linux网关，这个网关只配置最基本的功能，也就是选择“FEATURE_DEIVE_MODE_GATEWAY”，当我们选择基本配置后，然后执行代码抽取脚本，在output的输出的wrapper.c文件中，竟然没有线程相关的HAL函数，比如 HAL_PthreadCreate、信号量的HAL函数等。对于网关设备，肯定要涉及到 线程同步，信号量等的使用，经过与阿里的技术反复沟通，才发现，SDK目前对于网关功能的代码抽取，支持的不够好，需要选择一些高级的功能，在wrapper.c中，才会有相应的HAL函数抽取，比如我们如果选择http2,就可以，这显然是不够完善的，可能阿里的理念是，网关就应该是比较复杂的设备，功能上，尽可能是“全家桶”式的。 那么对于我们就想实现一些最基本的配置，而wrapper.c中又没有相应的HAL函数时，我们在编译工程时，势必会出现各种的“未定义”报警信息，这个时候，我们也只能是根据报错信息，自己一点点的去手动添加HAL函数了。

（2）使用SDK自带的编译系统，更适合于嵌入式开发环境为linux，尤其是我们要开发嵌入式linux网关。前面分析了，对于网关设备，SDK的代码抽取功能支持的不太完善，所以我们只能是针对整个SDK的源码，使用SDK自带的编译系统，通过选择功能来编译生成对应的静态库（libiot_sdk.a、libiot_hal.a等），然后我们基于这些静态库来进行开发应用程序，这种方式对于应用开发来讲，也是很方便的，起码不用针对sdk源码自己编写Makefile了，但是这种方式的难点在于我们需要熟悉SDK的源码结构，熟悉使用SDK自带编译系统，移植编译的方法和细节，这一点，在SDK的教程中，目前只有一种案例可以参考，连接如下：

使用SDK自带编译系统时的移植示例

这种方式有点类似于u-boot的移植方式，简单的实现比较容易，但是如果想要实现比较复杂，或者需要涉及到一些技术细节的时候，就需要我们熟悉嵌入式linux的各种细节知识点，比如kconfig、SDK的整个编译流程等等，这个对于刚接触嵌入式LInux的开发者而言，是很难的，毕竟linux的开发涉及到的知识点，太多。

特别说明：上述两种方式，都需要先执行“功能选择配置”，在linux下是 makemenuconfig，在Windows下是 config.bat。前面的SDK自带编译系统的移植案例中，没有涉及到这一块，并不是不需要，那里使用了 make reconfig，也是再次编译，是基于已经选择好的配置功能来编译的。也就是不管哪种移植方式，都是需要那个  make.settings 文件的，而这个文件就是通过 功能选择配置 生成的。