stm32hal回调

STM32HAL轮询模式串口接收函数超时等待问题？

是的，HAL里面这个HAL_UART_Receive()函数已经明明白白地写了，它是阻塞式查询工作方式，只要标志不置位或者超时不结束，就干等到天荒地老。

如果你不需要阻塞式查询工作方式，就应当选用中断工作方式，改用 HAL_UART_Receive_IT()函数并配置对应的NVIC模块、调用对应的中断服务函数并且钩上对应的回调。

STM32 利用Hal库实现UART中断处理

实验室项目需要使用STM32开发，Hal库的资料相对较少，关于UART中断与之前使用飞思卡尔芯片的中断不同。

首先在CubeMX中配置好UART中断；重点是：需要在主循环之前手动开启接收中断：

只有手动开启之后才能进入中断。

此外，HAL库中，无论何种类型的UART中断，都会进入：

在此函数中判断具体是何种中断，再调用相应的中断服务函数，接收中断是：

而此函数会调用：

最需要注意的一点是：

在回调函数最后需要再次开启中断！！否则只能执行一次！！

个人理解 这里将中断服务设置为等待模式 等待接收字符。

在Keil中进行断点调试 发现接受字符后会首先进入

HAL_UART_IRQHandler

函数，而不是直接进入 UART_Receive_IT 函数进行处理

相当于UART中断服务程序有一个统一入口

HAL_UART_Receive_IT(huart1, (uint8_t *)aRxBuffer, 1) 语句相当于打开这个入口，经测试如果去掉这句的话，再发送字符是不会进入HAL_UART_IRQHandler语句的。

刚开始接触STM32与HAL库函数，理解肯定不是很到位。

参考自：

细究STM32 HAL库的中断式串口接收

当使用HAL库中断式串口接收，除了在NVIC中使能全部串口中断，我们还需要使用 HAL_UART_Receive_IT(UART_HandleTypeDef *huart, uint8_t *pData, uint16_t Size) 来使能串口接收中断。

该函数请求UART句柄 huart ，接收数据缓存区 pData ，以及期望接收的数据个数 size 。

进入到该函数中，首先会确保huart处于空闲状态，否则返回 HAL_BUSY ，同时校验参数 pData 和 size 的合法性，视情况返回 HAL_ERROR

随后使用宏 __HAL_LOCK() 锁死huart，这样huart在释放前被调用时，返回 HAL_BUSY

后面是关于接收模式，接收超时中断的一些设置，并不重要，在程序最后return时调用了 UART_Start_Receive_IT(huart, pData, Size) ,进入下一层，该函数是整个中断注册的关键。

进入 UART_Start_Receive_IT(); ,首先是把接收数据缓存区以及接收个数传递给句柄huart， 清除掉接收中断服务函数指针 ，以及进行一些必要的设置。

随后会根据USART的设置来选择不同的中断服务函数

得到4个中断函数，我们研究相对简单的8倍过采样RxISR

在接收ISR中，配置好Mask后，如果UART有数据，则会读 RDR 数据接收寄存器，反之直接清掉 RXNE 标记位.

重点在于后面的判断语句，这也是整个HAL库中断式串口接收的阴间之处

在确定读取到预期数量的数据后，会直接 失能RXNE串口接收中断 ，同时 也清理RxISR函数指针 ，回调 接收事件函数 HAL_UARTEx_RxEventCallback(huart, huart-RxXferSize); 和 接收完毕函数 HAL_UART_RxCpltCallback(huart);

那么这个RxISR是在哪里被调用的呢？答案在 void USART1_IRQHandler(void) 中的 HAL_UART_IRQHandler() 中

如何正确使用HAL

HAL（硬件抽象层） 初始化

2 HAL IO 操作流程 -- HAL functions 与内部数据处理类似发送/接收，读/写. 提供三种处理模型 a Polling mode 查询模式，HAL函数在数据处理完成（阻塞）后返回处理状态（ok or err）,可以通过HAL_PPP_GetState()获取具体错误信息 img src="d99d3f80-e264-472f-a9db-a088dc0c5c20_files/6ae88b28-8824-40a4-a8ea-71c3b1b5a415.png" border="0" alt="" style="font-size: 10.5pt; line-height: 1.5;" name="" width="416" height="205" b Interrupt mode 中断模式，启动数据处理并开启了相应中断后返回处理状态；该模式下，驱动程序声明了4个函数 • HAL_PPP_Process_IT(): 启动中断处理，一般在用户文件中 • HAL_PPP_IRQHandler(): 全局外设中断，一般在stm32f0xx_it.c中 • __weak HAL_PPP_ProcessCpltCallback (): 有关处理结束回调函数 • __weak HAL_PPP_ProcessErrorCallback(): 有关错误回调处理 __weak 弱声明，用户可以在应用中重新实现

c DMA mode 使能相应的DMA中断并启动DMA处理数据后返回处理状态；操作结束后调用回调函数通知用户处理完成；该模式下，驱动程序声明了4个函数： • HAL_PPP_Process_DMA():启动DMA过程，一般在用户文件中 • HAL_PPP_DMA_IRQHandler():外设使用的DMA中断，一般在stm32f0xx_it.c中 • __weak HAL_PPP_ProcessCpltCallback():有关过程结束回调函数 • __weak HAL_PPP_ErrorCpltCallback():过程错误回调函数 如果使用DMA模式，通常在HAL_PPP_MspInit()回调函数中执行DMA初始化

rt-thread移植finSH控制台中STM32 HAL库的缺陷

小小的一个串口居然看了半天，原来对STM32系列的lib库，好像是1.x版本感觉还不错的。后来ST非要整个CUBEMx库，往一个中断接受函数里丢了一堆东西。

在rt-thread官网中给出了nano版本增加控制台的示范例程，主要是增加了一个接受队列。(如果用rt-thread studio配置控制台，接受好像用的是查询模式，如果只是单纯一个控制台，不干其他事情好像也没啥事)

用中断模式+接受队列接受大量数据可能会更健壮可靠些。问题是实验了几次，只要在串口助手中发送了2个字节，中断接受就出现问题，再也进入不了中断函数了。后来关闭了控制台的echo回应功能，居然神奇的好了。

多半定位到是串口发送导致的。原来这是ST的HAL库的bug，在串口发送中进行了互斥操作，导致有接受中断时不能再次启动接受中断。如下

国外论坛也有这个讨论

[ ]

在中断回调函数中加入个unlock就好了。

当时是注意到RTT官方的文档中断发送函数中有unlock操作，看来接受 也得加个

stm32HAL库串口回调函数怎么判断桢头

stm32HAL库串口回调函数，用两种不同的帧头的数据判断桢头。

用串口中断接收两种帧头的数据，1. 以0x0D 0x0A为帧头的数据。2，以0x55 0xA5为帧头的数据。两数据包帧头不同,大小不同。首先串口接收中断是以一个字节为单位接收数据，然后串口接收处理部分全都写在的回调函数中。

STM32F103器件采用Cortex-M3内核，CPU最高速度达72 MHz。该产品系列具有16KB ~ 1MB Flash、多种控制外设、USB全速接口和CAN。ST在后续几年陆续推出了Cortex-M0+、Cortex-M4内核的芯片，并进行不断优化。