免费注册 查看新帖 |

Chinaunix

  平台 论坛 博客 文库
1234下一页
最近访问板块 发新帖
查看: 14189 | 回复: 37
打印 上一主题 下一主题

[中断] Linux中断响应,使用Linux信号传送机制,内核层发送信号至用户层 [复制链接]

论坛徽章:
0
跳转到指定楼层
1 [收藏(0)] [报告]
发表于 2013-06-19 10:42 |只看该作者 |倒序浏览
5可用积分
要求为:ARM外部GPIO接收下降沿硬件中断,在中断回调函数中发送信号SIGIO给用户层,用户层异步接收到信号后在自身回调函数中做出一部分简单处理。
具体要求很简单:外部4mS一个硬件中断(GPIO),如何实时传入Linux用户层,并快速处理,对这个中断事件的处理主要是在用户层的操作(有一些消息分发,进程管理之类的工作需要外部中断来触发)。


内核层可通过kill_fasync异步发送,kill_fasync发送方法网上资料很多,借用即可。

用户层通过signal(MYSIG, sig_handler)绑定信号和回调函数
共一下几个步骤:
        signal(MYSIG, sig_handler);
        fcntl(fd, F_SETOWN, getpid());
        f_flags = fcntl(fd, F_GETFL);
        fcntl(fd, F_SETFL,  f_flags | O_NONBLOCK | FASYNC);
        fcntl(fd, F_SETSIG, MYSIG);//如果要发送实时信号(MYSIG可自行定义),则需要通过fcntl设置
现测试后,发现信号传送正常。如果要周期性的接收信号,比如4mS一个GPIO中断,就需要对应时间里内核发送信号(相同信号)至用户层,用户层及时接收到相应信号。

测试遇到的问题是:周期性的信号交互并不是每次都能实时的响应,会出现中断事件未响应的现象。即GPIO的中断事件并不能在用户层实时响应(4mS的中断并不是很快),对于这种现象,不知道大家有没有好的解决办法,或者能够指出我所犯的错误。

最后在进程中pause等待信号,这样就不会出现中断事件传递过程中丢失的现象,但是在实际应用中又是不能pause的。

另外,为了满足要求,又尝试使用了一下input子系统,使用input_event来上报中断事件,这样起单个进程跑是不会丢失事件的,但是,如果增加几个线程或者进程来调度的话就会出现事件丢失的现象,在优先级方面,处理事件的线程的优先级是最高的。

还望同志们给点意见,谢谢!

最佳答案

查看完整内容

HZ会影响调度时延,更改HZ肯定是有效果的。但调度时延的不确定性,HZ无能为力。实时抢占补丁对内核改动还是非常大的,坛子里没什么人讨论这个补丁啊。

论坛徽章:
0
2 [报告]
发表于 2013-06-19 10:42 |只看该作者
HZ会影响调度时延,更改HZ肯定是有效果的。
但调度时延的不确定性,HZ无能为力。
实时抢占补丁对内核改动还是非常大的,坛子里没什么人讨论这个补丁啊。

论坛徽章:
0
3 [报告]
发表于 2013-06-19 15:03 |只看该作者
这个如果其他进程抢占了cpu, 应该很难保证事件马上会被处理吧。
只能把工作线程的粒度弄小点,然后把这个定时器事件检测整合到事件循环里面去。

论坛徽章:
0
4 [报告]
发表于 2013-06-20 09:18 |只看该作者
回复 2# hmsghnh
谢谢回复!粒度小一些可能会有点效果,但应该不能从根本上解决这个问题吧?如果系统调度过于复杂和频繁,应该还是会出现此类问题的。


   

论坛徽章:
0
5 [报告]
发表于 2013-06-20 10:13 |只看该作者
处理事件的线程在获取cpu后,占用cpu多长时间后,释放cpu?
还有这个处理事件的线程是sched_FIFO,还是SCHED_RR的?
tick应该设置为1ms吧,linux2.6应该能胜任毫秒级的实时吧

论坛徽章:
9
程序设计版块每日发帖之星
日期:2016-02-13 06:20:00数据库技术版块每日发帖之星
日期:2016-06-15 06:20:00数据库技术版块每日发帖之星
日期:2016-06-16 06:20:00数据库技术版块每日发帖之星
日期:2016-06-18 06:20:00程序设计版块每日发帖之星
日期:2016-06-27 06:20:00程序设计版块每日发帖之星
日期:2016-07-09 06:20:00IT运维版块每日发帖之星
日期:2016-07-15 06:20:00IT运维版块每日发帖之星
日期:2016-07-27 06:20:00程序设计版块每日发帖之星
日期:2016-08-18 06:20:00
6 [报告]
发表于 2013-06-20 10:46 |只看该作者
赞同楼上。到了用户态,CPU 啥时给你用就很不好说了。
如果是多核,不妨给这个线程一个独占的核试试看

论坛徽章:
0
7 [报告]
发表于 2013-06-20 11:28 |只看该作者
回复 5# mordorwww
谢谢回复!CPU处理这个线程的时间不会超过4mS,具体操作可精简。线程使用的是sched_FIFO。TICK值更改应该要慎重吧?我也认为,Linux对于处理mS级的实时不应该这么烂。那么,你认为问题的关键是在哪里?
   

论坛徽章:
0
8 [报告]
发表于 2013-06-20 11:30 |只看该作者
回复 5# mordorwww

谢谢回复!ARM仅仅是一个单核A8,没办法单独用一个核来做这个事情。

   

论坛徽章:
0
9 [报告]
发表于 2013-06-20 11:36 |只看该作者
我觉很实时的部分,还是放在kernel层比较好, 剩下实时性要求不高的部分,signal user space去做。

论坛徽章:
9
程序设计版块每日发帖之星
日期:2016-02-13 06:20:00数据库技术版块每日发帖之星
日期:2016-06-15 06:20:00数据库技术版块每日发帖之星
日期:2016-06-16 06:20:00数据库技术版块每日发帖之星
日期:2016-06-18 06:20:00程序设计版块每日发帖之星
日期:2016-06-27 06:20:00程序设计版块每日发帖之星
日期:2016-07-09 06:20:00IT运维版块每日发帖之星
日期:2016-07-15 06:20:00IT运维版块每日发帖之星
日期:2016-07-27 06:20:00程序设计版块每日发帖之星
日期:2016-08-18 06:20:00
10 [报告]
发表于 2013-06-20 12:07 |只看该作者
本帖最后由 mordorwww 于 2013-06-20 12:07 编辑

先排除其它因素的干扰,系统仅处理这个中断信号,其它网络、其它中断等能关闭就关闭,用户态进程也只做信号处理,看看结果如何

如果这个结果是OK的,再逐步添加关闭的东西


有时中断会让你的时延增加
您需要登录后才可以回帖 登录 | 注册

本版积分规则 发表回复

  

北京盛拓优讯信息技术有限公司. 版权所有 京ICP备16024965号-6 北京市公安局海淀分局网监中心备案编号:11010802020122 niuxiaotong@pcpop.com 17352615567
未成年举报专区
中国互联网协会会员  联系我们:huangweiwei@itpub.net
感谢所有关心和支持过ChinaUnix的朋友们 转载本站内容请注明原作者名及出处

清除 Cookies - ChinaUnix - Archiver - WAP - TOP