Використання процедур обробки переривань

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 виводиться адреса програмної пам'яті, з якого буде продовжено виконання завдання. Подвійним клацанням миші по цьому полю можна перейти до того місця вихідного коду, яке відповідає вказаною адресою, тобто по суті, до тієї точки виконання, в якій завдання була перервана.

Крім цього в цій вкладці можна змінювати стан завдань, а саме:

a.         відключити завдання (команда Disconnect Task в системному меню);

b.         перевести задачу з режиму очікування, блокування або призупиненого стану в режим готовності (команда Make Task Ready);

c.         змінити пріоритет завдання (редагуванням значення в полі Priority);

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

Зліва від імені кожного завдання присутній прапорець, включивши який, можна встановити точку зупину, спрацьовує в момент перемикання 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.