RTOS cho các hệ thống nhúng


57

Tôi đã thấy nhiều bài báo nói với tôi rằng tôi nên sử dụng RTOS để quản lý thời gian và quản lý tài nguyên. Thời gian của tôi không cho phép nghiên cứu của riêng tôi, vì vậy tôi đến gặp chiphacker để được tư vấn.

Tôi sử dụng vi điều khiển tài nguyên thấp (MSP430, PIC) và đang tìm kiếm RTOS tôi có thể sử dụng.

Đến điểm:

  1. Chi phí tài nguyên của hệ thống
  2. Ưu điểm của hệ thống
  3. Nhược điểm của hệ thống
  4. Thủ thuật thực hiện
  5. Các tình huống RTOS nên / không nên được sử dụng trong.

Tôi không sử dụng các hệ thống như arduino, các dự án tôi làm việc không thể hỗ trợ chi phí của một hệ thống như vậy.


2
Tôi bối rối không biết điều này nhận được một phiếu bầu nào. Nếu cử tri có thể cho tôi phản hồi, tôi sẽ cố gắng tránh một hành động như vậy trong tương lai.
Kortuk

1
như trên. Đó là một câu hỏi tuyệt vời ....
Jason S

Tôi đã chấp nhận một câu hỏi bởi vì, thậm chí nghĩ rằng đây là kết thúc mở, tôi đã có một số câu trả lời tuyệt vời và muốn thưởng cho ít nhất một nhà văn cho nỗ lực này.
Kortuk

Câu trả lời:


29

Tôi chưa có nhiều trải nghiệm cá nhân với RTOS ngoài QNX (rất tuyệt vời nhưng không hề rẻ và tôi đã có trải nghiệm thực sự tồi tệ với một nhà cung cấp bảng cụ thể và thái độ không quan tâm của QNX đối với các hệ thống khác so với phổ biến nhất của chúng) quá lớn đối với PIC và MSP430.

Nơi bạn sẽ được hưởng lợi từ RTOS là trong các lĩnh vực như

  • quản lý chủ đề / lập kế hoạch
  • truyền thông liên chủ đề + đồng bộ hóa
  • I / O trên các hệ thống có stdin / stdout / stderr hoặc cổng nối tiếp hoặc hỗ trợ ethernet hoặc hệ thống tập tin (không phải MSP430 hoặc PIC cho hầu hết các phần, ngoại trừ các cổng nối tiếp)

Đối với các thiết bị ngoại vi của PIC hoặc MSP430: đối với các cổng nối tiếp tôi sẽ sử dụng bộ đệm vòng + ngắt ... một cái gì đó tôi viết một lần cho mỗi hệ thống và chỉ cần sử dụng lại; các thiết bị ngoại vi khác Tôi không nghĩ rằng bạn sẽ tìm thấy nhiều sự hỗ trợ từ RTOS, vì chúng rất dành riêng cho nhà cung cấp.

Nếu bạn cần thời gian ổn định đến từng giây, thì RTOS có thể sẽ không giúp ích gì - RTOS có giới hạn thời gian, nhưng thường có thời gian bị xáo trộn trong lịch trình do sự chậm trễ chuyển đổi ngữ cảnh ... QNX chạy trên PXA270 jitter trong hàng chục micro giây điển hình, tối đa 100-200us, vì vậy tôi sẽ không sử dụng nó cho những thứ phải chạy nhanh hơn khoảng 100Hz hoặc cần thời gian chính xác hơn khoảng 500us. Đối với loại công cụ đó, bạn có thể sẽ phải thực hiện xử lý ngắt của riêng bạn. Một số RTOS sẽ chơi tốt với điều đó và một số khác sẽ khiến nó trở thành nỗi đau của hoàng gia: thời gian của bạn và thời gian của chúng có thể không thể cùng tồn tại tốt.

Nếu thời gian / lập lịch không quá phức tạp, bạn có thể nên sử dụng một máy trạng thái được thiết kế tốt. Tôi đặc biệt khuyên bạn nên đọc Statecharts thực tế trong C / C ++ nếu bạn chưa có. Chúng tôi đã sử dụng phương pháp này trong một số dự án của chúng tôi khi tôi làm việc và nó có một số lợi thế thực sự so với các máy trạng thái truyền thống để quản lý sự phức tạp .... đó thực sự là lý do duy nhất bạn cần RTOS.


Tôi làm việc tại một công ty khởi nghiệp nơi những người có hệ thống nhúng giàu kinh nghiệm nhất mới ra khỏi trường đại học (ví dụ: Bản thân tôi và anh chàng kia đã làm việc với tôi khoảng 2 năm). Tôi dành một phần rất lớn thời gian để dạy bản thân về thực hành công nghiệp trong tuần làm việc của mình. Khi tôi đang đọc, tôi đã được thông báo cho tất cả nhưng hệ thống chi phí thấp nhất của chúng tôi, RTOS sẽ là một sự ngẫu hứng lớn.
Kortuk

Dường như có hệ thống RTOS tài nguyên rất thấp cho những thứ như PIC và MSP430 có thể giúp tạo ra một hệ thống xác định từ một hệ thống rất phức tạp, cũng làm sạch đáng kể việc quản lý các mô-đun tách biệt. Tôi đã tham gia vào một nhóm hai người xây dựng một hệ thống định tuyến và thu thập dữ liệu thực địa. Bây giờ tôi nhìn vào RTOS tôi thấy nó hoàn hảo cho những gì chúng tôi thiết kế.
Kortuk

Xin lỗi vì đã sử dụng ba vị trí bài đăng, câu trả lời của bạn rất hữu ích, tôi đang tìm kiếm một giải pháp tài nguyên rất thấp, nhưng thông tin này rất có giá trị, cảm ơn bạn đã giúp đỡ.
Kortuk

đừng lo lắng về số lượng bình luận (IMHO một điều mà khung StackExchange thiếu là hỗ trợ cho các cuộc thảo luận ... định dạng Q / A bao gồm hầu hết mọi thứ nhưng không phải là một số) ... nghe có vẻ như bạn đã xử lý khá tốt những gì Bạn đang tìm. Tôi đã không nhìn vào FreeRTOS mà Steve đã đề cập nhưng nếu nó đã được chuyển sang các bộ vi điều khiển cấp thấp thì có lẽ nó sẽ thực hiện việc quản lý lịch trình mà bạn cần.
Jason S

Nó dường như lưu trạng thái của từng luồng mặc dù ngăn xếp (giống như 50 câu lệnh đẩy / kéo) và có thể xử lý các ngắt thời gian. Hệ thống của tôi thường sử dụng ngắt cổng để chuyển đổi luồng, nhưng tác vụ có vẻ khả thi. Tôi muốn loại trang web này xử lý thảo luận trong một định dạng tốt hơn.
Kortuk

26

Bạn đã thử FreeRTOS chưa? Nó miễn phí (tuân theo T & C) và đã được chuyển sang cả MSP430 và một số hương vị của PIC.

Nó nhỏ so với một số người khác, nhưng điều này cũng giúp bạn dễ học, đặc biệt nếu bạn chưa sử dụng RTOS trước đây.

Giấy phép thương mại (không miễn phí) có sẵn, cũng như phiên bản IEC 61508 / SIL 3.


Cảm ơn bạn rất nhiều, tôi sẽ xem xét nó trong vòng một tuần, tôi sẽ để lại câu hỏi mở cho các câu trả lời khác, nhưng bạn là một trợ giúp tuyệt vời!
Kortuk

12

Tôi mới tìm hiểu về NuttX RTOS, thậm chí có thể hoạt động trên hệ thống 8052 (8 bit). Nó không có nhiều cổng, nhưng có vẻ thú vị. POSIX có thể là một điểm cộng, bởi vì nó có thể làm cho một số mã của bạn dễ mang theo hơn một chút nếu bạn chuyển lên bộ xử lý mạnh hơn và bạn muốn chạy linux hoặc QNX thời gian thực.

Bản thân tôi không có bất kỳ kinh nghiệm nào với RTOS thương mại, nhưng tôi đã sử dụng những sản phẩm tự chế trong nhiều năm! Họ rất giỏi trong việc giúp bạn phân chia sự phát triển mã của bạn cho nhiều lập trình viên, bởi vì về cơ bản họ có thể nhận được một "nhiệm vụ" hoặc "luồng" để làm việc từ phía họ. Bạn vẫn phải phối hợp và ai đó phải giám sát toàn bộ dự án để đảm bảo mỗi nhiệm vụ có thể thực hiện đúng thời hạn.

Tôi cũng khuyên bạn nên nghiên cứu Phân tích đơn điệu hoặc RMA khi sử dụng RTOS. Điều này sẽ giúp bạn đảm bảo rằng các nhiệm vụ quan trọng của bạn sẽ đáp ứng thời hạn của họ.

Tôi cũng sẽ xem xét khuôn khổ lập trình hướng sự kiện QP-nano của Miro Samek có thể hoạt động với hoặc không có RTOS mà vẫn cung cấp cho bạn khả năng thời gian thực. Với nó, bạn đang chia thiết kế của mình thành các máy trạng thái phân cấp thay vì các tác vụ truyền thống. Jason S đã đề cập đến cuốn sách của Miro trong bài viết của mình. Một đọc tuyệt vời!


9

Một điều tôi thấy hữu ích trên một số máy là trình chuyển đổi ngăn xếp đơn giản. Tôi chưa thực sự viết một cái cho PIC, nhưng tôi hy vọng cách tiếp cận sẽ hoạt động tốt trên PIC18 nếu cả hai / tất cả các luồng sử dụng tổng cộng 31 hoặc ít hơn các cấp độ ngăn xếp. Trên 8051, thói quen chính là:

_taskswitch:
  xch a, SP
  xch a, _altSP
  xch a, SP
  nghỉ

Trên PIC, tôi quên tên của con trỏ ngăn xếp, nhưng thường trình sẽ là một cái gì đó như:

_taskswitch:
  Movlb _altSP >> 8
  Movf _altSP, w, b
  Movff _STKPTR, altSP 
  Movwf _STKPTR, c
  trở về

Khi bắt đầu chương trình của bạn, hãy gọi một thường trình task2 () tải altSP với địa chỉ của ngăn xếp thay thế (16 có thể sẽ hoạt động tốt cho PIC18Fxx) và chạy vòng lặp task2; thói quen này không bao giờ trở lại nếu không mọi thứ sẽ chết một cái chết đau đớn. Thay vào đó, nó nên gọi _taskswitch bất cứ khi nào nó muốn mang lại quyền kiểm soát cho nhiệm vụ chính; sau đó, nhiệm vụ chính sẽ gọi _taskswitch bất cứ khi nào nó muốn chuyển sang nhiệm vụ phụ. Thông thường, người ta sẽ có những thói quen nhỏ dễ thương như:

void delay_t1 (val ngắn không dấu)
{
  làm
    nhiệm vụ ();
  while (không dấu ngắn) (mili giây_clock - val)> 0xFF00);  
}

Lưu ý rằng trình chuyển đổi tác vụ không có bất kỳ phương tiện nào để thực hiện bất kỳ 'chờ điều kiện'; tất cả những gì nó hỗ trợ là một spinwait. Mặt khác, công tắc tác vụ nhanh đến mức cố gắng thực hiện một tác vụ chuyển đổi tác vụ () trong khi tác vụ khác đang chờ đồng hồ hết hạn sẽ chuyển sang tác vụ khác, kiểm tra bộ hẹn giờ và chuyển trở lại nhanh hơn trình chuyển đổi tác vụ thông thường sẽ xác định rằng nó không cần taskswitch.

Lưu ý rằng đa nhiệm hợp tác có một số hạn chế, nhưng nó tránh được nhu cầu khóa và mã liên quan đến đột biến khác trong trường hợp bất biến tạm thời bị xáo trộn có thể được thiết lập lại nhanh chóng.

(Chỉnh sửa): Một vài cảnh báo về các biến tự động và như vậy:

  1. nếu một thường trình sử dụng chuyển đổi tác vụ được gọi từ cả hai luồng, thông thường sẽ cần phải biên dịch hai bản sao của thường trình (có thể bằng cách bao gồm cùng một tệp nguồn hai lần, với các câu lệnh #define khác nhau). Bất kỳ tệp nguồn đã cho nào cũng sẽ chỉ chứa mã cho một luồng hoặc nếu không sẽ chứa mã sẽ được biên dịch hai lần - một lần cho mỗi luồng - vì vậy tôi có thể sử dụng các macro như "#define delay (x) delay_t1 (x)" hoặc #define delay (x) delay_tx (x) "tùy thuộc vào chủ đề tôi đang sử dụng.
  2. Tôi tin rằng các trình biên dịch PIC không thể "nhìn thấy" một hàm được gọi sẽ cho rằng một hàm như vậy có thể bỏ qua bất kỳ và tất cả các thanh ghi CPU, do đó tránh việc phải lưu bất kỳ thanh ghi nào trong thói quen chuyển đổi tác vụ [một lợi ích tốt so với đa nhiệm ưu tiên]. Bất cứ ai xem xét một trình chuyển đổi tác vụ tương tự cho bất kỳ CPU nào khác đều cần phải biết về các quy ước đăng ký đang sử dụng. Đẩy các thanh ghi trước khi chuyển đổi tác vụ và bật chúng sau là một cách dễ dàng để xử lý mọi thứ, giả sử có đủ không gian ngăn xếp.

Đa nhiệm hợp tác không cho phép một người hoàn toàn thoát khỏi các vấn đề về khóa và như vậy, nhưng nó thực sự đơn giản hóa rất nhiều thứ. Ví dụ, trong một RTOS ưu tiên với bộ thu gom rác nén, cần phải cho phép các đối tượng được ghim. Khi sử dụng trình chuyển đổi hợp tác, điều này không cần thiết với điều kiện là mã giả định các đối tượng GC có thể di chuyển bất kỳ khi nào tác vụ chuyển đổi () được gọi. Một bộ sưu tập nén mà không phải lo lắng về các đối tượng được ghim có thể đơn giản hơn nhiều so với một đối tượng.


1
Câu trả lời tuyệt vời. Tôi nghĩ sẽ rất thú vị khi có được một số liên kết về các tài nguyên khi tiếp cận RTOS của riêng tôi. Trọng tâm của tôi ở đây thực sự là nhận được một RTOS chất lượng cao từ một nhà cung cấp đã thực hiện công việc đảm bảo thời gian thực khó khăn, nhưng đây có thể là một dự án sở thích thú vị cho bản thân tôi.
Kortuk

1
Thật

1
@JGord: Tôi đã thực hiện các trình chuyển đổi tác vụ nhỏ trên 8x51 và trên TI DSP. 8051, được hiển thị ở trên, được thiết kế cho chính xác hai nhiệm vụ. DSP một được sử dụng với bốn và nó phức tạp hơn một chút. Tôi chỉ có một ý tưởng điên rồ: một người có thể xử lý bốn nhiệm vụ chỉ bằng cách sử dụng ba trình điều khiển tác vụ. Mỗi khi một trong hai tác vụ đầu tiên muốn chuyển đổi tác vụ, nó sẽ gọi TaskSwitch1 và TaskSwitch2. Khi một trong hai nhiệm vụ thứ hai muốn tác vụ, nó sẽ gọi Taskswitch1 và Taskswitch3. Giả sử mã bắt đầu trong stack0 và mỗi trình chuyển đổi tác vụ được đặt với số ngăn xếp tương ứng.
supercat

@JGord: Hmm ... điều đó không hiệu quả lắm; nó dường như mang lại một vòng tròn 3 chiều và bỏ qua bộ chuyển đổi thứ ba. Vâng, thử nghiệm và tôi nghĩ rằng bạn có thể sẽ tìm thấy một công thức tốt.
supercat

7

Tôi đã sử dụng Salvo trên MSP430. Điều này rất nhẹ về tài nguyên bộ xử lý và, miễn là bạn tuân thủ các quy tắc thực hiện, rất dễ sử dụng và đáng tin cậy. Đây là một hệ điều hành hợp tác và yêu cầu các chuyển đổi tác vụ được thực hiện ở cấp độ gọi chức năng bên ngoài của các chức năng nhiệm vụ. Ràng buộc này cho phép HĐH hoạt động trong các thiết bị bộ nhớ rất nhỏ mà không cần sử dụng lượng lớn không gian ngăn xếp để duy trì bối cảnh tác vụ.

Trên AVR32 tôi đang sử dụng FreeRTOS. Một lần nữa rất đáng tin cậy cho đến nay nhưng tôi đã có một số khác biệt về cấu hình / phiên bản giữa phiên bản mà FreeRTOS xuất bản và phiên bản được cung cấp với khung Atmel. Điều này tuy nhiên có lợi thế là nó miễn phí!


5

Phiên bản tháng 12 của Điện tử thực hành hàng ngày có phần 3 của loạt bài về Hệ điều hành thời gian thực cho PIC (trong Cột kết hợp PIC n ') và có chi tiết thiết lập FreeRTOS với MPLAB và PICKit 2. Hai bài viết trước (tôi chưa thấy) dường như đã thảo luận về giá trị của các RTOS khác nhau và giải quyết trên FreeRTOS. Khi bài viết hiện tại đã thiết lập môi trường phát triển, họ tiếp tục bắt đầu thiết kế đồng hồ kỹ thuật số nhị phân. Dường như có ít nhất một phần nữa để đến với chủ đề này.

Tôi không chắc chắn EPE có sẵn ở Mỹ như thế nào, nhưng dường như có một Cửa hàng Hoa Kỳ được liên kết từ trang web của họ và có thể có các bản sao điện tử có sẵn.


4

Trình biên dịch CCS cho PIC đi kèm với RTOS đơn giản. Tôi đã không thử nó, nhưng nếu bạn có trình biên dịch này, nó sẽ dễ dàng thử nghiệm.


1
Tôi thực sự đã thử điều này như là lần đầu tiên của tôi. Nó không phải là một RTOS trong bất kỳ ý nghĩa thực sự của từ này. Nó không được ưu tiên trong bất kỳ cách nào. Nó yêu cầu sử dụng thường xuyên các lệnh hiệu suất để RTOS có thể quyết định ai sẽ chạy tiếp theo, bạn phải cố tình đưa chúng vào liên tục trong trường hợp chương trình khác cần tiếp quản.
Kortuk

2
Tôi nghĩ rằng nó vẫn được gọi là RTOS. Có vẻ như nó có một lịch trình hợp tác thay vì một lịch trình hoàn toàn phủ đầu.
Jay Atkinson

Vâng, về mặt kỹ thuật nó vẫn là một RTOS, nhưng tôi đã có và vẫn còn rất ít giá trị cho nó. Tôi biết đó là một việc cá nhân, nhưng với tôi nó cần phải được ưu tiên để có giá trị. Tôi vẫn +1 vì đó là một câu trả lời hay và có giá trị.
Kortuk

3

Cảm ơn! Có vẻ như hầu hết mọi người không nhận được câu hỏi, nhưng nó vẫn thú vị.
Kortuk

Tôi đã đăng lên câu hỏi về SO mời người dùng đến E & R để được giúp đỡ!
Kortuk

Tôi nghĩ rằng chúng tôi "có" câu hỏi về SO, nó đã hỏi điều gì đó khác biệt nhưng liên quan đến câu hỏi này. Đối với nhận xét của bạn có về chứng nhận; điều đó phụ thuộc vào nhiều thứ Nhìn vào các câu trả lời ở đây, tôi thích câu trả lời của DoxaLogos đề cập đến QP-nano; kinh nghiệm của tôi dẫn tôi đến việc thích mã hướng sự kiện hơn các luồng và chuyển đổi ngữ cảnh ngầm định của các luồng.
janm

2

Bạn chưa nói nhiều về ứng dụng của bạn. Việc bạn có sử dụng RTOS hay không phụ thuộc rất nhiều vào những gì bạn cần làm trong PIC. Trừ khi bạn đang thực hiện một số điều không đồng bộ khác nhau, đòi hỏi giới hạn thời gian nghiêm ngặt hoặc có một số luồng đang chạy, thì RTOS có thể là quá mức cần thiết.

Có nhiều cách để sắp xếp thời gian trên vi điều khiển tùy thuộc vào điều quan trọng nhất:

  1. Tốc độ khung hình không đổi: Ví dụ, đối với PIC chạy bộ điều khiển servo phải chạy ở 1000Hz. Nếu thuật toán PID mất ít hơn 1ms để thực thi, thì bạn có thể sử dụng phần còn lại của mili giây để thực hiện các tác vụ khác, như kiểm tra bus CAN, đọc cảm biến, v.v.

  2. Tất cả các ngắt: Mọi thứ xảy ra trong PIC được kích hoạt bởi một ngắt. Các ngắt có thể được ưu tiên theo tầm quan trọng của sự kiện.

  3. Dán nó trong một vòng lặp và làm mọi thứ nhanh nhất có thể. Bạn có thể thấy điều này cung cấp giới hạn thời gian phù hợp.


Tôi hiểu các phương pháp khác, nhưng tôi muốn mở rộng sang RTOS. Tôi sẽ chạy nhiều nhiệm vụ và có một hệ thống thời gian thực khó khăn, nhưng sẵn sàng bắt đầu mà không có yêu cầu của thời gian thực khó khăn. Cảm ơn bạn đã dành thời gian để trả lời, nhưng tôi muốn học RTOS để tôi có thể sử dụng nó trong tình huống có nhu cầu cao.
Kortuk
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.