关于底层驱动的API接口讨论

[versaloon]

VSF中的底层API接口使用类似这样的方式定义：
halo_err_t gd32f1x0_gpio_init(uint8_t index)
然后在项目的工程设置里，定义__TARGET_CHIP__宏为gd32f1x0，再通过
#define HALO_GPIO_INIT(m) __CONNECT(m, _gpio_init)
halo_err_t HALO_GPIO_INIT(TARGET_CHIP)(uint8_t index);
来声明对应的接口，并且使用
#define halo_gpio_init HALO_GPIO_INIT(TARGET_CHIP)
来定义通用的API访问接口。这种方式并不利于移植和调试，大家有什么看法？

[ianhom]

也就是说，在程序中调用halo_gpio_init就等同于直接调用gd321x0_gpio_init，函数静态链接对吗？这样效率高，也不浪费内存，但对命名规范有较高要求

[versaloon]

也就是说，在程序中调用halo_gpio_init就等同于直接调用gd321x0_gpio_init，函数静态链接对吗？这样效率高，也不浪费内存，但对命名规范有较高要求

是的，如果__TARGET_CHIP__定义为gd32f1x0的话，halo_gpio_init就是gd32f1x0_gpio_init，没有额外的开销。不过调试的时候，halo_gpio_init查定义的时候，得到的是宏，而不是gd32f1x0_gpio_init。

之前leop建议的是，不是用gd32f1x0_gpio_init，而是直接使用halo_gpio_init作为GD32的GPIO的接口，不需要通过宏来中转，也不需要定义__TARGET_CHIP__，直接导入gd32f1x0的驱动文件就行了。

[ianhom]

• 那这样的话，就需要所有平台的GPIO都使用相同的函数名halo_gpio_init，只要大家命名规范遵守的好，这样做确实简单高效。对于底层本身，在函数名上强调自己的平台区别意义略显不大，文件名或路径即可区分不同平台。而且在同一个平台上不会出来两种平台的gpio驱动，每个平台的gpio都自称为halo_gpio_init也不会有冲突。
• 这种方式简洁高效，但还是牺牲了一定灵活性。如果资源条件允许的话，是否可以考虑一下动态/静态的接口的方式。一些少见的情景，比如一种普通ADC读取，和ADC+DMA方式的读取，两种方式最好选择不同的函数名halo_adc_read 和 halo_adc_dma_read以示区分，但这样就不适用统一函数名方式的调用。使用接口固然有一定开销，但对命名的要求就会松很多。以上个人拙见，一种对机器友好，一种对程序员友好，大家怎么看？
• 这里有些我之前的笔记，一些不成熟的想法：
  • 函数调用
  • 驱动接口
  • 注册接口结构

[versaloon]

我觉得adc_read和adc_dma_read都可以提供，因为高层使用什么方式，往往是和应用相关的。我觉得接口即需要提供轮询方式的API，也需要提供非轮询方式的API，还需要提供DMA方式的API，因为这些都是非常常见的用法。倒也不用担心驱动会比较庞大，因为一般直接通过halo_adc_read这样调用的话，没有调用到的函数会自动被优化，不占用空间。确实对于MCU的应用来说，太过于多样性，所以HAL要考虑的问题就很多。

我看了一下你的接口，其实和以前的ASF（Atmel的软件构架）里的驱动很像，他们的做法就是模仿POSIX，通过read, write, ioctrl等标准接口控制硬件。这种方式会增加一些资源占用，并且有时候对于特定外设来说，接口并不是最简单明了的。当然，我并不是说POSIX不好，好像RTT的也是类似POSIX的方式，不过这个主要看应用等级，对于MCU等级的话，我觉得没有必要用这种方式。

[GorgonMeducer]

不是很赞同MCU向POSIX靠的方式。接口要简洁，目前用POSIX并看不到实质性的好处，而且未来如果真的需要POSIX，也不过是在Level2的API层增加一个平行的封装包的问题。Level1的驱动一定要做到最大的适应性和最高的性能或最高的尺寸。
基于这种情况：

1、在Level1 强制必须实现非阻塞的接口，接口命名提供规范（但不强制）方便讨论这部分接口叫做 Non-Block Meta-Driver (NBMD) 非阻塞的元驱动。其中，符合规范的叫做 Driver.meta.nb.std，不符合命名规范的叫做 Driver.meta.nb.nstd
2、使用非阻塞接口在Level 2额外封装出阻塞的接口。这里，对于Driver.meta.nb.std，因为符合规范，所以可以提供统一的阻塞封装库，放在类似common的东西里面，这样只要实现Driver.meta.nb.std，阻塞和非阻塞的版本都一并提供了。对于Driver.meta.nb.nstd，这就要开发者自己去实现对应的非阻塞版本了。
3、从Level 2开始，所有接口都应该强制符合某一个接口标准，否则HAL的意义就不存在了。但这并不妨碍我们可以拥有“少数”不同的接口标准。但这里的少数需要本组织所有人都通过才能列入halo的官方标准，否则意义不大。
4、无论是哪个接口标准，Level 2 都应该同时提供 Non-Block-Driver （Driver.nb）和 Block-Driver（Driver.block）。
5、关于用什么办法来处理模块之间关系（依赖），有成熟的办法，在另外一个帖子里面讨论。

这是我的看法。——@versaloon，我们应该开一个帖子，明确各个Level的职能和要求——我知道你写过，但是需要一些讨论来让大家提问，并且理解他们。

[versaloon]

POSIX从诞生的时候，就是针对文件的操作。Linux里由于设备（甚至总线等等），都可以安装到对应的VFS上，所以采用这种方式的。

to GorgonMeducer:
我目前是想先把lv1的代码先定下来，主要是因为lv1是最基础的，当然VSF目前只是使用lv1。
不过确实可以把这几个不同等级的接口的职责和要求说明一下，对了，你也可以发issue，说明这些问题。

[ianhom]

@versaloon @GorgonMeducer
感谢二位的指导:smile:
可否简单介绍下不同的level

[GorgonMeducer]

同意，目前首要目标是：搞定Lv1的接口规范。

@ianhom 你看首页介绍里面有介绍三个Level分别负责什么东西，如果有不清楚，请专门发issue来讨论