Користувачка:Inna Z/Чернетка RTOS

FreeRTOS переклад: http://www.freertos.org/implementation/a00007.html

Як працює FreeRTOS

Основи

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

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

Використання багатозадачних операційних систем дозволяє спростити створення того, що в іншому випадку стало б складним програмним застосунком:

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

Багатозадачність і паралелізм

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

Планування задач

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

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

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

Система реального часу

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

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

Приклад:

Базовий приклад описаного вище при роботі систем реального часу яка працює з клавіатурою і LCD дисплеєм. Користувач повинен отримати візуальну реакцію на кожне натиснення клавіши за адекватний період часу - якщо користувач не може бачити, що натиснення клавіши було прийняте системою за цей період програмний продукт буде не зручно користувати. Найбільший прийнятний перід становить 100мс - будь-який відгук за час від 0 до 100мс буде вважатися адекватнимe. Ця функціональність може бути реалізована як незалежна задача подібної структури:

void vKeyHandlerTask( void *pvParameters )
{
    // Обробка натиснення клавіш це тривалий процес і така задача
    // виконується з використанням нескінченного циклу (якими є більшість задач
    // реального часу).
    for( ;; )
    {
        [Призупинення в очікуванні натиснення клавіши]
        [Обробка натиснення клавіши]
    }
}

Тепер припустимо, що система реального часу також виконує функцію контролю, яка потребує цифрової фільтрації вхідного сигналу. Вхідний сигнал треба дискретизувати, відфільтрувати, а цикл контролю має виконуватись кожні 2мс. Для правильної роботи фільтру регулярність часу дискретизації має задовольняти точності в 0.5мс. Цю функціональність можна виконати як незалежну задачу наступної структури:

void vControlTask( void *pvParameters )
{
    for( ;; )
    {
        [Призупинитися на 2мс від почату попереднього циклу]
        [Отримати показання на вході]
        [Виконати фільтрацію вхідного значення]
        [Виконати алгоритм контролю]
        [Видати результат]
    }
}

Інженер програмного забезпечення повинен назначити задачі контролю найвищій пріоритет тому що:

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

Наступний приклад демонструє як ці задачі будуть плануватися операційною системою реального часу.

• На початку жодна з наших задач не готова виконуватись - vControlTask очікує на свій правильний час для того, щоб розпочати цикл контролю, а задача vKeyHandlerTask очікує натиснення клавіши. Процесорний час вільний для RTOS, тобто виконується пуста задача.
• В момент t1, відбувається натиснення клавіши. vKeyHandlerTask готова почати виконання - оскільки вона має більший пріоритет ніж пуста задача RTOS їй надається процесорний час.
• В момент t2 vKeyHandlerTask закінчило обробку клавіши і оновлює LCD екран. Вона не може продовжувати виконання далі, доки не буде натиснута нова клавіша, тому призупиняє сама себе і RTOS знову повертається виконувати пусту задачу.
• В момент t3 таймерна подія повідомляє, що настав час виконувати наступний цикл контролю. vControlTask тепер може виконуватись і оскільки має найбільший пріоритет починає виконання миттєво.
• Між моментами t3 і t4, поки задача vControlTask продовжує роботу, відбувається натиснення на клавішу. vKeyHandlerTask тепер може виконуватись, але вона має менший пріоритет ніж vControlTask і планувальник не виділяє їй ніякого часу процесора.
• В t4 vControlTask закінчує виконання циклу контролю і не може продовжити доки не настане наступна таймерна подія - вона призупиняє сама себе. vKeyHandlerTask тепер є задачею з найбільшим пріоритетом, яка може виконуватись, тому їй надається процесорний час для обробки попереднього натиснення клавіши.
• В t5 закінчується обробка натиснення клавіши, і vKeyHandlerTask призупиняє сам себе і продовжує очікувати наступного натиснення клавіши. Знову жодна з задач не може виконуватись і RTOS повертається до пустої задачі...

Перемикання контексту

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

Аби уникнути таких помилок є важливим аби при відновленні роботи задача мала контекст ідентичний тому що був безпосередньо перед її призупиненням. За це відповідальне ядро операційної системи - так само як і за збереження контексту при призупинені задачі. Коли задача відновлює свою роботу, ядро операційної системи відновлює контекст перед її виконанням. Процес збереження і відновлення контексту задачі називається перемиканням контексту (context switching).

Задачі і спів-програми

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

Спів-програми (англ. Co-routines) були створенні для використання на дуже малих пристроях, але вони рідко використовується на практиці зараз. Із цих причин, хоча і нема планів усувати co-routines із коду, також немає планів розвивати їх далі.

Спів-програми змістовно схожі на задачі, але мають ряд фундаментальних відмінностей :

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