关于Hi3861硬件子系统&SDK适配

1、Hi3861 SDK 接口位置
1）code1.0：vendor\hisi\hi3861\hi3861\include\
2）code2.0canary：device\hisilicon\hispark_pegasus\sdk_liteos\include\

2、code1.0 源码中适配的硬件子系统：
1）头文件：base\iot_hardware\interfaces\kits\wifiiot_lite\
2）源代码：vendor\hisi\hi3861\hi3861_adapter\hals\iot_hardware\wifiiot_lite\

3、code2.0 canary源代码适配的硬件子系统
1）头文件：base\iot_hardware\peripheral\interfaces\kits\
2）源代码：device\hisilicon\hispark_pegasus\hi3861_adapter\hals\iot_hardware\wifiiot_lite\

两个源代码版本，对应Hi3861 SDK的接口位置不同，但是API是一致的；适配的硬件子系统都在调用Hi3861 SDK 的API，但提供接口名字不一样了，现在看到硬件外设案例中都是使用code1.0适配的接口，到2.0完全对不上了。

例如设置GPIO的输入/输出:

//sdk提供的API

hi_u32 hi_gpio_set_dir(hi_gpio_idx id, hi_gpio_dir dir);

//1.0适配的实现:

unsigned int HalGpioSetDir(HalWifiIotGpioIdx id, HalWifiIotGpioDir dir)
{
    return hi_gpio_set_dir((hi_gpio_idx)id, (hi_gpio_dir)dir);
}

//2.0适配的实现：

unsigned int IoTGpioSetDir(unsigned int id, IotGpioDir dir)
{
    return hi_gpio_set_dir((hi_gpio_idx)id, (hi_gpio_dir)dir);
}

你这code1.0应该是指通过IDE的HPM工具下载和安装的工程吧？或者是直接下载的源码压缩包？ 那些工程有些是非常久远以前的鸿蒙系统裁剪出来的，鸿蒙系统在不停地优化和调整，但是这些工程没有同步更新，所以最新的鸿蒙系统，很多子系统/组件的结构和API等，都与远古时期的代码有很大差异。

建议在LTS分支上做开发和学习轻量/小型系统，代码教新且稳定。 要学习标准系统，只能在Canary上进行了，但是该分支存在大量的不稳定现象，需要自己看着办。

如果要开发外设控制应用程序，直接使用sdk提供的API(hi_xx)应该就可以了吧？为什么还要适配硬件子系统？？

我理解使用硬件子系统的接口，是为了更换硬件开发板，而外设控制应用程序不需要任何改变的，只需要开发板厂商适配好自己的SDK，给上层应用操作提供统一的接口就好了。

不知道这样理解对不对，如果是这样，硬件子系统的接口应该要保持不变吧？？

现在是硬件还没有改变，源代码从1,0到2.0，外设控制程序就跑不起来了。

而且我发现2,0canary版本适配的硬件子系统并不完整，编写GPIO中断案例都不行，最近写的案例都是直接调用sdk提供的API，可能是windows对应金丝雀版本全量代码，还没更新好么？

去看一下我的文章《OpenHarmony 2.0 Canary 的 IoT硬件子系统》。

“如果要开发外设控制应用程序，直接使用sdk提供的API(hi_xx)应该就可以了吧？”

不建议这样做，鸿蒙系统的低耦合性就是通过framework层接口，把上层调用跟底层sdk的实现隔离来实现的，你直接用hi_xx接口，就跟鸿蒙的设计思想背道而驰了。

“只需要开发板厂商适配好自己的SDK” 这是对的，但是厂商要适配的接口是HalGpioSetDir/IoTGpioSetDir这一层，鸿蒙系统的这一层接口保持不变，而不是hi_gpio_set_dir这一层，hi_gpio_set_dir这一层是厂商内部自己的接口，A厂家可以是ha_gpio_set_dir，B厂家可以是hb_gpio_set_dir......