实时操作系统(RTOS)上的Python

1. 使用线程/多处理 从主线程卸载非RT工作,在主线程中,线程之间的队列是可接受的,并且协作线程是可能的(没有抢占线程!)。

2. 避开吉尔。这基本上意味着不仅要避免线程,还要尽可能避免系统调用,特别是在时间关键型操作期间,除非它们是非阻塞的。

4. 使用Python加速器加速代码。我的第一个RT Python项目从Psyco中受益匪浅(是的,我已经做了一段时间了)。我今天选择Python2.x的一个原因是PyPy:东西

5. 当需要关键时刻时,不要害怕忙着等待。使用time.sleep()在所需的时间内“悄悄地向上”,然后在最后1-10毫秒内忙着等待。我已经能够通过10微秒的自计时获得可重复的性能。确保Python任务以最高OS优先级运行。

6. 巨石!如果你正在进行“实时”分析或大量统计,那么 与使用Numpy相比,使用更少的工作(更少的代码,更少的bug)更快地完成更多的工作。不是用我所知道的任何其他语言,包括C/C++。如果您的大部分代码都由Numpy调用组成,那么您的速度将非常非常快。我迫不及待地等待Numpy端口PyPy完成!

7. 请注意Python如何以及何时进行垃圾收集。监视内存使用情况,并在需要时强制GC。确保在时间关键型操作期间显式禁用GC。我所有的RT-Python系统都是连续运行的,Python喜欢占用内存。仔细的编码可以消除几乎所有的动态内存分配,在这种情况下,您可以完全禁用GC!

9. 我提到过使用PyPy吗?嗯,值得一提两次。

使用Python进行RT开发还有许多其他好处。例如,即使您相当确定您的目标语言不能是Python,但使用Python开发和调试原型,然后将其用作最终系统的模板和测试工具,也会带来巨大的好处。多年来,我一直在使用Python创建系统“硬部分”的快速原型,并创建快速的“脏”测试GUI。我的第一个RT Python系统就是这样诞生的:原型(+Psyco)足够快,即使测试GUI正在运行!

-BobC

我不能为你说话 数据采集设置在那里,但是 等待 让数据进来——至少是我研究过的那些数据。

那么当数据 进来吧,你需要立即记录事件或对其作出反应,然后再回到等待的游戏。这通常是数据采集系统中时间最关键的部分。出于这个原因,我会 通常地

如果您有相当宽松的要求——也许只需要毫秒精度——这会为Python中的所有工作增加一些重量。就开发时间而言,如果您已经熟悉Python,那么如果您使用Python做所有事情,并且只在出现瓶颈时重构,那么您可能会更快地完成产品。用Python完成大部分工作也会使彻底测试代码变得更容易,并且作为一般的经验法则,代码行会更少,因此产生bug的空间也会更少。

如果你需要特别多- 任务 (不是多重的- ), Stackless Python 喜欢 明显地 减少。您可以将Stackless配置为协作或抢占多任务。最大的缺点是阻塞IO通常会阻塞整个Tasklet集。无论如何,考虑到QNX已经是一个实时系统,很难推测Stackless是否值得使用。

我的投票将是尽可能多地使用Python——我认为这是一种低成本、高效益的方法。如果您确实需要用C语言重写,那么您已经有了可以开始工作的代码。

不确定性 --当你运行一次例行程序时,可能需要100个US;下次运行同一个例程时,它可能会决定扩展一个哈希表,调用malloc,然后malloc向内核请求更多内存,这可以做任何事情,从立即返回到毫秒后返回到返回 秒 之后发生错误,从代码中没有一个是明显的(或可控的)。而理论上,如果你用C(甚至更低)写,你可以证明你的关键路径“总是”(除非流星撞击)在X时间内运行。

我们的团队已经在QNX上结合多种语言做了一些工作,并且在该方法上取得了相当大的成功。使用python会对生产力产生很大影响,并且像 SWIG

然而,如果您要编写任何对时间要求很高的东西,几乎可以肯定它应该用c语言编写。这样做意味着您可以避免像GIL这样解释语言的隐含成本( Global Interpreter Lock ),及 contention 在许多小内存分配上。这两种情况都会对应用程序的性能产生很大影响。

一个重要的注意事项:PythonforQNX通常仅适用于x86。