RTLinuxPro处理器预留和中断控制技术.docVIP

　　RTLinuxPro处理器预留和中断控制技术|第1 ...同类技术中，其它方法的重点是放在对中断响应时间的提高方面。其工作本身是有探索价值的，但取得的结果却很有限，只是在一个特定LINUX版本和硬件体系结构下使中断响应时间得到了改善，仍然没有硬实时方面的保证。同时，采用这些方法的操作系统提供给编程者的服务也十分有限。尽管对于某些基础应用，如频繁的采样和对采样信号的简单快速响应的场合，这些方法是有效的，但多数情况下，却反映出现实中的应用领域根本就不是那么地简单。 500)this.style.ouseg(this) 特定CPU上的线程引导 先来看一个实时线程如何将自己装入一个给定的CPU的例子。 ----此处放L1---- 这里没有什么新的东西，一个新的线程产生，就像其他任何的POSIX应用一样。区别只是这一行——“pthread_attr_setcpu_np(attr, 0);”。这句告诉RTCore当新的线程创建的时候，应该把它放到CPU 0中，而且永远不会从CPU中被清除掉。原因在于当一个线程/任务被允许从一个处理器转移到另一个的时候，高速缓存(Cache)的影响会改变实时性能。如果知道了在什么样的CPU上都有哪些线程，那么就可以把这种转移的影响降低到最小，实时性能也会得到显著提高，同时RTOS的调度负荷也降到了最低。 500)this.style.ouseg(this) 另外一个比较新的东西是“timespec_add_ns(next,1000*1000);”，这句给timespec结构体增加了一个毫秒，它是为了方便起见而提供的一个函数(POSIX并没有定义这个函数，所以用户通常要手工规格化一些数据)。如果用户熟悉RTLinux，就不应该对这个函数感到陌生，它已经用了好几年了。RTLinuxPro的用户应该注意到这个函数：rtl_main_p;attr, 0); pthread_attr_setreserve_np(attr, 1); pthread_create(thread, NULL, thread_code, 0); ... “pthread_attr_setreserve_np(attr, 1);”这句设置了线程的一个布尔属性。当在特定处理器上产生了一个线程后，只要该线程存在，GPOS就被禁止在这个处理器上运行。 实际上也是如此的，一旦这条语句被执行，GPOS就被禁止在处理器上面运行了，只能为创立的线程保留CPU(包括运行在CPU上的其它实时线程)。在有些情况下，允许所有的实时应用程序直接保留在处理器的高速缓存中。由于处理器不用再去RAM中取代码了，所以处理器的性能相对得到了提高。因为GPOS永远不会在Cache中运行，从而不会把实时代码挤出Cache，所以Cache永远都被实时代码占据。(Linux相当庞大，一旦运行起来就会占据很大的Cache空间)。 中断控制 在上面的代码中，为实时代码保留CPU会对其上的GPOS中断产生负面的影响。由于Linux不在其上运行了，不能接受中断了，所以对于其他设备，如以太网设备这样的硬件就只等通过另外一个CPU为Linux提供信号了。这样就使得保留的处理器不处理任何除了产生实时线程以外的任何中断。 现在处理器完全在实时线程的控制下了，我们再次把重点放在处理器上所感兴趣的实时中断上。对于线程，由于可控的高速缓存的作用而使得结果的性能更好，同时也使得中断控制器被激活的次数达到最小，只需要处理很少量的中断了。 下面看一下如何处理这个问题，由于POSIX处理不了中断，所以必须要有专门的RTCore函数来处理它，首先，我们在函数的前面定义一个counting中断句柄： ... static int interrupt_count = 0; unsigned int interrupt_handler(unsigned int irq, struct rtl_frame *regs) { interrupt_count++; rtl_global_pend_irq(irq); return 0; } ... 然后把它加入到线程代码中，重新关注一下CPU 0的中断： ... static unsigned long affinity = 1; static unsigned long old_affinity; void *thread_code(void *t) { struct timespec next; rtl_request_irq(4, interrupt_handler); rtl_irq_set_affinity(4, affinity, old_affinity); ... 在这里，有一个非常基本的