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

【问题标题】：Python on an Real-Time Operation System (RTOS)实时操作系统 (RTOS) 上的 Python
【发布时间】：2010-11-27 00:56:06
【问题描述】：

我计划在 RTOS 平台上实现一个小型数据采集系统。（在 QNX 或 RT-Linux 系统上。）

据我所知，这些作业是使用 C/C++ 执行的，以充分利用系统。然而，我很想知道并想了解一些有经验的人的意见，然后我盲目地投入到编码行动中，用 Python 编写所有东西是否可行和更明智（从低级仪器接口到闪亮的图形用户界面）。如果不是，则将设计中对时间至关重要的部分与“C”混合，或者用 C 编写所有内容，甚至不放一行 Python 代码。

或者至少使用 Python 封装 C 代码，以便更轻松地访问系统。

您建议我采用哪种方式工作？如果你能指出一些类似的设计案例和进一步的阅读材料，我会很高兴。

谢谢

NOTE1：之所以强调 QNX，是因为我们已经有一个基于 QNX 4.25 的数据采集系统 (M300) 用于我们的大气测量实验。这是一个专有系统，我们无法访问它的内部。进一步了解 QNX 可能对我们有利，因为 6.4 具有免费的学术许可选项，附带 Python 2.5 和最近的 GCC 版本。我从未测试过 RT-Linux 系统，不知道它在稳定性和效率方面与 QNX 相比如何，但我知道 Python 栖息地和非 Python 工具（如 Google Earth）的所有成员都认为新系统大部分时间都可以在开箱即用的作品上开发。

【问题讨论】：

你能提示一下时序要求吗？您需要什么频率/响应时间？秒还是微秒？查看您的 RTOS，我假设您拥有 PC 或强大的嵌入式平台。对吗？
对于大多数测量，1Hz 采样率是令人满意的。然而，有些仪器需要以 100Hz 左右的高速率进行采样。通常超快速测量设备（例如云粒子成像仪）带有专用的数据系统——这些超出了我最初的意图范围。是的，当前系统在 PC 上运行，用于采集任务，其中有许多板卡与各种设备连接。我认为将其称为嵌入式平台而不是典型的台式 PC 是正确的。

标签： python rtos python-stackless qnx

【解决方案1】：

我已经构建了几个全 Python 软实时 (RT) 系统，主循环时间从 1 毫秒到 1 秒不等。在此过程中，我学到了一些基本的策略和战术：

使用线程/多处理仅从主线程卸载非 RT 工作，其中线程之间的队列是可接受的并且协作线程是可能的（没有抢占式线程！）。
避免使用 GIL。这基本上意味着不仅要避免线程，还要尽可能地避免系统调用，尤其是在时间关键的操作期间，除非它们是非阻塞的。
在实际情况下使用 C 模块。事情（通常）用 C 来得更快！但主要是如果您不必自己编写：除非确实别无选择，否则请留在 Python 中。优化 C 模块性能是一个 PITA，尤其是当跨 Python-C 接口进行翻译成为代码中最昂贵的部分时。
使用 Python 加速器来加速您的代码。我的第一个 RT Python 项目从 Psyco 中受益匪浅（是的，我已经这样做了一段时间）。我今天继续使用 Python 2.x 的一个原因是 PyPy：使用 LLVM 让事情总是更快！
在需要关键时间时不要害怕忙等待。使用 time.sleep() 在所需时间“偷偷摸摸”，然后在最后 1-10 毫秒内忙等待。我已经能够通过大约 10 微秒的自定时获得可重复的性能。确保您的 Python 任务以最高操作系统优先级运行。
麻木的岩石！如果您正在执行“实时”分析或大量统计数据，那么NO 与使用 Numpy 相比，没有办法以更少的工作（更少的代码、更少的错误）更快地完成更多的工作。不是我所知道的任何其他语言，包括 C/C++。如果你的大部分代码由 Numpy 调用组成，你会非常非常快。我等不及要完成到 PyPy 的 Numpy 端口了！
注意 Python 进行垃圾回收的方式和时间。监控您的内存使用情况，并在需要时强制 GC。确保在时间关键操作期间显式禁用 GC。我所有的 RT Python 系统都在连续运行，而 Python 喜欢占用内存。仔细编码可以消除几乎所有的动态内存分配，在这种情况下你可以完全禁用 GC！
尽量分批进行处理。不要以输入速率处理数据，而是尝试以输出速率处理数据，这通常要慢得多。批量处理还可以更方便地收集更高级别的统计信息。
我是否提到过使用 PyPy？嗯，值得提两次。

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

-BobC

编辑：忘了提及跨平台的好处：我的代码几乎可以在任何地方运行 a) 无需重新编译（或编译器依赖项，或需要交叉编译器），b) 几乎没有平台相关的代码（主要用于诸如文件处理和串行 I/O 之类的杂项）。我可以在 Win7-x86 上进行开发并在 Linux-ARM（或任何其他 POSIX 操作系统，现在所有这些操作系统都有 Python）上进行部署。 PyPy 目前主要是 x86，但 ARM 端口正在以令人难以置信的速度发展。

【讨论】：

这个问题迟到了，但感谢您提供详细的回答。对我来说这是最有趣的部分：仔细的编码可以消除几乎所有的动态内存分配，在这种情况下你可以完全禁用 GC。你能举一些关于那个仔细的编码部分的例子吗？

【解决方案2】：

重要提示：Python for QNX 通常仅适用于 x86。

我确信你可以为 ppc 和其他拱门编译它，但这不是开箱即用的。

【讨论】：

【解决方案3】：

一般来说，反对在实时上下文中使用高级语言的原因是不确定性——当你运行一个例程时，它可能需要 100us；下次你运行相同的例程时，它可能决定扩展一个哈希表，调用 malloc，然后 malloc 向内核请求更多内存，这可以做任何事情，从立即返回到毫秒后返回到返回秒后来到错误，从代码中都不会立即显现（或可控）。而理论上，如果你用 C（甚至更低）编写，你可以证明你的关键路径将“总是”（除非流星撞击）在 X 时间内运行。

【讨论】：

我几乎同意所有这些，但是任何语言的关键路径（尤其是最坏情况下的执行时间）分析都是一个非常可怕的问题，并且很大程度上取决于硬件平台（缓存、管道、分支预测器、页面错误）和软件（操作系统服务、中断、阻塞时间）。如果时机很关键，Ada 可能是必不可少的
是的，随心所欲地服用尽可能多的盐粒。我想也许我的论点应该是“如果所有这些东西对你来说听起来都是古怪的废话，那么你就没有足够的实时性来担心你用什么语言写作”。
此时不低于 C。并且无意使用 CorePy 之类的工具从 Python 调用汇编操作码。时间紧迫性很重要，但让我改用 Ada 并不重要。

【解决方案4】：

我不能代表每一个数据采集设置，但大多数他们中的大部分“实时操作”等待 em> 让数据进来——至少是我处理过的数据。

那么当数据确实进来时，你需要立即记录事件或响应它，然后再回到等待的游戏中。这通常是数据采集系统中时间最关键的部分。出于这个原因，我一般会说在数据采集的 I/O 部分坚持使用 C，但没有任何特别令人信服的理由不在非时间关键部分使用 Python .

如果您的要求相当宽松——也许只需要毫秒精度——这会增加在 Python 中执行所有操作的权重。就开发时间而言，如果您已经对 Python 感到满意，那么如果您在 Python 中做所有事情并仅在出现瓶颈时进行重构，那么您可能会更快地完成产品。在 Python 中完成大部分工作还可以更轻松地彻底测试代码，并且作为一般经验法则，代码行数会更少，因此出现错误的空间也会更小。

如果您需要专门处理多任务（不是多线程），Stackless Python 也可能是有益的。它类似于多线程，但线程（或小任务，在 Stackless 术语中）不是操作系统级别的线程，而是 Python/应用级别的线程，因此在小任务之间切换的开销是显着的减少。您可以将 Stackless 配置为协作或抢占式多任务。最大的缺点是阻塞 IO 通常会阻塞你的整个 tasklet。无论如何，考虑到 QNX 已经是一个实时系统，很难推测 Stackless 是否值得使用。

我的投票是采用尽可能多的 Python 路线——我认为它是低成本和高收益的。如果并且当您确实需要用 C 重写时，您将已经有了可以开始工作的代码。

【讨论】：

我之前没有使用过 Stackless，也不知道它与许多核心科学工具的集成。我想继续使用 RT-Linux 的原因之一是它所有的 Python 工具和 2D / 3D 可视化库都运行良好。然而在 QNX 方面，很多库都丢失了，我相信让它们在 QNX 上工作需要付出巨大的努力。对此的任何 cmet 将不胜感激。
Stackless 仅修改现有的 Python 安装——它替换了几个不应影响任何 Python 库的核心文件。它不再使用 C 堆栈，但它甚至不应该影响用 C 编写的与 Python 接口的库。稍微玩一下 Stackless（在 Windows 上非常容易安装），看看它是否适合您的需求。我没有从源代码构建 Stackless，所以我无法评论 QNX 的任何可预见的困难。

【解决方案5】：

我们的团队已经完成了一些在 QNX 上结合多种语言的工作，并且在这种方法上取得了相当大的成功。使用 python 可以对生产力产生重大影响，SWIG 和 ctypes 等工具可以非常轻松地优化代码并结合不同语言的功能。

但是，如果您要编写任何时间紧迫的内容，则几乎可以肯定它应该用 c 编写。这样做意味着您可以避免像 GIL (Global Interpreter Lock) 和 contention 这样的解释语言在许多小内存分配上的隐含成本。这两件事都会对您的应用程序的性能产生重大影响。

QNX 上的 python 也往往不是 100% 兼容其他发行版（即/有时缺少模块）。

【讨论】：

而用于 QNX 的 python 在最新版本中很难找到......而且为 QNX 构建并不总是那么容易
@Fuzz，2.5 在 QNX 6.4.x 上，如果我没记错的话，PyQt 4 二进制文件应该在第三方存储库的某个地方。到目前为止，我还没有看到 NumPy 端口，也没有尝试自己构建任何库。我相信需要大量的黑客攻击才能使其中一些工作半途而废。这就是我考虑在 QNX 上使用 RT-Linux 解决方案的原因，但我需要更多的输入和资源。
@Andrew，您能否给我一些指示，告诉我在哪里可以找到在 RTOS 系统上使用 Python - C 方法的此类项目？显然，这在网络上有些隐藏，需要更深入地挖掘或只是采用反复试验的方法。
QNX 上的 Python 构建由 Crank 软件 cranksoftware.com/downloads 提供和托管。您将在 OpenQNX、openqnx.com 和 Foundary27 community.qnx.com/sf/sfmain/do/home 上获得一些好的建议至于开始，这在很大程度上取决于您要做什么。我们构建跨平台，因此我们对 QNX 特定功能的使用很少。但是，如果我可以提出一个建议，请确保如果您有大量时间关键的 IO（通过 COM 端口、自定义硬件或 IPC），请确保您进行一些原型设计以使您的设计正确。