RTAI的用户空间编程(五)——注意事项

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/cjecho/article/details/55053285
  1. 所谓的LXRT实即Linux Real Time module,不存在LXRT scheduler
    所谓的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任务的实时性能。但无论如何,context switch是需要时间的。在RTAI域内用户态和内核态的切换也免不了牺牲一定的时间开销。RTAI相关的文档指出LXRT下的硬实时相对于内核态下而言仍有若干微秒的差别。笔者也在试验中发现,前者实时性能与后者相比相差约有十几微秒,有时甚至更多。对于一些要求苛刻的实时任务而言,LXRT下的时延(或者还有实时误差?)是无法接受的。
  3. 在进入和离开LXRT域这两段时间,系统的实时性是无法保证的。
    也就是说,在时间轴上的这两个区间,所有LXRT任务并非处于真正的硬实时状态,期间任何操作都有可能因其不稳定性导致10~20微秒的实时误差(具体数值未做严密测量)。这一点在RTAI自身文档中也有阐述,但因为不引人注意,使得基于RTAI/LXRT的实时控制开发人员非常容易忽略。对这一问题的最简单处理办法就是在调用rt_make_hard_real_time()后随即插入短暂的等待,再进入实时处理阶段。实践中笔者在等待500微秒后得到理想的实时表现。
  4. stop_rt_timer是全局变量,如果在进程中某个线程结束时候使用,则会结束全部线程的定时器。
    解决这种情况可以,一,全部用周期,这样既不用去start也不用去stop;二,每个单独启动oneshot定时,然后在最后再结束。
阅读更多
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页