本帖最后由 yanhaijian 于 2019-3-13 17:23 编辑
转眼工作十年了，这十年我见证了ST微控制器的起步、发展、崛起以至现在牢牢占领着微控制器的半壁江山。
刚毕业的时候使用其他品牌的单片机，这些单片机不同型号的手册都是不同的，这就导致简单的串口程序同一个系列的不同型号单片机之间可能都不兼容。后来STM32F1开始起步，这种微控制器价格低，能够在线擦写，使用通用的编辑、编译器，同一系列驱动移植方便，通用的烧录、仿真器，资料多，购买渠道多，需要什么资料可以在STMCU中文论坛上面找到，有文档有例程，用户手册还有中文版本，多么贴心，简直就是个暖男。一时间大家都在研究STM32，买开发板看配套资料，我也买了神舟系列开发板研究，学习如何驱动液晶屏，学习CAN总线、FSMC总线，许多外设以前都没有接触过，现学现卖，使用STM32F1做了人机接口。
后面ST推出了固件库，又是行业中的一个突破，更是让一批工程师认定了STM32。以前写串口驱动需要使用计算器计算相应波特率对应的寄存器值，现在不需要了，你只要填充波特率固件库自动帮你算好，惊喜不惊喜，神奇不神奇，当然ST固件库的优势还不仅仅是这些，谁用谁知道。
固件库后面ST推出了HAL库（我的理解HAL库是对固件库的再封装），但是一直到现在我个人认为HAL库还有很大的改进空间，比如对操作系统多任务的支持，一些驱动的框架也需要改进。比如STM32Cube_FW_F1_V1.6.1中CAN发送和接收函数都加了锁__HAL_LOCK()（__HAL_LOCK()是一个宏定义，判断如果锁被占用了则调用函数直接返回），一般情况下大家会在CAN中断服务函数的接收回调函数中调用CAN接收函数，如果在CAN发送期间有CAN接收中断将导致CAN接收函数直接返回，CAN数据没接收到接收中断还被关闭了，一般对HAL库不太精通的工程师需要花费很长时间才能找到这个问题的根源，实际上CAN的发送和接收在驱动层面类似全双工（物理层面是半双工），但是HAL库实现起来硬生生的搞成了半双工。STM32Cube_FW_F1_V1.7.0中针对这个问题进行了修正，但是接收、发送接口函数发生了改变，不能兼容之前的版本。
HAL库之后ST又做了图形化编程工具STM32CubeMX，正是这款广受好评的工具确立ST在微控制器领域的绝对领导地位。起初对STM32CubeMX不太了解，当遇到要配置驱动时就在STMCU中文论坛搜索“HAL库每天一例”，学习前辈们是如何配置的，STM32CubeMX明显缩短了产品的开发周期。STM32CubeMX5以后明显不如STM32CubeMX4，STM32CubeMX5一屏显示的内容过多，对于14寸笔记本来说是个灾难，还有各种各样的BUG，比如STM32CubeMX5.0.1不支持汉字路径的显示，GPIO配置界面引脚较多显示不下时不能上下翻转页面浏览所有引脚，生成工程时报错等等，这在STM32CubeMX4时都是没有的现象，希望ST能够做好软件内测。
|
楼主
标题置顶
标题高亮
