打印

[uCOS/RTOS] Freertos printf可重入的问题

[复制链接]
205|4
跳转到指定楼层
楼主
本帖最后由 wzt19910506 于 2019-11-27 09:45 编辑

调试程序时候常用printf来作为调试日志输出,方便定位问题所在位置。但最近出现一个现象程序运行过程中会出现莫名的异常死机。
但是在死之前有个征兆,观看打印的日志,有两条信息穿插打印的现象。所以才想起来去考虑是不是printf引起的。
在整个项目中我运行的有8个任务,而在每一个任务里面几乎都会有使用printf进行调试信息打印。所以从开始就埋下了一颗定时炸弹。只是要碰下运行,运气好的时候一切风平浪静。运气不好的时候就炸的异常到处横飞。
在看下自己代码printf重映射的fput接口用的还是HAL_UART_Transmit 阻塞发送函数接口。这样在波特率为115200的情况下,假如打印一条200bytes的日志信息就要约等于19ms的时间。这岂不严重影响其他任务的实时性。
所以先把fput改为非阻塞的形式,这个可以使用freertos的stream_buffer,这个可以把要发送的数据压入buffer,然后真正的发送就使用串口发送为空中断从stream_buffer一个个byte进行读取发送。这样可以保证调用printf——》到fput 就只是写stream_buffer。而不再是阻塞式调用一次printf就要等待串口完全把数据发送完。fput的代码如下:
  1. int fputc(int ch,FILE *file)
  2. {
  3.     xStreamBufferSend(streamDebug,&ch,1,1000);
  4.     __HAL_UART_ENABLE_IT(&DEBUG_UART,UART_FLAG_TXE);   
  5.     return ch;
  6. }
复制代码

本以为把阻塞改为非阻塞,这个bug解决完的美妙心情就要到来了的时候,按下了复位按键,啥?运行了还没10秒钟就又死了,甚至比之前更惨烈。
而现在调用printf的最关键的一条代码就是xStreamBufferSend() 只能默默的打开freertos的参考手册,看下stream的详细描述。而在注意里面有下面一段话:
有多个不同的writers或者多个不同的readers是不安全的。也就是说在多个不同的任务中调用发送就会有可能有问题。这不正符合了我现在的场景,多个任务可能同时调用printf,相当于多个任务同时调用stream的write接口。
stream有这个限制,那注定printf就是不可重入的了。而针对不可重入的资源最简单的办法就是用互斥量进行?;?。所以我就把printf进行包装了一层取名为debug_printf:
  1. void debug_printf(const char *fmt, ...)
  2. {   
  3.     va_list args;
  4.     if(xSemaphoreTake(semDebug,portMAX_DELAY);
  5.     va_start(args,fmt);
  6.     vprintf(fmt,args);
  7.     va_end(args);
  8.     xSemaphoreGive(semDebug);   
  9. }
复制代码

当调用debug_printf的时候先去获取信号量semDebug,如果获取不到就一直等待直到获取。该函数执行完毕以后再释放信号量。这样就充分保证了资源的独占,同时只可能有一个任务再进行debug_printf。需要说明的是vprintf底层最终还是会调用我们重映射的fput函数。
再次上电,打印终于正常了,但是,还有但是……一波未平一波又起??氖焙蚴О芰?,开锁任务是一个需要实时的任务,要检测传感器转动位置。而这个异常明显是实时性得不到满足。
仔细分析下,问题就出在printf互斥量的获取。有可能造成高优先级任务产生延时,甚至造成优先级翻转。
假如有三个任务:任务A、任务B、任务C,优先级从低到高。现在任务A调用了debug_printf 获取了信号量,而高优先级的任务C也需要调用debug_printf,但因为获取不到信号量就会造成暂时挂起,等到任务A打印完成把信号量释放了任务C才能得以运行。这样高优先级的任务无法抢占低优先级任务而降低了实时性。如下图所示:

上图的是一种情况,还不算最坏的?;褂锌赡艹鱿钟畔燃斗奈侍?,造成延时更大。同样最低优先级任务A先运行并且调用了debug_printf获取到了信号量,而这时候任务c也需要运行并调用了debug_printf。但是因为A已经把信号量占用而无法获取到,所以暂时被挂起。任务A开始打印,在打印到一半的时候,被中等优先级的任务B给打断了(任务B不调用debug_printf所以可以打断A)。这时候A又挂起了,任务B开始运行,等到B运行完以后继续运行A。等A运行完信号量释放了,高优先任务C终于可以得到运行了。如下图所示,这时候看看任务C本来可以实时的运行的,现在却中间又穿插先运行了中优先级任务B。造成一个中优先级比高优先级任务先得到运行的优先级翻转现象。而实时性相比上图就更差了。
并且这个延时是不可估量的,想想任务B还可能再被更高优先级的任务打断。高优先级任务C反而被一再延时执行。所以出现高优先级任务出现问题就不难理解了。

发现了问题还是要解决问题。根据分析肯定要改造一下debug_printf,同时为了实时性得到满足。我就把任务C高优级的打印LOG暂时关闭。
而针对debug_printf中获取信号量修改为有时间限制,不再无限期等待。这样顶多出现获取不到信号量5ms超时返回少打印一条log信息,总比把任务卡出异常要好的多。改造后的debug_printf如下:
  1. void debug_printf(const char *fmt, ...)
  2. {   
  3.     va_list args;
  4.     if(xSemaphoreTake(semDebug,5)==pdFALSE)return;
  5.     va_start(args,fmt);
  6.     vprintf(fmt,args);
  7.     va_end(args);
  8.     xSemaphoreGive(semDebug);   
  9. }
复制代码
转载请注明转自:电子创客营
欢迎关注我们的公众号 [电子创客营] 获取更多技术分享!

使用特权

评论回复
沙发
| 2019-11-29 10:34 | 只看该作者
信号量是根本

使用特权

评论回复
板凳
 楼主 | 2019-11-30 23:09 | 只看该作者

信号量只是解决问题的一种办法而已,根本是对不可重入资源的互斥访问

使用特权

评论回复
地板
| 2019-12-2 10:28 | 只看该作者
wzt19910506 发表于 2019-11-30 23:09
信号量只是解决问题的一种办法而已,根本是对不可重入资源的互斥访问

信号量最主要就是解决这个问题的

使用特权

评论回复
5
| 2019-12-9 15:01 | 只看该作者
本帖最后由 七颗咖啡豆 于 2019-12-9 15:02 编辑

噗?。?!,要这么复杂。

使用特权

评论回复
扫描二维码,随时随地手机跟帖
*滑动验证:
您需要登录后才可以回帖 登录 | 注册

本版积分规则

我要发帖 投诉建议 创建版块 申请版主

快速回复

您需要登录后才可以回帖
登录 | 注册
高级模式

论坛热帖

关闭

热门推荐上一条 /5 下一条

在线客服 快速回复 返回顶部 返回列表
快3注册邀请码tt 保定市| 翁源县| 美姑县| 将乐县| 交口县| 嘉禾县| 习水县| 额济纳旗| 望谟县| 青铜峡市| 伊金霍洛旗| 鱼台县| 子长县| 科尔| 布拖县| 邵武市| 图们市| 宁国市| 昆山市| 博乐市| 盐亭县| 松江区| 天水市| 郸城县| 闻喜县| 盐亭县| 东光县| 仙游县| 剑阁县| 琼结县| 高陵县| 广平县| 孙吴县| 承德市| 荥经县| 民丰县| 贡嘎县| 建德市| 潞西市| 保康县| 巴里|