Python trên Hệ điều hành thời gian thực (RTOS)

Question

Tôi đang lên kế hoạch triển khai hệ thống thu thập dữ liệu quy mô nhỏ trên nền tảng RTOS. (Hoặc trên hệ thống QNX hoặc RT-Linux.)

Theo như tôi biết, các công việc này được thực hiện bằng cách sử dụng C/C++ để tận dụng tối đa hệ thống. Tuy nhiên, tôi tò mò muốn biết và muốn tìm hiểu ý kiến ​​của một số người có kinh nghiệm trước khi tôi chuyển sang hành động mã hóa một cách mù quáng cho dù có khả thi và khôn ngoan hơn để viết mọi thứ bằng Python (từ công cụ cấp thấp giao tiếp thông qua giao diện người dùng đồ họa sáng bóng). Nếu không, trộn với các phần thời gian quan trọng của thiết kế với "C", hoặc viết tất cả mọi thứ trong C và thậm chí không đặt một dòng mã Python.

Hoặc ít nhất gói mã C bằng Python để cung cấp khả năng truy cập dễ dàng hơn vào hệ thống.

Bạn sẽ khuyên tôi làm việc theo cách nào? Tôi sẽ vui mừng nếu bạn chỉ một số trường hợp thiết kế tương tự và đọc thêm là tốt.

Cảm ơn bạn

Note1: Nguyên nhân của nhấn mạnh trên QNX là do chúng tôi đã có một QNX 4,25 dựa trên hệ thống thu thập dữ liệu (M300) cho các thí nghiệm đo lường khí quyển của chúng ta. Đây là một hệ thống độc quyền và chúng tôi không thể truy cập vào nội bộ của nó. Nhìn xa hơn về QNX có thể có lợi cho chúng tôi vì 6.4 có tùy chọn cấp phép học thuật miễn phí, đi kèm với Python 2.5 và phiên bản GCC gần đây. Tôi chưa bao giờ thử nghiệm một hệ thống RT-Linux, không biết làm thế nào so sánh được với QNX về tính ổn định và hiệu quả, nhưng tôi biết rằng tất cả các thành viên của môi trường sống Python và các công cụ không phải Python (như Google Earth) có thể được phát triển trên các công trình hầu hết thời gian ngoài hộp.

Answer 1

tôi không thể nói cho mỗi thu thập dữ liệu thiết lập trên mạng, nhưng hầu hết trong số họ dành phần lớn "các hoạt động thời gian thực" của họ chờ cho dữ liệu đi vào - ít nhất là những cái tôi đã làm việc trên.

Sau đó, khi dữ liệu làm, bạn cần phải ghi lại sự kiện ngay lập tức hoặc trả lời sự kiện và sau đó quay lại trò chơi đang chờ. Đó thường là phần quan trọng nhất trong thời gian của một hệ thống thu thập dữ liệu. Vì lý do đó, tôi sẽ nói chung là nói với C cho các phần I/O của việc thu thập dữ liệu, nhưng không có bất kỳ lý do đặc biệt hấp dẫn nào không sử dụng Python trên các phần không quan trọng.

Nếu bạn có các yêu cầu khá lỏng lẻo - chỉ cần độ chính xác đến mili giây, có lẽ - thêm một số trọng lượng để thực hiện mọi thứ bằng Python.Theo như thời gian phát triển, nếu bạn đã thoải mái với Python, có thể bạn sẽ có một sản phẩm hoàn chỉnh sớm hơn nếu bạn làm mọi thứ trong Python và tái cấu trúc chỉ như những nút cổ chai xuất hiện. Việc thực hiện phần lớn công việc của bạn bằng Python cũng sẽ giúp kiểm tra kỹ mã của bạn dễ dàng hơn, và theo nguyên tắc chung, sẽ có ít dòng mã hơn và do đó ít có lỗi hơn.

Nếu bạn cần phải đặc biệt đa nhiệm vụ (không đa chủ đề), Stackless Python có thể mang lại lợi ích là tốt. Đó là giống như đa luồng, nhưng các chuỗi (hoặc các tác vụ, trong Stackless lingo) không phải là chủ đề cấp hệ điều hành, mà là cấp Python/ứng dụng, do đó chi phí chuyển đổi giữa các tác vụ được giảm đáng kể. Bạn có thể định cấu hình Stackless thành đa nhiệm hợp tác hoặc preemptively. Nhược điểm lớn nhất là chặn IO nói chung sẽ chặn toàn bộ các tác vụ của bạn. Dù sao, xem xét rằng QNX đã là một hệ thống thời gian thực, thật khó để suy đoán liệu Stackless có đáng để sử dụng hay không.

Phiếu bầu của tôi sẽ mang theo lộ trình càng nhiều càng tốt - tôi thấy nó là chi phí thấp và lợi ích cao. Nếu và khi bạn cần phải viết lại trong C, bạn sẽ có mã làm việc để bắt đầu.

Answer 2

Nhóm của chúng tôi đã thực hiện một số công việc kết hợp nhiều ngôn ngữ trên QNX và có khá nhiều thành công với cách tiếp cận này. Sử dụng python có thể có tác động lớn đến năng suất và các công cụ như SWIG và ctypes giúp bạn dễ dàng tối ưu hóa mã và kết hợp các tính năng từ các ngôn ngữ khác nhau.

Tuy nhiên, nếu bạn viết bất kỳ thời điểm nào quan trọng, nó gần như chắc chắn sẽ được viết bằng c. Làm điều này có nghĩa là bạn tránh được các chi phí tiềm ẩn của một ngôn ngữ thông dịch như GIL (Global Interpreter Lock) và contention trên nhiều phân bổ bộ nhớ nhỏ. Cả hai điều này có thể có tác động lớn đến cách ứng dụng của bạn hoạt động.

Ngoài ra python trên QNX có xu hướng không tương thích 100% với các bản phân phối khác (nghĩa là đôi khi có các mô-đun bị thiếu).

Answer 3

Nói chung lý do nâng cao khi sử dụng ngôn ngữ cấp cao trong ngữ cảnh thời gian thực là không chắc chắn - khi bạn chạy thường xuyên một lần, nó có thể mất 100us; lần sau bạn chạy cùng một thói quen, nó có thể quyết định mở rộng bảng băm, gọi malloc, sau đó malloc hỏi hạt nhân để có thêm bộ nhớ, có thể làm bất cứ điều gì từ trả về ngay lập tức để trở về mili giây sau đó để trở về giây sau đó để báo lỗi trong đó ngay lập tức (hoặc có thể điều khiển được) từ mã. Trong khi về mặt lý thuyết nếu bạn viết bằng C (hoặc thậm chí thấp hơn), bạn có thể chứng minh rằng các đường dẫn quan trọng của bạn sẽ "luôn luôn" (chặn cuộc đình công sao băng) chạy trong thời gian X.

Answer 4

Một lưu ý quan trọng: Python cho QNX thường chỉ có sẵn cho x86.

Tôi chắc chắn bạn có thể biên dịch nó cho ppc và các vòm khác, nhưng điều đó sẽ không hoạt động.

Answer 5

Tôi đã xây dựng một số hệ thống thời gian thực (RT) thời gian thực mềm bằng Python, với thời gian chu kỳ chính từ 1 mili giây đến 1 giây. Có một số chiến lược cơ bản và chiến thuật tôi đã học được trên đường đi:

1. Sử dụng luồng/đa xử chỉ để giảm tải công việc phi RT từ thread chính, nơi mà hàng đợi giữa các chủ đề được chấp nhận và hợp tác luồng là có thể (không có chủ đề preemptive!).

2. Tránh GIL. Về cơ bản, điều này có nghĩa là không chỉ tránh luồng, mà còn tránh các cuộc gọi hệ thống ở mức độ lớn nhất có thể, đặc biệt là trong các hoạt động thời gian quan trọng, trừ khi chúng không bị chặn.

3. Sử dụng mô-đun C khi thực tế. Mọi thứ (thường) đi nhanh hơn với C! Nhưng chủ yếu là nếu bạn không phải viết của riêng bạn: Ở trong Python, trừ khi có thực sự là không có thay thế. Tối ưu hóa hiệu suất mô-đun C là một PITA, đặc biệt khi dịch qua giao diện Python-C trở thành phần đắt nhất của mã.

4. Sử dụng trình tăng tốc Python để tăng tốc mã của bạn. Dự án RT Python đầu tiên của tôi được hưởng lợi rất nhiều từ Psyco (vâng, tôi đã làm điều này một thời gian). Một lý do tôi ở lại với Python 2.x hôm nay là PyPy: Mọi thứ luôn luôn chuyển nhanh hơn với LLVM!

5. Đừng ngại bận khi chờ khi cần thời gian quan trọng. Sử dụng time.sleep() để 'sneak up' vào thời gian mong muốn, sau đó bận chờ trong 1-10 ms cuối cùng. Tôi đã có thể nhận được hiệu suất lặp lại với thời gian tự trên 10 micro giây. Hãy chắc chắn rằng nhiệm vụ Python của bạn được chạy ở mức ưu tiên hệ điều hành tối đa.

6. Numpy ROCKS! Nếu bạn đang thực hiện phân tích 'sống' hoặc tấn số liệu thống kê, có KHÔNG cách để hoàn thành công việc nhanh hơn và ít công việc hơn (ít mã hơn, ít lỗi hơn) bằng cách sử dụng Numpy. Không phải bằng bất kỳ ngôn ngữ nào khác mà tôi biết, bao gồm C/C++. Nếu phần lớn mã của bạn bao gồm các cuộc gọi Numpy, bạn sẽ rất, rất nhanh. Tôi không thể chờ đợi cho cổng Numpy để PyPy được hoàn thành!

7. Hãy nhận biết cách thức và thời điểm Python thu thập rác thải. Theo dõi việc sử dụng bộ nhớ của bạn và buộc GC khi cần. Đảm bảo vô hiệu hóa GC một cách rõ ràng trong các hoạt động quan trọng về thời gian. Tất cả các hệ thống RT Python của tôi chạy liên tục, và Python yêu thích bộ nhớ hog. Cẩn thận mã hóa có thể loại bỏ gần như tất cả các cấp phát bộ nhớ động, trong trường hợp này bạn hoàn toàn có thể vô hiệu hóa GC!

8. Cố gắng thực hiện xử lý theo lô đến mức tối đa nhất có thể. Thay vì xử lý dữ liệu ở tốc độ đầu vào, hãy thử xử lý dữ liệu ở tốc độ đầu ra, thường chậm hơn nhiều. Xử lý theo lô cũng giúp việc thu thập số liệu thống kê cấp cao trở nên thuận tiện hơn.

9. Tôi có đề cập đến việc sử dụng PyPy không? Vâng, nó đáng nhắc đến hai lần.

Có nhiều lợi ích khác khi sử dụng Python để phát triển RT. Ví dụ, ngay cả khi bạn khá chắc chắn ngôn ngữ đích của bạn không thể là Python, nó có thể trả các lợi ích to lớn để phát triển và gỡ lỗi một bản mẫu trong Python, sau đó sử dụng nó làm cả mẫu và công cụ kiểm tra cho hệ thống cuối cùng. Tôi đã sử dụng Python để tạo ra các nguyên mẫu nhanh chóng của "phần cứng" của một hệ thống trong nhiều năm, và để tạo ra các GUI thử nghiệm nhanh chóng. Đó là cách mà hệ thống RT Python đầu tiên của tôi xuất hiện: Nguyên mẫu (+ Psyco) đủ nhanh, ngay cả khi chạy thử GUI!

-BobC

Edit: Quên đề cập đến những lợi ích đa nền tảng: Mã của tôi chạy khá nhiều ở khắp mọi nơi với a) không biên dịch lại (hoặc phụ thuộc biên dịch, hoặc cần cho cross-trình biên dịch), và b) hầu như không có mã phụ thuộc vào nền tảng (chủ yếu cho các công cụ khác như xử lý tệp và I/O nối tiếp). Tôi có thể phát triển trên Win7-x86 và triển khai trên Linux-ARM (hoặc bất kỳ hệ điều hành POSIX nào khác, tất cả đều có Python trong những ngày này). PyPy chủ yếu là x86, nhưng cổng ARM đang phát triển với tốc độ đáng kinh ngạc.