Коли нам потрібна операційна система для вбудованої системи?

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

Моє правило полягає в тому, що вам слід розглянути операційну систему, якщо для продукту потрібне одне або більше з наступного: стек TCP / IP (або інший складний мережевий стек), складний графічний інтерфейс (можливо, один з об’єктами GUI, такими як Windows та події ) або файлову систему.

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

У міру збільшення вимог до програмного забезпечення суперконтур стає складнішим. Коли вимог до програмного забезпечення настільки багато, що супер-цикл стає занадто складним або не може виконати вимоги системи в реальному часі, настав час розглянути іншу архітектуру.

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

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

Це дійсно залежить від вашого визначення вбудованої системи. Можливо, є хтось, хто стверджує, що якщо це не програмування голими металами, він не вбудований (що виключає ваше запитання), але я не погоджуся з цим - я б заперечував, що будь-яка система, яка призначена виконувати лише одну функцію, тобто, щоб запустити лише одну конкретну програму, можна назвати вбудованою системою.

З огляду на це, слід досить легко уявити ситуації, які б виграли від послуг повноцінної ОС. Наприклад, там, де я працюю, досить часто зустрічаються люди, які будують тестове обладнання поверх набору інструментальних конструкцій, який працює над вікнами. Ці системи виконані з можливістю завантаження в конфігурацію тестової станції та блокування загального користування (для запобігання пошкодження станції) і, можливо, тому вбудовані системи.

Тим НЕ менше, просто відкупитися від готових модулів введення / виведення, підключити їх в стійку ПК і нагнітання конфігурацію в GUI може не кваліфікуватися як вбудовані системи проектування для деяких. Для трохи менш простої ситуації розгляньте спеціальний контролер процесу з FPGA, для якого ви хочете зробити кілька фантазійних журналів даних. Ви можете вбудувати програмну систему з основними процесорами (з існуючою BSP) та запустити Linux у режимі реального часу, щоб запустити мережевий стек (для вашої реєстрації та NTP тощо) та зробити все інше за логікою.

Моє (дуже розпливчасте) правило: якщо вам потрібно більше ніж один потік управління (скажімо, принаймні один пристрій, що включає протокол або стан машини, а також щось інше), то деякі для програмного забезпечення OSish полегшать ваше життя

Старе питання, але я все одно прокоментую.

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

RTOS також надає такі речі, як захист пам’яті тощо, що значно полегшує відстеження деяких загальних гафів у коді С, але прості мікроконтролери просто не можуть працювати зі складним захистом пам’яті. Напр., MSP430 дозволяє розділяти код і дані на високому рівні, але немає тонкозернистого контролю доступу до пам'яті.

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