第三，操作寄存器，你要不要看参考手册里到寄存器的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> 维护问题。肯定有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还要好的底层库?