Мікро операційні системи на контролерах avr. Мікроконтролери застаріли? Операційні системи реального часу

Я розробив трохи більше 10 електронних пристроїві цілком обходився в їхній низькорурівневій роботі без операційної системи. Ситуація змінилася, коли функціонал наступного девайса різко розширився. Крім того, виникла потреба в задачі, яка викликається через задані інтерваличасу, причому точність виклику впливає результат. Також стало зрозуміло, що написати все програмне забезпечення за виділений час не вийде, і воно буде створено пізніше. Після недовгих роздумів я зрозумів, що проект необхідно включити операційну систему реального часу (ОСРВ чи RTOS).

На відміну від ПК, де ОС - це більше шар для роботи з системними ресурсами, для мікроконтролера ОСРВ - це насамперед планувальник завдань, що він і відіграє головну роль у «реальному часі». На даний момент для мене важливо забезпечити так зване псевдопаралельне виконання завдань. Тобто є кілька завдань із однаковим пріоритетом і важливо викликати в заданому порядку через задані інтервали часу.

Наглядний наступний приклад: у проекті Євробот 2011 у системі було 18 периферійних пристроїв. 2 електронні плати можна було по функціоналу об'єднати в одне. Знизилася б їхня вартість, підвищилася надійність (зменшили кількість компонентів у системі), збільшилася кількість вільного місцяу корпусі. Обставина ускладнює те, що кількість завдань зростає пропорційно і вже не обійтися без ОС. Також ОСРВ допомагає уникнути можливих простоїв роботи процесора, наприклад, під час перетворення АЦП, ви можете заблокувати це завдання і виконувати інші, тим самим правильно розподіляючи роботу пристрою. Важливо й те, що тепер пристрій не впаде через збій у задачі, натомість можливе збереження часткової працездатності (хоча це може призвести до непередбачуваних результатів). За рахунок чого ми забезпечуємо зростання цих показників? Власне, ми вичавлюємо з МК усе можливе, ефективно використовуючи його обчислювальні можливості.

Після недовгих пошуків вибір ліг на freeRTOS. Ця ОСРВ поширюється у вихідниках С і портована на 27 архітектур. Остання обставина для мене – вирішальна. Воно знизить трудовитрати під час роботи з МК інших виробників. Зараз мене більше цікавить порт для AVR.

Наявність ОСРВ freeRTOS у проекті з'їдає у вас близько 9.8 Кб пам'яті програм та 1.8 Кб ОЗУ. Наприклад для ATmega32 і компілятор WinAVR це 60% і 85% відповідно. Вже для цієї моделі створити девайс із великим функціоналом складно – не вистачить пам'яті. Але ця проблема відпадає під час використання нових моделей AVR. Це абсолютно дарма для Mega2560 з її 256Кб пам'яті програм і 8 Кб ОЗУ. Тенденція майбутніх МК лише супроводжує успіх ОСРВ.

Побіжно пробігшись по рунету, я з подивом виявив, що немає документації на ОС російською мовою. Та яке тут! Оригінальна документація поширюється на додаткову вартість. Ситуацію спростила стаття Андрія Курниця ( [email protected]) з журналу «Компоненти та технологи». За згодою з автором я використовуватиму матеріали статті у переробленому варіанті. Його стаття цілком може бути документацією російською мовою. Але оригінал недоступний у друкованому вигляді, сайт журналу лежить, тому матеріал доведеться трохи переробити. В цілому автор зробив відмінну статтю і немає сенсу ще раз пройтися по теорії, вона буде повністю опублікована тут. Оригінал статті буде доданий наприкінці публікації. Також я помітив, що користувачі мали труднощі при компіляції ОСРВ. Це пов'язано з тим, що використовується зовнішній makefile, в якому прописані шляхи до папок. Тому я прикладу готовий проект у вигляді шаблону для AVR Studio та AVR Eclipse. На жаль, рідний makefile не виводить налагоджувальну інформацію, таку, як ступінь зайнятості ОЗУ та пам'яті програм, це довелося пофіксувати, додавши відповідний стандартний виклик.

Отже, коротко про необхідність, у вашому проекті бажано використовувати ОСРВ, якщо необхідно:

Організувати мультизадачність та почергове виконання завдань

Забезпечити запуск завдання через певні інтервали часу

Передати інформацію від одного завдання до іншого

Додавати при необхідності нові завдання

Переваги ОСРВ перед МДо:

1. Багатозадачність. ОСРВ надає програмісту готовий, налагоджений механізм багатозадачності. Кожне завдання у випадку можна програмувати окремо, всю роботу розбити між кількома членами команди. Не потрібно дбати про перемикання між завданнями, це зробить планувальник.
2. Тимчасова база. Потрібно відміряти інтервали часу. ОСРВ повинен мати цей інструмент. Він дозволить виконувати дії через чітко виділені інтервали часу.
3. Обмін даними між завданнями. Для цього в ОСРВ використовується черга.
4. Синхронізація. Якщо різні завданнявикористовують той самий ресурс, наприклад послідовний порт, можна використовувати мьютексы і критичні секції. Якщо необхідно виконувати завдання у суворій послідовності або при настанні певної події, можна використовувати семафори або сигнали для синхронізації завдань.

Недоліки ОСРВ:

1. Різке збільшення потрібної пам'яті програм реалізації ядра

2. Збільшення потрібної ОЗП для зберігання стека кожного завдання, семафорів, черг, м'ютексів та інших об'єктів ядра системи.

3. Затримки під час перемикання між завданнями на збереження контексту.

ОписfreeRTOS:

FreeRTOS – це безкоштовна ОС жорсткого реального часу з відкритим кодом. Переважно написана на С, але є асемблерні вставки. Вона була розроблена компанією Real Time Engineers ltd спеціально для систем, що вбудовуються. Нещодавно почав розвиватися проект "SafeRTOS" - доопрацьований, документований, протестований і пройшов сертифікацію на відповідність стандарту безпеки IEC 61508 варіант FreeRTOS. Цим проектом займалася німецька компанія і тепер safeRTOS використовується в аерокосмічній промисловості та медичній техніці. Також існує проект openRTOS – комерційна версія з гарантією виробника.

Основні характеристики freeRTOS:

1. Планувальник підтримує 3 типи багатозадачності:

Витіснюючи

Кооперативну

Гібридну

2. Розмір ядра складає 9.8 Кб у скомпільованому вигляді для AVR. (WINAVR)

3. Основа ядра - 4 файли на С.

4. Підтримує завдання та співпрограми. Співпрограми спеціально створені для МК із малим обсягом ОЗУ.

5. Багаті можливості трасування.

6. Можна відстежувати переповнення стека.

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

8. Немає обмеження на кількість пріоритетів завдань.

9. Декільком завданням може бути призначений однаковий пріоритет

10. Розвинені засоби синхронізації «завдання-завдання» та «завдання-переривання»:

Черги

Двійкові семафори

Рахункові семафори

Рекурсивні семафори

М'ютекси

11. М'ютекси з наслідуванням пріоритету.

12. Підтримка модуля захисту пам'яті для Cortex-M3

13. Постачається у налагодженому вигляді з демо-проектами для різних платформ та компіляторів.

14. Безкоштовна. Можна використовувати проекти без розкриття вихідного коду відповідно до розширеної ліцензії GPL.

15. Документація платна, але доступна онлайн тут.

16. Час перемикання контексту для AVR з кварцом на 16МГц становитиме лише 20.8 мкс. Саме стільки потрібно для збереження даних у стек завдання та виклик наступного. (Цікаве зауваження, якщо порівняти це з PIC18xxx, то контролер від AVR робить це швидше в 4 рази!, швидше за все це пов'язано з якістю компілятора)

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

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

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

Кооперативна багатозадачність відрізняється від витісняючої тим, що планувальник самостійно не може перервати виконання поточного завдання, навіть готове до виконання завдання з великим пріоритетом. Кожне завдання має самостійно передати управління планувальнику. Таким чином, високопріоритетне завдання чекатиме, поки низькопріоритетне завершить свою роботу і віддасть управління планувальнику. Час реакції системи на зовнішню подію стає невизначеним і залежить від того, як довго поточне завдання виконуватиметься до передачі управління. Кооперативна багатозадачність застосовувалася у сімействі ОС Windows 3.x.

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

З чогоначать?

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

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

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

Детальну структуру директорій наведено на малюнку.

Весь вихідний код ядра знаходиться у директорії /Source.

Вміст:

1.tasks.c- реалізація механізму завдань, планувальник

2. queue.c- реалізація черг

3. list.c- внутрішні потреби планувальника, проте функції можуть використовуватись і в прикладних програмах.

4. croutine.c- реалізація співпрограм (може бути відсутнім у разі, якщо співпрограми не використовуються).

Заголовні файли, що знаходяться в директорії source/include

1. tasks.h, queue.h, tist.h, croutine.h- заголовні файли відповідно для однойменних файлів із кодом.

2. FreeRTOS.h- Містить препроцесорні директиви для налаштування компіляції.

3. mpu_wrappers.h- Містить перевизначення функцій програмного інтерфейсу (API-функцій) FreeRTOS для підтримки модуля захисту пам'яті (MPU).

4. portable.h-платформозалежні налаштування.

5. projdefs.h-деякі системні визначення

6. semphr.h- Визначає API-функції для роботи з семафорами, які реалізовані на основі черг.

7. StackMacros.h- Містить макроси для контролю переповнення стека. Кожна апаратна платформа вимагає невеликої частини коду ядра, яка реалізує взаємодію FreeRTOS із цією платформою. Весь платформно-залежний код знаходиться в піддиректорії /Source/Portable, де він систематизований середовищ розробки (IAR, GCC і т.д.) і апаратних платформ (наприклад, AtmelSAM7S64,MSP430F449). Наприклад, піддиректорія /Source/Portable/ GCC/ATMega323містить файли port.c і portmacro.h, що реалізують збереження/відновлення контексту завдання, ініціалізацію таймера для створення тимчасової бази, ініціалізацію стека кожного завдання та інші апаратно-залежні функції мікроконтролерів сімейства mega AVR і компілятора WinAVR (GCC).

Окремо слід виділити піддиректорію /Source/Portable/MemMang, в якій містяться файли heap_l.c, heap_2.c, heap_3.c, що реалізують 3 різні механізми виділення пам'яті для потреб FreeRTOS, які будуть докладно описані пізніше.

У директорії /Demo знаходяться готові до компіляції та збирання демонстраційні проекти. Загальна частина коду для всіх демонстраційних проектів виділена до піддиректорії /Demo/Commo n.

Щоб використовувати FreeRTOS у своєму проекті, необхідно включити файли вихідного коду ядра і супутні заголовкові файли. Немає необхідності модифікувати їх чи розуміти їхню реалізацію.

Наприклад, якщо планується використовувати порт для мікроконтролерів MSP430 і GCC-компілятор, то для створення проекту з нуля знадобляться піддиректорії /Source/ Portable/GCC/MSP430_GCCта / Source/Portable/ MemMang. Всі інші піддиректорії з директорії /Source/Portable не потрібні та можуть бути видалені.

Якщо планується модифікувати існуючий демонстраційний проект (що, власне, і рекомендується зробити на початку вивчення FreeRTOS), то знадобляться також піддиректорії /Demo/msp430_GCCі /Demo/Common. Інші піддиректорії, що знаходяться в /Demo, не потрібні і можуть бути видалені.

Під час створення програми рекомендується використовувати makefile(або файл проекту середовища розробки) від відповідного демонстраційного проекту як відправну точку. Доцільно виключити зі складання (build) файли з директорії /Demo, замінивши їх своїми, а файли з директорії /Source - недоторканими. Слід згадати також про заголовний файл FreeRTOSConfig.h, що знаходиться у кожному демонстраційному проекті. FreeRTOSConfig.h містить визначення (#define), що дозволяє зробити налаштування ядра FreeRTOS:

1. Набір системних функций.

2. Використання співпрограм.

3. Кількість пріоритетів завдань та співпрограм

4. Розміри пам'яті (стека та купи).

5. Тактова частотаМК.

6. Період роботи планувальника часу, що виділяється кожній задачі виконання, який зазвичай дорівнює 1 мс. Вимкнення деяких системних функцій та зменшення кількості пріоритетів (зменшує витрати пам'яті).

У дистрибутив FreeRTOS включені також засоби для конвертування трасувальної інформації, отриманої від планувальника, текстову форму (директорія /ТгасеСоn) та текст ліцензії (директорія /License).

Висновки

За допомогою першої статті циклу читач познайомився з операційною системою мікроконтролерів FreeRTOS. Показано особливості роботи. Опис вміст дистрибутива FreeRTOS. Наведено основні кроки, з яких слід розпочинати розробку пристрою, який працює під керуванням FreeRTOS.

У наступних публікаціях увага буде приділена механізму багатозадачності, а саме завданням та співпрограмам. Буде наведено приклад роботи планувальника на прикладі мікроконтролерів AVR фірми Atmel і компілятора WinAVR (GCC).

Що спадає на думку коли чуєш операційна система? Напевно кватирки, лінукс, макось.. або щось подібне. Правильно, і на питання навіщо вона потрібна, всі впевнено дадуть відповідь: послухати музику, пограти в гру (по інтернету!), розмовляючи при цьому з другом по скайпу. Заодно споглядаючи, як блимає світлодіод, отримавши байт з юарта =).

А якщо копнути глибше, то прослуховування музики, пересилання даних через Інтернет — це все одиночні процеси, а оскільки процесор у нас один, то одночасно він може виконувати лише одне завдання. Тому завдання виконуються почергово невеликими «порціями», суть ОС робити це непомітно для користувача: щоб звук не хрипів і байтики слали і все працювало одночасно. При цьому якщо одне із завдань «повисне», то все інше продовжувало працювати.

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

Є два основні види ОС: витісняюча та кооперативна. У першому випадку, перемикання між завданнями буде «жорстким», тобто. якщо квант часу 1мс, то спочатку перше завдання виконуватиметься рівно 1мс, потім друге рівно 1мс і т.д. Такі осі називаються реальним часом (ОСРВ). У кооперативних трохи простіше, процес сам повинен сказати, що «я здійснився», тому до ОСРВ їх віднести не можна.

Вгамувати витісняючу на дрібні AVR не вийде через невелику кількість ОЗУ. З наявних варіантів кооперативок, мені сподобалася mRTOS, почитати подробиці цієї системи можна на сайті автора (легко Гугл). Головна причина її використання – простота, наявність готової версії під CAVR для розуміння загальних принципівсаме те.

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

Тому варто поставити собі кілька запитань:
1. Чи зможете ви розпорядитися грамотно ресурсами?
2. Чи не передбачається в процесі написання прошивки винаходити такий же велосипед, подібний до планувальника?
3. Наскільки читаємо ваш код? Чи здатні Ви через півроку-рік відкрити його і відразу розібратися?
4. Чи один ви пишете або групою?

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

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

Тепер заглянемо під капот. Для запуску mRTOS до проекту потрібно підключити mrtos.c та зафіксувати mrtos.h. Структура коду трохи відрізняється від звичного

#include #include "mrtos.h" //тут тіло функції де ми пишемо свій супер код void task1() ( while(1)//завдання в будь-якій ОС побудовані на базі нескінченного циклу ( //тут код Вашого завдання DISPATCH; //функція передачі управління планувальнику);) // обробник переривання таймера 0 interrupt void timer0_ovf_isr(void) (char ii; #asm("cli") TCNT0=0x9C; inc_systime(); for(ii = 0; ii

Тепер докладніше. кількість завдань вказується в mrtos.h дефайному APPTASKS N. Завдання оголошується всередині task1()(), task2()() тощо, всередині while(1) не потрібно нічого писати, викликати функції теж ніяк не потрібно, все це зробить за вас планувальник. Як бачимо завдання складається з нескінченного циклу, це нормально так і має бути, але всередині завдання потрібно обов'язково віддавати управління планувальнику. Або функцією WAIT, чи DISPATCH. Якщо цього зробити, то завдання виконуватиметься нескінченно.

Як це працює? Створимо таск блимання світлодіодом.

void task1() ( while(1) ( PORTB.0 = !PORTB.0; WAIT(100); ); )

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

При використанні WAIT важливо розуміти, що вся система має мінімальний тик (квант часу), тому ми чекаємо не WAIT(50) 50 мілісекунд, а 50 тиків системи. Налаштування тику залежить від цього, як часто викликається переривання таймера0, тобто. якщо ми налаштували переривання на 1мс, ми можемо припускати, що дію виконається протягом 1мс. Досліди показали, що зменшити системний тик можна до ~20 мкс при тактовій 16МГц.

Налаштування таймера нічим не відрізняється вивченого раніше, так як таймер0 має тільки переривання по переповненню, всі налаштування зав'язані на це. В останніх версіях CAVR дуже зручно зроблено можна писати time requiments, налаштування автоматично згенеруються.

create_task(task1,1,Active);

З пріоритетами все досить непросто. Якщо є дві задачі з різними пріоритетом і завдання з великим пріоритетом постійно виконується, то завдання з низьким пріоритетом ми ніколи не зайдемо. Тому потрібно організовувати роботу так, щоб усі завдання отримували доступ. Загострювати увагу на цьому не будемо, припасемо наступного разу. Стан завдання, Active - запущена, зупинена StopTask.

Отже, для охочих просто блимнути світлодіодом:

#include #include "mRTOS.h" void task1() ( while(1) ( WAIT(1000); PORTB.0=!PORTB.0; ) ) // Timer 0 overflow interrupt service rutina interrupt void timer0_ovf_isr(void) ( char ii #asm("cli") TCNT0=0xb2; inc_systime(); for(ii = 0;ii

Як бонус я спробував зробити поліфонічну (двоголосу) мелодію «Dr.Mario chill». Ідея в тому, що кожна ніжка контролера постійно інвертується в окремому тягу, тим самим генеруючи частоту. Змінюючи зачіпку можна змінювати висоту ноти.

void task2(void) ( while(1) ( if(mute == 0) //якщо дозволено грати ( if(note_ch2 == 0) //якщо пауза то чекаємо, нічого не граємо ( PORTB.4 = 0; WAIT( 5); ) else ( PORTB.4 = !PORTB.4; //якщо не пауза то бригаємо ногою з потрібною частотою WAIT(note_ch2); ) ) ) ))

Я не морочився з ідеєю, в 1 тасці генерується меандр із частотою ноти для соло партії, у другому для басу. Висота кожної ноти береться із масивів. Тривалість, перемикання та обривання в таске3.

void task3 (void) (while (1) (WAIT (1500); // граємо мінімальну тривалість ноти for (mute = 0; mute)< 500; mute++) //обрываем ноту, чтобы не сливались { PORTB.3 = 0; PORTB.4 = 0; }; mute = 0; //выставляем флаг, что можно воспроизводить звук n_n++; //переходим на следующую ноту if(n_n == n_max) //если сыграли все то идем по кругу { n_n = 0; } } }

Щоб змішати два канали використовував просту схему.

Разом невеликий шматочок

Для бажаючих прошивка

Обидва Stellaris Launchpad і Arduino Due дуже потужні, але не призначені для запуску Linux. Вони працюють або на виконуваному коді, написаному безпосередньо для них, або під управлінням операційної системи реального часу (RTOS) - мінімалістичної ОС, з дуже коротким часом реакції на зовнішні події. Також вони обидва значно складніше, ніж MSP430 або 8-бітні AVR.

З іншого боку, в реальному житті (за межами інтернету), більшість, кого я знаю, використовують Raspberry Pi або інші системи, що вбудовуються на Linux. Використання саме мікроконтролерів, досить рідкісний випадок серед тих, кого я зустрічав. Навіть Arduino, набагато менш популярно, в моєму оточенні, ніж вбудований Linux. Як я це розумію, – навіщо комусь купувати Arduino, коли можна придбати Raspberry Pi, який може набагато більше, а коштує стільки ж чи менше? Під Linux є безліч готового софту, і на ньому можна програмувати, використовуючи прості скриптові мови.

Особисто для мене, причина, через яку я не бажаю використовувати Linux, це тому, що я щодня використовую його на роботі, і повертаючись додому, не відчуваю задоволення від необхідності знову працювати на Linux-подібних системах. У мене немає проблем з використанням Linux, але його занадто багато усюди, він мене гнітить. Мені набагато цікавіше працювати з простими електронними пристроями на 8-ми/16-бітних мікрочіпах.

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

У моєму проекті розумного будинку я реально зіткнувся з цією проблемою. Я вже зробив драйвер локальної мережі для системи контролю на MSP430 і все виглядає дуже гідно. Насправді, я можу зробити все, що необхідно для системи автоматизації на MSP430. Проте, я замислююся, чи правильно те, як це роблю? Чи не намагаюся я, чи є суп виделкою, коли є ложка? Можливо, Linux більш схожа система? Дозвольте, я поясню.

Якщо зупинитися та поглянути на поточну ситуацію, за технологічними досягненнями на листопад 2012 року. Я запитую себе, чи досить хороші та актуальні мікроконтролери, порівняно із системами-на-чіпі, які використовують Linux?

Якщо перераховувати проекти на вбудовуваних системах, які спадають мені на думку, це: дрони, роботи, домашня автоматизація, контролери моторів, сенсори, наручний годинник, 3D-принтери тощо. У яких із цих випадків, вбудований Linux підходить більше, ніж мікроконтролери? І чому?

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

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

Наприклад, для проекту розумного будинку, я можу розробити дистанційно контрольований вимикач. Він може включати/вимикати світло або щось інше. У той же час, я можу піти в місцевий магазин електротехніки і купити те саме за $20, вироблене в Китаї. Чи можу я колись перебити цю ціну, спробувавши продавати власний вимикач? Не думаю що це можливо.

Якщо замислитися, це відноситься і до багатьох інших речей, необхідних для домашньої автоматизації. Датчики температури, диму, руху і т.д., я цілком здатний самостійно зробити такі ж, але навряд чи з цього можна отримати фінансову вигоду. Кому цікаво купувати такі речі у мене за $75, коли вони можуть знайти їх за $20 у Госптоварах?

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

Але бажання, досягти вигіднішої ціни остаточного пристрою, не означає, що потрібно використовувати найдешевший мікроконтролер на Землі. Насправді це погана ідея, т.к. час розробки той самий має власну вартість, як і деталі. Можливо, мікроконтролер дешевий, але вимагає більше часу для написання коду, що управляє. Час – гроші, і якщо ви працюєте швидше, ви встигнете більшого досягти.

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

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

З іншого боку, мікроконтролери можуть бути кращим вибором, ніж системи на чипі, коли необхідне низьке споживання енергії. У таких системах є два моменти: низьке споживання самої схеми, під час роботи та короткий час старту. Типовим способом економії батареї для дрібних пристроїв є самовідключення (shut off). Коли ви вимикаєте комп'ютер на Linux, йому потрібен пристойний час, щоб повернутися до роботи, іноді до декількох хвилин. Такий час не прийнятний для систем, що вбудовуються.

Якщо взяти такий мікроконтролер, як MSP430, він може роками працювати від однієї батарейки. Stellaris Launchpad і Arduino Due, в принципі те ж саме на таке здатні, вони споживають більше енергії ніж MSP430, але все-таки дуже мало, порівняно з Raspberry Pi. Ще, MSP430, може моментально стартувати після вимкнення.

Таким чином, я абсолютно впевнений, що у всіх ситуаціях, де необхідні низьковольтні операції, є сенс використовувати мікроконтролери. Існує безліч різноманітних пристроїв, що працюють на батарейках, де виникає така необхідність.

У третьому випадку, як я вже говорив, використання мікроконтролера більш осмислено, ніж Linux, в операціях, що потребують моментальної реакції (realtime response). Я маю на увазі такі пристрої, як 3D-принтери та верстати ЧПУ, я знаю, про що говорю, тому що присвятив багато часу їх вивченню. За своєю природою, вони вимагають високої точності в роботі, яка менш ніж повністю залежить від часу реакції на команди.

Наприклад, якщо у вас запущена циркулярна пилка, яка відрізає в даний момент шматок дерева або металу, ви не можете зупинити процес, через те, що комп'ютеру, який їй керує, знадобилася пауза, щоб скинути дані з пам'яті на диск або щось інше в тому ж дусі. Будь-хто, хто використовував ПК, знайомий з випадковими підвисаннями, що періодично виникають під час звичайної роботи. А тепер уявіть собі, що у вас великий свердлильний верстат, під керуванням ПК, який раптом починає перевіряти оновлення для Windows, під час роботи, і дриль, свердлить наскрізь стіл, на якому стоїть, тому що це не так. комп'ютер втратив над нею контроль.

ПК та системи-на-чіпі не призначені для роботи в реальному часі, хоч з Windows, хоч з Linux, але само собою вони намагаються до цього наблизитися. Як приклад, існує патч реального часу для ядра Linux і спеціальний ЧПУ софт, створений для роботи такого роду. Я мало знайомий з цим патчем Linux, і не знаю, наскільки він гнучкий, для повного контролю подій реального часу. Але гадаю, що це лише можлива альтернатива, т.к. Linux, які б патчі на нього не навішували, ніколи не поб'є мікроконтролери в цій галузі завдяки наявності у них системи переривань.
На закінчення хочу сказати, що витратив багато часу, намагаючись знайти області, де застосування мікроконтролерів в моїх проектах має перевагу. І все виглядає так, що прийшла епоха світового домінування Raspberry Pi та Beaglebones. Це поточна ситуація у DIY спільноті. У більшості випадків, швидше і легше розробляти на цих системах, так що найчастіше це найкращий вибір для більшості проектів.

Для мікроконтролерів залишаються лише області низьковольтних пристроїв, операцій реального часу та пристроїв низької вартості.

Це не залежить від того, що мікроконтролери можуть здаватися «веселіше» ніж ПК. Це те, з чим доведеться змиритись.

Переклад з англійської мови оригінального посту

Вбудована система, вбудована система(англ. embedded system) - це спеціалізована комп'ютерна система, у якій сам комп'ютер зазвичай вбудований у пристрій, яким він управляє.

Характерні особливості:

• Дуже мале енергоспоживання, близько від 0,5 до ~20 Вт
• Маленькі розміри
• Відсутність великих систем відведення тепла (охолодження). Найчастіше ЦПУ взагалі не охолоджується або використовується невеликий радіатор.
• ЦПУ та системна логіка, а також деякі інші ІС, часто поєднані на одному кристалі (System On Crystal = SOC)

Основою побудови вбудованих систем можуть бути одноплатні або однокристальні мікроконтролери, спеціалізовані або універсальні ЦПУ, ПЛІС. Цікавою особливістю деяких видів вбудованих систем є використання досить застарілих процесорів сімейства x86 (наприклад i386, i486, Pentium) та їх клонів через мале енергоспоживання та низьку вартість (близько 1-5 доларів США). Також багато видів вбудованих систем використовують ЦПУ архітектури ARM.

На даний момент досить велика кількість фірм (у тому числі в Росії) виробляє одноплатні комп'ютери на основі мікроконтролерів та ЦПУ з архітектурою RISC. Серед них Advantech, AAEON, Advanced Micro Peripherals (AMP), Ampro Computers, Diamond Systems, iBASE, InnoDisk, Fastwel (Росія), Lippert, Octagon Systems, RTD Embedded Technologies, Tri-M Systems - Engineering, SanDisk, STEC.Прикладами вбудованих систем можуть бути банкомати, авіоніка, КПК, телекомунікаційне обладнання тощо.

Деякі вбудовані системи використовуються в масових кількостях (наприклад, RFID пристроїв). Вбудовані системи є привабливою метою для творців шкідливого коду через свою розповсюдженість та відносну беззахисність. Поступово виникає шкідливий код для вбудованих систем (Cabir, RFID-вірус); на щастя, цей процес поки що утрудняється різнорідністю вбудованих пристроїв, відсутністю домінуючого ПЗ і обмеженою функціональністю деяких видів пристроїв. З іншого боку, завдання антивірусних компаній та дослідників комп'ютерної безпеки також ускладнене цими обставинами, а також малопотужністю вбудованих систем, що часто не дозволяє користуватися розповсюдженим антивірусним програмним забезпеченням.

Основними виробниками CPU для вбудованих систем є VIA technologies, Transmeta Corporation, Infineon Technologies.

Операційні системи для систем, що вбудовуються

У системах, що вбудовуються, для управління використовуються про ційні системи реального часу (ОС РВ) .

Операційна система реального часу ОС - це ОС, що реагує у передбачуваний час на непередбачувану появу зовнішніх подій. Іноді ОСРВ називають інтерактивними системами постійної готовності. У категорію ОСРВ їх відносять виходячи з маркетингових міркувань і якщо інтерактивну програму називають «працюючою в реальному часі», це лише означає, що запити від користувача обробляються із затримкою, непомітною для людини. Іноді поняття системи реального часу ототожнюють з «швидкою системою», але це не завжди правильно, оскільки важливо не час затримки реакції ОСРВ, а те, щоб цього часу було достатньо для додатка, що розглядається, і воно було гарантовано.

Іноді розрізняють системи «жорсткого» та «м'якого» реального часу. ОС "жорсткого" реального часу гарантує виконання якихось дій за певний інтервал часу, ОС "м'якого" реального часу, як правило, встигає виконати дії за проміжок часу, але повністю не гарантує цього. Більшість програмного забезпечення орієнтована на «м'який» реальний час.

Для таких систем характерно:

• гарантований час реакції на зовнішні події (переривання від обладнання);
• жорстка підсистема планування процесів (високопріоритетні завдання не повинні витіснятися низькопріоритетними, за деякими винятками);
• підвищені вимоги до часу реакції на зовнішні події або реактивності (затримка виклику обробника переривання не більше десятків мікросекунд, затримка при перемиканні задач не більше сотень мікросекунд)

Класичним прикладом завдання, де потрібно ОСРВ, є управління роботом, що бере деталь зі стрічки конвеєра. Деталь рухається, і робот має лише невеликий проміжок часу, що він може її взяти. Якщо він запізниться, то деталь вже не буде на потрібній ділянці конвеєра, а отже, робота не буде зроблена, незважаючи на те, що робот знаходиться в правильному місці. Якщо він спозиціонується раніше, деталь ще не встигне під'їхати, і він заблокує їй шлях.
Windows CE (вона WinCE)- це варіант операційної системи Microsoft Windows для налагоджених комп'ютерів, мобільних телефонів та систем, що вбудовуються. Windows CE не є "урізаною" версією Windows для настільних ПК і заснована на зовсім іншому ядрі. До основних недоліків системи можна віднести повну відсутність необхідних програмних програм. Підтримуються архітектури x86, MIPS, ARM та процесори Hitachi SuperH.

Основні конкуренти WinCE – це VxWorks, eCos, OSE, QNX, LynxOS, Symbian OS, OS-9 , а також різні похідні Linux (наприклад, uClinux ) і, найбільш відомий, PalmOS . Деякі виробники пристроїв також виготовляють власну систему.

Windows CE оптимізована для пристроїв, які мають мінімальний об'єм пам'яті: ядро ​​Windows CE може працювати на 32 КБ пам'яті. З графічним інтерфейсом (GWES) для роботи Windows CE буде потрібно від 5 МБ. Пристрої часто не мають дискової пам'яті і можуть бути сконструйовані як «закриті» пристрої без можливості розширення користувачем (наприклад, ОС може бути «зашита» в ПЗУ). Windows CE відповідає визначенню операційної системи реального часу.

На базі Windows CE засновано безліч платформ, включаючи Handheld PC, Pocket PC, Pocket PC 2002, Pocket PC 2003, Pocket PC 2003, Smartphone 2002, Smartphone 2003, Windows Mobile, а також безліч промислових пристроїв і вбудованих систем. Приставка Sega Dreamcast мала підтримку Windows CE. Самою Windows CE у початковій поставці не було, але вона могла запускатися на приставці з CD. Деякі ігри використовували цю можливість.

Часто назви Windows CE, Windows Mobile, Pocket PC використовують як взаємозамінні. Це не зовсім вірно. Windows CE 3.0 - це модульна операційна система, яка є основою для пристроїв кількох класів. Будь-який розробник може купити інструментарій (Platform Builder), який містить усі ці компоненти та програми, що дозволяють побудувати власну платформу. При цьому такі програми, як Word Mobile/Pocket Word, не є частиною цього інструментарію.

Windows Mobile найкраще уявляти собі як набір платформ, що базуються на Windows CE. В даний час цей набір входять платформи: Pocket PC, SmartPhone і Portable Media Center. Кожна платформа використовує свій набір компонентів Windows CE плюс свій набір супутніх особливостей і додатків.

Windows CE.– це кодова назва Windows CE версії 4.2.

Windows Embedded CE 6.0(кодове ім'я Yamazaki) є шостою версією операційної системи Windows Embedded, орієнтованої на підприємства, що виготовляють промислові контролери та пристрої побутової електроніки. У Windows Embedded CE 6,0 повністю перероблено ядро, яке підтримує понад 32 000 процесів, порівняно з 32 у попередніх версіях. З 32 Мб до 2 Гб піднялося віртуальний адресний простір, що виділяється для процесів.

Windows Embedded CE 6.0 було випущено 1 листопада 2006 року.
Windows CE 6.0 R2 було випущено 15 листопада 2007 року.
Windows Embedded CE 6.0 також є основою для Windows Mobile 7 (кодове ім'я Photon).

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

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

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

QNX Neutrino, Випущена в 2001 році, перенесена на багато платформ, і зараз здатна працювати практично на будь-якому сучасному процесорі, що використовується на ринку систем, що вбудовуються. Серед цих платформ присутні сімейства x86, MIPS, PowerPC, а також спеціалізовані сімейства процесорів, такі як SH-4, ARM, StrongARM і xScale.

Версія для некомерційного використання доступна для завантаження на веб-сайті розробника.

LynxOS- Unix-подібна операційна система реального часу, розроблена для систем, що вбудовуються, сумісна зі стандартами POSIX і, останнім часом, з операційною системою GNU/Linux. LynxOS використовується переважно в авіації, системах управління промисловими процесами та в галузі телекомунікацій.

ChorusOS- мікроядерна операційна система реального часу, розроблена для систем, що вбудовуються. У 1997 році Sun Microsystems купила Chorus systems, компанію, яка створила ChorusOS. У серпні 2002 року Засновники Chorus Systems організували нову компанію VirtualLogix і зайнялися розробкою систем, що вбудовуються, використовуючи Linux і ChorusOS.

Nucleus- операційна система реального часу, створена Accelerated Systems, підрозділом по системам компанії Mentor Graphics, що вбудовуються, для різних процесорних платформ. Набула поширення в телевізійних декодерах, мобільних телефонах, та інших переносних та кишенькових пристроях. Nucleus використовується Garmin International у GPS-модулі, призначеному для цивільної авіації.

OS-9- багатозадачна, розрахована на багато користувачів операційна система реального часу, розроблена Microware Systems Corporation.
Використовується для інтерактивних та вбудованих систем. У наші дні OS-9 належить компанії RadiSys Corporation, розташованої в штаті Орегон (США).

VxWorks- Операційна система реального часу (ОСРВ), що розробляється компанією Wind River Systems (США).
Як і більшість інших ОСРВ, VxWorks включає багатозадачне ядро ​​з витісняючим планувальником і швидким відгуком на переривання, засоби міжпроцесної взаємодії та синхронізації, а також файлову систему і мережеву підсистему (стек протоколів TCP/IP). У комплект поставки входять засоби для крос-компіляції, моніторингу продуктивності (WindView), віддаленого символьного налагодження, а також емуляції різних процесорів. Додатково поставляється значна кількість різних стеків протоколів, графічних підсистем та ін. як від самої Wind River Systems, так і від третіх фірм. Безліч підтримуваних VxWorks платформ, що вбудовуються, є одним з найбільших серед ОСРВ.

Остання версія інтегрованого середовища розробки Wind River Workbench (яка постачається з VxWorks версій 6.x, втім як і 5.x) побудована на основі середовища Eclipse. Попереднє пропрієтарне середовище розробки називалося Tornado.

Використання:

• Апарат Mars Reconnaissance Orbiter на орбіті Марса (використовується система VxWorks)
• Зонди Spirit та Opportunity, а також апарат Mars Reconnaissance Orbiter використовують VxWorks на платформі POWER. Система використовується в інших космічних місіях, наприклад Deep Impact.
• Планується використання у нових авіалайнерах Boeing 787.
• Комунікаційне обладнання багатьох компаній (наприклад, Nortel, 3COM, Alcatel та ін.).
  
• Linksys WRT54G (ver.5,6,...), NetGear WGR614 (ver. 5,6,7)
• Деякі PostScript-принтери.
• Медичне обладнання компанії Siemens AG (зокрема магнітно-резонансні томографи).
• Останні системи інтерфейсів BMW iDrive

ОС2000- Операційна система реального часу (ОС РВ) розроблена НІІСІ РАН на замовлення МО РФ для мікропроцесорів MIPS та Intel.
Ця ОС РВ призначена розробки програмного забезпечення для систем (програмно-апаратних комплексів), які у режимі жорсткого реального часу.
Підтримка пристроїв:

• мережеві пристрої Ethernet (протоколи NFS, FTP, Telnet), для Intel-версії підтримка обмежена ISA-і PCI-картами фірми Realtek, NE2000-сумісних карт.
• накопичувальні пристрої - флоппі- та жорсткі диски (файлові системи vfat та tar)

Є підтримка графічної клієнт-серверної підсистеми X Window System, яка використовується в Unix-системах.

Приклади вбудованих систем

Робот, такий як марсохід, показаний на малюнку 1.1 є вбудованою системою. Стільниковий телефон, PDA або портативний мультимедіа плеєр, показані на малюнку 1.2, є вбудованими пристроями. Навіть електрична зубна щітка, показана на малюнку 1.2 є вбудованою системою. Невеликий мікроконтролеру зубній щітці забезпечує програмоване керування швидкістю та індикацію стану заряду батареї. Високоякісні автомобілі можуть містити близько ста вбудованих мікроконтролерів. Типове домоволодіння середнього класу має близько п'ятдесяти вбудованих пристроїв. Для кожного ПК у світі є більше сотні вбудованих пристроїв. Загалом вбудовані пристрої складають більшу частину світового виробництва мікропроцесорів.

Рис. 1.1.

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

Конструктори вбудованих систем часто стикаються зі складними проектними завданнями. Вбудовані системи мають бути надійними. Багато вбудованих пристроїв не можуть ламатися і не можуть бути перезавантажені. Програмне забезпеченнянеможливо оновити у багатьох вбудованих пристроях. Багато пристроїв мають жорсткі конструкційні обмеження щодо продуктивності та споживання енергії. Деякі пристрої повинні працювати від батареї протягом тривалого часу. Крім того, споживчі пристрої зазвичай дуже швидко виходять на ринок із новими продуктами та мають жорстку цінову конкуренцію. У багатьох додатках існують обмеження реального часу і багато пристроїв мають обмежену пам'ять та обчислювальну потужність.

Операційні системи реального часу

Системи реального часуповинні відповідати на зовнішні параметривведення та створювати нові результати виведення за обмежений час, як показано на малюнку 1.3. Час відповіді має бути обмеженим. Дуже тривалий час відповіді може спричинити відмову систем реального часу.

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

У м'якій системі реального часу пріоритет мають критично важливі завдання. М'яка система реального часу зазвичай задовольняє обмеження відгуку реального часу. Прикладом типової м'якої системи реального часує плеєр мультимедіа. Плеєр може іноді пропустити відео кадр або аудіо семпл, і користувач може навіть не помітити, поки плеєр правильно працює більшу частину часу.

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

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

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

Операційні системи часто класифікують за характеристиками реального часу. Операційна системареального часу має бути ретельно спроектована, щоб підтримувати програми реального часу. Недавнє дослідження приходить до висновку, що 95% програм реального часу вимагають обмеженого часу відповіді в діапазоні від 0.5 до 10 мсек. Тільки 10% відхилення (коливання від 50 мікросекунд до 1 мсек) у часі відповіді може бути допустимим. Відповідно до таких вимог, більшість операційних систем загального призначення не є системами реального часу. Згідно з цими критеріями, вбудована ОС, така як Windows XP, може розглядатися в кращому випадку тільки як м'яка ОС реального часу. Для Windows XP є деякі інструменти сторонніх постачальників, які покращують час відповіді.

Операційні системи для вбудованих систем

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

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

Ліцензійні відрахування типової комерційної вбудованої ОС становлять лише кілька доларів на пристрій. Деякі дуже прості пристрої можуть обходитися без ОС, але нові пристрої стають дедалі складнішими.

У зв'язку з цим більшість вбудованих пристроїв використовують вбудовану операційну систему. Вбудовані операційні системи зазвичай розробляються здебільшого на C/C++ і поставляються разом з компілятором C/C++, асемблером та інструментами налагодження, щоб допомогти розробникам у розробці прикладних програм і тестуванні пристрою. Інструменти розробки вбудованих систем повинні також підтримувати виконання програм за допомогою коду, що зберігається в незалежній пам'яті, такій як ROM або пам'ять Flash.