STM32踩坑:UCOSIII下串口中断服务中使用OSIntEnter函数使程序卡死解决方案

UCOSIII下串口中断服务中使用OSIntEnter函数使程序卡死解决方案

本文侧重于 STM32 标准库,HAL 库可以借鉴,因为该项目是基于标准库做的(因为涉及到保密问题,这里我就不张贴源码进行描述了)。

因项目需求,需要使用RTOS实时操作系统来完成单片机程序的应用开发,今天在串口模块开发完成后自测,功能实现没有问题,问题出在串口在高频数据收发下,会造成整个程序卡死(因为只对串口收发模块做了改动,所以可以直接锁定问题出处,就死在串口收发上),用Debug进行程序调试,发现卡死的程序最终都会跑飞,一直在中断函数HardFault_Handler中死循环。

/**
  * @brief  This function handles Hard Fault exception.
  * @param  None
  * @retval None
  */
void HardFault_Handler(void)
{
  /* Go to infinite loop when Hard Fault exception occurs */
  while (1)
  {
  }
}

在学习了众多资料后,得出了一个结论,就是只要是中断函数,我们都把函数 OSIntEnter 与 函数 OSIntExit 怼起来(这里加删除线的原因是因为,这句话大部分时候是正确的,但有时候还是不管用,不要记住这句话,因为他是不完美的) ,大致形式如下:

void XXX_IRQHandler()
{
	OSIntEnter();

	。。。

	OSIntExit();
}

基于以上的形式,我对串口中断服务函数做了相同的处理,为了避免中断被打断,我还加了函数 OSSemPend 与函数 OSSemPost 来确保串口在数据接收过程中不被打断,在中间还使用了函数 OSQPost 来提交消息队列,把完整有效的数据帧传递到一个任务中进行处理。

在高频的串口数据收发模式下,我在网上查阅了很多资料,然而并没有把问题解决掉,我看有篇文章说有情况下的函数 OSIntEnter 使用会带来很大开销,然后又用 ChatGPT 查了一下,初步判定函数 OSIntEnter 对程序卡死会有一定影响,屏蔽掉函数 OSIntEnter 与 函数 OSIntExit 后,测试,还是会卡死,不过正常使用的次数多了几次,接着把函数 OSSemPend 与函数 OSSemPost 也给屏蔽掉,发现串口高频收发正常了,程序也不会卡死了。

下面是一些chatGPT的截图:

STM32踩坑:UCOSIII下串口中断服务中使用OSIntEnter函数使程序卡死解决方案_第1张图片
STM32踩坑:UCOSIII下串口中断服务中使用OSIntEnter函数使程序卡死解决方案_第2张图片

STM32踩坑:UCOSIII下串口中断服务中使用OSIntEnter函数使程序卡死解决方案_第3张图片

学习分享,一起成长!以上为小编的经验分享,若存在不当之处,请批评指正!

你可能感兴趣的:(STM32学习,stm32,单片机,嵌入式)