RTOS Vocabulary: FreeRTOS, Tasks, and Real-Time Concepts in English (англійською)
Основний словник RTOS для інженерів вбудованих систем: завдання, планування, пріоритети, семафори, mutexes, черги, ISR і ключові поняття FreeRTOS пояснені простою англійською мовою.
Операційна система реального часу (RTOS) забезпечує планування, синхронізацію і комунікацію примітивів, які вбудовані системи повинні задовольняти вимогам часу. FreeRTOS є найбільш широко розгорнутою у світі RTOS. Незалежно від того, пишете ви мікропрограму, переглядаєте вбудований код або обговорюєте дизайн RTOS у технічному інтерв’ ю, цей словник охопить основні поняття.
Фундаментальні принципи
RTOS (Real-Time Operating System) — операційна система реального часу
** RTOS ** це операційна система, розроблена для виконання завдань у строгих часових обмеженнях — гарантуючи, що критичні операції завершаться до вказаного терміну.
Контраст з ОС загального призначення (Linux, Windows) - вони надають пріоритет продуктивності і справедливості; RTOS надає пріоритет детермінізму і дотримання терміну.
«Ми використовуємо FreeRTOS, тому що петля контролера двигуна повинна виконуватися кожні 1 мс — ОС загального призначення не може надати таку гарантію»
Реальний час (Real-time) — час, що використовується в реальному часі
- ** Сумнівний режим реального часу ** — промах у строкових датах призведе до збою системи або порушення безпеки (наприклад, контролер повітряної подушки, стискач серця)
- ** Soft real- time ** — пропуск терміну погіршує якість, але не спричиняє катастрофічних помилок (наприклад, буферизація звуку, оновлення дисплея)
Determinism
** Детерміністична ** система має передбачуваний, обмежений час відповіді. Дизайн RTOS надає перевагу детермінізму над пропускною здатністю.
Latency
У контексті RTOS, ** latency ** це час між подією (перерванням, сигналом) і початком обробки, яка відповідає на неї. Мінімізація найгіршого випадку затримки є критичним.
Jitter
** Нестійкість ** — це змінність часу — різниця між найранішим і найновішим фактичним часом виконання. Низька тривога є необхідною для періодичних циклів керування.
Tasks
Задача (нитка)
Задача є незалежною одиницею виконання в RTOS — аналогічно до потоку в настільній ОС. Кожне завдання має:
- Його власний стек
- Рівень пріоритету
- Стан (запуск, готовність, блокування, припинення)
«Ми маємо чотири завдання: керування двигуном (найвищий пріоритет), зчитування датчиків, оновлення дисплея і комунікація (найнижчий пріоритет)»
Стани завдань
| State | Description |
|---|---|
| Running | Currently executing on the CPU |
| Ready | Can run but waiting for the CPU (preempted by higher-priority task) |
| Blocked | Waiting for an event, delay, or resource |
| Suspended | Explicitly paused; not eligible to run until resumed |
Пріоритет завдання
Кожне завдання має пріоритет — число, яке вказує його пріоритет у розкладі. Задачі з вищим пріоритетом мають перевагу перед завданнями з нижчим пріоритетом.
“Контролер двигуна працює на пріоритеті 7 (найвищий). Задача ведення журналу виконується з пріоритетом 1 (майже бездіяльна). Якщо обидва готові, контролер двигуна завжди працює першим»
Розмір стека
Кожне завдання потребує ** стека ** — області пам’ яті для локальних змінних, кадрів виклику функцій і обробки перерв. Задачі RTOS вимагають ретельного розміщення стека, щоб уникнути переповнення.
«Стек задач переповнився, тому що функція виділила 1 КБ локальних змінних — стек задачі був лише 512 байтів»
Неактивне завдання
** неактивне завдання ** виконується, коли інші завдання не готові — це завдання виконує очищення фону і може перевести процесор у стан спокою з низьким споживанням енергії.
Scheduling
Scheduler
** Планувальник ** є компонентом RTOS, який вирішує, яке завдання буде виконано у будь- який момент часу, на основі пріоритету і стану.
Попереднє планування
За допомогою ** попереднього планування** планувальник може перервати виконання завдання у будь- який час, щоб перейти до готового завдання з більшим пріоритетом.
“Датчик перерива установил флаг. Планувальник негайно перемикає з завдання дисплея на завдання обробки датчика, тому що воно має вищий пріоритет.”
Незавершений (неопублікований) твір
У кооперативному плануванні завдання добровільно віддають процесор викликом функції блокування або явним віддаванням. Менше витрат, але ризиковано, якщо завдання неправильно поводиться і монополізує процесор.
Tick
Tick є базою часу RTOS — періодичне переривання (наприклад, кожні 1 мс), яке дозволяє планувальнику оцінити стани завдань і реалізувати операції з затримкою часу.
** Період часу ** — інтервал між часами. Типовий для FreeRTOS: configTICK_RATE_HZ (зазвичай 1000 Гц = 1 мс).
Перемикання контексту
** Перемикач контексту ** це процес збереження поточних регістрів/ стану завдання і відновлення стану іншого завдання. Контекстні перемикачі RTOS зазвичай становлять 1-10 мікросекунд.
Розклад руху поїздів
** Кругове розкладання** надає рівні частини часу для завдань з однаковим пріоритетом, циклічно проходячи їх послідовно.
Примітивні синхронізатори
Semaphore
** Семафор ** — це механізм сигналізації, який використовується для синхронізації завдань.
- ** Двійковий семафор ** — прапорець, який можна надати (сигнал) і прийняти (очікувати). Класичний використовується для ISR-до-задачі сигналізації.
- ** Counting semaphore ** — як лічильник; дозволяє до N одночасних захоплень. Використовується для керування пулом ресурсів.
“UART ISR записує в буфер і віддає двійковий семафор. Задача UART блокує на семафорі — вона прокидається тільки коли ISR сигналізує, що нові дані доступні»
Mutex (семафор взаємного виключення)
** mutex ** надає виключний доступ до спільного ресурсу. На відміну від двійкового семафора, мутек має власника (задачу, яка його отримала) і підтримує ** успадкування пріоритетів **.
** Спадкування пріоритетів ** запобігає ** інверсії пріоритетів **: якщо завдання з низьким пріоритетом має мутекс, на який чекає завдання з високим пріоритетом, завдання з низьким пріоритетом тимчасово успадковує високий пріоритет, щоб мати змогу швидко звільнити мутекс.
«Ми використовуємо mutex, а не семафор, для шини SPI — mutexes запобігають інверсії пріоритету, що може призвести до того, що наше завдання управління двигуном пропустить свій термін»
Інверсія пріоритетів
** Інверсія пріоритетів ** — це ситуація, коли завдання з високим пріоритетом блокується завданням з нижчим пріоритетом, яке має спільний ресурс, а завдання зі середнім пріоритетом випереджає завдання з низьким пріоритетом, заважаючи звільненню ресурсу.
Класичний приклад: місія Mars Pathfinder (1997) зазнала інверсії пріоритетів — вирішена в середині місії, ввівши успадкування пріоритетів.
Deadlock
** Застібка ** в RTOS відбувається, коли дві або більше задач чекають на ресурс, який тримає інша задача — обидві заблоковані на неопределенный час.
“Задача А утримує Mutex 1 і чекає на Mutex 2. Завдання B утримує Mutex 2 і чекає на Mutex 1. «Діалог»
Інтерактивне спілкування
Queue
** queue ** (черга повідомлень) — це буфер FIFO для передачі даних між завданнями або з ISR до завдання. Надає безпечний, безпечний для потоків механізм для обміну даними.
“Задача считывания датчика ставит 8-байтовые структуры измерений в очередь. Задача обробки блокує в черзі і обробляє кожне вимірювання, як тільки воно приходить»
Довжина / Глибина черги
** Глибина черги ** — кількість елементів, які можна розмістити у черзі. Якщо черга заповнена, відправники можуть блокувати або повертати повідомлення про помилку.
Notification
** Сповіщення про завдання ** (FreeRTOS) є легким, швидким механізмом для сигналізації про певне завдання — швидшим за семафори, оскільки вони працюють безпосередньо на значення сповіщення завдання.
Буфер потоку / Буфер повідомлень
FreeRTOS stream buffers дозволяють надсилати потоки байтів довільної довжини з ISR/task до одного отримувача. Message buffers розширюють це для обробки дискретних повідомлень з розміщенням у рамки.
Переривання і ISR
ІСР (Interrupt Service Routine)
** ISR ** — це функція, яка виконується у відповідь на апаратне переривання. ISR повинні бути короткими і швидкими — вони випереджають всі завдання незалежно від пріоритету.
“ADC ISR запускає кожні 500µs. Він тільки зберігає зразок і дає семафор — вся обробка відбувається в задачі ADC. “
Функціональна безпека
FreeRTOS надає ISR-безпечні варіанти API функцій (наприклад, xQueueSendFromISR, xSemaphoreGiveFromISR ) — вони можуть бути викликані з ISR.
⚠️ Ніколи не викликайте звичайні функції RTOS з ISR — це пошкодить стан планувальника.
Пріоритет переривання
На ARM Cortex-M, перерва пріоритет рівні контролю, які перерви можуть випереджати інших. RTOS-відомі переривання повинні працювати на налаштовуваних рівнях пріоритету нижче порогу configMAX_SYSCALL_INTERRUPT_PRIORITY.
Затримка переривання
** Затримка переривання ** — це час між повідомленням про переривання і початком ISR. Критична для чутливих до часу апаратних подій.
Керування пам’яттю
Heap
** куп ** є динамічно виділеною пам’ яттю. FreeRTOS надає кілька схем розподілу купів (heap_1 через heap_5) з різними компромісами між фрагментацією і детермінізмом.
«Ми використовуємо heap_4, тому що він підтримує як розподіл, так і відокремлення з алгоритмом найкращого підключення — але ми розподіляємо всі ресурси при запуску, щоб уникнути фрагментації часу виконання»
Виявлення переповнення стека
FreeRTOS може заповнювати стеки завдань відомим шаблоном і перевіряти на пошкодження. configCHECK_FOR_STACK_OVERFLOW дозволяє це.
Корисні фрази
** У обговореннях проекту: **
-
- “Задача керування двигуном потребує попереднього планування з пріоритетом 7 — якщо будь- яке завдання з нижчим пріоритетом виконується занадто довго, петля двигуна пропустить свій термін виконання у 1 мс.” *
-
- “Ми замінили двійковий семафор на mutex, оскільки нам потрібна спадковість пріоритетів, щоб запобігти інверсії.” *
** В обзорах коду: **
- “Ця функція виділить локальний масив на стеку задач — переконайтеся, що розмір стека задач достатньо великий.”
- “Ніколи не викликайте
vTaskDelayз ISR — використовуйте варіант APIFromISR.”
Practice
Збудуйте ваш словник вбудованих систем за допомогою ** Набір вправ для вбудованих систем та Інтернету речей ** і ** Вбудований інженер з IoT **.