技术专栏
unknow Hi-irq triggered
该打印只是起提醒作用,并非错误。
主从级联应用场景中,主从之间完成一个消息的通信过程如下:
从侧发起一个消息写,随后触发主侧一个中断,主侧响应中断,在共享内存区中取得消息;接下来主片可能会回复消息给从片,采用同样的程序,先写消息到共享内存,然后触发从侧中断。从侧进入中断服务程序,处理已经存在共享内存的消息。
按照最初的想法,本侧每次向对端提交中断的时候,先查看对端中断状态,若中断状态未被清除,则等待,待对端中断处理完毕,再触发对端中断。这种方法能保证一个消息,一个中断,但会造成对端频繁进入中断服务程序,效率较低。为提高消息交互的效率,考虑以下方法,对实时性要求较低的消息,通过定时器对多个消息进行一次性处理。每次发送消息后,即使上一个中断还没有被响应,触发对端中断时不需要等待对端的中断状态被清除,直接提交中断。这样就存在一种情况,本侧发送一个消息过去后,写了对端的中断,但还没来得及触发对端中断,这个对端的上一个中断刚好正在处理,顺便也把本次发送的消息给处理了;这个时候对端的中断状态也被清除了。等到本侧触发对端中断的时候,对端在检测中断状态的时候,却没有找到相应的中断状态标志,于是就打印了上面那个信息(“unknow Hi-irq triggered”)。
以上这个机制经过深入分析,不会导致丢消息,也不会有其他异常!
声明:本文内容由易百纳平台入驻作者撰写,文章观点仅代表作者本人,不代表易百纳立场。如有内容侵权或者其他问题,请联系本站进行删除。
红包
点赞
收藏
评论
打赏
- 分享
- 举报
评论
0个
手气红包

相关专栏
-
浏览量:897次2024-08-27 10:56:56
-
浏览量:5176次2020-08-11 17:39:02
-
浏览量:1046次2023-12-29 15:07:00
-
浏览量:4360次2018-05-25 21:45:17
-
浏览量:4147次2020-08-31 08:41:19
-
浏览量:8676次2020-09-05 15:06:28
-
浏览量:3493次2020-08-19 18:32:47
-
浏览量:4674次2020-07-27 16:34:42
-
浏览量:3852次2017-11-16 18:17:23
-
2023-06-12 14:35:55
-
浏览量:917次2023-12-06 14:42:44
-
2023-10-18 14:44:59
-
浏览量:3877次2020-08-19 18:27:30
-
浏览量:9718次2020-09-20 00:22:59
-
浏览量:3992次2020-08-30 09:57:38
-
浏览量:10378次2021-12-31 09:00:12
-
浏览量:5224次2017-11-15 11:09:58
-
浏览量:2004次2020-09-13 21:38:58
-
浏览量:7256次2021-07-29 14:18:58
置顶时间设置
结束时间
删除原因
-
广告/SPAM
-
恶意灌水
-
违规内容
-
文不对题
-
重复发帖
打赏作者

JZ_hacker
您的支持将鼓励我继续创作!
打赏金额:
¥1

¥5

¥10

¥50

¥100

支付方式:

举报反馈
举报类型
- 内容涉黄/赌/毒
- 内容侵权/抄袭
- 政治相关
- 涉嫌广告
- 侮辱谩骂
- 其他
详细说明
审核成功
发布时间设置
发布时间:
请选择发布时间设置
是否关联周任务-专栏模块
审核失败
失败原因
请选择失败原因
备注
请输入备注