也许在嵌入式领域，不选择Linux的原因主要有两点吧：
1、不容易上手，不容易开发，维护成本高，工作量大....
2、实时性差
这里暂且不说第一点。现在，很多人都在讨论Linux实时化的问题。做工程的人，能选择的可能就是RTLinux、RTAI也或者是其他实时Linux等东西。这里，我把我今年年初，用了3个月的时间，在香港理工做的一些研究拿出来和大家分享吧。我也很希望这些工作能实际用在我们的产品上，创造出实际的价值，而不仅仅是为了发paper。
论文（~cszlshao/Papers/RTSS-07.pdf）是2007.12.3，发表在RTSS'07（）上的文章。有幸可以在RTSS上发表论文，可以说是2007年我最大的收获（这里，我还是忍不住感谢香港理工邵老师对我的指导）。
这里大体说一下思路。Linux的实时性差主要因为两个问题：
1、调度算法————这个在2.6内核下加入的抢占，还能好一点
2、中断响应速度太慢————主要是因为某些情况下，关闭中断时间太长
RTAI（或者RTLinux）采用的方法是，用软件接管了中断的控制。让实时中断可以得到及时的响应。在此基础上，在Linux内核之外，又加了一层实时调度的内核。Linux内核是运行在这个实时系统上的优先级最低的任务。因此，实时任务和中断就得到了保证。不过，在非x86的体系下，RTAI有很多问题需要解决。按照我在ARM上移植的经验，确实遇到不少麻烦。而且，中断程序入口的复杂，给中断响应本身也带来了更多的不确定性。
我的思路和RTLinux的原理基本类似，但是，我利用了ARM处理器本身的特点。ARM（我只看过ARMv4 ARMv5 ARMv6的体系）处理体系本身提供了两个外设中断入口，FIQ和IRQ。通常的操作系统，Linux、winCE、Vxworks仅仅使用了一个中断IRQ。而FIQ在这些系统的ARM移植体系下，基本都是没有使用的。FIQ是比IRQ优先级更高的中断，它可以抢占IRQ甚至其他的ARM异常（具体可以参考ARM体系）。这就在硬件上为我们提供了一个实时中断的入口。利用这个思路，我在Pxa270的处理器上，Linux 2.6.9内核上实现了这个想法。并且，采用uC/OS-II实时调度内核来调度Linux，解决Linux的实时化的问题。我最后的试验结果证明，在ARM体系下，这种方法，带来的中断延迟和确定性，会比RTAI提高很多。另外，我也讨论了Cache-Locking技术对实时性的影响。
阅读(1669) | 评论(2) | 转发(0) |
