中断方式下，arm（嵌入式的linux）读双口ram的驱动中，读ram只能一直处于阻塞状态，只有中断来了才能唤醒读。只能这样吗？

中断方式下，arm（嵌入式的linux）读双口ram的驱动中，读ram只能一直处于阻塞状态，只有中断来了才能唤醒读。只能这样吗？
而不能象单片机的中断那样，来了中断直接进入中断函数进行处理。

初次接触系统的线程设计是吗？

操作系统里面，使用中断线程来实现中断程序功能的。在无中断时，该线程是被挂起的，有中断时被唤醒执行相应功能。

习惯就好。既然系统升级了（从单片机的裸跑到现在的OS），那思维方式也要跟着升级。

谢谢shuiyan 的指教。

如果是“中断时被唤醒执行相应功能”这样的做法的话，那当下一个中断来了，而我还没有处理完上一个中断的数据，这种情况我该怎么办？

还有，一般情况下，中断处理双口ram收发数据的流程是怎样的？谢谢大家指导

DPRAM驱动不是很懂
中断的话要看优先级等其它因素
而且建议不要在中断服务程序中进行太多的数据处理,中断服务程序应尽量简洁,数据处理放到中断触发的其他任务去做为好

一般情况下，中断处理双口ram收发数据的流程是怎样的？

顶，
还请有经验的朋友指教

请教shuiya :
   无中断时，该线程是被挂起的？
    如何实现，例如我现在有个外部中断，在中断来了后，马上实现读写，我的中断中利用了中断上下部分机制，上半部分为具体的读部分，在用户空间线程执行时，是一直组塞在read调用的，只有当中断来临后才马上进入上文进行读取，那这样不是一直阻塞在中断的上文了吗？
    请赐教！
    谢谢！

在中断中不要做太多的事情，越简单越好，这个原则和单片机设计中是一致的。而中断线程才是真正进行中断处理的一段程序。

中断线程，其实已经不是中断程序了，和普通的线程都是同样的等级，会被系统任务调度管理的。在这里面做任何事都不会造成系统阻塞。

不过，正如你所担心的：一个未处理完，下一个来了怎么办？

首先，中断来了，是通知CPU可以做处理了（读写外部RAM），但是并不是说，CPU必须立即去处理。操作的主动权在CPU，中断标志位会被置位，直到中断线程完成一次处理，可以进行下一次处理。

然后，你算一下，以现在CPU的运算速度，到底有多少可能会发生这样的中断事件拥挤？当然，如果你的cpu是从端，对数据的处理没那么快，可能会碰到，不过中断的设计，本来就是为了防止数据处理不及时造成的数据丢失，只要不去处理，中断就一直悬而未决，而数据就一直保持着。这也是双口RAM的一个标准。

双口RAM是为了在两个CPU之间快速交换大量数据的。所以为了防止有误操作，有完善的机制进行保护。

一方获取了RAM的操作权，RAM就会自动产生一个BUSY信号，另一方就无法操作RAM了，直到有操作权的CPU结束此次操作，或者中途释放操作权。

这个就有点类似OS中的资源占用，互斥变量等等了。

在程序设计中，也是判断相应的状态，本方是否能获得RAM的操作权，若可以，就进行操作，若不行，则设好触发条件，将线程挂起睡眠，直到RAM被对方释放，触发“READY”条件，线程才会被唤醒并开始操作RAM。

至于读写RAM就是普通的总线操作了，应该不需要多说了。

回复 楼主 majuncheng 的帖子

可以设置成非阻塞的吧？