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

Введення

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

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

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

У даній статті ми розглянемо операційну систему реального часу, розроблену в ІСП РАН для приватної «системи на чіпі» (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. Ця функція виконує дію, зворотне блокування. Стан завдання відновлюється в те, що було до блокування, за одним тільки винятком: якщо завдання виконувалася, вона переводиться в стан готовності, а не виконання. Таймаут (для станів призупинення та очікування) починає зменшуватися з кожним квантом часу; завдання може отримувати сигнали і повідомлення і так далі.

13. Отримання даних, переданих завданню.

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

15. Зміна пріоритету завдання.

16. Ця функція дозволяє змінити пріоритет будь-якої задачі (при цьому новий пріоритет не повинен бути зайнятий). Для зручності роботи, щоб не потрібно було запам'ятовувати і визначати, яким пріоритет має кожна завдання в кожний момент часу, звернення до завдань здійснюється через унікальні ідентифікатори. По суті, ці ідентифікатори є змінними, які містять реальні значення пріоритетів завдань. У результаті до задачі, скажімо, номер 3 завжди можна звертатися через змінну TASK3, не замислюючись про те, змінювався чи є у неї пріоритет, і якщо змінювався, то який він зараз, оскільки ця змінна завжди буде містити коректне поточне значення пріоритету.

1.3 Синхронізація та взаємодію задач

Для синхронізації завдань і взаємодії їх один з одним передбачені наступні механізми:

• сигнали;

• семафори;

• повідомлення;

• черги повідомлень.

Тони.

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

Семафори.

У MiscoDSP-RTOS реалізовані виконавчі семафори і семафори з лічильником. Як ті, так і інші зазвичай використовуються для забезпечення контролю роботи із загальними ресурсами.

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