最原始的操作芯片的方式是:直接操作地址,在地址的基础上,芯片厂家一般都会封装一层寄存器,寄存器本质就是基地址+偏移地址的形势来进行封装,方便用户操作。然而使用寄存器方便了操作,即使是寄存器的名字起得比较通俗易懂,但碰到比较复杂的功能,要同时操作好多个寄存器配合,才能使用这个功能的话,寄存器就又有些麻烦了,于是就诞生了库,最开始ST推出的是标准库,也就是你所说的库函数版本,库的出现就大大简化了配置过程,让用户可以更快进行配置,只需要学习用那个函数就可以了,而且库函数的名字可以起得非常直接,按照功能起名字就可以。
在近年来,ST专注于把生态做好,也就是说整个ST芯片的生态环境,为了提高可移植性,以及方便用户更加脱离硬件,更专注与软件开发,HAL库与CUBEMX应运而生,用户可以通过CUBEMX软件来直接进行图形化的配置,然后直接生成HAL库的程序,大大简化了芯片的初始化过程。当然,HAL库的臃肿也是无可避免的,因为HAL库首先的目标就是可移植性与脱离硬件,因此HAL库在一些地方上会比标准库更多一层封装,比如中断回调函数,HAL库把同类型的中断都全部归类到一起,调用一个回调函数,也就是又多了一层封装。
由于HAL库的臃肿,ST又想办法开发了LL库,在CUBEMX5.0以上版本已经可以直接选择HAL库或者LL库,LL库的操作更加接近寄存器操作,而且与HAL库是可以同时存在的。当然HAL库与LL库还是有bug的,HAL经过这么多版本的更新,bug已经稍微少了点,LL库还是有待完善的。
目前,ST已经明说了,以后不会再更新标准库,专注于HAL库,CUBEMX,因此,如果后续会经常使用ST的芯片,HAL库是有必要熟悉一下的。
说到这,应该就会明白,在代码的执行效率上大致是这样的,直接操作地址无疑是最快的,其次是寄存器操作,其次是LL库操作,然后是标准库,然后是HAL库。
针对于开发效率与执行效率,当然也是可以兼得的,HAL库的优势在于可以使用CUBEMX进行图形化配置,那么用这个进行功能初始化操作就会很快,很方便,在程序功能实现方面,使用寄存器或LL库,程序执行效率会更高,不过LL库还不是很完善,慎用吧