Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Введення
В даний час все більшу роль починають грати вбудовуванні системи на основі цифрових процесорів обробки сигналів (ЦПОСІ). ЦПОСІ використовуються практично у всіх областях діяльності людини – в побуті, науці, медицині. Найважливішим програмним компонентом, які лежать в основі функціонування таких систем, є операційна система, яка дозволяє запускати одночасно декілька різних програм і організовувати взаємодію між ними для вирішення однієї загальної задачі. Для вбудованих систем обробки сигналів характерні операційні системи реального часу (ОСРВ). Ці системи застосовуються в тих випадках, коли головне завдання – встигнути зреагувати на подію в рамках строго певного максимального часу реакції. Наприклад, це може бути сигнал на датчику, що відображає поточний стан якогось об'єкта в реальному часі. Можлива ситуація, коли стан об'єкта на короткий час змінюється, а потім повертається назад, і якщо це зміна залишиться непоміченим і необроблене системою, наслідки можуть бути самими різними – від зовсім нешкідливих до катастрофічних.
Важливо також відзначити, що можливість «встигнути зреагувати на подію» зовсім не означає високу швидкість роботи. Система може працювати відносно повільно, і все ж бути системою реального часу. Головна відмінність ОСРВ від ОС загального призначення – це якийсь фіксований проміжок часу, протягом якого система гарантовано зреагує на подію і виконає його обробку. Величина цього проміжку часу визначається розв'язуваної завданням і є однією з вимог до розроблюваної системі. Він може бути дуже коротким, але може бути і довгим, важливо лише те, що він фіксований і відомий заздалегідь.
Застосування систем реального часу може бути найрізноманітнішим. Розглянемо, наприклад, роботу стільникового телефону. Його процесор повинен виконувати одночасно досить багато завдань: прийом та кодування мови при розмові, відправку закодованого звуку на ретрансляційну станцію, прийом вхідного закодованого звукового потоку, розкодування та відтворення його; плюс до цього необхідно обмінюватися зі станцією всякого роду службовою інформацією – такий як перехід з зони в зону і перемикання на іншу станцію, відстеження рівня сигналу, при необхідності – посилення його і так далі. Причому багато хто з цих завдань мають виконуватися в реальному часі, без затримок. Наприклад, затримка в обробці сигналу з мікрофона призведе до того, що частина фрази буде втрачено; запізнення з перемиканням на іншу ретрансляційну станцію може призвести до втрати зв'язку та розриву з'єднання. Таким чином, застосування операційної системи реального часу в даній ситуації не лише виправдане, а й необхідно.
У даній статті ми розглянемо операційну систему реального часу, розроблену в ІСП РАН для приватної «системи на чіпі» (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) викликається функція обробки переривання таймера. Ця функція виконує наступні дії:
У системі завжди присутній одна внутрішня завдання, що називається background і має найнижчий можливий пріоритет – 63. Це значення нижче пріоритету будь-якій з користувацьких завдань, і тому це завдання виконується тільки тоді, коли всі користувальницькі завдання знаходяться в стані очікування; таким чином, завдання background є індикатором простою системи. У початковій реалізації це завдання представляла собою цикл, що складається з декількох інструкцій NOP. Надалі туди була додана інструкція IDLE, яка зупиняє процесор до тих пір, поки не з'явиться запит на переривання. Тим самим було знижено енергоспоживання процесора на час простою.
1.2 Управління завданнями
1.3 Синхронізація та взаємодію задач
Для синхронізації завдань і взаємодії їх один з одним передбачені наступні механізми:
Тони.
Для повідомлення про настання якої-небудь події завдання може послати другий задачі сигнал. Розглянемо, наприклад, ситуацію, коли завдання повинна вважати дані з порту введення-виведення. У цьому випадку можна перевести задачу в режим очікування сигналу. Коли дані будуть готові, інше завдання або процедура обробки переривання пошле відповідний сигнал, в результаті чого перша завдання буде активована і зможе виконати читання даних.
Семафори.
У MiscoDSP-RTOS реалізовані виконавчі семафори і семафори з лічильником. Як ті, так і інші зазвичай використовуються для забезпечення контролю роботи із загальними ресурсами.
Двійковий семафор може приймати значення 1 або 0, що означає, відповідно, доступність і недоступність ресурсу. Якщо задачі потрібен доступ до ресурсу, вона повинна викликати системну функцію, яка перевіряє, чи доступний ресурс. Якщо він вже зайнятий, то завдання переводиться в стан очікування, а управління передається наступному найбільш пріоритетне завдання. Якщо ж ресурс доступний (значення семафора дорівнює 1), то він блокується (значення встановлюється в 0), і управління повертається в завдання. Коли робота з ресурсом завершена, його потрібно звільнити викликом відповідної функції. При цьому зі списку всіх завдань, які очікують даний ресурс, обирається найбільш пріоритетна і переводиться в стан готовності (а якщо вона має більш високий пріоритет, ніж поточна завдання, то відбувається перемикання). Якщо таких завдань немає, то ресурс просто позначається як вільний (значення встановлюється в 1), і управління повертається в виконуваних завдань.
Відмінність семафорів з лічильником від декількох двійкових семафорів полягає тільки в тому, що ресурси можуть використовуватися кількома завданнями одночасно. Наприклад, якщо є канал передачі даних, що складається з чотирьох паралельних ліній, що працюють незалежно, то для роботи з ним може використовуватися семафор з лічильником, спочатку рівним 4. Коли задачі потрібно лінія передачі даних, вона робить системний запит. У результаті, якщо кількість доступних ліній більше нуля, воно зменшується на 1; в іншому випадку завдання переводиться в режим очікування до тих пір, поки одна із завдань, які блокують ресурси, не звільнить використовувану лінію. Варто відзначити, що даний підхід суттєво відрізняється від використання декількох двійкових семафорів. Семафор з лічильником не робить відмінності між контрольованими їм ресурсами. У наведеному вище прикладі завдання, що очікує ресурс, переводиться в стан готовності при звільненні будь-який з чотирьох ліній. При використанні ж чотирьох двійкових семафорів довелося б чекати звільнення якоїсь однієї конкретної лінії, навіть якщо всі інші вже вільні.
Повідомлення.
Повідомлення дозволяють завданням обмінюватися даними. Цей механізм може використовуватися, коли одній задачі потрібно не тільки сповістити іншу про настання події, а й передати їй якісь додаткові відомості (наприклад, повідомлення про завершення читання з порту із зазначенням адреси буфера, де знаходяться лічені дані). Принцип дії є таким же, як у сигналів і семафорів: завдання, якому потрібні дані, викликає системну функцію, яка визначає, чи доступні дані в цього вимагають поштовій скриньці. Якщо дані доступні, то вони передаються задачі, і їй повертається управління. Якщо ж скринька порожня, то завдання переводиться в режим очікування. При посилці повідомлення перевіряється, чи немає завдання, яка очікує отримання даних з цього ж поштової скриньки. Якщо таке завдання є, вона переводиться в режим готовності, і при необхідності виконується перемикання завдань, якщо ж дані ніким не запитані, вони будуть зберігатися в поштовій скриньці до першого запиту.
Черги повідомлень.
Черги повідомлень можуть використовуватися, коли дані надходять нерегулярно, і невідомо, чи буде завдання встигати відразу зчитувати всі вступники повідомлення. Черга повідомлень організована у вигляді циклічного буфера типу FIFO. Довжина черги, а також кількість черг повідомлень, яке можна використовувати в програмі, задається у конфігураційних файлах RTOS-проекту. Робота з чергами організована таким же чином, як і з поодинокими повідомленнями, з тією лише різницею, що можна зберігати не одне повідомлення, а декілька.
1.4 Робота з динамічною пам'яттю
В операційній системі MicroDSP-RTOS реалізовані найпростіші механізми роботи з динамічною пам'яттю. Зрозуміло, механізми, що використовуються в багатьох сучасних системах програмування, не підходять для ОС реального часу, тому що час їх виконання недетермінованих і залежить від фрагментації пам'яті. Тому для цієї ОС був розроблений свій підхід, що дозволяє уникнути фрагментації пам'яті і зробити час виконання функцій детермінованим.
У конфігураційних файлах RTOS-проекту задається загальна кількість динамічної пам'яті, яке буде використовуватися програмою. Користувач повинен оцінити, скільки буде потрібно пам'яті, з огляду на витрату пам'яті на службову інформацію. Динамічна пам'ять організована у вигляді набору областей (пулів) пам'яті, кожна з яких складається з деякої кількості буферів однакового розміру. Для роботи необхідно заздалегідь створити пул, вказавши кількість буферів в ньому і їх розмір (зрозуміло, сумарний розмір не повинен перевищувати кількість вільної динамічної пам'яті), після чого системними викликами можна виділяти буфера і повертати їх назад в пул, позначаючи їх, тим самим, як вільні. При такій функціональності дефрагментувати пам'ять немає необхідності, оскільки робота ведеться тільки з буферами однакового розміру.
1.5 Використання процедур обробки переривань
Із присутніх у процесорі ліній переривання одна зайнята самою операційною системою (переривання таймера для реалізації багатозадачності). У своїй програмі розробник може реалізовувати обробку інших переривань, але при цьому необхідно мати на увазі деякі особливості системи.
У першу чергу, це можливість забороняти переривання на деякий час. Це буває необхідно в разі, коли програмі потрібно винятковий доступ до даних, і ніяке стороннє втручання неприпустимо. Наприклад, в більшості системних функцій RTOS на початку коду переривання забороняються, а в кінці – дозволяються. Це зроблено для того, щоб в процесі зміни внутрішніх системних даних не могло статися перемикання завдання, що призвело б до помилок. Проте цією можливістю не слід зловживати, і вкрай бажано, щоб переривання не були заборонені протягом тривалого часу, оскільки це істотно знижує час реакції системи на зовнішні події.
Важливим моментом є також те, що всередині процедур обробки переривань неможливий виклик функцій очікування. При спробі викликати таку функцію буде повернуто код помилки. Здійснення ж сигналів та повідомлень, а також звільнення семафорів всередині обробників переривань допустимо, хоча і вимагає деяких додаткових дій, а саме: на початку процедури обробки необхідно зберегти контекст поточного завдання шляхом виклику відповідної системної функції, а в кінці замість звичайної інструкції повернення з переривання (RETI) потрібно виконати виклик системної функції повернення, яка присутня у RTOS API. Це все потрібно для того, щоб забезпечити коректну обробку переривання. У звичайній ситуації виклик функції відправлення повідомлення може викликати переключення на більш пріоритетну задачу. У разі ж обробки переривання така поведінка неприпустимо, і тому замість негайного перемикання функція відправлення повідомлення просто виставляє прапор перемикання. Після того, як обробка переривання буде завершена, можна виконувати перемикання завдань, що і робить системна функція повернення з переривання, якщо виявляє, що прапор виставлений (саме для цього на початку потрібно зберегти контекст завдання).
2. Підтримка MicroDSP-RTOS в MetaDSP
Система MicroDSP-RTOS розроблялася для створення проектів в інтегрованому середовищі крос-розробки MetaDSP, в якій були додані нові можливості, що полегшують створення й налагодження RTOS-проектів. У першу чергу це система RTOS Illuminator, що дозволяє переглядати і змінювати стан завдань у процесі виконання програми. Також були додані два нових типи профілюванням і новий тип проекту, що містить базовий шаблон для RTOS-проекту. Розглянемо ці нововведення докладніше.
2.1 RTOS Illuminator
Цей інструмент являє собою вбудовану утиліту для спостереження за станом процесів і управління ними ззовні. Візуально RTOS Illuminator є приєднується вікном у середовищі MetaDSP, в якому на декількох вкладках відображує стан підключених на даний момент задач.
Рис. 2. Вид вікна RTOS Illuminator, управління завданнями
Вона дозволяє переглядати поточний стан процесів: ім'я процесу (ім'я підключається функції, поле Name), пріоритет (поле Priority), поточний статус процесу (Status). Якщо завдання припинена або перебуває у стані очікування, для неї відображається значення таймауту (Delay), а для задач, які чекають настання деякого події, додатково вказується, яка саме ця подія (Event). Для виконуваної в даний момент завдання також зазначаються кількість тактів, що минув з моменту останнього перемикання на це завдання (Resumed Cycles), та поточний адресу виконання (Run Address). Для неактивних завдань у поле Run Address виводиться адреса програмної пам'яті, з якого буде продовжено виконання завдання. Подвійним клацанням миші по цьому полю можна перейти до того місця вихідного коду, яке відповідає вказаною адресою, тобто по суті, до тієї точки виконання, в якій завдання була перервана.
Крім цього в цій вкладці можна змінювати стан завдань, а саме:
Зліва від імені кожного завдання присутній прапорець, включивши який, можна встановити точку зупину, спрацьовує в момент перемикання RTOS на це завдання. Ця функція значно розширює можливості налагодження багатопоточних додатків.
На Рис. 3 показана вкладка Events.
Рис. 3. Вид вікна RTOS Illuminator, управління об'єктами синхронізації
На цій вкладці відображаються всі об'єкти межзадачного взаємодії і синхронізації, створені програмою. Для кожного об'єкта виводяться його адреса (у полі Name), тип об'єкта (сигнал, семафор, поштову скриньку і т. п., поле Type) і список завдань, які очікують даний об'єкт синхронізації (поле Waiting Tasks). Для сигналів і семафорів додатково виводиться лічильник, який представляє собою поточний стан об'єкту (Counter), а для поштових скриньок і черг повідомлень – покажчик на повідомлення, якщо воно присутнє (Message).
Так само, як і у вкладці Tasks, ліворуч від кожного об'єкта присутній прапорець, який включає / вимикає точку зупину, які виконуються при настанні зазначеного події.
Вкладка Stack Info надає інформацію про поточний стан стека для кожного завдання. Для поточного завдання це буде просто значення стековий регістрів, а для всіх інших завдань виводяться значення, збережені в контексті при перемиканні. На цій вкладці також відображаються розмір стека, процентне співвідношення його використання і максимальний відсоток використання, який був за весь час роботи даної задачі.
Вкладка RTOS Info відображає відомості про систему RTOS в цілому: кількість тактів, що минув з моменту останнього спрацьовування таймера, тривалість кванта часу, загальне число квантів часу, який минув з моменту старту системи, і версію RTOS.
2.2 RTOS Profiler
Рис. 4. Вид вікна RTOS Profiler, послідовність завдань
Спочатку, до розробки MicroDSP-RTOS, в MetaDSP був присутній вбудований Профілювальники, що надає інформацію про розподіл процесорного часу між різними функціями всередині програми, а також збирає статистику по кількості виконаних процесорних інструкцій різного типу. З появою MicroDSP-RTOS були додані два нових типи профілізацією.
Відображення послідовності виконуються завдань (Мал. 4).
Ця вкладка вікна Профілювальники надає в наочному графічному вигляді, які завдання і протягом якого проміжку часу виконувалися. Проміжок часу вказується як в процесорних тактах, так і в системних кванта часу.
Розподіл процесорного часу за завданням (Мал. 5).
Рис. 5. Вид вікна RTOS Profiler, розподіл часу за завданнями
У цій вкладці вікна Профілювальники відображається, яку частину процесорного часу займала кожна задача. Опціонально можна також відобразити сумарний час виконання для системної фонової завдання (background), для процедури обробки таймерного переривання (RTOS ISR – Interrupt Service Routine), за яким RTOS виконує перемикання завдань, та процедури початкової ініціалізації (Bootstrap).
RTOS-Профілювальники дозволяє оцінити різні показники додатку, що розробляється, пов'язані з мультизадачність, наприклад, наскільки правильно обраний розмір кванта часу, з'ясувати, протягом якого часу система перебувала в простої і так далі. Визначення значень цих характеристик дає можливість порівнювати ефективність системи при різних значеннях її параметрів, що в свою чергу полегшує створення ефективного продукту.
Висновок
У даній роботі була розглянута операційна система реального часу MicroDSP-RTOS, розроблена в ІСП РАН для одного з індустріальних партнерів. Дана система призначена для забезпечення роботи багатозадачних рішень на базі «системи на чіпі» c архітектурою MicroDSP. Реалізація MicroDSP-RTOS виконана повністю на мові асемблера зазначеного мікропроцесора з наданням прикладних інтерфейсів для програм на мові C. Були розглянуті основні можливості системи, етапи її розвитку, особливості підтримання налагодження багатозадачних додатків в інтегрованому середовищі крос-розробки.
Розроблена система має наступні характеристики (для часу виконання вказується максимально можливий час; для перекладу в мікросекунди розглядається процесор з частотою 200 МГц):
|
розмір ядра |
829 слів |
|
повний розмір системи (включаючи опціональні модулі) |
1957 слів |
|
час збереження / відновлення контексту |
65тактів (0,33 мкс) |
|
тривалість ISR (8 завдань) |
474 такту (2,37 мкс) |
|
тривалість ISR (63 завдання) |
2290тактів (11,5 мкс) |
До справжнього моменту робота над MicroDSP-RTOS завершена, результати впроваджені у виробництво замовника; зокрема, відомо про стільниковий телефон, в якому використовується ця система.
Література
1. С. Сорокін. Як багато ОС РВ хороших… Сучасні технології автоматизації, 2 / 1997, стор 7–11
2. С. Сорокін. Windows. Сучасні технології автоматизації, 2 / 1997, стор 18–20
3. С. Сорокін. Системи реального часу. Сучасні технології автоматизації, 2 / 1997, стор 22–29
4. Comparison between QNX RTOS V6.1, VxWorks AE 1.1 and Windows CE. NET. Dedicated Systems Experts
5. А. Жданов. Операційні системи реального часу. PCWeek, 8 / 1999.
6. А. Жданов, А. лати. Зауваження про вибір операційних систем при побудові систем реального часу. PCWeek, 1 / 2001
7. А.О. Жданов. Що день прийдешній нам готує? (У зв'язку з появою Windows NT на ринку ОСРВ).
8. А.О. Жданов. Сучасний погляд на ОС реального часу.
9. В. Семенюк. Системи реального часу.
10. T. Samuelsson, M. Åkerholm, Department of Computer Science and Engineering; P. Nygren, J. Stärner, L. Lindh. A Comparison of Multiprocessor RTOS Implemented in Hardware and Software. Computer Architecture Laboratory, Mälardalen University, Västerås, Sweden.