13. Отримання даних, переданих завданню.
14. При підключенні завдання їй можна передати будь-які дані (один з параметрів функції підключення – адреса довільної структури даних). Ця функція дозволяє отримати цю адресу, щоб мати можливість звернутися до переданих даних.
15. Зміна пріоритету завдання.
16. Ця функція дозволяє змінити пріоритет будь-якої задачі (при цьому новий пріоритет не повинен бути зайнятий). Для зручності роботи, щоб не потрібно було запам'ятовувати і визначати, яким пріоритет має кожна завдання в кожний момент часу, звернення до завдань здійснюється через унікальні ідентифікатори. По суті, ці ідентифікатори є змінними, які містять реальні значення пріоритетів завдань. У результаті до задачі, скажімо, номер 3 завжди можна звертатися через змінну TASK3, не замислюючись про те, змінювався чи є у неї пріоритет, і якщо змінювався, то який він зараз, оскільки ця змінна завжди буде містити коректне поточне значення пріоритету.
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, в якому на декількох вкладках відображує стан підключених на даний момент задач.