RTAI LXRT下 hard real time应该注意的几点

原载RTAI SPACE：http://justin8086.cublog.cn,转载请联系作者并注明出处。 RTAI/LXRT 为在用户态下实现硬实时控制提供了可能，这是其他系统或是系统模块没有的。RTAI开发者也更倾向于在用户态下完成原来必须在内核态才能做的任务。 原载RTAI SPACE：http://justin8086.cublog.cn,转载请联系作者并注明出处。 但值得注意的是，在充分利用（或者说是享受？）这一先进特性的同时，我们的程序员需要留心以下几点，避免进入LXRT就是无敌万金油的误区： 原载RTAI SPACE：http://justin8086.cublog.cn,转载请联系作者并注明出处。 1、所谓的LXRT实即Linux Real Time module，不存在LXRT scheduler。RTAI下只有3种调度器,UP,SMP和MUP。LXRT的存在使得RTAI所有的调度函数都能在Linux进程中直接调用。这样一来，RTAI的实时服务就具备了所谓的“完全对称”——在RTAI域和LINUX域中的使用几乎完全一样。也就是说，用户可以在LINUX和LINUX间，RTAI和LINUX间共用内存，发送消息，调用semaphore或时间相关服务，当然，在RTAI和RTAI之间更不是问题。（源自DIAPM RTAI - Beginner's Guide，https://www.rtai.org/index.php?module=documents&JAS_DocumentManager_op=downloadFile&JAS_File_id=32）   2、LXRT声称提供用户态下硬实时，但LXRT下的hard real time还是与内核态任务的执行有着本质区别的。RTAI通过其RTAI_PROTO为用户态下进程提供调用内核API的捷径，并由RTAI自身的调度器保证了RTAI任务对中断的优先权。处于中断处理链条终端的LINUX因此不能破坏RTAI任务的实时性能。 原载RTAI SPACE：http://justin8086.cublog.cn,转载请联系作者并注明出处。 但无论如何，天下没有白吃的晚餐，context switch是需要时间的。 原载RTAI SPACE：http://justin8086.cublog.cn,转载请联系作者并注明出处。 在RTAI域内用户态和内核态的切换也免不了牺牲一定的时间开销。RTAI相关的文档指出LXRT下的硬实时相对于内核态下而言仍有若干微秒的差别。笔者也在试验中发现，前者实时性能与后者相比相差约有十几微秒，有时甚至更多。对于一些要求苛刻的实时任务而言，LXRT下的时延（或者还有实时误差？）是无法接受的。 原载RTAI SPACE：http://justin8086.cublog.cn,转载请联系作者并注明出处。 3、在进入和离开LXRT域这两段时间，系统的实时性是无法保证的。也就是说，在时间轴上的这两个区间，所有LXRT任务并非处于真正的硬实时状态，期间任何操作都有可能因其不稳定性导致10～20微秒的实时误差（具体数值未做严密测量）。这一点在RTAI自身文档中也有阐述，但因为不引人注意，使得基于RTAI/LXRT的实时控制开发人员非常容易忽略。 原载RTAI SPACE：http://justin8086.cublog.cn,转载请联系作者并注明出处。 对这一问题的最简单处理办法就是在调用rt_make_hard_real_time()后随即插入短暂的等待，再进入实时处理阶段。实践中笔者在等待500微秒后得到理想的实时表现。 原载RTAI SPACE：http://justin8086.cublog.cn,转载请联系作者并注明出处。 总之，RTAI/LXRT确实给广大用户带来极大的便利和好处，但只有正确合理的应用才能最大程度的发挥其先进且至今仍是唯一的优势。 原载RTAI SPACE：http://justin8086.cublog.cn,转载请联系作者并注明出处。 本文未完待续，若有新的内容将尽快补充。   原载RTAI SPACE：http://justin8086.cublog.cn,转载请联系作者并注明出处。