打印

通用ARM外设驱动库

[复制链接]
2945|29
手机看帖
扫描二维码
随时随地手机跟帖
跳转到指定楼层
楼主
Simon21ic|  楼主 | 2017-1-14 00:39 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
做ARM开发做了多的人都会发现,ARM开发使用不同厂家的芯片,就会有不同的外设驱动库。如果产品换芯片的话,就会需要重新熟悉新的芯片的驱动库的使用。是否有人对通用的外设驱动库感兴趣?

外设包括最常用的一些,比如GPIO、SPI、IIC、USB(device, host, otg)、定时器等等,当然,有一些驱动还需要配合相应的通用协议栈,比如,USB device的驱动,就需要对应的通用USB device的协议栈

这种方式,好处就是换芯片基本没什么代价。对于通用应用而言,也不需要去熟悉各个厂家的MCU。
而且,接口可以做了非常简单统一,比如,初始化一个SPI接口,不用去设置相应的GPIO模式,不同的芯片,都是用一样的方式操控硬件。
当然,缺点也是有,通用的外设驱动库,可能占用的资源较多。

我正在考虑独立出一个通用外设驱动库开源项目,大家讨论定义接口的规范,然后大家一起维护这套驱动库。基于这套库的应用,基本上都可以是硬件无关,以后用其他芯片,只要在这套外设库中有驱动,基本可以直接切换使用,而不需要修改高层的代码,只需要修改和硬件相关的一些配置。

相关帖子

沙发
renxiaolin| | 2017-1-16 09:04 | 只看该作者
你的想法很善良,不现实

使用特权

评论回复
板凳
a20084666| | 2017-1-16 10:28 | 只看该作者
想法不错,只是一些硬件SPI  IIC之类的,想要高速就只能用芯片的硬件,不能用软件模拟,

使用特权

评论回复
地板
a20084666| | 2017-1-16 13:39 | 只看该作者
周立功的AMetal在做这件事情,

使用特权

评论回复
5
Simon21ic|  楼主 | 2017-1-16 13:52 | 只看该作者
本帖最后由 Simon21ic 于 2017-1-16 13:56 编辑
renxiaolin 发表于 2017-1-16 09:04
你的想法很善良,不现实

为啥不现实?我公司的硬件开发就是这么弄的,开发效率和维护效率很高
https://github.com/versaloon/vsf ... usbd_mscboot/main.c

这里就是一个demo,外设用了gpio和usbd,几个不停的芯片的工程,公用同一个main.c
只是,我们移植芯片驱动只是我们使用的,不用的芯片就没移植驱动了

使用特权

评论回复
6
renxiaolin| | 2017-1-16 13:57 | 只看该作者
Simon21ic 发表于 2017-1-16 13:52
为啥不现实?我公司的硬件开发就是这么弄的,开发效率和维护效率很高

要是M系列的,你确定比人家st做的好?要是A系列,人家移植os,然后基于os开发驱动,你还要做什么呀

使用特权

评论回复
7
Simon21ic|  楼主 | 2017-1-16 13:57 | 只看该作者
a20084666 发表于 2017-1-16 13:39
周立功的AMetal在做这件事情,

他们一直在维护吗?我看看

使用特权

评论回复
8
Simon21ic|  楼主 | 2017-1-16 14:00 | 只看该作者
这种RAD开发方式,很可能是以后MCU开发的常用方式
由于芯片速度和资源越丰富,就越可以把人从繁琐的重复开发中解放出来
以前PC上用RAD不也是一样情况?

使用特权

评论回复
9
a20084666| | 2017-1-16 14:00 | 只看该作者
Simon21ic 发表于 2017-1-16 13:57
他们一直在维护吗?我看看

有段时间没有更新,我看了下,相关的文档做的还是不错的

使用特权

评论回复
10
Simon21ic|  楼主 | 2017-1-16 14:06 | 只看该作者
本帖最后由 Simon21ic 于 2017-1-16 14:09 编辑
renxiaolin 发表于 2017-1-16 13:57
要是M系列的,你确定比人家st做的好?要是A系列,人家移植os,然后基于os开发驱动,你还要做什么呀 ...

呵呵,比ST做的好确实很容易,ST的库,随便就可以说一些BUG,当然,包括GD
不知道我好几年前给ST提的BUG,他们是否有修复
另外,你还是没明白我的意思,ST的库即使做了再好,你在NXP的芯片上用用看?
A系列的话,芯片原厂一般不是提供固件库,而是提供Android SDK

使用特权

评论回复
11
a20084666| | 2017-1-16 14:24 | 只看该作者
AMetal   你怎么看。

使用特权

评论回复
12
renxiaolin| | 2017-1-16 14:32 | 只看该作者
Simon21ic 发表于 2017-1-16 14:06
呵呵,比ST做的好确实很容易,ST的库,随便就可以说一些BUG,当然,包括GD
不知道我好几年前给ST提的BUG, ...

st的库就算有bug,你自己开发的就比人家的bug少?GD就是个山寨产品,不说那个,你想统一所有arm芯片的外设软件是没有意义的,因为底层还是有区别,不如用人家原厂家的sdk,在一个,就算有区别也是大同小异,对一个熟练工来说,st的换nxp的,不存在任何难度跟障碍

使用特权

评论回复
13
Simon21ic|  楼主 | 2017-1-16 14:45 | 只看该作者
renxiaolin 发表于 2017-1-16 14:32
st的库就算有bug,你自己开发的就比人家的bug少?GD就是个山寨产品,不说那个,你想统一所有arm芯片的外 ...

为啥不可以BUG少?BUG多少取决于多少人测试维护而已
如果你不能理解我说的话,那就不要回复了
我说的是不需要熟练工,因为换芯片,基本不用修改什么,只是把ST的底层库换成NXP的底层库而已,因为各种外设的API接口是一致的。你开发windows程序,不会因为是使用AMD或者Intel的芯片,而需要修改底层吧?现在ARM的资源越来越多,实现这个就很容易了。

使用特权

评论回复
14
Simon21ic|  楼主 | 2017-1-16 14:49 | 只看该作者
a20084666 发表于 2017-1-16 14:24
AMetal   你怎么看。

ZLG的这套思路和我做的VSF很类似,底层封装+各种通用的代码,实现RAD开发,我觉得这个就是以后嵌入式开发的方式。这个也已经一年时间了,不知道他们推广了怎么样。不过就现阶段而已,推广这种方式还是比较麻烦的,因为和现在的开发方式存在代差,很多人适应不了。但是,以后的话,这种方式可以提供更好的效率

使用特权

评论回复
15
a20084666| | 2017-1-16 14:54 | 只看该作者
底层封装+各种通用的代码
我也觉得这种方式不错,这样用不同的芯片,不用过多的去关注底层,不然换个芯片,就搞得很痛苦。期待你的开源活动。

ZLG的AMetal ,你觉得这个目前做的怎样,感觉文档做的还可以

使用特权

评论回复
16
Simon21ic|  楼主 | 2017-1-16 15:30 | 只看该作者
a20084666 发表于 2017-1-16 14:54
底层封装+各种通用的代码
我也觉得这种方式不错,这样用不同的芯片,不用过多的去关注底层,不然换个芯片 ...

嵌入式MCU开发,一般使用的是PC的淘汰的技术,毕竟资源上,MCU比PC要等几个等级了
不过,随着MCU的发展,资源越来越丰富,使得一些以前的PC技术,得以在MCU上使用,而这些技术,相对于普通的MCU开发方式,是存在代差和优势的,以后越来越多的人会看到这一点

使用特权

评论回复
17
a20084666| | 2017-1-16 15:38 | 只看该作者
mcu 性能越来越强,使得能够使用pc机的一些技术和方式来开发,

使用特权

评论回复
18
Simon21ic|  楼主 | 2017-1-17 02:41 | 只看该作者
a20084666 发表于 2017-1-16 14:54
底层封装+各种通用的代码
我也觉得这种方式不错,这样用不同的芯片,不用过多的去关注底层,不然换个芯片 ...

ametal支持的芯片貌似只有NXP的几个型号,如果要做成通用API接口,那就必须支持几个不同厂家的MCU,这样,更加容易归类出统一的API接口。

真正好用的外设库,开发过程中一般需要用户参与,API接口的确定,需要考虑各种用户的意见。甚至可能在开发过程中,为了适应一些新的需求,而修改接口。这个就是通用的外设驱动库开发最难的地方了。就是要适应不同芯片,并且要适应不同的应用,当然,需要是独立的,不能依赖高层的系统构架。

使用特权

评论回复
19
Simon21ic|  楼主 | 2017-1-17 02:51 | 只看该作者
本帖最后由 Simon21ic 于 2017-1-17 02:56 编辑

ST的外设库的设计目标,我个人认为只是用来替代寄存器操作的
但是,设计的好的外设库,远不止是替代寄存器操作,好的外设库还需要隐藏很多控制的细节,我随便举个例子做一下对比:

如果用ST的外设库实现一个SPI的操作的话,需要先调用GPIO接口,设置相应的引脚为SPI功能,然后调用ClockCmd使能对应的时钟,最后才是SPI_Init和SPI_Cmd。

VSF里的SPI,调用的都是SPI里的接口,没有其他GPIO和Clock的调用:
vsfhal_spi_init(....)
vsfhal_spi_config(....)
接口的第一个参数是SPI的序号,序号里还会包含SPI的引脚复用信息(一般是用户在hw_cfg.h里设置的硬件配置信息常数)。通过这个参数,底层代码完全可以自动初始化相应的IO口,自动设置时钟,这些操作完全不需要用户介入。用户需要关心的,只是SPI的控制和数据的传输而已。其他用户不需要关心的细节,外设库都应该隐藏掉。
这样引起的问题是,外设库会很大,因为需要包含所有引脚复用的代码。vsfhal里,通过外设库配置来解决,配置使能使用到的外设,没使用到的外设的代码就不会在库里。

当然,还看到过一些其他的外设库,用结构封装了所有API:
SPI[0].Init(....)
SPI[0].Config(....)
这种的问题就是,结构无法优化,即使有部分SPI的API没有使用的话,但是结构还是存在的,所以没使用的代码还是会占用空间。

使用特权

评论回复
20
Simon21ic|  楼主 | 2017-1-17 03:26 | 只看该作者
外设库还需要经过很多的应用,来验证,即使ST的外设库维护到现在,也还有不少问题,当然,这些问题并不是不能解决,但是解决这个问题,需用开发人员对芯片的很多细节非常熟悉。继续举几个例子,也是ST的外设库和USB device外设库,不过用的芯片是GD的芯片。

1. 芯片运行了慢,USBDevice就不能用了吗?
我记得很久以前就提出过ST的USBD的库的BUG,在USBD中断模式下,如果可以快速响应的话,是不会出问题的。但是,USB本身具备流控,并不需要实时的响应,如果响应慢一些的话,那很有可能出问题。对于GD的150的芯片,如果把usbd的demo放在后32K,那估计运行都会有问题。这个就是库的BUG。
2. bootloader跳到实际应用的时候,可能一些寄存器在bootloader里设置了,那么应用中的库,是否考虑了这些情况。比如,如果bootloader设置时钟是72M,USBD的PHY的分频是1.5。固件更新OK后,跳到APP,APP设置时钟是48M,USBD的PHY分频是1,然后就发现USBD不能用了。
原因就是设置USBD的PHY的分频系数的时候,USB不能使能,但是,USBD外设库里,并没有关闭USB使能的API,设置PHY分频系数的时候,也没有关闭USB的使能。

无论是ST的库,还是NXP还是其他库,要完善的话,肯定需要经过很多应用的。并且,外设库的维护者,需要能够听到这些问题。这个用开源社区是最好的解决方式,如果发现问题,直接可以和维护人员交流,如果维护人员搞不定,甚至可以自己发布patch request,经过确认后,更新到开源代码里去。这样,只要一个人碰到坑,解决后,其他人都不会碰到。而不像ST的库,如果碰到坑之后,需要很熟悉芯片才能解决,然后其他人也一样会再次跳进同一个坑里。

使用特权

评论回复
发新帖 我要提问
您需要登录后才可以回帖 登录 | 注册

本版积分规则

266

主题

2597

帖子

104

粉丝