Lợi ích của RTOS vs Bare Metal đối với lập trình MCU?

Xin lưu ý: Câu hỏi này đặc biệt đề cập đến hai RTOS nhưng chung chung hơn và có thể được trả lời bởi bất kỳ ai đã viết mã C cho RTOS nhúng trước đó và phần mềm của họ chạy trực tiếp trên MCU.

Tôi quan tâm đến việc tìm hiểu thêm về RTOS nhúng và viết các ứng dụng cho chúng. Tôi hiện đang xem Embox và RIOT vì chúng là nguồn mở, hiện đại, hoạt động và dường như có tài liệu tuyệt vời. Mục tiêu của tôi có hai giai đoạn: Giai đoạn 1 là tìm ra cách biên dịch và flash các hệ điều hành này vào MCU (có thể là AVR hoặc ARM). Giai đoạn 2 là sau đó viết một chương trình C đơn giản (về cơ bản là một daemon không đầu), sẽ phát triển theo thời gian như một "ứng dụng sở thích". Sau đó, tôi sẽ flash / triển khai chương trình này tới cùng MCU, từ đó triển khai thành công một appstack bao gồm Embox / RIOT và ứng dụng của tôi nằm trên nó.

Trước khi tôi đi vào bất kỳ con đường nào dẫn đến ngõ cụt, tôi tình cờ thấy bài viết này thực hiện khá tốt việc giải thích lý do tại sao các ứng dụng thời gian thực, được viết bằng C / trình biên dịch và flash vào MCU, không thực sự cần RTOS bên dưới chúng .

Vì vậy, bây giờ tôi thực sự bối rối, và đang đặt câu hỏi về một số hiểu biết cơ bản của tôi về lý thuyết điện toán. Tôi đoán tôi đang cố gắng đưa ra quyết định về việc có nên sử dụng Embox / RIOT ngay từ đầu hay không:

• Tiếp tục khóa học và đi với một "ngăn xếp ứng dụng" trên MCU của cả hai ứng dụng OS +; hoặc là
• Hãy chú ý đến cảnh báo của bài viết và chỉ cần đi với một MCU chạy ứng dụng của tôi "kim loại trần"

Rõ ràng, trước đây là công việc nhiều hơn, và vì vậy tốt hơn là có một lý do tốt / tiền chi trả cho việc đi theo con đường đó. Vì vậy, tôi hỏi: những lợi ích thực sự mà các RTOS nhúng này (và tương tự) cung cấp cho các nhà phát triển ứng dụng MCU / C là gì? Ứng dụng C nào của tôi có thể được hưởng lợi từ (có lẽ bằng cách không phát minh lại bánh xe?) Bằng cách sử dụng RTOS? Những gì đã mất bằng cách bỏ RTOS và đi kim loại trần?

Tôi đang yêu cầu các ví dụ cụ thể ở đây, không phải sự cường điệu về phương tiện truyền thông bạn nhận được khi bạn truy cập mục wikipedia cho RTOSes ;-)

Các chương trình vi điều khiển bao gồm một số nhiệm vụ . Giả sử bạn muốn chế tạo giá treo kính thiên văn điều khiển bằng máy tính. Các nhiệm vụ sẽ là:

• Lấy một byte đầu vào mới từ bộ đệm nối tiếp USB.
• Kiểm tra xem chúng tôi đã nhận được một lệnh hoàn chỉnh.
• Nếu vậy, thực hiện lệnh đó.
• Đọc các cảm biến cho vị trí kính thiên văn hiện tại.
• Đặt đầu ra thích hợp để điều khiển bước tiếp theo của động cơ.

Đây là một nhóm tác vụ khá điển hình cho một cái gì đó bạn sẽ sử dụng vi điều khiển và khá dễ quản lý với một vòng lặp vô hạn, như:

while(TRUE) {
  uint8_t input = readUsbBuffer();
  parseCommand(input);
  readSensors();
  setMotors();
}

Nếu bạn tiếp tục thêm và thêm các tính năng, cuối cùng bạn sẽ bắt đầu gặp các vấn đề phổ biến mà bạn muốn tạo ra sự trừu tượng hóa, như:

• Bộ đệm của bạn bị tràn, vì vậy bạn muốn đảm bảo rằng tác vụ đó có thể làm gián đoạn các tác vụ khác trước khi nó tràn ra.
• Bạn muốn tiết kiệm pin bằng cách ngủ khi không cần thiết.
• Bạn muốn đảm bảo tất cả các nhiệm vụ có được một cảnh quay công bằng. Nếu readSensorsmất quá nhiều thời gian, bạn muốn có thể làm gián đoạn nó và quay lại với nó sau.
• Bạn muốn có thể chỉ cần thiết lập lại một nhiệm vụ mà không ảnh hưởng đến người khác.
• Bạn muốn rò rỉ bộ nhớ hoặc lỗi khác trong một tác vụ để không loại bỏ các tác vụ khác.
• Bạn muốn có thể đưa ra các nhiệm vụ khác nhau ưu tiên khác nhau.
• Bạn muốn có thể sandbox một nhiệm vụ không đáng tin cậy.
• Bạn muốn có thể thực hiện các nhiệm vụ ở các mức độ khác nhau. Có lẽ cảm biến của bạn chỉ có thể được đọc 10 lần mỗi giây, nhưng bạn muốn thực hiện một bước động cơ 100 lần mỗi giây.

Một hoặc hai trong số các mục này có thể được xử lý bằng tay tương đối dễ dàng. Nếu bạn có đủ các loại vấn đề này thường xuyên đủ để bạn bắt đầu khái quát chúng vào các thư viện, về cơ bản bạn đã phát minh lại một RTOS. Nếu quản lý tác vụ của chương trình của bạn đủ phức tạp, ngay cả khi bạn không sử dụng RTOS ngoài luồng, cuối cùng bạn sẽ phát minh lại một cách kém.

Tuy nhiên, theo kinh nghiệm của tôi, dòng nơi bạn muốn RTOS rất gần với dòng nơi bạn muốn có bộ vi xử lý thay vì vi điều khiển. Nếu bạn dự đoán phần sụn của bạn trở nên phức tạp, thì tốt hơn là nên đi theo con đường vi xử lý ngay từ đầu.

Tôi đã viết thư viện đa luồng hợp tác của riêng mình cho ARM Cortex-M0.

Đó chỉ là một vài trang mã và phiên bản đầu tiên của nó không mất nhiều hơn một ngày để viết và gỡ lỗi.

Ưu điểm lớn của roll-your-own là bạn biết mã và bạn có thể chuyển nó sang chip mà RTOS có thể không hỗ trợ. Ngoài ra, bạn dành ít thời gian hơn để suy nghĩ về các câu hỏi như "nó có bị sập không. Tôi có cố gắng sử dụng đồng thời các tính năng A và B không?" Vì bạn đã viết mã, bạn biết câu trả lời.

Luồng là điều chính bạn nhận được từ một RTOS, và hóa ra đó không phải là một vấn đề lớn để tự thực hiện. Thật hiếm khi bạn cần nhiều tính năng của RTOS. Nhưng nếu bạn đáp ứng yêu cầu của bạn và hóa ra bạn làm vậy, thì hãy sử dụng RTOS.