Розробка операційної системи реального часу для цифрового сигнального процесора MicroDSP-RTOS (стр. 1 из 3)

Введення

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

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

Застосування систем реального часу може бути найрізноманітнішим. Розглянемо, наприклад, роботу стільникового телефону. Його процесор повинен виконувати одночасно досить багато завдань: прийом та кодування мови при розмові, відправку закодованого звуку на ретрансляційну станцію, прийом вхідного закодованого звукового потоку, розкодування та відтворення його; плюс до цього необхідно обмінюватися зі станцією всякого роду службовою інформацією – такий як перехід з зони в зону і перемикання на іншу станцію, відстеження рівня сигналу, при необхідності – посилення його і так далі. Причому багато хто з цих завдань мають виконуватися в реальному часі, без затримок. Наприклад, затримка в обробці сигналу з мікрофона призведе до того, що частина фрази буде втрачено; запізнення з перемиканням на іншу ретрансляційну станцію може призвести до втрати зв'язку та розриву з'єднання. Таким чином, застосування операційної системи реального часу в даній ситуації не лише виправдане, а й необхідно.

У даній статті ми розглянемо операційну систему реального часу, розроблену в ІСП РАН для приватної «системи на чіпі» (System-On-Chip) на базі цифрового сигнального процесора MicroDSP 1.1, коли на одному загальному кристалі розміщуються сам процесор, модулі розширення, програмна пам'ять і два банки пам'яті даних. Розміщення їх на одному кристалі дозволяє забезпечити дуже швидкий доступ до осередків пам'яті (звернення до пам'яті займає один такт). Розмір банків пам'яті даних може мінятися від 0 до 65536 16-бітних слів; вони незалежні, і до них можна звертатися одночасно. Програмна пам'ять може становити до 256К слів (4 сторінки за 64К слова), розмір слова складає 24 біта (довжина інструкцій процесора). Стек організується програмно, за допомогою трьох спеціальних регістрів, що містять кордону стека і поточне положення вказівника стека. Процесор підтримує до 15 програмованих переривань з індивідуальною настройкою пріоритетів і маскування, а також доступні три таймера.

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

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

1. ОСРВ MicroDSP-RTOS

Операційна система MicroDSP-RTOS призначена для роботи з багатозадачними додатками. Під завданням ми в даній статті маємо на увазі складову частину якого-небудь складного додатка, що працює самостійно і практично незалежно від інших частин. Також завдання часто називають процесами або потоками. Операційна система проводить необхідні дії з розподілу процесорного часу між завданнями і забезпечує перемикання між ними, зберігаючи і відновлюючи контексти так, що перемикання залишається для задач абсолютно прозорим. Також система містить набір функцій для виконання різних службових дій (функції ядра ОС), таких як ініціалізація внутрішніх структур, запуск самої ОС (по суті – запуск апаратного таймера), механізм збереження / відновлення контексту і перемикання завдань і так далі. Що стосується надається системою API, тут присутні функції для управління самими завданнями, їх станом, функції для синхронізації та взаємодії завдань між собою, для управління динамічною пам'яттю. Розглянемо можливості системи більш докладно.

1.1 Загальна функціональність

Всього в системі може бути присутнім максимум 63 користувацьких завдання. Самі завдання є звичайними функціями без параметрів, найчастіше представляють собою нескінченний цикл. Кожній задачі відповідає пріоритет від 0 до 62, що задається при підключенні, причому не може існувати двох завдань з однаковими пріоритетами. Системний час квантів, і в кожен квант часу виконується завдання, що має найвищий пріоритет (найвищий пріоритет відповідає значенню 0) серед тих, які не перебувають у стані очікування. На наведеній нижче схемі (Мал. 1) можна бачити основні стану, в яких може перебувати завдання, і можливі переходи між станами.

Рис. 1. Схема перемикання станів завдань

Після закінчення кожного кванта часу (system tick) викликається функція обробки переривання таймера. Ця функція виконує наступні дії:

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

· якщо у якоїсь із завдань таймаут минув, переводить це завдання в стан готовності (Ready);

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

У системі завжди присутній одна внутрішня завдання, що називається background і має найнижчий можливий пріоритет – 63. Це значення нижче пріоритету будь-якій з користувацьких завдань, і тому це завдання виконується тільки тоді, коли всі користувальницькі завдання знаходяться в стані очікування; таким чином, завдання background є індикатором простою системи. У початковій реалізації це завдання представляла собою цикл, що складається з декількох інструкцій NOP. Надалі туди була додана інструкція IDLE, яка зупиняє процесор до тих пір, поки не з'явиться запит на переривання. Тим самим було знижено енергоспоживання процесора на час простою.

1.2 Управління завданнями

1. Підключення завдання.

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

3. Відключення завдання.

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

5. Призупинення виконання завдання.

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

7. Відновлення з призупиненого стану.

8. Ця функція дозволяє при необхідності достроково поставити призупинену завдання в чергу на виконання, перевівши її в стан готовності.

9. Блокування завдання.

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

11. Висновок з режиму блокування.

12. Ця функція виконує дію, зворотне блокування. Стан завдання відновлюється в те, що було до блокування, за одним тільки винятком: якщо завдання виконувалася, вона переводиться в стан готовності, а не виконання. Таймаут (для станів призупинення та очікування) починає зменшуватися з кожним квантом часу; завдання може отримувати сигнали і повідомлення і так далі.