[资料]

关于中断架构在raw os 中的设计

2013-2-27 14:23:35 3858

0 由于中断在系统中的特殊作用，历来被os设计者一直所看重。raw os 系统内核最大关中断时间在S3c2440平台上实测为8.2us, 虽然不是皎皎冠军，但是也不至于落到最后。本人一直认为整个应用系统的最大瓶颈是在中断的驱动架构这里，只要抓好这个整体，系统的最大关中断时间是可以控制在10 us以下的。落眼于系统设计的架构，抓住事物内部的主要矛盾，从宏观角度处理问题比微观更为直接有效。为了设计raw os 的中断架构，首先要对中断的紧迫性和中断处理的时间做好划分。一般认为越快的中断，意味着时间越短，紧迫性越高。比如高速的gpio 中断可以很快。像串口这样的中断是很慢的。其次必须认识清楚发生中断后，中断处理需要的时间是多长，时间长的和时间短的处理方式不同。整体来说在raw os中总共有3种设计的方法：第一种假如中断处理的时间很短，这样的话直接可以在中断里面完成，这个是很容易理解的，和传统的操作方式是一样的。但是前提是中断处理的时间一定要足够短和足够快。第二种是中断处理的时间长，但是时间紧迫性不高，这样的话可以采用protothread的方式去解决这个问题。Protothread 是跑在raw os 的idle 任务中的，优先级是最低的。而且采用的是事件处理的方式，整个中断处理过程是不需要关中断的。第三种是中断处理时间长，紧迫性也高。这个时候可以开一个最高优先级的任务，比如优先级为0的任务。优先级为0的任务处于queue 的阻塞接收中，接收的信息是中断号，硬件中断来了之后发中断号消息给这个任务，同时清除interrupt pending 位，然后退出自动运行该任务。备注：紧迫性更高的中断可以甚至发消息到头部，直接插队^_^. 大概流程如下： Isr() { 发送中断号给最高优先级任务(0) 清除自身的中断pend 位 } Hightest_priority_task() { While (1) { 接收消息队列中的数据，即中断号。（无消息则阻塞queue）根据中断号处理相应中断。 } } 以上Hightest_priority_task 中断是始终打开的。总结，通过以上的设计后，系统驱动最大的关中断时间可以达到最小，而且是最自然的处理中断方式，对于芯片公司提供的驱动可以不需要任何修改，直接可以上面使用，只要遵循以上的设计架构。 0
举报淘帖0 只看该作者相关推荐 • Raw-OS移植到TMS320F28335处理器的感想 2597 • 请教RAW OS移植到stm32中 6851 • raw-os 以及micro raw-os的开发仓库 6420 • Raw-os 技术汇总 6762 • 基于raw os 的事件触发系统 5842 • raw os系统最大关中断时间为0us的原理 6058 • 关于raw os 的强实时性 5145 • raw os 支持了idle 任务级别的事件驱动框架 4892 • Raw os 移植篇 5351 • Raw os 内核调度篇 4191