Tôi có nghĩa là làm thế nào và tại sao các hệ điều hành thời gian thực có thể đáp ứng thời hạn mà không bao giờ bỏ lỡ chúng? Hay đây chỉ là một huyền thoại (rằng họ không bỏ lỡ thời hạn)? Chúng khác với hệ điều hành thông thường như thế nào và điều gì ngăn cản hệ điều hành thông thường trở thành RTOS?Hệ điều hành thời gian thực hoạt động như thế nào?
Thời hạn cuộc họp là một chức năng của ứng dụng bạn viết. RTOS chỉ đơn giản cung cấp các cơ sở giúp bạn đáp ứng thời hạn. Bạn cũng có thể lập trình trên "kim loại trần" (w/o a RTOS) trong một vòng lặp chính lớn và đáp ứng thời hạn của bạn.
Cũng xin lưu ý rằng không giống như một hệ điều hành mục đích chung khác, RTOS có một tập hợp rất hạn chế các tác vụ và quy trình đang chạy.
Một số cơ sở vật chất một RTOS cung cấp:
ưu tiên dựa trên Scheduler
Hầu hết RTOS đều có 32 và 256 ưu tiên có thể cho các tác vụ/quy trình riêng lẻ. Trình lên lịch sẽ chạy tác vụ có mức độ ưu tiên cao nhất. Khi một nhiệm vụ chạy từ bỏ CPU, nhiệm vụ ưu tiên cao nhất tiếp theo chạy, và vân vân ...
Nhiệm vụ ưu tiên cao nhất trong hệ thống sẽ có CPU cho đến khi:
Với tư cách là nhà phát triển, đó là công việc của bạn để chỉ định các ưu tiên của nhiệm vụ sao cho thời hạn của bạn sẽ được đáp ứng.
Hệ thống đồng hồ ngắt thói quen
Các RTOS thường sẽ cung cấp một số loại đồng hồ hệ thống (bất cứ nơi nào từ 500 uS đến 100ms) cho phép bạn thực hiện các hoạt động thời gian nhạy cảm. Nếu bạn có đồng hồ hệ thống 1ms và bạn cần thực hiện tác vụ 50ms một lần, thường có API cho phép bạn nói "Trong 50 phút, đánh thức tôi dậy". Tại thời điểm đó, nhiệm vụ sẽ được ngủ cho đến khi RTOS thức dậy.
Lưu ý rằng chỉ cần được đánh thức không đảm bảo bạn sẽ chạy chính xác tại thời điểm đó. Nó phụ thuộc vào mức độ ưu tiên. Nếu tác vụ có mức độ ưu tiên cao hơn hiện đang chạy, bạn có thể bị trì hoãn.
Hành vi xác định
Các RTOS đi đến độ dài lớn để đảm bảo rằng cho dù bạn có 10 nhiệm vụ, hoặc 100 nhiệm vụ, nó không mất bất kỳ thời gian để chuyển đổi bối cảnh, xác định những nhiệm vụ ưu tiên cao nhất tiếp theo là, vv ...
Nói chung, hoạt động RTOS cố gắng là O (1).
Một trong những vùng chính cho hành vi xác định trong RTOS là xử lý ngắt. Khi một dòng ngắt được báo hiệu, RTOS ngay lập tức chuyển sang chế độ ngắt dịch vụ ngắt chính xác và xử lý ngắt mà không bị trễ (bất kể mức độ ưu tiên của tác vụ hiện đang chạy).
Lưu ý rằng hầu hết các ISR phần cứng cụ thể sẽ được viết bởi các nhà phát triển trong dự án. RTOS có thể đã cung cấp ISR cho cổng nối tiếp, đồng hồ hệ thống, có thể là phần cứng mạng nhưng bất kỳ điều gì chuyên biệt (tín hiệu máy tạo nhịp, bộ truyền động, vv ...) sẽ không là một phần của RTOS.
Đây là tổng quát hóa và như với mọi thứ khác, có rất nhiều triển khai RTOS. Một số RTOS làm những việc khác nhau, nhưng mô tả ở trên nên được áp dụng cho một phần lớn các RTOS hiện có.
"Tác vụ này sẽ chạy để hoàn thành" các âm thanh như Windows 3.1! Sau đó, bạn có nghĩa là RTOSes là không preemptive? –
Không, nếu bạn là ưu tiên cao nhất bạn chạy cho đến khi bạn tự nguyện từ bỏ, HOẶC một nhiệm vụ ưu tiên cao hơn bạn đã sẵn sàng, tại thời điểm ưu tiên cao (cũ) bị làm trống trước. Tôi sẽ làm rõ trong văn bản chính. Cảm ơn! – Benoit
Nó không phải là họ có thể đáp ứng thời hạn, nó là thay vì họ có thời hạn cố định trong khi trong một hệ điều hành thường xuyên không có thời hạn như vậy.
Trong hệ điều hành thông thường, công cụ lập lịch tác vụ không thực sự nghiêm ngặt. Đó là bộ vi xử lý sẽ thực hiện quá nhiều lệnh mỗi giây, nhưng đôi khi nó có thể không làm như vậy. Ví dụ một nhiệm vụ có thể được làm trống trước để cho phép một nhiệm vụ ưu tiên cao hơn (và có thể là thời gian lâu hơn). Trong RTOS, bộ xử lý sẽ luôn thực hiện cùng một số nhiệm vụ.
Ngoài ra thường có giới hạn thời gian cho các tác vụ được hoàn thành sau khi báo cáo lỗi. Điều này không xảy ra trong hệ điều hành thông thường.
Rõ ràng có nhiều chi tiết hơn để giải thích, nhưng ở trên là hai khía cạnh thiết kế quan trọng được sử dụng trong RTOS.
Về cơ bản, bạn phải mã hóa từng "tác vụ" trong RTOS sao cho chúng sẽ kết thúc trong một thời gian hữu hạn.
Ngoài ra hạt nhân của bạn sẽ phân bổ số lượng thời gian cụ thể cho mỗi tác vụ, trong một nỗ lực để đảm bảo rằng một số điều đã xảy ra tại một số thời điểm nhất định.
Lưu ý rằng đây không phải là một nhiệm vụ dễ dàng để thực hiện. Hãy tưởng tượng những thứ như các cuộc gọi hàm ảo, trong OO rất khó để xác định những điều này. Ngoài ra, RTOS phải được mã hóa cẩn thận liên quan đến mức độ ưu tiên, nó có thể yêu cầu một nhiệm vụ ưu tiên cao được cấp cho CPU trong vòng x mili giây, có thể khó thực hiện tùy thuộc vào cách trình lập lịch biểu của bạn hoạt động.
"Về cơ bản, bạn phải mã hóa mỗi" nhiệm vụ "trong RTOS sao cho chúng sẽ kết thúc trong một thời gian hữu hạn" - sau đó ứng dụng của nó nên được gọi là thời gian thực chứ không phải hệ điều hành. –
Điều gì sẽ xảy ra khi một tác vụ hết thời gian? –
tác vụ được buộc trước và khởi động lại trên lát thời gian tiếp theo của nó. Một RTOS tốt sẽ gây ra lỗi hoặc thông báo rằng điều này đã xảy ra. – Spence
Điều quan trọng là các ứng dụng thời gian thực, không phải là hệ điều hành thời gian thực. Thông thường các ứng dụng thời gian thực có thể dự đoán được: nhiều kiểm tra, kiểm tra, phân tích WCET, bằng chứng, ... đã được thực hiện cho thấy thời hạn được đáp ứng trong bất kỳ tình huống cụ thể nào.
Điều đó xảy ra là RTOS giúp thực hiện công việc này (xây dựng ứng dụng và xác minh ràng buộc RT của nó). Nhưng tôi đã thấy các ứng dụng thời gian thực chạy trên Linux chuẩn, dựa nhiều hơn vào mã lực phần cứng hơn là trên thiết kế OS.
Một RTOS đảm bảo rất nghiêm ngặt về những thứ quan trọng, như thời gian phục vụ gián đoạn, độ trễ chuyển đổi nhiệm vụ, vv Các ứng dụng thời gian thực KHÔNG thể có mà không có RTOS thích hợp. –
Tôi chỉ nói về những gì tôi đã thấy. Và thường xuyên hơn, các vấn đề thời gian thực được giải quyết bằng các tần số CPU lớn và rất nhiều thời gian. – mouviciel
Tôi chưa sử dụng RTOS, nhưng tôi nghĩ đây là cách chúng hoạt động.
Có sự khác biệt giữa "thời gian thực cứng" và "thời gian thực mềm". Bạn có thể viết các ứng dụng thời gian thực trên một tổ chức phi RTOS như Windows, nhưng chúng 'mềm' real-time:
Là một ứng dụng, tôi có thể có một sợi hoặc hẹn giờ mà tôi yêu cầu O/S để chạy 10 lần mỗi giây ... và có lẽ O/S sẽ làm điều đó, hầu hết thời gian, nhưng không đảm bảo rằng nó sẽ luôn luôn có thể ... sự thiếu đảm bảo này là lý do tại sao nó được gọi là 'mềm' . Lý do tại sao O/S có thể không có khả năng là một luồng khác có thể giữ cho hệ thống bận rộn làm việc khác. Là một ứng dụng, tôi có thể tăng ưu tiên luồng của mình lên ví dụ HIGH_PRIORITY_CLASS, nhưng ngay cả khi tôi làm điều này thì O/S vẫn không có API mà tôi có thể sử dụng để yêu cầu bảo hành mà tôi sẽ chạy vào những thời điểm nhất định.
O/S thời gian thực 'cứng' (tôi tưởng tượng) có API cho phép tôi yêu cầu lát thực hiện được đảm bảo. Lý do tại sao RTOS có thể đảm bảo như vậy là nó sẵn sàng chấp nhận các chủ đề mất nhiều thời gian hơn dự kiến / hơn chúng được cho phép.
Nó không chỉ là lập kế hoạch - hệ điều hành phải đảm bảo rằng không có thứ ngẫu nhiên nào giống như bộ sưu tập rác hoặc phân mảnh không gian địa chỉ bộ nhớ, do đó bạn biết rằng malloc() sẽ luôn quay trở lại mà không bị chậm trễ, vì vậy (ví dụ) máy bay tự động điều khiển việc kiểm soát sẽ không sụp đổ. –
Và có lẽ là phần cứng ngắt quá. – ChrisW
RTOS của bạn được thiết kế sao cho nó có thể đảm bảo thời gian cho các sự kiện quan trọng, như xử lý ngắt phần cứng và đánh thức chính xác quá trình ngủ khi cần. Thời gian chính xác này cho phép lập trình viên đảm bảo rằng máy tạo nhịp tim của anh ta sẽ tạo ra một xung chính xác khi cần, chứ không phải vài chục mili giây sau vì hệ điều hành bận với một nhiệm vụ không hiệu quả khác.
Nó thường là một hệ điều hành đơn giản hơn nhiều so với Linux hoặc Windows chính thức, đơn giản bởi vì việc phân tích và dự đoán hành vi của mã đơn giản dễ dàng hơn. Không có gì ngăn cản một hệ điều hành hoàn chỉnh như Linux đang được sử dụng trong môi trường RTOS, và nó có phần mở rộng RTOS. Bởi vì sự phức tạp của các cơ sở mã nó sẽ không thể đảm bảo thời gian của nó xuống đến quy mô nhỏ như một hệ điều hành nhỏ hơn.
Bộ lập lịch RTOS cũng nghiêm ngặt hơn so với bộ lập lịch mục đích chung. Điều quan trọng là phải biết lịch trình sẽ không thay đổi ưu tiên công việc của bạn bởi vì bạn đã chạy một thời gian dài và không có bất kỳ người dùng tương tác nào. Hầu hết các hệ điều hành sẽ giảm nội dung ưu tiên của loại quy trình này để ủng hộ các chương trình tương tác ngắn hạn, nơi giao diện không được xem là tụt hậu.
Bạn có thể thấy hữu ích khi đọc nguồn của một RTOS điển hình. Có rất nhiều ví dụ về mã nguồn mở trên mạng, và các liên kết mang lại sau một chút tìm kiếm nhanh chóng:
Một RTOS thương mại cũng được ghi chép lại, có sẵn trong dạng mã nguồn và dễ làm việc với là µC/OS-II. Nó có một giấy phép rất dễ sử dụng cho giáo dục, và (một phiên bản hết hạn) nguồn của nó có thể bị ràng buộc vào một cuốn sách mô tả lý thuyết hoạt động của nó bằng cách sử dụng thực thi thực tế như mã ví dụ. Cuốn sách là MicroC OS II: The Real Time Kernel bởi Jean Labrosse.
Tôi đã sử dụng µC/OS-II trong một số dự án trong những năm qua và có thể giới thiệu nó.
... cũng ...
Một hệ điều hành thời gian thực cố gắng để được xác định và đáp ứng thời hạn, nhưng tất cả phụ thuộc vào cách bạn viết ứng dụng của bạn. Bạn có thể tạo RTOS rất không theo thời gian thực nếu bạn không biết cách viết mã "thích hợp".
Thậm chí nếu bạn biết cách viết mã thích hợp: Đó là nhiều hơn về việc cố gắng xác định hơn là nhanh.
Khi chúng ta nói về định mệnh đó là
1) sự kiện định mệnh
Đối với mỗi bộ đầu vào các trạng thái tiếp theo và kết quả của một hệ thống được gọi
2) thời gian định mệnh
... cũng là thời gian phản hồi cho mỗi tập hợp các đầu ra được biết là
Điều này có nghĩa là nếu bạn có các sự kiện không đồng bộ như tôi nterrupts hệ thống của bạn là nghiêm túc nói không còn xác định thời gian. (và hầu hết các hệ thống đều sử dụng các ngắt)
Nếu bạn thực sự muốn trở thành tất cả mọi thứ trong cuộc thăm dò ý thức.
... nhưng có thể không cần thiết phải xác định 100%
"Nếu bạn thực sự muốn được tất cả mọi thứ để xác định cuộc thăm dò ý kiến." - Điều gì xảy ra nếu bạn bỏ lỡ một sự kiện có mức ưu tiên cao hơn trong các chu kỳ thăm dò ý kiến? Điều này sẽ không làm cho hệ điều hành phản ứng thời gian thực không cho những sự kiện đó? –
Tất nhiên nó sẽ, nhưng bạn đã làm phân tích của bạn và chắc chắn rằng tất cả các sự kiện từ bên ngoài của hệ điều hành đến trong ranh giới thời gian nhất định (một cái gì đó giống như một máy chủ rời rạc cho đầu vào của bạn). Trong điều kiện lỗi (cáp bị nứt), bạn nên vứt đi các sự kiện bằng cách nào đó. Những gì bạn chắc chắn bằng cách bỏ phiếu và không sử dụng bất kỳ ngắt nào, rằng thực tế bạn sử dụng ngắt không còn là yếu tố quyết định xuống cấp nữa. –
Bạn đang cố gắng nói rằng điều này có hiệu quả là một sự cân bằng giữa độ trễ và tính quyết định? IMO mô hình "các sự kiện ở ranh giới được xác định rõ" không thành công khi bạn có một hệ thống phân cấp sự kiện (tức là các sự kiện được ưu tiên). Không có lý do tại sao một sự kiện hoàn toàn không liên quan nên phải tôn trọng ranh giới thời gian của một sự kiện/nhiệm vụ có mức độ ưu tiên thấp (LP). Nhiệm vụ LP cần được preempted ngay cả khi sự kiện HP xảy ra tại t0 + dt. Trong đó dt là một khoảng thời gian vô hạn nhỏ và t0 là thời gian khi nhiệm vụ LP bắt đầu. –
Câu trả lời sách giáo khoa/phỏng vấn là "xác định trước sự chấp nhận". Hệ thống được đảm bảo chuyển điều khiển trong một khoảng thời gian giới hạn nếu một quá trình ưu tiên cao hơn sẵn sàng chạy (trong hàng đợi sẵn sàng) hoặc ngắt được xác nhận (thường là đầu vào bên ngoài CPU/MCU).
Họ thực sự không đảm bảo thời hạn họp; những gì họ làm điều đó khiến họ thực sự là RTOS là cung cấp phương tiện để nhận ra và đối phó với việc vượt qua thời hạn. Hệ thống RT 'cứng' thường là những nơi thiếu thời hạn là thảm họa và một số loại tắt máy là cần thiết, trong khi hệ thống RT 'mềm' là hệ thống tiếp tục suy giảm chức năng. Dù bằng cách nào thì RTOS cũng cho phép bạn xác định câu trả lời cho những lỗi quá mức đó. Non RT OS thậm chí không phát hiện overruns.
"Về cơ bản, bạn phải mã hóa từng" tác vụ "trong RTOS sao cho chúng sẽ kết thúc trong một thời gian hữu hạn."
Điều này thực sự chính xác. RTOS sẽ có một hệ thống đánh dấu được xác định bởi kiến trúc, nói 10 millisec., Với tất cả các nhiệm vụ (chủ đề) cả được thiết kế và đo lường để hoàn thành trong thời gian cụ thể. Ví dụ trong xử lý dữ liệu âm thanh thời gian thực, với tốc độ mẫu âm thanh là 48kHz, có một lượng thời gian đã biết (tính bằng mili giây) mà tại đó bộ đệm trước sẽ trống đối với bất kỳ tác vụ hạ lưu nào đang xử lý dữ liệu. Do đó, việc sử dụng RTOS yêu cầu kích thước chính xác của bộ đệm, ước tính và đo thời gian thực hiện và đo độ trễ giữa tất cả các lớp phần mềm trong hệ thống. Sau đó, thời hạn có thể được đáp ứng. Nếu không, các ứng dụng sẽ bỏ lỡ thời hạn. Điều này đòi hỏi phải phân tích xử lý dữ liệu trường hợp xấu nhất trong toàn bộ ngăn xếp và một khi trường hợp xấu nhất được biết, hệ thống có thể được thiết kế cho thời gian xử lý 95% với thời gian nhàn rỗi 5% (quá trình xử lý này có thể chưa từng xảy ra bất kỳ việc sử dụng thực sự nào, vì việc xử lý dữ liệu trường hợp xấu nhất có thể không phải là trạng thái cho phép trong tất cả các lớp tại bất kỳ thời điểm nào trong thời gian).
Ví dụ thời gian sơ đồ cho việc thiết kế một ứng dụng mạng hệ điều hành thời gian thực là trong bài viết này tại EE Times, CÁC HƯỚNG DẪN: Cải thiện chất lượng âm thanh thời gian thực trong một thiết kế điện thoại VoIP dựa trên http://www.eetimes.com/design/embedded/4007619/PRODUCT-HOW-TO-Improving-real-time-voice-quality-in-a-VoIP-based-telephony-design
Trong RTOS, các tham số quan trọng nhất cần được quan tâm là độ trễ thấp hơn và xác định thời gian. Điều đó thật thú vị khi thực hiện theo các chính sách và thủ thuật nhất định.
Trong khi ở GPOS, cùng với độ trễ chấp nhận được, các thông số quan trọng là thông lượng cao. bạn không thể dựa vào GPOS để xác định thời gian.
RTOS có tác vụ nhẹ hơn nhiều so với quy trình/chủ đề trong GPOS.
Điều quan trọng cũng cần lưu ý là sự khác biệt giữa hệ thống thời gian thực mềm và hệ thống thời gian thực 'cứng'. – Thomas