Переваги RTOS проти Bare Metal для програмування MCU?

Зверніть увагу: Це питання спеціально згадує два RTOS, але є більш загальним і на нього, ймовірно, може відповісти хто-небудь, хто раніше написав код C для вбудованих RTOS, і своє програмне забезпечення запускалося безпосередньо на MCU.

Мені цікаво дізнатися більше про вбудовані RTOS та написання програм для них. Зараз я дивлюся на Embox та RIOT, оскільки вони з відкритим кодом, сучасні, активні і, здається, мають чудову документацію. Моя мета має дві фази: Фаза 1 - з'ясувати, як компілювати та прошивати ці ОС у MCU (можливо, AVR або ARM). Фаза 2 полягає в тому, щоб написати просту програму C (в основному безголовий демон), яка б розвивалася з часом як "додаток для хобі". Потім я б прошив / розгорнув цю програму в тому ж MCU, тим самим успішно розгорнувши програму, що складається з Embox / RIOT та мого додатка, розміщеного поверх нього.

Перш ніж спуститися на будь-які дороги, які в кінцевому підсумку призводять до тупиків, я наткнувся на цю статтю , яка досить добре пояснює, чому додатки в режимі реального часу, написані на C / асемблері та прошиті до MCU, насправді не потребують RTOS під ними. .

Тож зараз я справді розгублений і ставлю під сумнів деякі мої фундаментальні розуміння теорії обчислень. Я думаю, я намагаюся прийняти рішення про те, чи потрібно взагалі використовувати Embox / RIOT:

• Залишайте курс і перейдіть з "стеком додатків" на MCU обох ОС + додаток; або
• Прислухайтеся до попередження статті та просто перейдіть з MCU, який працює в моєму додатку "голий метал"

Очевидно, що колишнє - це більше роботи, і тому для того, щоб пройти цей маршрут, краще було б бути вагомою причиною. Тож я запитую: які реальні переваги ці (та подібні) вбудовані RTOS пропонують розробникам додатків MCU / C? Від яких конкретних особливостей може отримати користь моя програма C (можливо, не винаходивши колесо?) За допомогою RTOS? Що втрачається, викидаючи RTOS та голий метал?

Я прошу конкретних прикладів тут, а не медійного шуму, який ви отримуєте, коли переходите до Вікіпедії для RTOSes ;-)

Програми мікроконтролерів складаються з ряду завдань . Скажімо, ви хотіли зробити комп'ютерне кріплення телескопа. Завданнями були б:

• Отримайте новий байт вводу з послідовного буфера USB.
• Перевірте, чи ми отримали повну команду.
• Якщо так, виконайте цю команду.
• Прочитайте датчики поточного положення телескопа.
• Встановіть правильний вихід для управління наступним кроком двигунів.

Це досить типовий набір завдань для того, для чого ви використовували б мікроконтролер, і ними досить легко керувати нескінченним циклом, наприклад:

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

Якщо ви продовжуєте додавати та додавати функції, ви з часом натрапите на поширені проблеми, для яких потрібно створити абстракції, наприклад:

• Ваш буфер переповнений, тому ви хочете переконатися, що завдання може перервати інші завдання, перш ніж воно переповнене.
• Ви хочете заощадити акумулятор, сплячи, коли нічого не потрібно.
• Ви хочете переконатися, що всі завдання отримують справедливий результат. Якщо це readSensorsзайняло занадто багато часу, ви хочете мати можливість перервати його і повернутися до нього пізніше.
• Ви хочете мати можливість просто скинути одне завдання, не зачіпаючи інших.
• Ви хочете, щоб витік пам'яті чи інша помилка в одному завданні не переносили інші завдання.
• Ви хочете мати можливість давати різним завданням різні пріоритети.
• Ви хочете мати можливість пісочниці - не довірене завдання.
• Ви хочете мати можливість виконувати завдання з різною швидкістю. Можливо, ваші датчики можна прочитати лише 10 разів на секунду, але ви хочете виконати крок двигуна 100 разів за секунду.

Один або два з цих предметів можна обробляти вручну відносно легко. Якщо у вас досить часто виникають подібні проблеми, щоб почати узагальнювати їх у бібліотеках, ви в основному винаходили RTOS. Якщо управління завданнями вашої програми є досить складним, навіть якщо ви не використовуєте позачерговий RTOS, ви в кінцевому підсумку переймете винахід погано.

Однак, на мій досвід, лінія, де потрібно RTOS, дуже близька до лінії, де потрібно мікропроцесор замість мікроконтролера. Якщо ви передбачаєте отримання вашої прошивки такою складною, зазвичай краще пройти маршрут мікропроцесора з самого початку.

Я написав власну кооперативну багатопотокову бібліотеку для ARM Cortex-M0.

Це було ледь пару сторінок коду, і перша версія його не потребувала більше часу, ніж день, щоб написати та налагодити.

Великою перевагою власної ролики є те, що ви знаєте код і можете перенести його на чіпи, які RTOS може не підтримувати. Крім того, ви витрачаєте менше часу на роздуми над питаннями на кшталт "чи не вдасться я спробувати одночасно використовувати функції A і B?" Оскільки ви написали код, ви знаєте відповідь.

Нитки - це головне, що ви отримуєте від RTOS, і виявляється, що це не така велика справа, щоб реалізувати себе. Рідко коли вам потрібно багато функцій RTOS. Але якщо ви стискаєте свої вимоги, і виявляється, що ви це зробите, тоді використовуйте RTOS.