СОВРЕМЕННАЯ ЭЛЕКТРОНИКА 2010-5

ПРОГРАММИРОВАНИЕ 68 WWW.SOEL.RU СОВРЕМЕННАЯ ЭЛЕКТРОНИКА ◆ № 5 2010 Кроме установки своих обработчи ков при переключении контекста за дач или при возникновении ошибок, программист может указать при ком пиляции, какая задача будет выпол няться в системе при отсутствии дру гих готовых к выполнению задач ( idle task – задача бездействия системы). По умолчанию задача бездействия системы представляет собой беско нечную петлю (указатель на функ цию, которая выполняется при от сутствии других активных задач, со держится в таблице конфигурации системы). Для предотвращения возможных ошибок переполнения стека внутри потока, RTEMS предоставляет режим отладки со слежением за состоянием стека потока (модуль проверки гра ниц стека – Stack Bounds Checker ). Не обходимость контроля состояния сте ка указывается определением имени STACK_CHECKER_ON при компиляции, которое включается в таблицу кон фигурации системы. При создании новой задачи в RTEMS одним из па раметров является размер стека, ко торый будет использовать эта задача. Если в системе активен модуль конт роля состояния стека, то при созда нии новой задачи её область стека за полняется контрольными значения ми для индикации того, что данный адрес в стеке ещё не был использо ван. При выполнении задачи, по мере использования стека эти значения удаляются. При переключении кон текста задачи модуль проверки гра ниц стека проверяет, во первых, не повреждены ли последние N байт контрольных значений и, во вторых, попадает ли указатель стека задачи в заданный интервал. Если нарушено одно из этих условий, значит, поток превысил максимально допустимую границу, и при помощи команды printk будет сделана попытка вывода сообщения об ошибке переполнения стека. Число N последних байт, которые будут проверены, зависит от модели процессора. Также внутри самого потока можно вызывать системную функцию для проверки собствен ного стека потока ( rtems_stack_che cker_is_blown ). Также есть функция, докладывающая информацию об ис пользовании стека каждой из задач ( rtems_stack_checker_report_usage ). Платой за подключение этого модуля является увеличение времени созда ния задачи и переключения контекс та, т.к. данный модуль не может быть отключен «на лету». Если необхо димо динамически включать или выключать контроль стека, то осу ществить это можно при помощи динамически подключаемого набо ра расширений. Перечисленные вы ше компоненты ядра RTEMS дают возможность разработчику осущес твлять анализ работы приложения, не выходя из режима реального вре мени. Т АБЛИЦА КОНФИГУРАЦИИ СИСТЕМЫ Операционная система RTEMS долж на быть правильно сконфигурирована под конкретное приложение. Инфор мация для настройки системы включа ет все основные данные о ресурсах – период переключения контекстов за дач, используемые драйверы, макси мальное число дескрипторов в систе ме и т.д. Вся эта информация из табли цы конфигурации в заголовочном файле rtems/confdefs.h помещается RTEMS в системные структуры данных на этапе инициализации. Не указан ные в программе пользователя пара метры задаются по умолчанию. Сама таблица состоит из следующих разде лов: ● поддержка библиотек файловой системы и ввода вывода( filesystem and IO library support ) – параметры сбора статистики по вызовам mal loc , максимальное количество фай ловых дескрипторов, выбор корне вой файловой системы ( IMFS/mini IMFS ), указание собственной таблицы для монтирования разде лов, включение модуля проверки границ стека; ● основная системная информация ( basic system information ) – количест во микросекунд за один системный такт ( clock tick ), количество тактов за один квант времени ( timeslice quantum ) для каждой задачи, макси мальный приоритет любой задачи в системе, минимальный размер стека для каждой задачи и стека прерыва ний, указатели на функции пользо вателя по размещению и удалению стека; ● конфигурация задачи бездействия системы ( idle task ) – указатель на за дачу бездействия системы, предо ставленную пользователем, размер стека для задачи бездействия сис темы; ● таблица драйверов устройств ( device driver table ) – максимальное коли чество зарегистрированных драйве ров в системе, параметры использо вания драйвера консоли, часов, таймера, часов реального време ни, сторожевого таймера, драйвера / dev / null , драйверов для прило жения; ● таблица конфигурации RTEMS API – максимальное число задач, тайме ров, семафоров, наборов расшире ния и т.д.; ● таблица конфигурации POSIX API – максимальное число ресурсов для POSIX; ● таблица конфигурации ITRON API – максимальное число ресурсов для ITRON. П РИМЕР С ИСПОЛЬЗОВАНИЕМ МОДУЛЯ РАСШИРЕНИЙ В качестве примера использования функций Extension Manager рассмот рим небольшуюпрограмму, регистри рующую в системе динамически подк лючаемый набор расширений. Пол ный текст программы и Makefile к ней находятся на сайте журнала. Програм ма будет регистрировать набор расши рений, затем создаст две новые задачи и уничтожит себя. Работа наших расширений будет заключаться в выводе информации о задачах – их имён, идентификаторов, приоритета, времени выполнения. Для создания набора расширений не обходимо объявить свои функции – обработчики и структуру, состоящую из указателей на эти функции. По следняя состоит из восьми обработ чиков для следующих ситуаций: соз дание задачи, старт задачи, переза пуск задачи, уничтожение задачи, переключение, начало, выход, неисп равимая ошибка. // функции расширений Extension Manager bool my_task_create (rtems_tcb * curr, rtems_tcb * next); rtems_extension my_task_start (rtems_tcb * curr, rtems_tcb * next); rtems_extension my_task_restart (rtems_tcb * curr, rtems_tcb * next); rtems_extension my_task_delete (rtems_tcb * curr, rtems_tcb * deleted); rtems_extension my_task_switch (rtems_tcb * curr, rtems_tcb * © СТА-ПРЕСС