Під час роботи з мікроконтролерами часто створюється специфічний код, який виконує конкретне завдання з мінімальними витратами ресурсів. Однак існують сценарії, коли більш розгорнута система з операційною системою на борту мікроконтролера є доцільнішою завдяки її перевагам.
Федеріко Терранео на Hackaday Europe обговорив цю тему, розповівши про архітектуру ядра, операційні системи реального часу та ефективне використання C++ у світі мікроконтролерів.
Мікроконтролінг
Доповідь починається з пояснення суті операційної системи: це програмне забезпечення, що діє як посередник між апаратним забезпеченням і додатками. Операційна система зазвичай складається з основного ядра, поверх якого розташовуються системні служби, бібліотеки, драйвери пристроїв та утиліти для роботи з системою. Інтерфейс користувача знаходиться на верхівці, дозволяючи запускати додатки та використовувати систему для виконання завдань.
Архітектура операційних систем може відрізнятися. Монолітні ядра, як у Linux, розділяють простір ядра (kernelspace) та простір користувача (userspace). У монолітних ядрах ядро має повний доступ до апаратного забезпечення, працюючи в системному режимі, тоді як додатки виконуються в режимі користувача без такого прямого доступу. Зазвичай вони працюють на архітектурах з блоком керування пам’яттю (MMU), наприклад, повноцінні комп’ютери з процесорами. Унікарнельні операційні системи, як FreeRTOS, об’єднують додатки та ОС в один виконуваний бінарний файл, що працює з прямим доступом до апаратного забезпечення без абстракцій чи захисту пам’яті, що полегшує їх роботу на типових мікроконтролерах. Існують також мікроядра, які мінімізують код, що виконується в системному режимі, виносячи драйвери та доступ до файлової системи у простір користувача. Ця архітектура також потребує MMU і використовується переважно в нішевих застосуваннях, де критично важливі високий рівень безпеки та/або надійності.
Для мікроконтролерів найбільш релевантною є архітектура унікарнелів, проте вони мають обмеження щодо стабільності, безпеки, динамічного завантаження коду чи часткового оновлення системи. «Fluid kernel», представлений Федеріко, спрямований на вирішення цих проблем. Він пропонує масштабоване рішення для вбудованих систем, де ресурси мікроконтролерів часто обмежені, а MMU – рідкість. Ця архітектура також має бути сумісною зі стандартними API, такими як POSIX, стандартні бібліотеки C++ тощо. Федеріко називає це концепцією «UNIX на чіпі».
«Fluid kernel» прагне об’єднати переваги монолітного ядра та унікарнеля. Він дозволяє розміщувати додатки як у просторі ядра, так і в просторі користувача за потреби. «Fluid kernel» також розроблений для подвійної відповідності стандарту POSIX – з однаковим API як у просторі ядра, так і в просторі користувача. Концепція «fluid kernel» побудована навколо абстракції процесів за допомогою апаратного блоку захисту пам’яті (MPU), який часто зустрічається у сучасних 32-бітних мікроконтролерах. Це не повноцінний MMU, і він не підтримує віртуальну пам’ять, але достатній для базового захисту пам’яті на платформі мікроконтролера. «Fluid kernel» також може бути опціонально перетворений на унікарнель під час компіляції, що зменшує розмір коду за рахунок відмови від підтримки процесів. Це дозволяє розробляти унікарнелі, які згодом можна перетворити на «fluid kernel», просто змінивши опцію компіляції.
Федеріко детально пояснює переваги та недоліки архітектури «fluid kernel», а також розглядає аспекти безпеки. Miosix RTOS представлена як практична реалізація цієї філософії, а також є корисний розділ щодо ефективного використання C++ на мікроконтролерах. Ця доповідь буде цікавою для тих, хто серйозно займається розробкою вбудованих систем, або просто хоче дізнатися про нову архітектуру, яка може стати в нагоді в майбутньому.
fede.tft каже: 3 вересня 2026, 10:35 ранку
Автор оригінальної доповіді. Ось посилання з презентації:
документ (без платного доступу): https://ieeexplore.ieee.org/abstract/document/11173649
вебсайт ядра Miosix: https://miosix.org
приклад теплової камери: https://github.com/fedetft/thermal_camera
репозиторій компілятора для останньої частини презентації: https://sr.ht/~fedetft/ch32-cpp-runtime
Luke Gary каже: 3 вересня 2026, 12:40 дня
Цей проєкт та CMRX є цікавими альтернативами до більш популярних RTOS. Цікаво буде спостерігати за його розвитком.
Sinu каже: 3 вересня 2026, 11:06 вечора
Захоплива робота Федеріко. Подолання розриву між жорсткими унікарнелями (як FreeRTOS) та громіздкими монолітними ОС за допомогою MPU виглядає як логічний розвиток для платформ Cortex-M та RISC-V. Підтримка POSIX API як у просторі ядра, так і в просторі користувача значно спрощує портування стандартних бібліотек C++. Я хотів би побачити порівняння продуктивності між накладними витратами перемикання контексту Miosix з MPU та підходами мікроядер, як seL4 чи потоки користувацького режиму Zephyr.
fede.tft каже: 4 вересня 2026, 12:08 ночі
Використання бібліотек C++ (або C-бібліотек з підтримкою POSIX, як-от для файлової системи) на мікроконтролерах є однією з цілей проєкту. Skyward (https://skywarder.eu/departments/swd/), один з наших давніх користувачів, використовує для своїх ракет фільтри Калмана, написані за допомогою Eigen (популярної бібліотеки C++), що працюють у просторі ядра для максимальної продуктивності в реальному часі.
Zozo каже: 4 вересня 2026, 1:49 ночі
Чому така одержимість ізоляцією частин прошивки у вбудованих системах? Це ж не ПК! У більшості випадків користувач не встановлюватиме власні додатки. І перевірка походить від вендора.
- fede.tft каже: 4 вересня 2026, 7:46 ранку
32-бітні мікроконтролери сьогодні настільки ж потужні, як ПК 30 років тому.
Я думаю, ваша неохочість до ізоляції зумовлена тим, що інші API RTOS для використання MPU є надто складними та перекладають тягар ізоляції на розробника. З «fluid kernel» все інакше. Ваш ізольований процес кодується так само, як програма в Linux: ви починаєте з main.c (або main.cpp) і пишете там свою програму. Ви компілюєте її окремо та розгортаєте в /bin. ОС робить решту.
Щодо причин, чому це може бути корисно:
– розділяй і володарюй: розбиття складної прошивки на кілька програм дозволяє писати простіший код
– якщо процес виходить з ладу, це не призводить до збою решти вашої вбудованої системи
– ви можете використовувати привілеї для обмеження збитків, якщо процес буде скомпрометовано/зламано
– ви можете завантажувати та виконувати новий код без перезавантаженняТакож зауважте, що в «fluid kernel» все це необов’язково. Якщо ви хочете писати цілі додатки в просторі ядра, ви можете це робити. ОС робить те, що ви хочете, а не навпаки.