中断线程化的设计实现
目前几乎所有的rtos中断都是在中断上下文中处理的。即使raw-os提供了中断下半部的机制，中断上半部也是在中断环境中处理的。目前问题是，有的任务可能比有一些中断的优先级还要高，并不是所有的中断优先级都是很高的。比如某个任务执行当中不允许被中断打断，将如何去实现？还有一个问题是有一些用户的中断代码由于一些历史原因的设计导致中断内执行的代码实在太多，严重影响了整个系统的实时性，如何花最小的代价去改善这一块的实时性？以上提出的两个问题可以采用中断线程化的思想去解决。解决方案大致如下：
1 内核开启几组高优先级的任务，安排给不同优先级的中断。比如开启一个优先级为 10 的任务处理一般优先级的中断。开启一个9优先级的任务处理高优先级的中断。
2 中断服务程序内只发送一个消息，唤醒外面的任务来处理中断服务程序。这样整个中断上下文的环境时间是固定的，而且非常迅速，消耗只有一个内核api队列的发送函数而已。
通过以上的措施可以迅速的改进一些历史遗留驱动中中断时间太长的缺点。通过把中断的整个处理过程搬到外面去处理，也保证了一些更高优先级任务不被无关中断打断，从而实现了系统更高的实时性。
总结，以上的介绍更侧重在整个应用系统的设计思想，具体的实施方案可以灵活实现。 问题1、比如某个任务执行当中不允许被中断打断，将如何去实现？
可以使用进入临界状态，即关掉全局中断
问题2、有必要对代码进行分段，如状态机或切成几个小任务。
楼主，你好！
我清楚你提出的两个问题，但是我不理解你后面提出的解决方法，能否再具体说明一下吗？
本帖最后由 lulu爱 于 2014-11-29 19:19 编辑
tarzar 发表于 2014-11-29 14:07
问题1、比如某个任务执行当中不允许被中断打断，将如何去实现？
可以使用进入临界状态，即关掉 ...
关掉全局中断，实时性马上没了，因为中断都响应不了了，因为可能有的中断优先级更高，必须要实时响应，也就是说高优先级中断的任务会抢占低优先级中断的任务。分成状态机的一般是裸机的做法。 支持，在有OS的情况下，除非有实时性要求的，中断处理就应该只产生消息，处理交给任务做。 一般rtos都推荐这样做么，有些代码段不允许被中断的只能关中断没办法
页:
[1]