簡體 English 中英

實時操作系統（RTOS）上的Python

[英]Python on an Real-Time Operation System (RTOS)

原文 2009-09-10 01:12:23 7 5 python/ rtos/ python-stackless/ qnx

我計划在RTOS平台上實現一個小規模的數據采集系統。 （在QNX或RT-Linux系統上。）

據我所知，這些作業是使用C / C ++執行的，以充分利用系統。 然而，我很想知道並且想要學習一些經驗豐富的人的意見，然后我盲目地進入編碼行動，是否可行且更明智地用Python編寫所有內容（從低級儀器通過閃亮的圖形用戶界面連接）。 如果沒有，將設計的時序關鍵部分與“C”混合，或者用C編寫所有內容，甚至不用一行Python代碼。

或者至少使用Python包裝C代碼以便更容易地訪問系統。

你建議我以哪種方式工作？ 如果你指出一些類似的設計案例和進一步的閱讀材料，我會很高興的。

謝謝

注1：強調QNX的原因是我們已經有一個基於QNX 4.25的數據采集系統（ M300 ）用於我們的大氣測量實驗。 這是一個專有系統，我們無法訪問它的內部。 進一步研究QNX可能對我們有利，因為6.4有免費的學術許可選項，Python 2.5附帶，以及最近的GCC版本。 我從來沒有測試過RT-Linux系統，不知道它在穩定性和效率方面與QNX有多么可比，但我知道Python系統的所有成員和非Python工具（如Google Earth）的新系統可以在大多數情況下開箱即用。

5 個解決方案

我已經構建了幾個全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任務以最大OS優先級運行。
Numpy ROCKS！ 如果您正在進行“實時”分析或大量統計數據，那么與使用Numpy相比，沒有辦法更快地完成更多工作並且工作量更少（代碼更少，錯誤更少）。 不是我所知道的任何其他語言，包括C / C ++。 如果您的大多數代碼都包含Numpy調用，那么您將非常非常快。 我等不及Numpy端口到PyPy完成了！
請注意Python如何以及何時進行垃圾回收。 監控內存使用情況，並在需要時強制GC。 務必在時間關鍵操作期間明確禁用GC。 我的所有RT Python系統都在不斷運行，Python喜歡占用內存。 仔細編碼可以消除幾乎所有動態內存分配，在這種情況下，您可以完全禁用GC！
嘗試盡可能分批進行處理。 不要以輸入速率處理數據，而是嘗試以輸出速率處理數據，這通常要慢得多。 批量處理還可以更方便地收集更高級別的統計信息。
我提到過使用PyPy嗎？ 嗯，值得一提兩次。

使用Python進行RT開發還有許多其他好處。 例如，即使您非常確定您的目標語言不能是Python，它也可以為Python開發和調試原型帶來巨大好處，然后將其用作最終系統的模板和測試工具。 多年來，我一直使用Python來創建系統“硬件”的快速原型，並創建快速的測試GUI。 這就是我的第一個RT Python系統的出現：原型（+ Psyco）足夠快，即使測試GUI正在運行！

-BobC

編輯：忘了提到跨平台的好處：我的代碼幾乎無處不在運行a）沒有重新編譯（或編譯器依賴，或需要交叉編譯器），和b）幾乎沒有平台相關的代碼（主要用於misc之類的東西）文件處理和串行I / O）。 我可以在Win7-x86上開發並部署在Linux-ARM（或任何其他POSIX操作系統上，所有這些操作系統最近都有Python）。 PyPy目前主要是x86，但ARM端口的發展速度令人難以置信。

我無法代表那里的每一個數據采集設置，但他們中的大多數都花費大部分“實時操作”來等待數據進入 - 至少是我所做過的那些。

然后，當數據不進來，你需要立即記錄事件或響應它，然后又回到了等待的游戲。 這通常是數據采集系統中最重要的時間部分。 出於這個原因，我通常會說在數據采集的I / O部分堅持使用C，但是沒有任何特別令人信服的理由不在非時間關鍵部分使用Python。

如果你有相當寬松的要求 - 可能只需要毫秒精度 - 這會增加一些在Python中做所有事情的重量。 就開發時間而言，如果您已經熟悉Python，那么如果您在Python中執行所有操作並且僅在出現瓶頸時重構，則可能會更快地獲得完成的產品。 使用Python完成大部分工作也可以更容易地徹底測試代碼，並且作為一般經驗法則，代碼行數會減少，從而減少錯誤的空間。

如果您需要專門的多任務（而不是多線程）， Stackless Python也可能是有益的。 這就像多線程一樣，但是線程（或無法使用Stackless語言中的tasklet）不是操作系統級別的線程，而是Python /應用程序級別，因此大大減少了在tasklet之間切換的開銷。 您可以將Stackless配置為多任務協同或搶先。 最大的缺點是阻塞IO通常會阻止整個tasklet集。 無論如何，考慮到QNX已經是一個實時系統，很難推測Stackless是否值得使用。

我的投票將采用盡可能多的Python作為可能的路線 - 我認為它是低成本和高利益。 如果您確實需要在C中重寫，那么您已經擁有了可用的代碼。

一般來說，在實時環境中使用高級語言的原因是不確定性 - 當你運行例程一次時它可能需要100us; 下次你運行相同的例程時，它可能決定擴展一個哈希表，調用malloc，然后malloc要求內核提供更多的內存，這可以做任何事情，從立即返回到返回毫秒后返回到幾秒后返回錯誤，其中沒有一個從代碼中立即顯現（或可控制）。 而理論上如果你用C（甚至更低）寫作，你可以證明你的關鍵路徑將“永遠”（禁止流星撞擊）在X時間內運行。