在智能家居的开发项目中，大多数设备属于电池供电设备，并且多是环境监测sensor，也有DC供电的电灯控制和语音控制等，这些暂不在讨论范围，对于功能单一的终端检测设备来说，成本和低功耗就是最为关键的成本因素，所以ST的低功耗系列STM32L类单片机在这类应用中也是大放异彩，此类单片机成本、外设和低功耗都做得很完善，但对应缺点就是flash容量一般只有几十K，属于小容量的STM32单片机了。
我在刚开始使用STM32CUBEMX生成基本配置代码的时候，功能逻辑基本编写后有一个插曲：容量真的不够了，我就从HAL库里面把必须的寄存器语句摘出来，把冗余的有效检验和冲突判断注释掉，想着这样就可以精简下来。其实也有打算倒回去使用原来的标准库进行开发的，之前一直都是这么干，也没什么难的，可是考虑到一方面HAL库开发是未来的趋势，也为了公司的工程统一便于维护，所以决定把它拿下。
架构示意图
在开发过程中突然发现除了一般常用的“stm32f0xx_hal_”开头的文件，还有“stm32f0xx_ll_”开头的文件，而且这两种文件都是一一对应的，每个模块，GPIO, RCC, CRC, DMA，... ，都有对应的文件。打开看看，跟hal的一对比，发现精简很多。然后意识到这实际上是一个精简的库，于是查资料，原来这是STM32Cube LL库，那时候看起来比较新，是当时ST刚推出来的。于是，果断用它，并做了一下小小的对比。我当时使用的是一款64k的单片机，配置的时候把RTC，TIMER，UART, ADC,DMA和GPIO功能打开，分别用HAL库和LL库生成后，使用Keil 5进行编译后做了对比，编译后结果显示LL库只有HAL库的33%体积。
完美，于是使用LL库完成了剩余的编程工作。LL库基本是基于寄存器的操作，有的模块需要再自己再配置一下。比如Systick在使用STM32CUBEMX之后并不运行，需要Enable一下，并把IRQ打开。
两者比较
当前已支持的MCU
当然，HAL是一个大的趋势（由上图也可以看得出来），它的错误检查和有效检验都是比较严谨的，从一定程度来说，HAL库和STM32cubeMX的配合降低了STM32的开发门槛，我们可以不必过多的关注底层的配置和初始化，而把重心放在应用逻辑的实现上，对于底层的C程序员来说，更高的可移植性会产生更大的软件足迹，或者花费更多的时间来执行改编代码。不过我还是建议大家还是最好弄清楚基本的底层原理和寄存器配置，这些对于嵌入式开发人员来说是基本的能力，当设备运行出现bug的时候，你的bug定位分析能力也会更强。
LL库的配置选择如下：
在STM32CUBEMX中，点击菜单的“Project”-->“Settings”，在下面的界面中选择“Advanced Settings”，然后在每个模块后面选择使用的库
最后做一下总结：
1、如果使用的MCU是小容量的，那么STM32Cube LL将是最佳选择；
2、如果结合可移植性和优化，使用STM32Cube HAL并使用特定的优化实现替换一些调用，可保持最大的可移植性。另外HAL和LL可以部分并发使用(对于同一个外设，HAL和LL不可能并发运行)，也可以使用混合的HAL和LL实现来获得上述相同的优势。
關鍵字: STM32Cube STM32 STM32CUBEMX
