至于新芯片的支持，没有一家厂家会在每一款芯片上都采用完全不同的外设，甚至不同厂家的外设都会有相似之处。更有部分外设甚至有行业标准定义（例如 USB 的 OHCI／UHCI／EHCI／XHCI 和 UART 的 16C450／16C550A 接口）轮不到厂商半点话语权。芯片开发是要有代价的，不论是从时间角度，还是金钱的角度，厂家芯片升级换代都只会更新其核心竞争力的部分，而沿用其余部分。对于单片机来说这就是提高计算性能和降低功耗，前者换核心提升工艺，后者则几乎都是工艺上下功夫，基本不会碰外设。因此任凭芯片更新换代，这几个外设如同雷打不动，我又何必担心跟不上更新换代？您也可以关注一下用户手册里面某些外设（譬如 USB OTG）的部分，会冒出来另一家公司的名字和著作权标示，这些外设是 ST 从第三方买来的。这种外设 ST 大概率连修改的权利都没有，那我更是一个驱动通吃了。
第三，操作寄存器，你要不要看参考手册里到寄存器的bit定义（我已经强调了很多次了，拜托你看一下我强调的点啦~），操作库函数，USART_SendByte（xxxx），USART_GetByte(XXXX),的确也许不同的厂家API名字不一样，但是你从ST全系列的单片机里看一下这个API，命名调用完全一样，切换芯片还需要改？就算是切换不同厂家的时候，只需要到相关库文件找SendByte的API即可，这样比操作寄存器的效率高n倍,也许我说的太表面，那我再说深一点，ST的中断寄存器，不同的系列还不一样，中断状态寄存器中的中断标记的清除操作不一定相同，例如STM32F1等只需要把状态位清0即可，也就是说bit是WR属性的，而STM32F7有些中断标志位专门设立了一个清除标志位寄存器WO，也就是说，状态位是WO属性的，你需要给清除标志位寄存器中对应位写1才能清除相关中断标志位，你觉得看参考手册去了解这个居然比直接调用API clear IT penddingxxx 的还要高效？我可以肯定的说，只要接触过这些寄存器的人，都会知道，如果厂家本身封装好这些操作，不管他里面怎么操作寄存器都好，我上面依然用一样的API，这就是为什么在M0~M7甚至是STM8之间移植都这么容易的结果。
微信公众号
手机版
对于您的观点，抱歉我在此强行反驳了：
1、对于库来说，不知道你说的优化具体指什么，不知道你有没有仔细看过库，如果你需要操作寄存器，其实HAL提供了寄存器的入口地址指针，你完全可以使用此指针进行外部优化，然而，虽然我不知道你说的无谓的臃肿在哪里，不过我倒是可以说说HAL，HAL提供了外设内部状态机以及可视化的error callback，在使用者使用外设出现问题，只要操作正确，必然会通过callback得到错误的地方。而且每个外设都提供了get errorcode的api。虽然我不知道你说的所谓的标准api是啥，HAL，std的本质就是为了使用对象化的接口帮助使用者去熟悉外设的使用，而不需要使用者去仔细研读操作手册里具体到每一个bit的定义，而且.c文件的一开头注释地方会有详细的step by step告诉你这个外设应该怎么使用，我相信目前所有芯片厂商提供的sdk中，比st写得好的没几个！当然我觉得你可以写出比这个更详细更好用的库，也很期待，很多人说很臃肿，其实多数是基础问题！HAL之所以在MDK上运行得慢，是因为MDK本身的链接速度优化不当，导致在编译链接HAL库的时候显得龟速，然而在IAR或者使用GCC都不会感觉到慢！
MDK的律师涵我没见过，因为我工作用的是M0，虽然其他我的照样用山寨，然而我并不是什么大公司，只是基于用户级别来说，MDK如果查到我，基本上每一个人估计也遭殃，不过，我想知道的是，MDK有没有这么强力的资源区搞死所有的个体用户？当然我不是为用翻版辩护，“我也不支持，不鼓励用翻版”。
eclipse可以，vs也不错，qt creator也不错，尽管你说得他完美无缺，在我这里他也仅仅是个IDE，我平时自己玩都喜欢用VIM+CTAGS+YOUCOMPLETE+GCC+MAKEFILE.etc，在工作中我依然会用MDK，为什么呢？同事用，难道我要走非主流路线?那如何对接工作？。
我无心说那个好，那个不好，只不过，我觉得重点其实是应该放在我们应该放的地方，如何提高自己的能力，获得更高的工资又或者利用自己的研发优势创业? 基于此，一个单片机库写得再好，你无法跟的上芯片的更新换代的速度，当然你可以反驳，反正我不会吊死在一棵树上。等你做好这系列的库，H7，H8又出了，ST官方自然有更新库的资本和义务，然而我们的重点是如何利用芯片来开发应用，而不是点灯18掌。
最后，没意思，仅仅是对于我自己而已，因为我踩过坑，而对于楼主，对于大家，其实我更鼓励去试试看，你们可以写得更好，更方便，到哪个时候，不知道你们做好的库，能不能同时兼容其它的新的芯片呢？
说到优化，我想建议您先去看看 LLVM 文档中关于编译器优化的介绍。我这里推荐您去阅读 LLVM 的文档，是因为 LLVM clang 编译器是 ARMCC v6 的基础。然后您就知道为什么我会说 HAL 和 SPL 没法优化了。如果手工优化 HAL 或 SPL 代码，那不又退回到手写驱动上了么，用 HAL 或 SPL 的目的又何在？在代码注释里面解释操作流程是我所见过最愚蠢的做法。这些文件应该已经是库了，为什么还要给一寸光阴一寸金的用户出编程练习题？
关于 MDK，我已经讲过了 MDK 的语言支持是一个大坑。ARMCC v5 的语言限制意味着我之前好几年（那时候做的 iOS，被苹果压着一定要用最新的工具和最新的语言）辛辛苦苦积累的算法模块全部报销。这还没有谈到第三方库，譬如 libopencm3 或 libusb_stm32（一个体积很小的 USB 库，不依赖 HAL 或 SPL）这些都要求 C99 甚至 C11 才能编译。至少对于我来说，换用 MDK，哪怕是 M0 或者试用版，都意味着要大量重写我已经用的很习惯的算法模块，罔论我得先去买 Windows。
至于新芯片的支持，没有一家厂家会在每一款芯片上都采用完全不同的外设，甚至不同厂家的外设都会有相似之处。更有部分外设甚至有行业标准定义（例如 USB 的 OHCI／UHCI／EHCI／XHCI 和 UART 的 16C450／16C550A 接口）轮不到厂商半点话语权。芯片开发是要有代价的，不论是从时间角度，还是金钱的角度，厂家芯片升级换代都只会更新其核心竞争力的部分，而沿用其余部分。对于单片机来说这就是提高计算性能和降低功耗，前者换核心提升工艺，后者则几乎都是工艺上下功夫，基本不会碰外设。因此任凭芯片更新换代，这几个外设如同雷打不动，我又何必担心跟不上更新换代？您也可以关注一下用户手册里面某些外设（譬如 USB OTG）的部分，会冒出来另一家公司的名字和著作权标示，这些外设是 ST 从第三方买来的。这种外设 ST 大概率连修改的权利都没有，那我更是一个驱动通吃了。
不知道您有没有注重不同平台之间的代码积累和举一反三？其实我做单片机编程到现在，几个常用驱动的基本设计在好几个平台上都是一样的，换平台一般也就是改一下寄存器名字就能用了。STM32 上我用的串口驱动还是我从 AVR 上移植过来的呢。
LLVM我就不看了，你说的SPL我不知道是什么，HAL和STD没法优化，意思是代码已经没法优化了？既然没法优化，那么是指已经是最优化的了还是说没有优化的必要了呢？也就是说，剩下的并不是HAL还是STD，而是编译器的选择了吧？既然这样，那也毫无关系啊，HAL和STD在编写上已经考虑上了GCC、ARMCC和IAR的什么鬼CC了吧，单纯换个编译器的操作并不难吧？
在代码注释里解释操作流程《这个你是不是想歪了？》我来拷贝一下HAL或者STD的开头部分吧。
估计你没有看这个吧?如果你写的库能写得这么详细，那么我举双手的支持啊，就是不知道你有没有这个时间了？而且，你居然把这个比喻成练习手册？
对于新芯片的支持，的确没有一家厂家会在每一款芯片上采用完全不同的外设，而我的意思是，你有时间每用一个新芯片都需要去看参考手册，了解寄存器到bit的程度上吗？STM32F0，STM32F1的UART的寄存器不一样你信不信呢？STM32F1的发送寄存器只有一个DR，而F0，F7等分TDR和RDR你应该知道吧？然而对于上层库，都是统一的API，而且还带UserManual给你看怎么去用这些API。你觉得去熟悉寄存器的时间比熟悉API的时间多还是少呢？
注重不同平台的代码积累举一反三？我很注重，因为我随时会更换不同的芯片（成本、产能等原因），如何举一反三？但是不管你怎么举，你这个芯片你必须要知道，芯片外设的基地址以及芯片外设的寄存器控制吧？如果你不需要，说明你666了，而对于上层API来说，你压根就不需要关注这个，因为有统一的API给你使用，你压根不需要管下面是CR是怎么配置，接受用RDR，发送用TDR，因为在上层要么send，要么receive。
你STM32的串口驱动从AVR移植过来的，我就问你，需不需要改寄存器，改寄存器之前，你需不需要看手册？而相信如果我把串口驱动从AVR移植过来后，我只需要把寄存器屏蔽，改成USART_xxxx即可，但是你用寄存器就不这么简单了，你必须要知道，从哪里开启时钟，还要去看参考手册，波特率的计算公式，还要看CR的每个bit的定义应该如何配置吧？这就是每个厂家不一样的地方了，因为外设的明明以及波特率产生方法不一致，而在上层API，你只需要调用：BaudRate = 115200即可，你说哪一个方便？哪一个开发效率高?
哥们，我举双手给你点赞！
讨论来讨论去大家都忽视了问题的本质，时间才是问题的关键。
不管你的寄存器方法写得有多好，效率有多高，这些问题你得考虑：
1> 维护问题。肯定有BUG对吧？那么谁了维护？还是你吗？万一哪天你离职了，公司还说谁可以维护你写的代码？对于公司来说维护成本哪个高？
2> 移植问题，跨平台问题，假设哪天公司产品升级，想从F1换成F4，那么F4的相同外设和F1一样吗？寄存器有哪些差异？之前写的寄存器版本代码还能用吗？从公司的角度出发，那个成本要低？
3> 效率问题。SPL效率高，好吧，算吧，寄存器比HAL效率高？OK，我承认，HAL比SPL效率低？好吧，算吧，但你要知道，LL的效率>=SPL库，而LL与HAL完美兼容！LL很多接口都是基于宏定义，基本相当于直接操作寄存器，跟你所说的效率问题相差不大，但那个更有优势，你自己的代码不能保障，别人不敢用，但官方的LL无论可移植性和可维护性都比你的强，效率上，你敢确定你写的比ST官方的好？再说了，代码效率问题和MCU本省新能是相对的好吧？你犯得着用汇编写PC端软件吗？ 你犯得着为F7/F4用寄存器方式来写应用代码吗？从低到高，HAL，SPL，LL可以灵活选择好吧?
4> IDE问题，KEIL编译那是KEIL本身的问题，IAR就没有这个问题，收费方面AC6免费，至于你一定要在LInux这种OS用，好吧，eclipse+插件方式也可以支持。但问题的本质是，这里是开发MCU好吧，不是开发PC端软件，犯得着为了一个MCU上跑的软件非得弄个LInux开发环境来开发吗？非Linux开发环境我还不开心了，典型的脑袋被门夹了！
5> 关于库文档说明问题，你们居然不知道每个HAL库下载包内就已经包含一个CHM帮助文件，里面就有各个HAL接口函数的说明！别拿无知当荣耀好不？库内各种使用DEMO已经各个头文件的注释居然还不能满足你？我只能说明你已经中毒微软太深，一定要弄个类似微软的MSDN这种文档摆在你面前才叫满意，尽管其他各种CHM，DEMO，comment一概无视，任性！牛！
6> 看完以上内容，你还要坚持说，哥就是不爽库开发模式，哥就是想自己动手，从底层一点一滴的来.这只能说面你具有成为大咖的潜质，等你功成名就之时，媳妇早跟别人跑喽。太牛了，果然是英雄！
综述概之，会充分利用各种资源，灵活变通才叫叼！累死的往往是做最底层的！
我说的优化是指的编译器里面的优化算法对于 HAL 和 STD 无效。没有一家的编译器能知道 HAL 里面死代码到底有多少，结果编译出来的代码就臃肿了。你拷贝的一墙的文字我看过了，但这正是我所说的编程练习题。F1 和 F3 的 UART 的确不一样，我也的确有两个版本的驱动，不过这两个版本的驱动差异不大。
当你想要写出一套能横跨多个厂家的 API 的时候，你就会觉得直接操作寄存器能节省多少时间了，不论是编程时间，还是程序运行时间。每个厂家的 API 都是不一样的：HAL 和 STD 都不完全一样，Microchip 的 MCC 和 Harmony 和 ASF 又不一样，TI 还有 Stellarisware，NXP Xpresso 也是一回事等等等等。当你要把一个驱动从一个厂家移植到另一个厂家，本来就没有统一的 API 了，反正都要重新读一遍手册，那么我为什么还要引入这些无谓的代码？我从 AVR 移植串口驱动的确改了寄存器，但是你把寄存器屏蔽改用库函数不也是一回事，只不过多了个隔靴搔痒焉？
我的确有七八个不同的 UART 驱动，但是我的所有驱动上层都用了 POSIX 设备 API，这个标准接口已经存在了三十多年了。我写的应用代码从电脑到树莓派到 STM32 到 AVR 到 AT91SAM 都是一样的，这个是不是比你的做法更省时间，罔论开发可以更高效？这也就是为什么我一直在强调 HAL 和 STD 是无意义的库的原因。
你直接略过了问题的重点：SPL 或 HAL 的抽象度不够，距离硬件太近，没有意义。
你放心，我的教程不会特别针对我的开发板，举一反三应该不会很困难。
第一、没有一家的编译器能知道HAL里面死代码到底有多少
就这一句我就觉得，你真的是研究过编译器的优化算法吗？同时，我在重构自己的库是，为了对比参考，我有看过HAL的库里的详细实现，你说的编译器的优化算法能否举个粟子来看看？起码大家也能做个对比了！
第二，我拷贝的这墙文字居然是编程练习题，看来是我目光短浅，那么我反问一下，如何才不算是练习题，能否举个例子？
第三，操作寄存器，你要不要看参考手册里到寄存器的bit定义（我已经强调了很多次了，拜托你看一下我强调的点啦~），操作库函数，USART_SendByte（xxxx），USART_GetByte(XXXX),的确也许不同的厂家API名字不一样，但是你从ST全系列的单片机里看一下这个API，命名调用完全一样，切换芯片还需要改？就算是切换不同厂家的时候，只需要到相关库文件找SendByte的API即可，这样比操作寄存器的效率高n倍,也许我说的太表面，那我再说深一点，ST的中断寄存器，不同的系列还不一样，中断状态寄存器中的中断标记的清除操作不一定相同，例如STM32F1等只需要把状态位清0即可，也就是说bit是WR属性的，而STM32F7有些中断标志位专门设立了一个清除标志位寄存器WO，也就是说，状态位是WO属性的，你需要给清除标志位寄存器中对应位写1才能清除相关中断标志位，你觉得看参考手册去了解这个居然比直接调用API clear IT penddingxxx 的还要高效？我可以肯定的说，只要接触过这些寄存器的人，都会知道，如果厂家本身封装好这些操作，不管他里面怎么操作寄存器都好，我上面依然用一样的API，这就是为什么在M0~M7甚至是STM8之间移植都这么容易的结果。
第四，你觉得读参考手册，了解寄存器到bit的效率比阅读api文档还要高?那我只能说你独立开发时间太长，习惯了寄存器模式而SDK开发方式的习惯基本没有，因为你不肯阅读api文档，所以就说是HAL和STD的难用而且低效，我想知道你是从哪个方面判定HAL和STD低效的？你反复说HAL跟STD无限接近底层，跟操作寄存器一样，你前面的论点是不是有点矛盾？
我上面引入了例子，你要不要给出一点例子来表达你的观点？空炮没啥用呢！
哥们，你居然说HAL抽象度不够？ 通过HAL可以实现所有STM32跨平台开发，并且HAL与中间件层完全分离，只要使用了HAL，什么USB协议栈，文件系统emFs, 以太网协议栈LwIP,mbed,libJPEG,FreeRTOS,emWin分分钟就可以与HAL无缝集成，什么叫抽象度不够？什么时候那个中间件组件需要指定那块具体型号MCU了？哥们，你对HAL了解不过尔尔。
为了不误会楼主，我去楼主的github看了一下代码~
http://github.com/SushiBits/Lig ... ob/master/src/led.c
楼主，能否给一下你原创的底层代码大家看看，让大家学习一下，正确的操作手法应该是怎么样的？[增加编辑]
http://github.com/SushiBits/DAP42-Firmware/blob/master/system/src/gpio.c
are you sure这就是你传说中的比HAL和STD还要好的底层库?