PIC24 osa:tutorial

OSA : Учебник. Содержание

2010-09-24T16:58:12+03:00

OSA : Учебник. Содержание

Введение

(Продолжение следует…)

Виктор Тимофеев, osa@pic24.ru

OSA : Учебник. Введение

2011-01-19T11:25:24+03:00

OSA : Учебник. Введение

К оглавлению

Вступление

ОСРВ для многих - новый инструмент и, как при знакомстве с любым новым инструментом, у программиста возникает вопрос: с чего начать? В данном пособии приведены несколько примеров, позволяющих упростить понимание организации ОСРВ и принципов ее работы и самое главное - научиться ее использовать для проектирования своих программ.

Во "Введении" будут рассмотрены общие вопросы применения OSA. Здесь будет рассказано о том, как реализуется многозадачность на одном контроллере, показана структура взаимодействия программы и ядра ОС, а также будут приведены особенности программ, использующих OSA.

Предполагается, что читатель уже знаком с PIC-контроллерами и языком программирования Си.

Определения

Для начала дадим несколько определений.

Ядро

- совокупность подпрограмм и системных переменных, обеспечивающих взаимодействие задач и разделение ресурсов контроллера между ними. Ядро скрыто от программиста, взаимодействие с ним обеспечивается специальными сервисами ОС.

Задачи

- самостоятельные подпрограммы, имеющие возможность работать параллельно друг с другом.

Приоритет

- количественная характеристика задачи, отражающая ее важность по отношению к другим задачам. Приоритет рассматривается планировщиком при наличии нескольких готовых к выполнению задач как основной критерий для выбора, какой из них передавать управление.

Планировщик

- подпрограмма в составе ядра, занимающаяся поиском готовых к выполнению задач, выделением самой приоритетной из них и передачей ей управления.

Сервисы ОС

- набор подпрограмм и макросов, предназначенных для доступа к функциям ядра. В основном применяются для управления состояниями задач и обмена информацией между задачами.

Ресурсы

- аппаратные возможности микроконтроллера, а также внешние модули, подключенные к нему, которыми может пользоваться задача во время своего выполнения.

Ресурсами являются:

в первую очередь - модуль выборки и выполнения команд, программный счетчик, АЛУ, аккумулятор (WREG) и регистр состояния (STATUS) (в один момент времени выполняться может только одна задача);
оперативная память (каждая задача может по-своему использовать память);
внутренняя EEPROM (пока одна задача выполняет запись, другие не могут производить ни запись ни чтение);
встроенные периферийные модули: последовательный порт, параллельный порт, АЦП, таймеры, порты ввода/вывода и т.д. (несколько задач могут выводить данные через USART; один и тот же вывод контроллера используется для разных целей);
какие-то внешние устройства, подключенные к контроллеру: LCD, EEPROM, DAC и т.д.

Многозадачность

Термин многозадачность означает, что система способна обеспечить параллельное выполнение нескольких процессов (задач), разделяя между ними ресурсы контроллера.

Не вдаваясь в подробности, рассмотрим, как выглядит многозадачность на практике. Рассмотрим для простоты параллельное выполнение двух процессов (задач): Task1 (голубой график) и Task2 (зеленый график).

Рис.1

На рисунке рис.1а изображено то, как многозадачность воспринимается пользователем: обе задачи выполняются одновременно, каждая выполняет какие-то свои действия (например, одна задача управляет двигателем стиральной машины, а другая выводит на индикатор текущее состояние: режим работы, время до завершения стирки, температуру стирки и т.д.). Пользователю кажется, что обе задачи выполняются одновременно. Но на самом деле это не совсем так.

Т.к. контроллер в один момент времени может выполнять только одну команду (или одну последовательность команд), то для выполнения двух задач он должен переключаться с выполнения одной последовательности команд на другую и обратно. Поэтому на уровне программы многозадачность будет выглядеть несколько иначе, чем на уровне пользователя (рис.1б): задачи по очереди сменяют друг друга, захватывая на какое-то время ресурсы контроллера. Одна задача, отработав какое-то время, приостанавливается и начинает выполняться другая. Пользователю же это будет незаметно, т.к. смена задач происходит достаточно быстро.

Контроллер должен знать, когда и какую последовательность команд выполнять, когда и как переключаться между ними. Для этого и служит операционная система. И на уровне операционной системы многозадачность будет выглядеть так, как показано на рис.1в. Обратим внимание, что здесь добавлен еще один график - желтый - ядро операционной системы. Прерываясь, задача Task1 передает управление не задаче Task2, а планировщику операционной системы (в кооперативных ОСРВ именно задача передает управление планировщику, в отличие от вытесняющих, где сам планировщик либо более приоритетная задача отнимают управление у менее приоритетной), который в свою очередь принимает решение о том, какой задаче отдать управление. В нашем случае он отдает управление задаче Task2. Когда Task2 отдает управление планировщику, у Task1 появляется шанс получить управление вновь.

Наконец, для полноты картины добавим еще один график (рис.1г) - прерывания. Как видно из рисунка прерывание может прервать как задачу, так и планировщик.

Здесь, наверное, может возникнуть вопрос: для чего нужны сложности с планировщиком, если можно в вечном цикле (часто называют суперциклом или суперлупом) по очереди вызывать функции, содержащие код для Task1 и Task2? Штука в том, что при вызове функции мы каждый раз попадаем в ее начало, в то время как ОС позволяет нам прервать функцию в любом месте, позволив выполниться другим функциям, а затем продолжить ее выполнение с того места, где она была приостановлена. (Это основное отличие от суперцикла. На остальных отличиях пока не будем заострять внимание.) Благодаря этой особенности, каждая задача может быть написана как отдельная независимая программа (она должна быть написана с учетом некоторых требований, но об этом чуть ниже).

Структура программы под OSA

На рис.2 схематически изображено взаимодействие программы пользователя с ядром операционной системы. Все, что находится внутри желтого прямоугольника, - это ядро ОС, скрытое от программиста. Взаимодействие с ним производится только через сервисы ОС.

Рис.2

Логически программа получается разбита на 5 частей:

ядро системы (желтое);
main() - основная функция Си-программы;
прерывание (красное) - код прерывания; обратим внимание, что рядом с прерыванием стоит OS_Timer(), присоединенный к нему пунктирной линией; такая условная привязка показывает, что сервис OS_Timer чаще всего (но не всегда) вызывается именно из прерывания;
задачи (светло-голубые) - Си-функции, которые предполагается использовать как параллельно выполняющиеся задачи ОС;
функции - все вспомогательные функции.

Сердцем ядра является планировщик, который оперирует с массивом задач, выбирая из него самую приоритетную из готовых и передавая ей управление. Массив задач - это массив дескрипторов, содержащих для каждой активной задачи данные, необходимые для работы с ней: текущий адрес или точка возврата в задачу, состояние задачи (готова, ждет событие, пауза, задержка), таймер задачи (у каждой - свой) и некоторые дополнительные данные в зависимости от используемой платформы (например, для MCC18 - значение регистра FSR1, т.е. указателя стека; для MCC30 - регистры общего назначения W8..W15).

Передача управления внутри системы

Красными линиями показаны пути передачи управления внутри программы. Причем светло-красные обозначают вызов подпрограммы (т.е. подразумевает возврат из нее), а темно-красные - передачу управления безусловным переходом (без возврата). Обратим внимание на три момента:

передача управления от OS_Run() планировщику ОС производится только в одном направлении. Это означает, что после вызова сервиса OS_Run управление берет на себя ядро ОС, т.е. на этом вызове выполнение функции main() заканчивается;
вызов функций-задач осуществляется только самим планировщиком и скрыт от программиста;
вызов функций из тела прерывания - не всеми поддерживаемая практика, тем не менее, такое допустимо.

После ресета мы попадаем в функцию main(), где производим инициализацию системы OS_Init(), создаем задачи OS_Task_Create() и передаем управление планировщику OS_Run(). Планировщик живет сам по себе, циклически проверяя все задачи в своем внутреннем списке на предмет готовности. Когда появляются готовые к выполнению задачи, планировщик выбирает из них ту, приоритет которой самый высокий, и передает ей управление. Обратите внимание, что передача управления задаче отмечена на рисунке темно-красной линией: это значит, что задача должна будет сама вернуть управление ядру, иначе остальные задачи никогда не получат управление. Для возврата в планировщик есть специальные сервисы: безусловный возврат, перевод в режим ожидания события или задержки, приостановка задачи и удаление задачи.

Во время своего выполнения задача может вызывать другие функции (не являющиеся задачами).

Обмен данными

Голубыми линии показано направление обмена данными. Рассмотрим особенности:

OS_Init() очищает массив задач;
OS_Task_Create() - добавляет задачу в список, если там есть свободное место;
массив задач снабжает данными планировщик;
OS_Timer() увеличивает значения таймеров задач, отслеживая их переполнение, и пользовательских таймеров, также следя за переполнениями;
из функций задач, помимо обычных сервисов, разрешенных для использования в любом месте программы, можно также использовать сервисы, переключающие контекст (т.е. передающие управление планировщику), поэтому рядом с линией между задачами и сервисами стоит литера "Т";
из прерывания, помимо общих сервисов, можно вызывать специальные сервисы, предназначенные для работы в прерывании, поэтому рядом с линией стоит литера "I";
из функций разрешен вызов сервисов, не переключающих контекст и не предназначенных для работы в прерывании.

Особенности программы, написанной с использованием OSA

Программа, написанная с использованием ОСРВ OSA, должна быть написана с учетом некоторых требований:

в папке проекта должен быть размещен файл osacfg.h - файл конфигурации системы (в простейшем случае этот файл может быть пустым);
в проект, помимо файлов самой программы, должен быть включен файл osa.c (это требование не относится к программам, написанным на CCS);
во все Си-файлы проекта, в которых предполагается использование системных сервисов, должен быть включен файл osa.h (директивой #include);
в опциях компилятора должны быть указаны пути для включаемых файлов (include-пути): путь к папке проекта и путь к папке, где находятся файлы osa.c и osa.h;
в функции main() должны вызываться два системных сервиса: OS_Init и OS_Run.
в программе должна быть одна или несколько функций, описанных как задачи.

Ниже в двух словах все эти пункты расшифровываются. Здесь их расшифровка приводится только для информации; более подробно они будут рассмотрены по ходу уроков.

osacfg.h

Система OSA является довольно гибкой в настройке, что позволяет сконфигурировать ее под конкретный проект так, чтобы минимизировать ресурсозатраты. Все указания по конфигурации OSA для конкретного проекта задаются в файле osacfg.h (поэтому и важно, чтобы файл находился именно в папке проекта). В самом простом случае этот файл может быть пустым, тогда система будет сконфигурирована по умолчанию. Однако в большинстве случаев может понадобиться внести коррекцию в настройки системы с тем, чтобы повысить эффективность использования ОСРВ.

Этот файл можно создавать вручную, задавая нужные значения констант конфигурации, описанные здесь. Но гораздо проще, удобнее, быстрее и нагляднее пользоваться специальной утилитой OSAcfg_Tool, которую можно скачать здесь. Эта программа представляет собой диалоговое окно, в котором программист выбирает параметры системы для своего проекта: количество задач, банки памяти для размещения системных переменных, размерности переменных и т.д. Далее в уроках мы будем создавать этот файл с использованием этой утилиты. Те, кто не захотят ей пользоваться, а захотят создавать файл конфигурации вручную, смогут один раз заглянуть в сгенерированный утилитой файл, чтобы понять, как правильно его создавать.

osa.c

Этот файл содержит определения всех системных переменных и функций. Было решено его оставить именно в виде Си-файла, не компилируя в библиотеку, с тем, чтобы он был максимально гибким в настройке. Т.к. PIC-контроллеры младшего семейства имеют дефицит ресурсов, то бывает так, что каждый байт на счету. Максимальной оптимизации получится добиться только использованием условных директив в Си-файле. В противном случае пришлось бы создавать целую кучу вариантов библиотечных файлов под разные контроллеры и под различные конфигурации, что усложнило бы процесс создания проекта и процесс изменения конфигурации в ходе работы над проектом.

osa.h

Этот файл содержит прототипы системных функций, предопределения системных переменных, а также включает в себя файлы с определением макросов всех системных сервисов. Именно этому файлу требуется наличие файла конфигурации osacfg.h, т.к., опираясь на настроечные константы из него, будет принято решение о том, какие функции и переменные включать в программу.

include-пути

Здесь все просто: компилятор должен знать, где искать подключаемые файлы, а именно - osa.h (и, следовательно, все файлы включаемые в него из папок osa\port и osa\service) и файл osacfg.h, чтобы он был включен в osa.h.

OS_Init() и OS_Run()

Наличие вызова этих двух сервисов обязательно. Причем OS_Init должен быть вызван в самом начале программы до вызова какого-либо другого сервиса ОС, а OS_Run - в самом конце (после OS_Run ничего не будет выполняться, т.к. этот сервис переводит программу в вечный цикл).

OS_Init - процедура инициализации системы. В ней подготавливаются все системные переменные, обнуляются списки задач, таймеров, семафоров. Этот сервис должен вызываться один раз за все выполнение программы (если, конечно, самой программой не предусмотрен программный ресет).

OS_Run - этот сервис представляет собой вечный цикл, в котором крутится планировщик - подпрограмма, отвечающая за проверку готовности задач, сравнение приоритетов у готовых задач и передачу управления наиболее приоритетной из готовых задаче. Т.к. сервис содержит внутри себя вечный цикл, то все, что в программе идет за вызовом этого сервиса, будет либо проигнорировано на стадии компиляции, либо просто никогда не получит управление.

void main (void)
{
    ...           // Инициализация периферии, переменных программы и пр.
    OS_Init();
    ...           // Создание задач, подготовка сервисов
    OS_Run();
}

Функции-задачи

Те функции, которые предполагается выполнять параллельно, т.е. сами задачи, описываются как обычные Си-функции с параметром void, но должны быть оформлены по определенным правилам:

тело функции должно содержать вечный цикл (есть случаи, когда можно обойтись и без него, но на первых порах этого делать не стоит);
внутри вечного цикла должен вызываться хотя бы один сервис, передающий управление планировщику;
из этой функции нельзя осуществлять выход оператором return.

Из функции-задачи можно вызывать другие функции (не являющиеся задачами). Локальные переменные всех функций задач занимают одну и ту же область памяти, и после передачи задачей управления планировщику значения локальных переменных будут утеряны. Если есть переменные, значения которых важно сохранить до следующего получения управления, должны быть описаны как static.

Вот типичный пример функции-задачи:

void Task_1 (void)
{
    static unsigned char s_ucCounter;    // Определение глобальных переменных задачи
           unsigned char i, j;           // Определение локальных переменных задачи
 
    s_ucCounter = 0;                     // Код подготовки (если нужен)
 
    for (;;)
    {
        OS_Yield();
    }
}

Осталось только определиться с тем, как операционная система узнает, какие функции являются задачами, а какие - нет. Мы сами ей об этом сообщим через системный сервис OS_Task_Create, добавив, таким образом, указатель на функцию во внутренний список системы. Сервис OS_Run в своем цикле просматривает этот список и передает управление по занесенным в него указателям.

void main (void)
{
    OS_Init();
    OS_Task_Create(0, Task_1);    // Теперь система знает, что Task_1 - это задача ОС
    OS_Run();
}

Замечание об именах идентификаторов

Во всех уроках мы будем придерживаться единого стиля именования идентификаторов, чтобы не возникало путаницы. Вот они:

имена констант будут даваться заглавными буквами;
имена переменных будут содержать префиксы:
1. области видимости:
  - "m_" - глобальная для всех модулей;
  - "s_" - статическая переменная внутри функции;
  - без префикса - локальная переменная внутри функции или аргумент функции.
2. типа переменной:
  - "uc" - unsigned char;
  - "sc" - signed char;
  - "c" - char (в случаях, когда не важно, знаковый или беззнаковый);
  - "b" - bit;
  - "n" - signed int;
  - "w" - unsigned int;
  - "l" - signed long;
  - "dw" - unsigned long;
  - "smsg_", "msg_", "queue_" и т.п. - префиксы для глобальных переменных управления сервисами.
имена функций-задач будут содержать префикс "Task_".

Такая система имен может показаться запутанной и ненужной, однако моя практика показала, что она позволяет, во-первых, предотвращать ошибки на стадии написания программы, а во-вторых, сильно упрощает чтение чужой программы (или своей спустя год-два). Возможно, у кого-то есть своя система имен, я никому мою не навязываю, но в данных уроках мы будем пользоваться приведенной выше системой. И встретив в программе переменную с именем, например, s_ucCounter, вы сразу поймете, что это статическая переменная внутри задачи (ее значение будет сохраняться после передачи управления планировщику) типа unsigned char.

Замечание о локальных переменных внутри функций-задач

Я о локальных переменных в задачах уже упоминал, но остановлюсь на этом вопросе немного подробнее. Дело в том, что ОСРВ OSA является некоей надстройкой над компилятором, и сам компилятор не учитывает ее особенностей. В частности компилятор не знает о том, что в программе есть такие функции, выполнение которых может прерываться в произвольном месте (мы сами точно знаем, что функции прерываются в местах, где происходят вызовы сервисов передающих управление планировщику, но компилятору это неведомо). Поэтому он считает, что локальные переменные, описанные внутри такой функции, являются собственностью этих функций на протяжении всего времени их выполнения. На этапе компиляции строится граф вызовов, опираясь на который, линкер распределяет память под локальные переменные так, чтобы между ними не было пересечений на разных уровнях графа, при этом локальные переменные функций одного уровня могут располагаться в одной и той же области памяти, т.к. предполагается, что эти функции не будут прерывать друг друга.

Однако в случае с ОСРВ дело обстоит иначе, а именно - все функции-задачи, находящиеся на одном уровне в графе вызовов (первый уровень после main), выполняются параллельно, постоянно сменяя друг друга в ходе выполнения. И т.к. у них под локальные переменные задействована одна и та же область памяти, задачи при переключении между собой будут пользоваться этой областью каждая под свои нужды, затирая данные, записанные туда другими задачами. Поэтому, если важно, чтобы значение переменной сохранилось после передачи управления планировщику (а следовательно - и другим задачам), то ее нужно определять с квалификатором static. Тогда эта переменная будет размещена в другой области памяти и будет закреплена исключительно за той функцией, в которой она определена. По ходу рассмотрения уроков мы будем возвращаться к этой теме.

Состояния задач

Как описано в документации в параграфе "Состояния задач", задача может находиться в одном из пяти состояний: не создана (удалена), в ожидании, в готовности, в работе и приостановлена. Ниже схематически изображен граф изменения состояний:

Примечания:

Задача может быть создана или продолжена после приостановки только извне.
На графе состояний не показано, что любая задача в любой момент может быть приостановлена/продолжена/удалена извне.

Особенности отладки

Отладка программы, написанной под ОСРВ, немного отличается от отладки обычной программы. Это связано, главным образом, с тем, что тело основной функции программы (планировщика задач) скрыто от программиста (сам планировщик оформлен в виде макроса, что позволяет запускать его тело исключительно в окне дизассемблера).

Сейчас этот параграф можно пропустить, т.к. в нем используются термины и куски программ, которые будут рассмотрены в уроках. По ходу уроков мы будем ссылаться на этот параграф для объяснения некоторых моментов, связанных с отладкой.

Пошаговая отладка

Два слова о том, как работает пошаговый отладчик (это относится и к симулятору, и к внутрисхемным отладчикам). При выполнении команды Step Over (F8) отладчик делает следующее:

запоминает адрес следующей за выполняемой строкой строки (при работе в симуляторе он просто запоминается, при работе с внутрисхемными отладчиками на следующей строке устанавливается breakpoint);
запускает программу на выполнение;
дойдя до запомненного адреса (или до breakpoint'а) останавливает выполнение программы;
при работе с внутрисхемными отладчиками удаляет breakpoint.

Зачем такие хитрости с точками останова? Дело в том, что одна строка Си-кода может быть транслирована в несколько (иногда в сотни) инструкций ассемблера. Кроме того, текущая строка может просто-напросто содержать в себе вызов подпрограммы. Чтобы при выполнении каждой инструкции не проверять, дошла ли программа до требуемого адреса, ставится точка останова. К слову сказать, симулятору все равно, как это делать: через точку останова или прямым сравнением текущего адреса с адресом следующей строки; но внутрисхемному отладчику это важно, т.к. проверка адреса после выполнения каждой инструкции очень сильно замедлила бы его работу.

Рассмотрим на конкретном примере. Предположим, программный счетчик в данный момент указывает на строку программы, содержащую вызов функции:

Когда пользователь нажимает F8, запоминается программный адрес следующей за вызовом функции delay(10) строки: "cCounter = 25;". Далее программа начинает выполняться. Т.е. заходит внутрь подпрограммы delay(), выполняет внутри нее какие-то действия, возможно даже вызов других подпрограмм. Но как только будет произведен возврат из подпрограммы delay(), и программный счетчик станет равным запомненному в начале адресу (или, если мы работаем с внутрисхемным отладчиком, как только программа дойдет до точки останова), отладчик приостановит выполнение программы (удалив при этом точку останова), и мы увидим, что зеленая стрелка теперь указывает на строку присваивания "cCounter = 25;".

Примечание. Если в теле функции delay() или в теле одной из функций, которые вызываются из функции delay(), стоит пользовательская точка останова, то отладчик прервет выполнение программы, как только программный счетчик станет равным адресу точки останова.

Рассмотрим простой пример синхронизации двух задач с помощью бинарного семафора:

void Task1 (void)
{
    for (;;)
    {
        OS_Bsem_Set(0);      // Позволяем выполниться задаче 2
        OS_Delay(10);
    }
}
//--------------------------
void Task2 (void)
{
    for (;;)
    {
        OS_Bsem_Wait(0);     // Ждем события от задачи 1
        PIN_LED ^= 1;            // Мигаем светодиодом
    }
}

Примечание: PIN_LED - вывод контроллера, управляющий светодиодом.

Эта программа включает/выключает светодиод на выводе PIN_LED с интервалом в 10 системных тиков. Логика работы программы такова: задача Task1 с интервалом в 10 системных тиков устанавливает бинарный семафор. Задача Task2 находится в режиме ожидания семафора. Как только она видит, что семафор установлен, она становится готовой к выполнению и при первой же возможности получает его (становится в режим работы), при этом семафор сразу сбрасывается (это делается автоматически сервисом OS_Bsem_Wait()). После этого состояние светодиода меняется на противоположное (зажжен/погашен), и задача вновь становится в режим ожидания двоичного семафора (ведь он был сброшен сразу же при входе в задачу). Задача Task1 все это время находится в режимы ожидания задержки. Через 10 системных тиков она станет готовой к выполнению и после его получения вновь установит семафор.

Схематически программа будет выглядеть так:

Как видно из рисунка, обе задачи выполняются по одному разу, после чего система бездействует (планировщик крутится впустую, т.к. нет готовых задач: одна ждет завершения задержки, другая - установки семафора). В это время у нас происходят прерывания, в коде обработчика которых вызывается сервис OS_Timer, который следит за отсчетом задержки задачи Task1. Как только время задержки истекает, планировщик переводит задачу Task1 в готовность, а так как она единственная готовая к выполнению задача, то она сразу получает управление. Получив его, она вновь устанавливает семафор, делая готовой задачу Task2, а сама опять встает в режим ожидания задержки. И так по кругу.

Рассмотрим, что произойдет, если мы попытаемся пройти эту программу в симуляторе по шагам (F8).

Ниже будет рассмотрено поведение отладчика при работе под PICC18, MCC18 и MCC30. При отладке под PICC для контроллеров PIC10, PIC12 и PIC16 есть свои нюансы, которые будут рассмотрены далее.

Первым делом мы попадаем в начало функции main(). Пройдя по шагам вызовы всех подпрограмм инициализации (периферии и системы) и создание задач, мы подойдем к вызову сервиса OS_Run, который запускает планировщик в работу. Здесь мы столкнемся с первой неприятностью. Дело в том, что при попытке выполнить OS_Run командой Step Over (F8) программа начнет выполняться и никогда не остановится (если мы ее сами не остановим). Произойдет это потому, что отладчик запомнит адрес следующей за OS_Run строки, но на него программа никогда не попадет, т.к. OS_Run содержит в себе вечный цикл.

Поэтому, если мы хотим отладить какую-нибудь функцию-задачу по шагам, то сперва-наперво следует поставить в ней точку останова.

Task1

Итак, попробуем выполнить задачу Task1 по шагам, для чего сперва установим точку останова на вызове сервиса:

Далее хоть по шагам (F8), хоть сразу (F9) - дойдем до этой точки останова. Теперь рассмотрим, что получится, когда мы попытаемся выполнить пошаговую отладку. Если бы программа была написана по принципу суперцикла, то поведение отладчика было бы предсказуемым: после установки семафора мы бы через несколько шагов очутились бы в задаче Task2 на строке, следующей за ожиданием семафора. Однако с программой, написанной под ОСРВ, отладчик поведет себя немного иначе. Нажмем F8, выполним тем самым вызов сервиса OS_Bsem_Set(), т.е. установив двоичный семафор. Отладчик сделает шаг и остановится перед вызовом системного сервиса OS_Delay(). Сервис OS_Bsem_Set не содержит внутри себя передачи управления планировщику, поэтому с ним трудностей не возникло. Но вот сервис OS_Delay при выполнении передаст управление планировщику.

Что при этом произойдет. Отладчик запомнит адрес следующей строки за OS_Delay, т.е. адрес конца (или начала, как удобнее) цикла, и запустит программу на выполнение. Программа будет выполняться до тех пор, пока программный счетчик не станет равным запомненному адресу. Т.е. за один шаг F8 произойдет следующее:

управление будет передано планировщику;
планировщик запустит задачу Task2, т.к. она окажется единственной готовой к выполнению;
Task2 изменит состояние светодиода;
Task2 передаст управление планировщику, встав в режим ожидания;
планировщик будет крутиться вхолостую, пока вызываемый в прерывании сервис OS_Timer не обнаружит, что время задержки Task1 вышло; при этом Task1 установится в режим готовности;
планировщик передаст управление единственной готовой задаче Task1.

Другими словами вся работа Task2 выполнится незаметно для нас. Мы нажмем F8, находясь перед вызовом OS_Delay() и имея установленный семафор, и сразу же окажемся в начале цикла, перед вызовом сервиса OS_Bsem_Set(). К этому моменту мы обнаружим, что светодиод уже поменял свое состояние, а семафор уже сброшен. Схематически это можно изобразить так:

Все, что в заштрихованной области, включая все тело Task2, будет выполнено за один шаг.

Task2

Точно так же отладчик поведет себя, если мы попытаемся выполнить по шагам задачу Task2. Дойдя до вызова сервиса OS_Bsem_Wait, который передает управление планировщику, мы будем знать, что при выполнении команды отладчика Step Over (F8) мы за один шаг пропустим весь цикл выполнения задачи Task1, вместе с задержкой в 10 системных тиков.

Все, что в заштрихованной области, включая все тело Task1, будет выполнено за один шаг.

При пошаговой отладке задачи Task2 мы будет крутиться в цикле, по очереди выполняя две операции: ожидание семафора, изменении состояния светодиода. Все остальные задачи, которые активны на данный момент, будут выполняться в фоновом режиме незаметно для нас.

Вывод

К чему все это рассказывается? Вот к чему:

Если при отладке нам важно проследить цепочку взаимодействия задач между собой, то мы должны во всех местах, имеющих отношение к этому взаимодействию, ставить точки останова (breakpoint'ы). Причем устанавливать их нужно непосредственно за сервисами, переключающими контекст (передающими управление планировщику).

В нашем конкретном примере нужно поставить две точки останова: за сервисом OS_Delay (а именно - на вызове сервиса OS_Bsem_Set) для задачи Task1 и за сервисом OS_Bsem_Wait (а именно - на операции PIN_LED ^= 1) для задачи Task2.

Примечание для PIC10, PIC12 и PIC16

Все выше сказанное относилось к работе с компиляторами PICC18, MCC18 и MCC30. При работе с компилятором PICC нельзя точно предсказать поведение отладчика при попытке выполнить сервис, переключающий контекст, в пошаговом режиме. Поэтому, когда будете производить отладку программы, написанной под PICC, выполняйте сервисы, переключающие контекст, командой отладчика Run (F9), предварительно установив точки останова в интересующих местах. Иногда это бывает сложно (особенно при работе с внутрисхемным отладчиком, который имеет возможность поставить всего одну точку останова), т.к. не всегда удается предсказать, какую задачу планировщик выберет для выполнения. Но другого способа отладки пока нет.

Просмотр переменных

Работая с сервисами, управляющими пользовательскими данными (сообщения, очереди, флаги, семафоры, таймеры), иногда необходимо следить за их состояниями через окно Watch. С переменными, создаваемыми программистом явно, все понятно: каждая такая переменная имеет свой идентификатор и свою область видимости. Например:

OST_SMSG   smsg_Sound;
OST_DTIMER dt_Alarm;

Эти две переменные типов "короткое сообщение" и "динамический таймер" могут быть добавлены в окно Watch, в котором за ними можно будет наблюдать. Таким же образом можно наблюдать за переменными следующих типов:

OST_SMSG - короткое однобайтовое сообщение;
OST_MSG - указатель на сообщение;
OST_MSG_CB - дескриптор управления указателем на сообщение;
OST_FLAG, OST_FLAG16, OST_FLAG32) - флаги;
OST_CSEM - счетный семафор;
OST_QUEUE, OST_SQUEUE - очереди сообщений;
OST_DTIMER - динамический таймер.

Но OSA имеет два вида пользовательских переменных, которые создаются на этапе компиляции и контролируются самой системой:

двоичные семафоры;
статические таймеры.

Т.е. двоичные семафоры и статические таймеры не имеют собственных идентификаторов. Они сгруппированны в массивы, что позволяет сократить код обработки этих данных и сэкономить оперативную память. Однако такая организация затрудняет отслеживание значений этих переменных при отладке.

Как их наблюдать?

Двоичные семафоры

Все двоичные семафоры хранятся в массиве:

unsigned char OS_BSem[];

размерность которого зависит от количества используемых в системе семафоров (задается константой OS_BSEMS в файле конфигурации osacfg.h) из расчета: один байт на каждую неполную восьмерку. (Примечание. Для MCC30 элементы массива имею тип unsigned int.)

Младший бит в нулевом элементе массива - это нулевой семафор. Байт с маской 0x02 - первый, 0x04 - второй и т.д. Таким образом, чтобы отследить нужный нам семафор при отладке, нам надо следить за состоянием соответствующего бита в массиве OS_BSem. Это довольно неудобно, но такова плата за экономию оперативной памяти.

Статические таймеры

Все статические таймеры хранятся в массиве:

_OST_STIMER OS_STimers[];

Тип элементов массива и размерность массива задается в файле osacfg.h константами OS_STIMER_SIZE и OS_STIMERS, соответственно. Каждый элемент массива - отдельный таймер. Самый старший бит каждого таймера (7-ой, 15-ый или 31-ый, в зависимости от типа) - бит активности. Если он установлен, значит, таймер считает. Если сброшен, - таймер переполнился и остановлен. Статические таймеры в окне Watch удобно отображать в виде знаковых целых чисел. Тогда будет видно, сколько времени осталось до окончания счета. Например:

Здесь видно, что статический таймер 0 считает (т.к. число отрицательное), и ему осталось 2000 системных тиков до завершения счета. Статический таймер 1 - не считает, т.к. старший бит сброшен (число не отрицательное).

OSA : Учебник. Урок 1 - OS_Yield

2011-01-19T11:26:35+03:00

OSA : Учебник. Урок 1 - OS_Yield

К оглавлению

Тема

Для начала рассмотрим самый простой пример - параллельную работу двух пустых задач. Практически он ничего не будет делать, но для нас может оказаться полезным для понимания механизма работы ОС. Данную программу можно будет погонять в симуляторе, наставив брейкпоинтов. Цель урока - исследование работы сервиса безусловного переключения контекста OS_Yield().

Проект

Для начала создадим проект в оболочке MPLab по шагам, описанным в документации.

1. Создание проекта

создаем рабочую папку "c:\tutor\t1";
в ней создаем пустой файл "tutor1.c";
запускаем MPLab (если в ней открыт проект, то закрываем его через меню "File\Close Workspace";
через меню "Project\Project Wizard…" создаем новый проект:
1. в качестве процессора можно пока использовать любой (например, 16F887, т.к. он установлен на демоплате из набора PicKit2);
2. выбираем инструмент (toolsuite): HI-TECH PICC Toolsuite;
3. создаем файл проекта с именем tutor1.mcp в папке "c:\tutor\t1";
4. добавляем в проект созданный нами пустой файл tutor1.c и файл системы "c:\osa\osa.c";
5. нажимаем кнопку "Готово".

Проект создан, можно переходить ко второму шагу.

2. Конфигурирование проекта (osacfg.h)

Создаем файл конфигурации для нашего проекта, для чего воспользуемся утилитой OSAcfg_Tool.exe. После запуска программы перед нами диалоговое окно, позволяющее нам в интерактивном режиме сделать все настройки ОС для конкретного проекта. Для начала укажем программе, где проект будет располагаться, для этого кнопкой "Browse…" открываем диалоговое окно выбора файла и в нем выбираем рабочую папку "c:\tutor\t1", где будет располагаться наш файл конфигурации. Нажимаем "OK". Программа сообщит нам, что файл еще не существует и будет создан при сохранении. Жмем "OK".

Пока не будем вдаваться в подробности, касающиеся назначения различных секций в диалоговом окне, а ограничимся минимальным набором, который будет необходим нам для запуска первого проекта. Единственное, что нам нужно сделать, это установить количество задач в секции "System" равное двум (т.к. у нас будет две задачи). После этого жмем кнопку "Save" в нижней части экрана, читаем сообщение, что файл успешно сохранен, давим "OK" и выходим из программы конфигуратора по кнопке "Exit".

Убеждаемся, что файл OSAcfg.h создан в папке "c:\tutor\t1". Для интереса можете заглянуть в его содержимое. Там будет только одна значащая строчка (помимо сопровождающих комментариев):

#define OS_TASKS          2

Эта строчка скажет компилятору при сборке, что нужно зарезервировать память под два дескриптора задач. Сейчас для нас это главное.

3. #include <osa.h>

Включаем в tutor1.c используемые заголовочные файлы: pic.h и osa.h.

#include <pic.h>
#include <osa.h>

4. Указание путей

Через меню MPLab "Project\Build options…\Project" открываем параметры проекта и во вкладке "Directories" добавляем два пути в "Include Search Path":

"c:\osa" - путь к файлам операционной системы;
"c:\tutor\t1" - путь к файлам проекта.

5. Функция main()

В функцию main() добавляем вызов двух обязательных системных сервисов: OS_Init() и OS_Run().

#include <pic.h>
#include <osa.h>
 
void main (void)
{
    OS_Init();
    OS_Run();
}

Как уже было описано во "Введении", OS_Init() инициализирует все внутренние переменные системы, обнуляет список дескрипторов задач. OS_Run() организует вечный цикл, в котором просматривает список задач на предмет готовности, и когда обнаруживает готовую задачу, передает ей управление.

Описание задач

Как уже было сказано, задача в OSA - это обычная функция Си, которая содержит внутри себя вечный цикл, внутри которого вызывается хотя бы один сервис ОС, переключающий контекст. Для нашего примера мы воспользуемся самым простым сервисом переключения контекста - OS_Yield(), который просто передает управление обратно планировщику, оставляя задачу в состоянии готовности. Для наглядности мы нагрузим каждую задачу какой-нибудь простой операцией. В большинстве случаев в качестве такой операции приводят увеличение какой-нибудь переменной на 1. Мы не будем мудрить и воспользуемся общим подходом: для каждой задачи будет заведена своя переменная-счетчик, значение которой мы и будем отслеживать в процессе отладки программы. Итак, у нас будут две одинаковые задачи следующего вида:

char m_cCounter1;
char m_cCounter2;
 
void Task_T1 (void)
{
    m_cCounter1 = 0;
    for (;;)
    {
        OS_Yield();              // Передача управления операционной системе
        m_cCounter1++;
    }
}
 
void Task_T2 (void)
{
    m_cCounter2 = 0;
    for (;;)
    {
        OS_Yield();              // Передача управления операционной системе
        m_cCounter2++;
    }
}

Как видно, обе функции: Task_T1 и Task_T2 - соответствуют требованиям, предъявляемым к функциям-задачам, а именно:

они содержат в себе вечный цикл;
внутри вечного цикла есть вызов сервиса, переключающего контекст.

Все, что нам осталось сделать, - это дописать в функцию main() вызовы сервисов OS_Task_Create, которые сообщат операционной системе, что функции Task_T1 и Task_T2 являются задачами ОС. Эти сервисы должны вызываться после OS_Init (т.к. сам OS_Init, помимо всего прочего, обнуляет список задач) и перед OS_Run (т.к., как уже писалось ранее, этот сервис содержит вечный цикл, и код, стоящий после вызова этого сервиса выполнен не будет).

void main (void)
{
    OS_Init();
    OS_Task_Create(3, Task_T1);
    OS_Task_Create(3, Task_T2);
    OS_Run();
}

Первым параметром в сервисе OS_Task_Create указывается приоритет создаваемой задачи от 0 (высший) до 7 (низший). Сейчас задачам установлен одинаковый приоритет (позже будет объяснено, почему).

Полный текст

Итак, полный текст нашей программы теперь будет выглядеть так:

#include <osa.h>
 
//******************************************************************************
//  Глобальные переменные
//******************************************************************************
char m_cCounter1;
char m_cCounter2;
//******************************************************************************
//  Функции-задачи
//******************************************************************************
void Task_T1 (void)
{
    m_cCounter1 = 0;
    for (;;)
    {
        OS_Yield();              // Передача управления операционной системе
        m_cCounter1++;
    }
}
//------------------------------------------------------------------------------
void Task_T2 (void)
{
 
    m_cCounter2 = 0;
    for (;;)
    {
        OS_Yield();              // Передача управления операционной системе
        m_cCounter2++;
    }
}
//******************************************************************************
//  main
//******************************************************************************
void main (void)
{
    OS_Init();                  // Инициализация переменных системы
    OS_Task_Create(3, Task_T1); // Добавление задач в список
    OS_Task_Create(3, Task_T2);
    OS_Run();                   // Запуск планировщика
}
//******************************************************************************
//  end of file
//******************************************************************************

Как работает программа

Как будет работать наша программа? После обработки сервиса OS_Init список задач пуст. Два последовательно вызванных сервиса OS_Task_Create записывают в свободные ячейки списка задачи Task_T1 и Task_2. Обе задачи после создания находятся в состояния готовности. Далее мы запускаем в работу планировщик сервисом OS_Run. Он будет перебирать все активные (созданные) задачи в списке задач, проверять их готовность, сравнивать приоритеты и запускать самую приоритетную из готовых. Если к выполнению готовы несколько задач с одинаковым приоритетом, то они будут выполняться по очереди.

Итак, планировщик по очереди просмотрит обе задачи. Они обе готовы и обе имеют одинаковый приоритет, поэтому планировщик передаст управление сперва той, которая была создана первой, т.е. Task_T1. Задача переводится из состояния готовности в состояние "в работе". При первом запуске задача начинает работать с самого начала функции, в нашем случае первым выполнится присваивание переменной m_cCoutner1 значения "0". Далее мы попадаем в вечный цикл, в котором первым шагом производится передача управления планировщику сервисом OS_Yield. Т.е. OS_Yield() является своего рода эквивалентом return'а (но это не одно и то же). При выполнении сервиса OS_Yield() мы покинем функцию-задачу Task_T1 и вернемся в планировщик, задача при это переводится из состояния "в работе" в состояние "готовности" (при этом во внутреннюю переменную системы будет сохранен адрес выхода из задачи, и при следующем входе в нее выполнение продолжится с того места, откуда она была покинута, т.е. со следующей за OS_Yield строки).

Далее в работе опять планировщик. Он снова проверяет задачи на готовность и сравнивает приоритеты. Т.к. обе задачи опять являются готовыми и приоритеты у них равны, то он берет следующую по очереди задачу, т.е. Task_T2. Теперь Task_T2 переводится из состояния "готовности" в состояние "в работе", и с ней повторяется все то, что происходило с Task_T1. После обнуления счетчика m_cCounter2 и вызова сервиса OS_Yield управление опять получит планировщик, сохранив при этом адрес возврата в задачу и переведя ее из состояния "в работе" в состояние "готовности".

Следующей планировщик запустит задачу Task_T1. Но теперь уже она будет выполняться не с начала, а с того места, откуда мы ее покинули, т.е. со следующей строчки после OS_Yield. Поэтому мы сразу попадаем на увеличение счетчика m_cCounter1. После увеличения счетчика программа переходит на начало цикла. Т.е. вновь выполняется OS_Yield, который передает управление планировщику, сохраняя адрес возврата и переводя задачу в состояние "готовности".

Далее все то же самое повторяется с задачей Task_T2. Задачи будут выполняться по очереди в течение всего времени работы программы, увеличивая каждая свой счетчик. Графически это можно изобразить так:

Заметим важную деталь: в данном примере на работу планировщика затрачивается больше времени, чем на работу задач. Это не удивительно, ведь планировщик проверяет все задачи в списке, смотрит, какая из них в каком состоянии, выполняет сравнение приоритетов, вычисляет, какую задачу запустить. А сами задачи делают всего одну команду - увеличение счетчика. Потому и получается так, что большую часть времени контроллер тратит на работу планировщика.

Запуск в симуляторе

Здесь мы проведем несколько экспериментов для исследования работы сервиса OS_Yield. Сперва просто прогоним программу в симуляторе и убедимся, что она работает именно так, как было описано выше.

Работа программы

Включим симулятор через меню "Debugger\Select Tool\MPLAB SIM". Соберем проект по Ctrl+F10. Установим точки останова так, как показано на рисунке ниже:

Теперь, нажимая кнопку F9 (Run), проследим за тем, в какой последовательности будут получать управление задачи. Первым делом мы попадаем на начало Task_T1, как раз ту строчку, где производится обнуление переменной m_cCounter1.

Далее можно попробовать пройти по шагам (F8), но, как было описано во "Введении", это может привести к непредсказуемому поведению симулятора. Тем не менее, если симулятор где-то и "застрянет", у нас всегда есть возможность нажать F9, чтобы он автоматически дошел до ближайшей точки останова.

Итак, мы находимся на первой точке останова в задаче Task_T1. Если мы сейчас нажмем F9, то произойдет следующее:

программа войдет в цикл for(;;) и дойдет до вызова сервиса OS_Yield();
При выполнении OS_Yield() произойдет выход из задачи Task_T1 (с сохранением точки выхода) и передача управления планировщику;
планировщик решит, что следующей задачей нужно запустить Task_T2, и передаст ей управление (в самое начало функции Task_T2);
в самом начале Taks_T2 у нас стоит точка останова, где симулятор и остановится, ожидая дальнейших указаний.

Другими словами, если сейчас нажмем F9, то выйдем из задачи Task_T1 и войдем в Task_T2. Нажимаем F9 и убеждаемся, что так оно и произошло.

При следующем нажатии F9 произойдет все то же самое, что и в предыдущем абзаце, с той только разницей, что планировщик передаст управление задаче Task_T1 и не в начало, а на следующую за OS_Yield() строчку. Нажимаем F9 и видим, что мы вновь находимся в задаче Task_T1, причем уже на второй точке останова, где производится увеличение счетчика Task_T1.

При дальнейших нажатиях F9 мы увидим, что программа переключается между двумя задачами, каждая из которых увеличивает свой счетчик (значение счетчиков можно наблюдать в окне Watch). Также можем обратить внимание на то, что ни одна из задач больше не начинается сначала, т.е. они обе крутятся в вечном цикле. При этом значения счетчиков растут строго синхронно, т.к. задачи запускаются по очереди, а увеличение счетчика производится при каждом запуске задачи.

Так мы написали простейшую программу с использованием RTOS OSA. Теперь, когда мы разобрались с тем, как передается управление, можно немного поэкспериментировать.

Эксперимент 1

Попробуем добавить в задачу Task_T2 еще один дополнительный вызов сервиса OS_Yield():

void Task_T2 (void)
{
    m_cCounter2 = 0;
    for (;;)
    {
        OS_Yield();
        OS_Yield();
        m_cCounter2++;
    }
}

Пересоберем программу (Ctrl+F10). Теперь, нажимая F9 и наблюдая при этом за поведением счетчиков m_cCounter1 и m_cCounter2, мы увидим, что счетчик во второй задаче растет в два раза медленнее, чем в первой. Почему так происходит?

Дело в том, что хоть при равных приоритетах готовые задачи запускаются по очереди, но задача Task_T2 переключает контекст в двух местах. Т.е. задача Task_T1, отработав первый раз (после обнуления счетчика), передает управление Task_T2 (на самом деле, конечно, она передает управление планировщику, а уже планировщик передает его задаче Task_T2, но для краткости будем считать, что это Task_T1 передает управление Task_T2). Task_T2, обнулив счетчик, так же по OS_Yield() передает управление Task_T1, которая продолжается с того места, откуда была покинута, т.е. попадаем на строчку m_cCounter1++. После этого Task_T1 снова передает управление задаче Task_T2. А задача Task_T2 продолжается с того места, откуда была покинута, т.е. со следующей за первым OS_Yield строки, т.е. со второго OS_Yield. Таким образом, не добравшись еще до увеличения счетчика m_cCounter2, задача Task_T2 снова передает управление задаче Taks_T1, которая снова увеличивает счетчик. И только после третьего получения управления задача Task_T2 доберется до увеличения своего счетчика.

Схематически поведение программы можно изобразить так (для простоты не показан планировщик):

Как видно, из-за одного добавленного вызова сервиса OS_Yield в задаче Task_T2 увеличение счетчика происходит в два раза медленнее.

Эксперимент 2

Следующим экспериментом мы проверим требование N2 к функции-задаче: внутри бесконечного цикла должен быть хотя бы один вызов сервиса, переключающего контекст (передающего управление планировщику). Теперь мы из задачи Task_T2 вообще удалим все сервисы OS_Yield, оставив только операцию увеличения счетчика.

void Task_T2 (void)
{
    m_cCounter2 = 0;
    for (;;)
    {
        m_cCounter2++;
    }
}

Пересоберем проект (Ctrl+F10). Теперь посмотрим, что будет, если мы начнем выполнять программу. После первого нажатия F9, мы, как обычно, попадаем на начало задачи Task_T1. После обнуления счетчика управление передается задаче Task_T2. Задача Task_T2 обнуляет счетчик и попадает в вечный цикл, в котором будет увеличиваться счетчик m_cCounter2. Вот тут-то мы и прочувствуем, отчего есть требование к задачам иметь в себе хотя бы один вызов, переключающий контекст. Дело в том, что после попадания в задачу Task_T2 мы из нее уже никогда не выберемся, а будем вечно крутиться в цикле. В планировщик мы никогда не вернемся, следовательно, никакие другие задачи управление получить уже не смогут.

Первое требование к функциям-задачам (должна содержать внутри себя вечный цикл) мы не проверяем по той причине, что при отсутствии вечного цикла мы обязательно дойдем до конца функции, выход из которой будет совершен по команде return, в результате чего произойдет порча стека.

Эксперимент 3

Теперь проделаем такой опыт: изменим приоритет одной из задач. Пусть задача Task_T2 теперь будет с более низким приоритетом, чем Task_T1. Для этого заменим аргумент в вызове сервиса создания задачи (чем значение больше, тем приоритет ниже):

    OS_Task_Create(4, Task_T2);

Пересоберем проект (Ctrl+F10). Теперь, нажимая F9, мы увидим, что задача Task_T2 вообще не получает управления, а программа постоянно выполняет задачу Task_T1. Разберемся, почему это произошло. Обе задачи при начале работы планировщика являются готовыми к выполнению. Управление получит та, приоритет которой выше (или они будут получать управление по очереди, если их приоритеты равны). Очевидно, что управление получит задача Task_T1. Нажимаем F9 и убеждаемся, что так оно и есть. Рассмотрим, что произойдет, если мы нажмем F9 еще раз. После обнуления счетчика m_cCounter1 мы доходим до вызова сервиса OS_Yield, который передает управление планировщику, оставляя задачу в состоянии готовности. Далее планировщик пробегается по списку задач, находит все готовые (это опять будут задачи Task_T1 и Task_T2), а потом выбирает из них самую высокоприоритетную, и ей снова окажется задача Task_T1. И так будет при каждом входе в планировщик, т.е. каждый раз самой приоритетной из готовых будет оказываться задача Task_T1, поэтому задача Task_T2 управление никогда не получит.

Заключение

В данном уроке мы рассмотрели работу простейшей программы, написанной с использованием RTOS OSA, просмотрели в симуляторе порядок работы программы и порядок смены задач. В "Эксперименте 2" мы убедились в необходимости соблюдать требования к функциям-задачам, а именно наличие в них вызова сервисов, переключающих контекст. Кроме того, мы исследовали работу сервиса безусловного переключения контекста OS_Yield и узнали его свойства:

он передает управление планировщику, оставляя задачу готовой к выполнению;
при передаче управления планировщику он сперва сохраняет адрес возврата в задачу.

OSA : Учебник. Урок 2 - Локальные переменные

2012-03-20T14:23:47+03:00

OSA : Учебник. Урок 2 - Локальные переменные

К оглавлению

Тема

Разбирая этот урок, мы убедимся в том, что переменные внутри функций-задач нужно объявлять как static. На простом примере будет показано, к чему может привести пренебрежение этим правилом.

Проект

Создадим проект, следуя инструкциям, описанным в первом уроке, только создадим его в папке "c:\tutor\t2" и назовем файл "tutor2.c".

Описание задач

Текст нашей второй программы будет очень похож на текст первой: те же две задачи, то же переключение с помощью сервиса OS_Yield().

char m_cTest1;
char m_cTest2;
 
void Task_T1 (void)
{
    char cTemp1;
    for (;;)
    {
        cTemp1 = 1;              // Значение этой переменной будет потеряно
                                 // после передачи управления системе.
        OS_Yield();
        m_cTest1 = cTemp1;
    }
}
 
void Task_T2 (void)
{
    char cTemp2;
    for (;;)
    {
        cTemp2 = 2;              // Значение этой переменной будет потеряно
                                 // после передачи управления системе.
        OS_Yield();
        m_cTest2 = cTemp2;
    }
}

Переменные m_cTest1 и m_cTest2 сделаны глобальными для того, чтобы их было удобнее отслеживать при отладке в симуляторе. В каждой задаче объявлено по одной локальной переменной. Цель данного урока - продемонстрировать, что значения локальных переменных могут быть потеряны (затерты) после передачи управления ядру операционной системы.

Допишем к программе функцию main(), которая:

вызовет сервис инициализации ОС;
объявит системе, что Task_T1 и Task_T2 являются функциями-задачами;
запустит планировщик на выполнение.

void main (void)
{
    OS_Init();
    OS_Task_Create(3, Task_T1);
    OS_Task_Create(3, Task_T2);
    OS_Run();
}

Полный текст

Итак, полный текст нашей программы теперь будет выглядеть так:

#include <osa.h>
 
//******************************************************************************
//  Глобальные переменные
//******************************************************************************
char m_cTest1;
char m_cTest2;
//******************************************************************************
//  Функции-задачи
//******************************************************************************
void Task_T1 (void)
{
    char cTemp1;
    m_cTest1 = 0;
    for (;;)
    {
        cTemp1 = 1;              // Значение этой переменной будет потеряно
                                 // после передачи управления системе.
        OS_Yield();
        m_cTest1 = cTemp1;
    }
}
//------------------------------------------------------------------------------
void Task_T2 (void)
{
    char cTemp2;
    m_cTest2 = 0;
    for (;;)
    {
        cTemp2 = 2;              // Значение этой переменной будет потеряно
                                 // после передачи управления системе.
        OS_Yield();
        m_cTest2 = cTemp2;
    }
}
//******************************************************************************
//  main
//******************************************************************************
void main (void)
{
    OS_Init();                  // Инициализация переменных системы
    OS_Task_Create(3, Task_T1); // Добавление задач в список
    OS_Task_Create(3, Task_T2);
    OS_Run();                   // Запуск планировщика
}
//******************************************************************************
//  end of file
//******************************************************************************

Как работает программа

Порядок переключения между задачами идентичен порядку, описанному в первом уроке. Разница только в содержимом функций-задач: если в первом уроке мы при каждом запуске задачи увеличивали переменную-счетчик, то теперь мы некоей тестовой переменной (m_cTest1 или m_cTest2) присваиваем значение локальной переменной (cTemp1 или cTemp2, соответственно).

Запуск в симуляторе

Работа программы

Включим симулятор через меню "Debugger\Select Tool\MPLAB SIM". Соберем проект по Ctrl+F10. Для наблюдения за состоянием переменных откроем два окна: Watch и Local (оба окна открываются через меню "View"). В окно Watch добавляем две глобальные переменные m_cTest1 и m_cTest2. Установим точки останова так, как показано на рисунке ниже:

Теперь нажимаем F9 (Run) и попадаем на первую точку останова в задаче Task_T1, где локальной переменной cTemp1 присваивается значение "1". Нажимаем F8 (Step Over) и убеждаемся, что локальная переменная cTemp1 приняла значение "1" (ее значение будет отображаться в окне Local).

Итак, в данный момент курсор симулятора установлен на строке, содержащей вызов OS_Yield() из задачи Task_T1. Следующей строкой у нас присваивание m_cTest1 = cTemp1, а сама переменная cTemp1 у нас имеет значение "1". Мы подошли к главному моменту урока. Как было описано в параграфе "Введение. Особенности отладки.", сервисы, переключающие контекст нужно выполнять командой Run (F9), предварительно установив точку останова на следующей за сервисом строке. У нас точка останова уже стоит, так что смело давим F9 (Run).

Сервис OS_Yield() выполнился, и курсор симулятора теперь стоит на строке присваивания m_cTest1 = cTemp1. Но Обратим внимание на самый важный момент: значение переменной cTemp1 изменилось и стало равно "2".

Разберемся, что с ней произошло. Для начала разберемся с тем, где размещаются локальные переменные.

Локальные переменные в MCC18 и MCC30

В этих двух компиляторах локальные переменные создаются в стеке, причем в MCC18 стек эмулируется программно с помощью указателей FSR1 и FSR2, а в MCC30 используется общий стек, он адресуется регистрами WREG14 и WREG15.

Рассмотрим, как выделяется память под локальные переменные в этих компиляторах. На этапе компиляции производится подсчет, какой объем памяти требуется под локальные переменные для каждой функции. В начало каждой функции, содержащей локальные переменные, компилятором автоматически вставляется код, который увеличивает указатель стека на значение, соответствующее объему локальных переменных функции. Например, если в функции используются 3 локальных переменных типа unsigned int, то указатель стека будет увеличен на 6.

Рассмотрим рисунок:

На рисунке приведен порядок изменения указателей стека для MCC18 и MCC30. Теперь обращение к локальным переменным внутри функции будет производиться через указатель фрейма FSR2 для MCC18 или WREG14 для MCC30. Если из функции func() будет вызвана другая функция func2(), локальные переменные которой занимают 4 байта, то стек будет выглядеть так:

Как видно, локальные переменные функций не пересекаются, когда одна вызывает другую. Более того, при такой организации возможна рекурсия.

Теперь важный момент: если одна функция по очереди вызывает две другие, то при попадании в каждую из них значение регистров указателей стека будет одинаковым. Т.е. если бы функция func1() после вызова func2() вызывала бы еще некую func3():

void func1 (void)
{
    ...
    func2();
    ...
    func3();
    ...
}

, то для локальных переменных func3() использовалась бы область памяти, начинающаяся с указателя FSR₂, т.е. та же самая область, которая была занята под локальные переменные функции func2().

Функция func1 по очереди вызывает func2 и func3. При входе в func2 происходит следующее:

FSR2 → [FSR1++] - сохранение текущего значения FSR2
FSR2 = FSR1 - FSR2 становится указателем фрейма локальных переменных
FSR1 += x - указаетль стека увеличивается на количество байт, занимаемых под локальные переменные функции func2.

После того, как функция func2() отработает, перед выполнением return производятся следующие опреации:

FSR1 -= x - восстанавливаем прежнее знанчение укаателя стека
FSR2 = [–FSR1] - восстанавливаем указатель фрейма

Таким образом, к моменту вызова func3 значения регистров FSR1 и FSR2 те же, что и перед вызовом func2. Очевидно, что при входе в функцию func3 под ее локальные переменные будут заняты те же ячейки памяти, что были заняты и под func2().

Локальные переменные в PICC и PICC18

Стратегия распределения памяти под локальные переменные в этих компиляторах несколько отличается от стратегий MCC. На этапе линковки строится граф вызовов, который содержит информацию о том, какие функции из каких функций вызываются и сколько каждая функция требует памяти под свои локальные переменные. Такой граф может выглядеть, например, так (в квадратных скобках указан объем памяти под локальные переменные):

Далее линкер, опираясь на эту информацию, строит все возможные цепочки вызовов от верхушки графа до концевого узла (в нашем случае их 7), и для каждой цепочки строится своя схема выделения локальных переменных. Обратим внимание на функцию func4(), которая встречается в двух цепочках, причем, количество элементов в этих цепях различное. Это также учитывается линкером при распределении памяти под локальные переменные. Рассмотрим для примера три цепочки:

Task_T1 → func1
Task_T2 → func3 → func4
Task_T3 → func4

Для первой цепочки никаких коллизий нет и локальные переменные разных уровней графа вызовов будут следовать непрерывно друг за другом. А вот вторая и третья цепочки графа имеют две общие вершины: main() и func4().

Не вдаваясь в подробности, сосредоточим внимание на том, что под локальные переменные функций, вызываемых из функции main(), выделяется одна и та же область памяти (она может быть разного объема, но начинается для всех с одного и того же адреса).

Примечание. Из-за такой стратегии размещения локальных переменных PICC и PICC18 не позволяют делать рекурсивные вызовы.

.

Вернемся к нашему примеру. В ОСРВ OSA все функции задачи вызываются (хоть и не напрямую) планировщиком OS_Run, который расположен в функции main(). Следовательно, вне зависимости от стратегии выделения памяти под локальные переменные, получается так, что локальные переменные всех функций-задач будут начинаться по одному и тому же адресу. Для MCC при вызове из main() мы в любую задачу попадаем с одними и теми же значениями регистров-указателей стека; для PICC линкер, построив граф вызовов, разместит все задачи на одном уровне после main().

Итак, что же происходит с переменной cTemp1 при выполнении OS_Yield()? Сперва производится возврат в планировщик, который, в свою очередь, принимает решение, что нужно запускать задачу Task_T2. Получив управление Task_T2 своей локальной переменной cTemp2, которая оказывается расположенной в той же области памяти (в той же ячейке), что и локальная переменная cTemp1 из задачи Task_T1, присваивает значение "2". Т.к. cTemp1 и cTemp2 имеют один и тот же адрес, то при записи в любую из этих переменных произойдет запись и во вторую. Далее Task_T2 вызывает сервис OS_Yield, который возвращает управление планировщику, а планировщик передает управление задаче Task_T1 на строчку, следующую за вызовом OS_Yield(), т.е. на присваивание m_cTest1 = cTemp1. При этом, как мы уже поняли, значение переменной cTemp1 изменилось задачей Task_T2.

Эксперимент 1

Перепишем задачу Task_T1 так:

void Task_T1 (void)
{
    static char s_cTemp1;
    m_cTest1 = 0;
    for (;;)
    {
        s_cTemp1 = 1;
        OS_Yield();
        m_cTest1 = s_cTemp1;
    }
}

Установим брейкпоинты на тех же местах и попробуем выполнить программу в симуляторе. Дойдя до строки присваивания m_cTest1 = s_cTemp1, мы можем убедиться, что значение переменной s_cTemp1 осталось неизменным после того, как отработала задача Task_T2. Все дело в квалификаторе static, стоящим перед объявлением локальной переменной. Этот квалификатор говорит компилятору, что переменная должна сохранять свое значение после выхода из функции до следующего в нее входа. Эта переменная не будет размещаться в стеке (для MCC) или в области локальных переменных (для PICC), она будет помещена в отдельную область, где за ней на все время выполнения программы закрепится одна ячейка памяти.

Заключение

В данном уроке мы рассмотрели важное свойство локальных переменных: их время жизни ограничено с момента входа в задачу до момента возврата в планировщик. Локальные переменные можно применять только в пределах одного сеанса работы задачи, иначе последствия непредсказуемы. Вот типичная ошибка:

void Task (void)
{
    char i;       // Ошибка здесь. Эта переменная должна быть объявлена
                  // как static
    for (;;)
    {
        i = 20;
        while (--i) OS_Yield();
        ...
    }
}

Мы можем подвиснуть в этом цикле навсегда, а можем выйти из него на первом же шаге, в зависимости от того, как область памяти, занимаемая авто-переменной i, используется другими задачами.

Компилятор не предполагает одновременной работы нескольких функций, расположенных на одном уровне в графе вызовов, поэтому, управляя операционной системой как надстройкой над компилятором, программист должен сообщать ему, какие переменные не должны пересекаться в памяти программы, объявляя их с квалификатором static.

Не лишним будет на первых порах работы с ОСРВ все локальные переменные внутри задачи объявлять как статические.

OSA : Учебник. Урок 3 - Задержки

2009-12-09T17:16:27+03:00

OSA : Учебник. Урок 3 - Задержки

К оглавлению

Тема

В данном уроке мы научимся формировать задержки в задачах. Часто бывает нужно какую-либо задачу выполнять не постоянно, а с каким-то интервалом. Например, измерять температуру в помещении вовсе не обязательно каждую миллисекунду, достаточно делать это раз в минуту (или еще реже). Это позволит разгрузить контроллер, дав ему возможность больше ресурсов выделять под остальные задачи, или просто перейти в режим пониженного энергопотребления, что очень важно для батарейных устройств.

Для формирования задержек в задачах есть сервис OS_Delay(). Целью урока является исследование работы этого сервиса.

Для работы мы уже сможем прошить программу в контроллер и посмотреть ее работу в железе. В качестве отладочной платы мы будем использовать демо-плату из набора PICKit 2 на базе котроллера PIC16F887. Подойдут и другие демо-платы, наконец, можно будет собрать собственную макетку на любом имеющемся под ругой контроллере. Хотя, можно будет ограничиться и симулятором.

Теория

OS_Delay()

Сервис OS_Delay по своей функциональности немного похож на сервис OS_Yield с той только разницей, что при OS_Yield задача передает управление планировщику, оставаясь готовой к выполнению, и будет запущена при первой же возможности (т.е. как только станет самой приоритетной из всех готовых), а OS_Delay передает управление планировщику, переведя задачу в состояние ожидания на некоторое время, и только по истечении этого времени ставит ее в состояние готовности, позволяя получить управление. При вызова этого сервиса задача как бы засыпает на заданное время, а по его истечении просыпается и продолжает работать. Во время ожидания завершения задержки задача не рассматривается планировщиком (не участвует в сравнениях приоритетов, например), что ускоряет работу планировщика.

Сервис OS_Delay вызывается с числовым параметром, например:

    OS_Delay(10);

Данная запись говорит планировщику о том, что задача будет находиться в задержке в течение какого-то времени. Какого именно? В нашем примере в параметре указано число 10, но что оно значит? Очевидно, что задержка с параметром 20 продлится дольше, чем 10. Только 10 и 20 чего? Остановимся здесь подробнее.

Т.к. микроконтроллеры могут решать совершенно разные задачи, которые предъявляют разные требования к скорости работы самого контроллера, невозможно придумать какую-то универсальную временную единицу, от которой можно было бы отталкиваться при формировании задержек для разных проектов. Один контроллер предполагается тактировать кварцевым генератором 20 МГц, другому хватит встроенного генератора 4 МГц, третий обходится с генератором 32 КГц. Операционная система не знает, на какой частоте будут работать контроллеры с конкретной программой; частоту используемого генератора будет знать только разработчик проекта. Поэтому именно сам программист должен подсказать операционной системе ту самую временную единицу, которая будет базовой для формирования всех задержек. Назовем эту временную единицу системным тиком - минимальный квант времени для отсчета задержек.

Для того чтобы разобраться с тем, как объяснять операционной системе, какой длительности мы хотим получить системный тик, разберемся сначала, как работают задержки в задачах.

OS_Timer

Операционная система для каждой активной задачи хранит свою переменную-счетчик и свой бит состояния этого счетчика (считает/не считает). Когда задача выполняет сервис OS_Delay, счетчику, привязанному к этой задаче, присваивает значение, указанное в параметре этого сервиса, а бит состояния устанавливает в "считает". После этого управление передается планировщику, и он, пока видит, что у задачи бит состояния установлен в значение "считает", задачу не запускает на выполнение. Счетчик постепенно уменьшается, и, когда он доходит до нуля, бит состояние устанавливается в "не считает", что служит сигналом планировщику, что задача снова готова к выполнению.

Примечание. Переменная-счетчик, применяемая для отсчета задержек в задачах, называется таймером задачи.

Как быстро будет уменьшаться этот счетчик? В OSA есть сервис OS_Timer, при каждом вызове которого все активные счетчики (с битом состояния = "считает") уменьшаются на 1. В нем же производится проверка на завершение счета и сброс бита состояние в "не считает". Программист сам решает, когда и с каким периодом вызывать этот сервис. Чаще всего он вызывается в обработчике прерывания по переполеннию какого-нибудь таймера. Удобно (но вовсе не обязательно) вызывать сервис OS_Timer с одинаковым периодом.

Системный тик будет равен периоду вызова OS_Timer().

Таким образом, программист сам решает, что означает параметр 10 в вызове сервиса OS_Delay. Предположим, OS_Timer вызывается в обработчике прерывания TMR2, которое происходит каждые 250 мкс. Тогда время системного тика будет равно 250 мкс, а OS_Delay(10) будет длиться 10*250 мкс = 2.5 мс.

Очевидно, что в ходе программы можно менять длительность системного тика (например, в режиме пониженного энергопотребления системный тик удобно приравнять к периоду таймера watchdog). Очевидно также, что если ни разу не вызывать сервис OS_Timer, то все задачи, вызвавшие сервис OS_Delay, окажутся в состоянии вечного ожидания, т.к. счетчики, привязанные к задачам, никогда не обнулятся.

Некоторые свойства OS_Delay

Вызов OS_Delay(0) функционально эквивалентен OS_Yield().
Параметр сервиса OS_Delay не должен превышать разрядности таймеров задач (по умолчанию = 16 бит). Подробнее про разрядность речь пойдет ниже.
Последовательный вызов OS_Delay с параметрами X и Y эквивалентен одному вызову OS_Delay с параметром X + Y (если сумма не выходит за границы разрядности таймера).

Ну, а теперь, рассмотрим работу OS_Delay и OS_Timer на конкретном примере.

Проект

Напишем программу, которая будет мигать тремя светодиодами, каждым со своей частотой.

Для начала создадим проект в оболочке MPLab по шагам, описанным в документации.

1. Создание проекта

создаем рабочую папку "c:\tutor\t3";
в ней создаем пустой файл "tutor3.c";
запускаем MPLab (если в ней открыт проект, то закрываем его через меню "File\Close Workspace");
через меню "Project\Project Wizard…" создаем новый проект:
1. в качестве процессора выбираем 16F887 (или тот, который вы собираетесь использовать);
2. выбираем инструмент (toolsuite): HI-TECH PICC Toolsuite;
3. создаем файл проекта с именем tutor3.mcp в папке "c:\tutor\t3";
4. добавляем в проект созданный нами пустой файл tutor3.c и файл системы "c:\osa\osa.c";
5. нажимаем кнопку "Готово".

Проект создан, можно переходить ко второму шагу.

2. Конфигурирование проекта (osacfg.h)

Создаем файл конфигурации для нашего проекта, для чего воспользуемся утилитой OSAcfg_Tool.exe. После запуска программы перед нами диалоговое окно, позволяющее нам в интерактивном режиме сделать все настройки ОС для конкретного проекта. Для начала укажем программе, где проект будет располагаться, для этого кнопкой "Browse…" открываем диалоговое окно выбора файла и в нем выбираем рабочую папку "c:\tutor\t3", где будет располагаться наш файл конфигурации. Нажимаем "OK". Программа сообщит нам, что файл еще не существует и будет создан при сохранении. Жмем "OK".

Теперь в секции "System" устанавливаем параметр "Tasks" = 3 (у нас будут три задачи). Теперь нам нужно сказать системе, что мы будем использовать задержки в программе. Для этого нам нужно включить таймеры задач: в секции "Timers" устанавливаем галочку напротив пункта "Task timers".

После этого жмем кнопку "Save" в нижней части экрана, читаем сообщение, что файл успешно сохранен, давим "OK" и выходим из программы конфигуратора по кнопке "Exit".

Убеждаемся, что файл OSAcfg.h создан в папке "c:\tutor\t3".

3. #include <osa.h>

Включаем в tutor3.c используемые заголовочные файлы: pic.h и osa.h.

#include <pic.h>
#include <osa.h>

4. Указание путей

"c:\osa" - путь к файлам операционной системы;
"c:\tutor\t3" - путь к файлам проекта.

5. Функция main()

В функцию main() добавляем вызов двух обязательных системных сервисов: OS_Init() и OS_Run().

#include <pic.h>
#include <osa.h>
 
void main (void)
{
    OS_Init();
    OS_Run();
}

Теперь, когда заготовка для проекта готова, можно приступать к написанию программы.

Программа

Логически программа разделена на четыре части:

определения - здесь будут определены константы, включены заголовочные файлы, задана конфигурация контроллера;
задачи - каждая задача будет управлять своим светодиодом;
инициализация - здесь будет инициализирована периферия контроллера и операционная система;
прерывание - в нем мы будем вызывать сервис управления задержками OS_Timer.

Определения

Итак, начнем с определений. Что нам нужно?

включить заголовочные файлы: pic.h и osa.h;
задать биты конфигурации контроллера;
определить выводы контроллера, к которым подключены светодиоды.

#include <pic.h>
#include <osa.h>
 
//------------------------------------------------------------------------------
// Задаем биты конфигурации:
//   - внутренний RC-генератор
//   - отключаем WDT
//   - отключаем низковольтное программирование
//   - отключаем функцию отладки
//------------------------------------------------------------------------------
 
__CONFIG(INTIO & WDTDIS & PWRTEN & MCLRDIS & LVPDIS & UNPROTECT & BORDIS
               & IESODIS & FCMDIS & DEBUGDIS);
 
 
//------------------------------------------------------------------------------
//  Определяем выводы для светодиодов
//------------------------------------------------------------------------------
 
#define PIN_LED1    RD0
#define PIN_LED2    RD2
#define PIN_LED3    RD4
 
//------------------------------------------------------------------------------
//  Параметры таймера:
//  - прескейлер = 4,
//  - постскейлер = 1,
//  - предел счета = 250
//
//  Тактовая частота контроллера = 4 МГц.
//
//  Период возникновения прерывания по TMR2 получается
//  равным 4 * 1 * 250 * Tcyc = 1 ms
//
//------------------------------------------------------------------------------
#define PR2_CONST       250-1
#define TMR2_PRS        1                           // prs = 4
#define TMR2_POST       0                           // post = 1
#define T2CON_CONST     (TMR2_POST<<3) | TMR2_PRS

Задачи

Как уже было сказано, для демонстрации мы заведем по одной задаче на каждый светодиод. Внутри задачи будет содержаться вызов сервиса OS_Delay и операция переключения светодиода. Таким образом, получится, что каждый светодиод будет переключаться с интервалом, указанным в параметре к сервису OS_Delay. Например, задача управления первым светодиодом будет выглядеть так:

void Task_T1 (void)
{
    for (;;)
    {
        PIN_LED1 ^= 1;       // Меняем состояние первого светодиода
        OS_Delay(500);       // Переводим задачу в режим ожидания на
                             // время, равное 500 системным тикам
    }
}

По аналогии будут запрограммированы две другие задачи для управления светодиодами 2 и 3, но с той разницей, что параметрами сервиса OS_Delay будут числа 1000 и 1500.

Инициализация

Инициализация периферии будет вынесена для наглядности в отдельную функцию init(), которая будет вызываться из функции main(). Мы должны проинициализировать следующее:

установить все порты ввода/вывода на выход;
инициализировать таймер;
инициализировать модуль прерываний.

void init (void)
{
    //------------------------------------------------------------------------------
    //  Настройка портов I/O
    //------------------------------------------------------------------------------
 
    PORTA = 0;
    PORTB = 0;
    PORTC = 0;
    PORTD = 0;
 
    TRISA = 0;
    TRISB = 0;
    TRISC = 0;
    TRISD = 0;
 
    //------------------------------------------------------------------------------
    //  Настройка таймера 2
    //------------------------------------------------------------------------------
 
    PR2 = PR2_CONST;
    T2CON = T2CON_CONST | 0x04;
 
    //------------------------------------------------------------------------------
    //  Настройка прерываний
    //------------------------------------------------------------------------------
 
    PIR1 = 0;
    PIR2 = 0;
    INTCON = 0;
 
    TMR2IE = 1;         // Разрешаем прерывание по TMR2
    PEIE = 1;           // Разрешаем периферийные прерывания
                        // Глобальные бит разрешения прерываний будет
                        // установлен непосредственно перед запуском
                        // планировщика в функции main()
}

Остальная часть кода инициализации будет размещена в main().

void main (void)
{
    init();             // Инициализация периферии
    OS_Init();          // Инициализация системы
 
    // Создаем задачи
    OS_Task_Create(3, Task_T1);
    OS_Task_Create(3, Task_T2);
    OS_Task_Create(3, Task_T3);
 
    OS_EI();            // Разрешаем прерывания
    OS_Run();           // Запускаем планировщик
}

Обратим внимание на новый сервис OS_EI(). Фактически он всего-навсего устанавливает бит GIE. Но мы предполагаем, что любая программа может быть перенесена на другой контроллер (например, на PIC24, где бита GIE нет), поэтому изначально будет писать программу так, чтобы по возможности свести к минимуму усилия по портированию. Сервис OS_EI() для всех контроллеров описан по-своему, поэтому предпочтительнее использовать именно его, а не явное разрешение прерываний через установку бита GIE.

Прерывание

Как уже говорилось ранее, сервис, управляющий отсчетом задержек (фактически - управляющий таймерами задач), обычно вызывается в периодическом месте программы. Интервал вызовов этого сервиса называется системным тиком. В большинстве случаев удобно, чтобы OS_Timer вызывался с одним и тем же интервалом времени, что обеспечит программу системным тиком фиксированной длительности. Самый удобный способ (но не единственный) - вызывать его в обработчике прерывания по таймеру. В нашей программе мы воспользуемся таймером TMR2.

void interrupt isr (void)
{
    OS_EnterInt();
    if (TMR2IF)
    {
        OS_Timer();
        TMR2IF = 0;
    }
    OS_LeaveInt();
}

Прерывание будет возникать 1 раз в миллисекунду, следовательно, системный тик в нашей программе также будет равен 1 мс.

Весь текст программы

Для удобства здесь приведен весь текст программы целиком:

//******************************************************************************
//  Программа для исследования работы задержек в OSA
//******************************************************************************
 
#include <pic.h>
#include <osa.h>
 
 
 
//------------------------------------------------------------------------------
// Задаем биты конфигурации:
//   - внутренний RC-генератор
//   - отключаем WDT
//   - отключаем низковольтное программирование
//   - отключаем функцию отладки
//------------------------------------------------------------------------------
 
__CONFIG(INTIO & WDTDIS & PWRTEN & MCLRDIS & LVPDIS & UNPROTECT & BORDIS
               & IESODIS & FCMDIS & DEBUGDIS);
 
 
//------------------------------------------------------------------------------
//  Определяем выводы для светодиодов
//------------------------------------------------------------------------------
 
#define PIN_LED1    RD0
#define PIN_LED2    RD2
#define PIN_LED3    RD4
 
//------------------------------------------------------------------------------
//  Параметры таймера:
//  - прескейлер = 4,
//  - постскейлер = 1,
//  - предел счета = 250
//
//  Тактовая частота контроллера = 4 МГц.
//
//  Период возникновения прерывания по TMR2 получается
//  равным 4 * 1 * 250 * Tcyc = 1 ms
//
//------------------------------------------------------------------------------
 
#define PR2_CONST       250-1
#define TMR2_PRS        1                           // prs = 4
#define TMR2_POST       0                           // post = 1
#define T2CON_CONST     (TMR2_POST<<3) | TMR2_PRS
 
 
//******************************************************************************
//  Прерывание. Возникает каждую мс
//******************************************************************************
 
void interrupt isr (void)
{
    OS_EnterInt();
    if (TMR2IF)
    {
        OS_Timer();
        TMR2IF = 0;
    }
    OS_LeaveInt();
}
 
//******************************************************************************
//  Описание задач управления светодиодами
//******************************************************************************
 
void Task_T1 (void)
{
    for (;;)
    {
        PIN_LED1 ^= 1;       // Меняем состояние первого светодиода
        OS_Delay(500);       // Переводим задачу в режим ожидания на
                             // время, равное 500 системным тикам
    }
}
 
//------------------------------------------------------------------------------
 
void Task_T2 (void)
{
    for (;;)
    {
        PIN_LED2 ^= 1;       // Меняем состояние второго светодиода
        OS_Delay(1000);      // Переводим задачу в режим ожидания на
                             // время, равное 1000 системным тикам
    }
}
 
//------------------------------------------------------------------------------
 
void Task_T3 (void)
{
    for (;;)
    {
        PIN_LED3 ^= 1;       // Меняем состояние третьего светодиода
        OS_Delay(1500);      // Переводим задачу в режим ожидания на
                             // время, равное 1500 системным тикам
    }
}
 
//******************************************************************************
//  Инициализация периферии
//******************************************************************************
 
void init (void)
{
    //------------------------------------------------------------------------------
    //  Настройка портов I/O
    //------------------------------------------------------------------------------
 
    PORTA = 0;
    PORTB = 0;
    PORTC = 0;
    PORTD = 0;
 
    TRISA = 0;
    TRISB = 0;
    TRISC = 0;
    TRISD = 0;
 
    //------------------------------------------------------------------------------
    //  Настройка таймера 2
    //------------------------------------------------------------------------------
 
    PR2 = PR2_CONST;
    T2CON = T2CON_CONST | 0x04;
 
    //------------------------------------------------------------------------------
    //  Настройка прерываний
    //------------------------------------------------------------------------------
 
    PIR1 = 0;
    PIR2 = 0;
    INTCON = 0;
 
    TMR2IE = 1;         // Разрешаем прерывание по TMR2
    PEIE = 1;           // Разрешаем периферийные прерывания
                        // Глобальные бит разрешения прерываний будет
                        // установлен непосредственно перед запуском
                        // планировщика в функции main()
 
}
 
//******************************************************************************
//  MAIN
//******************************************************************************
 
void main (void)
{
    init();             // Инициализация периферии
    OS_Init();          // Инициализация системы
 
    // Создаем задачи
    OS_Task_Create(3, Task_T1);
    OS_Task_Create(3, Task_T2);
    OS_Task_Create(3, Task_T3);
 
    OS_EI();            // Разрешаем прерывания
    OS_Run();           // Запускаем планировщик
}
 
//******************************************************************************
//  END
//******************************************************************************

Как работает программа

К тому моменту, как будет вызван планировщик, у нас созданы три задачи. Т.к. все они равноприоитетны и готовы к выполнению (после создания задача сразу становится готовой), то планировщик выберет для запуска ту, которая была создана первой, т.е. Task_T1. Получив управление, задача Task_T1 первым изменит состояние светодиода (светодиод был погашен, и теперь он зажжется). Далее она вызывает сервис OS_Delay с параметром 500. При этом происходит следующее:

задача инициализирует свой внутренний таймер (переменную-счетчик) значением 500;
переводит себя в состояние ожидания (т.е. она не сможет получить управление, пока не произойдет ожидаемое ей событие, а именно, - пока не обнулится ее таймер);
передает управление планировщику.

Теперь планировщик видит, что готовы к выполнению только две задачи (одна уже в режиме ожидания): Task_T2 и Task_T3. Т.к. приоритеты их равны, то она выбирает следующую по очереди (порядок очереди определяется последовательностью создания задач сервисов OS_Task_Create), т.е. Task_T2. Эта задача, получив управление, выполняет те же самые операции, только ее внутренний таймер будет инициализирован значением 1000. Задача также становится в режим ожидания, а управление возвращается планировщику.

Теперь готова к выполнению только одна задача - Task_T3, и планировщик передает ей управление. Так же как и первые две, она зажигает свой светодиод, после чего уходит в режим ожидания, инициализируя свой внутренний таймер значением 1500. После этого управление опять возвращается планировщику.

Что у нас получилось в результате? Готовых задач нет, поэтому планировщик будет крутиться теперь сам в себе. Есть три задачи, стоящие в режиме ожидания завершения задержки, с разными значениями таймеров: 500, 1000 и 1500. Эти задачи будут оставаться в режиме ожидания, пока их таймеры не обнулятся.

Как уже говорилось, за таймерами задач следит сервис OS_Timer, который при каждом вызове уменьшает все активные таймеры на 1. Мы вызываем этот сервис в прерывании, возникающем раз в миллисекунду. Т.е. каждую миллисекунду значения таймеров будут уменьшаться на 1. Таким образом, через 500 мс таймер задачи Task_T1 будет обнулен, и она переведется в режим готовности. А так как она окажется единственной задачей, готовой к выполнению, то планировщик сразу же передаст ей управление. Значения таймеров для задач Task_T2 и Task_T3 за это время уменьшатся на 500 и станут равны 500 и 1000, соответственно. Задача Task_T1, получив управление, повторит все действия, которые были проделаны при предыдущем ее запуске: изменит состояние светодиода (теперь уже погасит его) и вызовом сервиса OS_Delay снова уйдет в задержку, вернув управление планировщику.

На этот момент времени готовых задач опять нет. Значения таймеров будут 500, 500 и 1000. Теперь через 500 мс (т.е. через 500 вызовов сервиса OS_Timer) у нас одновременно обнулятся таймеры задач Task_T1 и Task_T2, и они обе перейдут в режим готовности. В данном случае трудно предсказать, какая из задач получит управление первой. Предположим, что это будет Task_T1. После того как она отработает (зажжет светодиод и уйдет в задержку), сразу же запустится задача Task_T2, т.к. она уже готова к выполнению. После отработки она также уходит в задержку, передав управление планировщику. И планировщик снова ждет, когда какая-нибудь из задач стает готовой (это произойдет через 500 мс, готовыми станут Task_T1 и Task_T3).

Схематически работу программы можно изобразить так:

(Для наглядности здесь не показан пятый график - прерывания.) Из графика хорошо видно, что есть участки, где планировщик крутится вхолостую, не выполняя никаких задач. Также видно, что задача Task_T1 получает управление в два раза чаще, чем Task_T2, и в 3 раза чаще, чем Task_T3.

Примечание по рассинхронизации

Стоит отметить один важный момент, касающийся счета таймеров задач. Прерывание, в котором производится декремент всех активных таймеров может возникнуть в любой момент, и это может привести к рассинхронизации задач. Поясню на конкретном примере. По нашей схеме предполагается, что задача Task_T1 будет выполняться в два раза чаще, чем Task_T2. Однако есть одна тонкость. Предположим, что таймер первой задачи досчитал до 0, а таймер второй задачи - до 500. Планировщику на то, чтобы просмотреть список задач, выбрать готовую и передать ей управление, требуется некоторое время. Если длительность системного тика сравнительно мала, то за это время может успеть произойти еще одно прерывание, т.е. еще один вызов OS_Timer, который в свою очередь вычтет еще одну единицу из таймера задачи Task_T2 (таймер задачи Task_T1 и так уже нулевой, поэтому он останется без изменений). После получения управления Task_T1 обновит свой таймер, и он примет значение = 500, а таймер задачи Task_T2 будет к этому времени уже = 499. Таким образом, получается некоторая рассинхронизация. В общем случае в зависимости от количества задач, от их состояний, от периода вызова OS_Timer, от того, как задачи забирают под себя время процессора, такая рассинхронизация может происходить чаще или реже. В нашем конкретном примере она будет очень редким явлением, но в более навороченной программе, это будет происходить чаще. Поэтому в общем случае не стоит использовать OS_Delay для точной синхронизации задач друг с другом.

Запуск

Запуск в железе

Выполним сборку нашей программы (Ctrl+F10) и прошьем ее в контроллер. Убедимся, что светодиоды работают именно так, как описано в предыдущем параграфе, т.е. один светодиод мигает раз в секунду, другой - раз в две секунды, третий - раз в три секунды. Теперь можно переходить к параграфу "Эксперименты", где мы попытаемся внимательнее исследовать свойства сервиса OS_Delay. Но сначала пройдем нашу программу по шагам в симуляторе.

Запуск в симуляторе

Расставим брейкпоинты, как показано на рисунке:

Откроем окно "Watch", куда добавим внутренний массив дескрипторов задач OS_Task_Vars (это единственный способ проследить за таймерами задач). Раскроем весь массив, как показано на рисунке, чтобы мы смогли наблюдать отдельно за таймером каждой задачи. Теперь установим параметры отображения для каждого таймера, для этого на поле Timer для каждого дескриптора жмем правую кнопку мышки и во всплывающем меню выбираем пункт "Properties…". В открывшемся диалоговом окне задаем значение "Decimal" в поле "Format" и справа от него устанавливаем галочку в пункте "Signed", как показано на картинке:

Нам нужно именно знаковое отображение, т.к. на самом деле в переменные, содержащие таймеры задач, пишутся отрицательные значения.

Теперь выберем симулятор для отладки через пункт меню "Debugger/Select Tool…/MPLAB SIM". Выполним кое-какие настройки: откроем окно "Debugger/Settings…" и в поле "Processor frequency" зададим значение 4 МГц. Откроем окно "Debugger/Stopwatch" (секундомер), в котором будем засекать время выполнения различных кусков программы. Теперь можно приступать к отладке.

Нажимаем F9 (Run). Программа начнет выполняться и остановится на первой встретившейся точке останова, предварительно выполнив все шаги инициализации и создания задач. Первой встретившейся точкой останова будет PIN_LED1 ^= 1 в задаче Task_T1. Если мы сейчас нажмем F9 (Run), то окажемся на второй точке останова, но сможем в Watch-окне увидеть, что при выполнении OS_Delay в первой задаче у нас изменилось значение ее таймера (поле Timer), оно стало равным -500. Нажав F9 (Run) еще раз, мы перейдем на третью точку останова (в задаче Task_T3), обнаружив, что и значение поле Timer для второй задачи теперь стало -1000.

Прежде чем выполнять очередную задачу, поставим еще одну точку останова внутри прерывания:

Теперь нажимаем F9. Поставив третью задачу в режим ожидания, программа начинает крутиться в планировщике, который раз в миллисекунду будет прерываться по переполнению таймера TMR2. При первом же переполнении программа остановится на брейкпоинте, который мы установили в прерывании. Указатель симулятора сейчас находится перед вызовом сервиса управления таймерами OS_Timer. Обратим внимание на состояния таймеров задач в окне Watch и убедимся в том, что они имеют значения: -500, -1000, -1500. Сервис OS_Timer выполним командой отладчика Step Over (F8), после чего увидим, что значения всех таймеров увеличилось на 1, и они приняли значения: -499, -999, -1499. Теперь, нажимая F9 (Run) мы будет все время попадать на брейкпоинт, установленный в прерывании, т.к. задачи находятся в режиме ожидания и управление не получают. При каждом попадании в прерывание мы убеждаемся, что значения таймеров по одному шагу приближаются к нулю. Кроме того, по значениям в окне Stopwatch (секундомер) мы можем убедиться, что прерывание происходит раз в миллисекунду.

Так мы разобрались с тем, как в программе инициализируются таймеры и как они обновляются сервисом OS_Timer. Чтобы не нажимать F9 (Run) 500 раз, ожидая, когда же обнулится таймер первой задачи, снимем точку останова, которую мы поставили в прерывании.

Теперь, нажав F9 (Run), мы запустим программу на выполнение так, что она остановится только тогда, когда хотя бы одна из задач, где установлены брейкпоинты, получит управление. Это произойдет через 500 вызовов сервиса OS_Timer - мы снова попадем в задачу Task_T1. По окну Watch можем убедиться в том, что таймер первой задачи теперь обнулен, а по окну Stopwatch - что прошло 500 мс.

Нажимая F9 (Run) и следя за тем, в каком порядке задачи получают управление, мы через окно Stopwatch будем видеть, что это происходит как раз с заданными нами периодами. Т.е. задача Task_T1 будет выполняться раз в 500 мс, задача Task_T2 - раз в секунду, Task_T3 - в полторы секунды. Таким образом, мы в симуляторе по шагам проверили то, что только что видели в железе. Теперь можно поэкспериментировать.

Эксперименты

Эксперимент 1 - приоритеты

В уроке, посвященном изучению сервиса OS_Yield, мы сделали эксперимент с заменой приоритета одной из задач, что привело к тому, что она не смогла получить управление. Попробуем сделать то же самое в данной программе:

    // Создаем задачи
    OS_Task_Create(2, Task_T1);    // Приоритет повышен
    OS_Task_Create(3, Task_T2);
    OS_Task_Create(4, Task_T3);    // Приоритет понижен

Выполняем сборку (Ctrl+F10) и прошиваем программу в контроллер. Светодиоды будут мигать так же, как и до изменения приоритетов: первый - раз в секунду, второй - раз в две секунды, третий - раз в три секунды. Это говорит о том, что все задачи получают управление. В чем же отличие от такой же ситуации с OS_Yield?

Вспомним еще раз: OS_Yield, передавая управление планировщику, оставляет задачу готовой к выполнению. А планировщик передает управление самой приоритетной из готовых. Поэтому в случае с OS_Yield задача с более низким приоритетом просто не могла получить управление из-за того, что всегда была в наличии готовая задача с более высоким приоритетом.

В случае с OS_Delay все не так. OS_Delay, в отличие от OS_Yield, переводит задачу в режим ожидания. А задача, находящаяся в режиме ожидания, не рассматривается планировщиком как кандидат на запуск, поэтому менее приоритетные задачи получают шанс получить управление. Исключение составляет лишь вызов OS_Delay(0), который, как уже писалось, является функциональным эквивалентом OS_Yield.

Эксперимент 2 - конкатенация

Среди свойств OS_Delay упоминалось такое: "Последовательный вызов OS_Delay с параметрами X и Y эквивалентен одному вызову OS_Delay с параметром X + Y". Рассмотрим его на практике. Перепишем задачу Task_T1 следующим образом:

void Task_T1 (void)
{
    for (;;)
    {
        PIN_LED1 ^= 1;
        OS_Delay(250);
        OS_Delay(250);
    }
}

Соберем программу (Ctrl+F10) и прошьем контроллер. Мы увидим, что светодиод 1 мигает так же и с той же частотой. Дело в том, что функционально мы ничего не изменили. После выполнения первого OS_Delay(250) задача уйдет в ожидание на 250 системных тиков. Как только задержка закончится, задача станет готовой к выполнению, и когда получит управление, она вернется на вызов второго OS_Delay, который также переведет ее в режим ожидания на 250 системных тиков. Т.е. получается, что мы выдерживаем ту же самую задержку в 500 тиков, только другим способом.

На практике такое встречается редко, однако, у этого способа есть практическое применение: для меньших чисел в параметре сервиса OS_Delay мы может использовать таймеры задач меньшей разрядности. Подробнее этого мы коснемся чуть ниже.

Теперь перепишем задачу Task_T1 так:

void Task_T1 (void)
{
    for (;;)
    {
        PIN_LED1 = 1;
        OS_Delay(500);
        PIN_LED1 = 0;
        OS_Delay(500);
    }
}

Соберем программу (Ctrl+F10) и прошьем контроллер. Работа программы также останется без изменений. Мы сделали то же самое, что и было, но только опять же другим способом. Раньше состояние светодиода менялось через каждые 500 тиков, а теперь оно явно задается так же через 500 тиков. Т.е. суммарное время горения и негорения светодиода и в том и в другом случае равно 1 секунде. Но последняя форма записи позволяет нам изменить скважность (например, для экономии заряда батарейки):

        PIN_LED1 = 1;
        OS_Delay(50);
        PIN_LED1 = 0;
        OS_Delay(950);

Здесь мы видим, что время горения составляет всего 50 тиков, а время негорения - 950. На глаз вспышки будут хорошо заметны, а светодиод стал потреблять в 10 раз меньше тока.

Эксперимент 3 - системный тик

Поговорим немного о выборе системного тика для проекта. Очевидно, что для нашего случая такой частый вызов OS_Timer избыточен. Для нашей конкретной задачи подошел бы системный тик длительностью, например, в 50 мс, в 100 мс или в 500 мс. Перепишем немного нашу программу:

изменим период генерации прерывания по TMR2 с 1 мс на 10 мс;
сократим значения всех аргументов OS_Delay в 10 раз:

#define TMR2_POST      9       // Постскейлер = 10
...
//--------------------------------------------
void Task_T1 (void)
{
    for (;;)
    {
        PIN_LED1 = 1;
        OS_Delay(5);
        PIN_LED1 = 0;
        OS_Delay(95);
    }
}
//--------------------------------------------
void Task_T2 (void)
{
    for (;;)
    {
        PIN_LED2 ^= 1;
        OS_Delay(100);
    }
}
//--------------------------------------------
void Task_T3 (void)
{
    for (;;)
    {
        PIN_LED3 ^= 1;
        OS_Delay(150);
    }
}
//--------------------------------------------

Выполним сборку (Ctrl+F10) и прошьем контроллер. Работа устройства опять же не изменилась: светодиоды мигают с теми же частотами. Фактически мы и не меняли логику работы программы. Задержки как были 500, 1000 и 1500 мс, так и остались. Просто изменилось время системного тика. Но что мы можем выиграть, удлинив время системного тика? Обратим внимание, что после деления всех значений аргументов в вызовах сервиса OS_Delay, все они у нас стали меньше 255. А это значит, что для конкретного случая под каждый таймер задач будет достаточно одного байта, а не двух (по умолчанию таймеры двухбайтовые).

Посмотрим на статистику, выданную компилятором при сборке:

Memory Summary:
    Program space        used   18Ah (   394) of  2000h words   (  4.8%)
    Data space           used    1Eh (    30) of   170h bytes   (  8.2%)
    EEPROM space         used     0h (     0) of   100h bytes   (  0.0%)
    Configuration bits   used     1h (     1) of     2h words   ( 50.0%)
    ID Location space    used     0h (     0) of     4h bytes   (  0.0%)

Примечание. Статистика может немного отличаться в зависимости от версии компилятора. Данная статистика приведена для PICC STD 9.60PL3.

Как видно, у нас занято 30 байт оперативной памяти. И мы знаем, что 6 из них заняты таймерами задач во внутренних переменных операционной системы (3 таймера по 2 байта). Так же мы знаем, что в конкретной программе значения таймеров никогда не превышают по модулю значения 150 (для таймеров используется только отрицательная область значений, поэтому для однобайтового таймера допустимы значения -1..-255). Следовательно, старший байт каждого таймера висит мертвым грузом.

Запустим программу конфигуратор OSAcfg_Tool и откроем в ней конфигурацию для проекта C:\TUTOR\T3 (теперь это можно сделать через выкидной список Path, т.к. там сохраняются все пути, которые были введены). Верхняя правая часть диалогового окна отведена для конфигурирования таймеров. У нас стоит галочка рядом с пунктом Enable для Task timers. А справа от этого пункта есть ComboBox, в котором можно выбрать размерность таймера задач. По умолчанию там стоит (system), т.е. использовать размерность системного таймера, которая задается чуть выше и по умолчанию имеет тип default (int). Изменим тип таймера задач на char:

Теперь сохраняем (кнопка "Save") и выходим (кнопка "Exit"). В файл OSAcfg.h добавится строчка:

#define OS_TTIMER_SIZE    1

Пересоберем проект (Ctrl+F10) и прошьем контроллер. Программа работает, как и раньше. А теперь заглянем в статистику компилятора:

Memory Summary:
    Program space        used   173h (   371) of  2000h words   (  4.5%)
    Data space           used    1Bh (    27) of   170h bytes   (  7.3%)
    EEPROM space         used     0h (     0) of   100h bytes   (  0.0%)
    Configuration bits   used     1h (     1) of     2h words   ( 50.0%)
    ID Location space    used     0h (     0) of     4h bytes   (  0.0%)

Мы увидим, что использованная RAM сократилась на 3 байта (отрезали по одному байту от каждого таймера). Но обратим внимание еще на то, что используемая ROM-память также сократилась (на 23 байта). Это связано с тем, что:

во-первых, сократился код сервиса OS_Timer, который теперь обрабатывает однобайтовые переменные, вместо двухбайтовых;
во-вторых, в сервис OS_Delay теперь также передается однобайтовый параметр, опять экономится место;
в-третьих, само нутро сервиса OS_Delay теперь тоже работает с однобайтовыми числами.

Сейчас у нас три задачи, которые почти ничего не делают, а кроме них ничего нет. Поэтому выигрыш 3х байт оперативной памяти и 23 слов программной памяти не ощутим. Но когда в программе будет 10 задач и под 50 вызовов OS_Delay, да еще куча всяких переменных и подпрограмм, тогда мы почувствуем, что выигрыш в 10 байт RAM и в 200 слов ROM уже ощутим. Также не лишним будет упомянуть, что и скорость работы OS_Timer возрастает, т.к. однобайтовые переменные обрабатываются быстрее.

Системный тик

О каких параметрах нам нужно думать, выбирая время системного тика?

Диапазон задержек

В первую очередь, конечно же, о диапазоне формируемых задержек. Например, совершенно понятно, что если системный тик = 10 мс, то мы не сможем сформировать задержку в 5 мс. С другой стороны, имея системный тик в 1 мс, при разрядности таймера задач по умолчанию в 16 бит мы сможем сформировать задержку только в 65.5 секунд, что может оказаться недостаточным для некоторых приложений (например, регистрация температуры и влажности производится раз в 10 минут = 600 секунд). Кроме того, как уже было описано выше, иногда есть возможность (а иногда и необходимость) сократить размерность таймера задач до одного байта.

Поэтому, первое, о чем нужно думать при выборе длительности системного тика, - это чтобы он позволял при выбранной размерности таймеров задач обеспечивать формирование всего диапазона задержек, применяемых в программе.

Следует добавить, что на особые случаи есть возможность делать таймеры задач 32-битными.

Точность задержек

При написании программы следует помнить, что точность формирования задержки равна одному системному тику. Дело в том, что, вызывая сервис OS_Delay, мы не знаем, через какое время будет вызван OS_Timer в первый раз. Если прерывание уже на подходе, а мы вызываем в задаче OS_Delay(10), то практически сразу за вызовом этого сервиса таймер задачи уменьшится на 1. В результате чего задача прождет не 10, а 9 системных тиков. Об этой особенности надо помнить и по возможности избегать вызовов OS_Delay с параметром 1, т.к. в этом случае задача может вообще ничего не прождать, а получить управление следующим же шагом.

Чем выше требуемая точность, тем меньше должно быть время системного тика. При этом надо помнить, что чем больше значение параметра в вызове сервиса OS_Delay, тем больше относительная точность формирования задержки. Если требуется высокая точность при длинных задержках, то есть смысл увеличить разрядность таймеров задач.

Однако не стоит забывать о трех вещах:

OSA - кооперативная ОС, и только сама задача может решить, когда отдавать управление планировщику. Поэтому как бы точно не была задана задержка в задаче, например, Task_A, она не получит управление раньше, чем задача, например, Task_B отдаст управление планировщику, даже если ее приоритет ниже.
Сам планировщик на поиск готовых задач и сравнение их приоритетов затрачивает некоторое время. Поэтому если время системного тика сопоставимо или меньше времени работы планировщика, то точность не улучшится.
Наконец, сам сервис OS_Timer выполняется не мгновенно, а за какой-то промежуток времени (в нашем примере 21 такт для 3х 16-разрядных таймеров). Чем больше активных таймеров, тем дольше выполняется OS_Timer. Если системный тик будет выбран достаточно маленьким, чтобы прерывание успевало выполниться до того, как весь обработчик прерывания отработает, то можно зависнуть в прерывании до тех пор, пока OS_Timer не разгрузится (не обнулит часть таймеров).

Прочие условия

К прочим условиям можно отнести все, что угодно. Например, можно вызывать OS_Timer с периодом WDT, который будет использоваться для пробуждения контроллера из Sleep-режима:

void Task_Sleep (void)
{
    for (;;)
    {
        OS_SLEEP();
        OS_CLRWDT();
        OS_Timer();
        OS_Yield();
    }
}

Очевидно, что системный тик в данном случае будет равен периоду WDT. Обратим внимание на два новых сервиса OS_SLEEP и OS_CLRWDT. Эти сервисы так же, как и OS_EI, были добавлены для упрощения переноса кода на другую платформу.

Также к прочим условиям можно отнести удобство, например, использование круглых чисел: 1 мс, 10 мс, 100 мс, 1 сек.

Можно сделать системный тик зависимым от внешних условий, например, вызывать OS_Timer при приходе каждого импульса на вывод RB0.

Заключение

Итак, в этом уроке мы познакомились с очень полезным и удобным сервисом операционной системы для формирования задержек OS_Delay, а также узнали порядок обработки внутренних таймеров, привязанных к задачам, с помощью сервиса OS_Timer. Практически ни одна программа не обходится без задержек, и сервис OS_Delay будет, наверное, одним из самых часто используемых в ваших программах. Поэтому мы так подробно на нем и остановились.

Задание

Для особо пытливых могу предложить небольшое задание: модифицировать программу так, чтобы во время простоя контроллер входил в режим пониженного энергопотребления (проще говоря - в Sleep).

Рекомендации к решению:

включить WDT в битах конфигурации контроллера;
увеличить количество задач в файле конфигурации ОС;
убрать вызов OS_Timer из прерывания, иначе, иногда выполняясь, он будет приводить к более быстрому обнулению таймеров;
пересчитать все аргументы вызовов OS_Delay с учетом периода WDT.

OSA : Учебник. Урок 4 - Бинарные семафоры

2010-05-25T21:33:06+03:00

OSA : Учебник. Урок 4 - Бинарные семафоры

К оглавлению

Тема

В предыдущих примерах наши задачи жили самостоятельной жизнью и могли рассматриваться как отдельные независимые программы, которым просто волею судьбы довелось делить один микроконтроллер на всех. Они крутились каждая в своем цикле, временно передавая управление планировщику, а уж что он там делал - их не касалось. На практике - довольно редкая ситуация. Обычно задачи, хоть и живут каждая своей жизнью, но все вместе делают одно дело. Т.е. между ними требуется какое-то взаимодействие, или синхронизация. Например, в системе работают две задачи: измерение температуры и вывод информации на экран. Вторая задача не может вывести на экран значение температуры, пока первая задача не завершила измерение. В данном уроке будет рассмотрен самый простой способ синхронизации задач - использование бинарных (двоичных) семафоров.

Теория

Бинарный семафор - внутренняя системная переменная, которая может принимать значения "0" и "1". Фактически - это битовая переменная, которая может быть установлена/сброшена/проверена любой задачей. Чаще всего бинарный семафор применяется тогда, когда из двух задач в один момент времени может работать только одна. Например, из всех работающих задач две задачи одновременно захотели записать какие-то данные во внешнюю EEPROM. Если данных для записи много, то процесс записи может затянуться (поскольку операция записи одной ячейки требует несколько миллисекунд). Разумеется, расходовать время ожидания записи каждой ячейки вхолостую не хочется, ведь в это время по-прежнему можно опрашивать клавиатуру, управлять какими-то внешними исполнительными устройствами и т.д. Т.е. желательно на время ожидания управление передавать другим задачам. Но что делать, если одна из этих других задач тоже хочет произвести запись? Ведь она обратится к внешней EEPROM в тот момент, когда та уже занята записью. Вот здесь на помощь и приходят бинарные семафоры. Из всех желающих произвести запись задач та, которая получает управление первой, сбрасывает семафор в "0", говоря тем самым всем остальным задачам, что EEPROM уже занята. Теперь все остальные задачи, желающие произвести запись, видя, что семафор сброшен (т.е. EEPROM уже кем-то используется), будут ждать его установки (т.е. освобождения EEPROM). По завершении записи первая задача вновь устанавливает семафор в "1", говоря остальным, что EEPROM освободилась и может быть использована другими задачами.

Одновременно в программе могут использоваться несколько семафоров: один - для EEPROM, один - для UART, один - еще для каких-то целей и т.д. В OSA доступное количество ограничивается свободной RAM-памятью: один байт вмещает в себя 8 бинарных семафоров. Сами бинарные семафоры хранятся во внутреннем системном массиве, размер которого определяется на этапе компиляции и зависит от предполагаемого количество используемых семафоров. Это количество указывается программистом явно в файле osacfg.h (заданием константы OS_BSEMS). Для работы с бинарными в OSA есть несколько сервисов:

OS_Bsem_Set	Установка семафора
OS_Bsem_Reset	Сброс семафора
OS_Bsem_Switch	Переключение семафора
`bool` OS_Bsem_Check	Проверка семафора
OS_Bsem_Wait	Ожидание семафора.
OS_Bsem_Wait_TO	Ожидание семафора с выходом по таймауту.

В параметрах каждому сервису передается номер бинарного семафора. Семафоры нумеруются от 0 до OS_BSEMS-1. Например:

семафор номер 0 служит для блокировки внешней EEPROM. Все задачи, желающие произвести чтение/запись в EEPROM должны проверять нулевой семафор;
семафор номер 1 служит для блокировки USART. Все задачи, которые хотят передать какие-то данные по USART должны проверять первый семафор;
и т.д.

Для удобства обращения к семафорам можно задать им идентификаторы (как это сделать, описано ниже).

Разберемся с работой бинарных семафоров на практике.

Проект

Для знакомства с бинарными семафорами напишем программу, состоящую из двух задач, управляющих светодиодами:

первая задача будет по очереди зажигать по одному светодиоду слева направо;
вторая задача будет по очереди гасить по одному светодиоду справа на лево.

Следуя инструкциям, описанным в первом уроке, создадим проект в папке "c:\tutor\t4" и назовем его "tutor4.c". Остановимся только на конфигурировании.

Конфигурирование проекта (osacfg.h)

Запустим утилиту OSAcfg_Tool.exe и создадим новый файл конфигурации для нашего проекта (кнопка "Browse…" и выбор папки проекта в открывшемся диалоговом окне).

Теперь в секции "System" устанавливаем параметр "Tasks" = 2 (у нас будут две задачи). Теперь нам нужно сказать системе, что мы будем использовать задержки в программе (задержки нужны, т.к. иначе программа будет работать слишком быстро, и на глаз будет не заметно, что происходит). Для этого нам нужно включить таймеры задач: в секции "Timers" устанавливаем галочку напротив пункта "Task timers".

Мы предполагаем использовать в своей программе бинарный семафор, поэтому укажем это в конфигурации, установив количество бинарных семафоров и задав имя.

Имя BS_LEDS_ARE_FREE, которое мы указали, мы будем использовать в качестве идентификатора семафора при обращении к нему в программе. Его, конечно, можно было и не задавать, оставив поле имен (ID name) пустым, но тогда придется обращаться к семафору по номеру, например:

    OS_Bsem_Wait(0);    // Ждем нулевой семафор

Однако, запись:

    OS_Bsem_Wait(BS_LEDS_ARE_FREE);    // Ждем освобождения порта со светодиодами

намного нагляднее и информативнее. Тем более, если в программе будут использоваться несколько семафоров, то без имен в них можно будет запутаться. Задание же имен в списке ID names в утилите OSAcfg_Tool сделает наш код намного нагляднее и позволит снизить вероятность ошибки.

Убеждаемся, что файл OSAcfg.h создан в папке "c:\tutor\t4". Обратим внимание, что в файле OSAcfg.h появилась конструкция enum, в которой описан идентификатор нашего бинарного семафора:

enum OSA_BSEMS_ENUM
{
    BS_LEDS_ARE_FREE           // Для блокировки светодиодов
};

Описание задач

Для начала создадим задачи без учета того, что порт, к которому подключены светодиоды, является разделяемым ресурсом. Т.е. опишем две задачи, как живущие сами по себе.

Задача для зажигания светодиодов:

void Task_LEDS_ON (void)
{
    static char s_i;      // Счетчик
    static char s_cMask;  // Маска для зажигания светодиодов
 
    for (;;)
    {
        s_cMask = 1;                    // Первым зажигаем нулевой светодиод
        for (s_i = 0; s_i < 8; s_i++)
        {
            PORT_LEDS |= s_cMask;       // Зажигаем текущий светодиод
            s_cMask <<= 1;              // Берем очередной светодиод
            OS_Delay(100);              // Пауза в 100 мс
        }
    }
}

Эта задача по очереди с интервалом в 100 мс зажжет все 8 светодиодов.

Теперь опишем задачу гашения светодиодов, для разнообразия сделаем в ней время паузы отличное от первой задачи:

void Task_LEDS_OFF (void)
{
    static char s_i;      // Счетчик
    static char s_cMask;  // Маска для гашения светодиодов
 
    for (;;)
    {
        s_cMask = 0x80;                 // Первым гасим седьмой светодиод
        for (s_i = 0; s_i < 8; s_i++)
        {
            PORT_LEDS &= ~s_cMask;      // Гасим текущий светодиод
            s_cMask >>= 1;              // Берем очередной светодиод
            OS_Delay(150);              // Пауза в 150 мс
        }
    }
}

Эта задача по очереди с интервалом в 150 мс гасит все 8 светодиодов.

Не забудем в функцию main() добавить сервисы, которые:

инициализируют ОС;
объявят системе, что Task_LEDS_OFF и Task_LEDS_ON являются функциями-задачами;
разрешат прерывания;
запустят планировщик на выполнение.

void main (void)
{
    // Инициализация периферии
    init();
 
    // Инициализация системы
    OS_Init();
 
    // Создание задач
    OS_Task_Create(3, Task_LEDS_ON);
    OS_Task_Create(3, Task_LEDS_OFF);
 
    // Разрешение прерываний
    OS_EI();
 
    // Запуск планировщика
    OS_Run();
}

Полный текст программы

Итак, полный текст нашей программы теперь будет выглядеть так:

#include <pic.h>
#include <osa.h>
 
 
 
//------------------------------------------------------------------------------
// Задаем биты конфигурации:
//   - внутренний RC-генератор
//   - отключаем WDT
//   - отключаем низковольтное программирование
//   - отключаем функцию отладки
//------------------------------------------------------------------------------
 
__CONFIG(INTIO & WDTDIS & PWRTEN & MCLRDIS & LVPDIS & UNPROTECT & BORDIS
               & IESODIS & FCMDIS & DEBUGDIS);
 
 
//------------------------------------------------------------------------------
//  Определеяем порт для работы со светодиодами
//------------------------------------------------------------------------------
 
#define PORT_LEDS   PORTD
 
//------------------------------------------------------------------------------
//  Параметры таймера:
//  - прескейлер = 4,
//  - постскейлер = 1,
//  - предел счета = 250
//
//  Тактовая частота контроллера = 4 МГц.
//
//  Период возникновения прерывания по TMR2 получается
//  равным 4 * 1 * 250 * Tcyc = 1 ms
//
//------------------------------------------------------------------------------
 
#define PR2_CONST       250-1
#define TMR2_PRS        1                           // prs = 4
#define TMR2_POST       0                           // post = 1
#define T2CON_CONST     (TMR2_POST<<3) | TMR2_PRS
 
 
//******************************************************************************
//  Глобальные переменные
//******************************************************************************
 
char m_cCounter1;
char m_cCounter2;
 
 
 
 
 
//******************************************************************************
//  Прерывание. Возникает каждую мс
//******************************************************************************
 
void interrupt isr (void)
{
    OS_EnterInt();
    if (TMR2IF)
    {
        OS_Timer();
        TMR2IF = 0;
    }
    OS_LeaveInt();
}
 
 
 
//******************************************************************************
//  Функции-задачи
//******************************************************************************
 
void Task_LEDS_ON (void)
{
    static char s_i;      // Счетчик
    static char s_cMask;  // Маска для зажигания светодиодов
 
    for (;;)
    {
        s_cMask = 1;                    // Первым зажигаем нулевой светодиод
        for (s_i = 0; s_i < 8; s_i++)
        {
            PORT_LEDS |= s_cMask;       // Зажигаем текущий светодиод
            s_cMask <<= 1;              // Берем очередной светодиод
            OS_Delay(100);              // Пауза в 100 мс
        }
    }
}
 
//------------------------------------------------------------------------------
 
void Task_LEDS_OFF (void)
{
    static char s_i;      // Счетчик
    static char s_cMask;  // Маска для гашения светодиодов
 
    for (;;)
    {
        s_cMask = 0x80;                 // Первым гасим седьмой светодиод
        for (s_i = 0; s_i < 8; s_i++)
        {
            PORT_LEDS &= ~s_cMask;      // Гасим текущий светодиод
            s_cMask >>= 1;              // Берем очередной светодиод
            OS_Delay(150);              // Пауза в 150 мс
        }
    }
}
 
//******************************************************************************
//  Инициализация периферии
//******************************************************************************
 
void init (void)
{
    //------------------------------------------------------------------------------
    //  Настройка портов I/O
    //------------------------------------------------------------------------------
 
    PORTA = 0;
    PORTB = 0;
    PORTC = 0;
    PORTD = 0;
 
    TRISA = 0;
    TRISB = 0;
    TRISC = 0;
    TRISD = 0;
 
    //------------------------------------------------------------------------------
    //  Настройка таймера 2
    //------------------------------------------------------------------------------
 
    PR2 = PR2_CONST;
    T2CON = T2CON_CONST | 0x04;
 
    //------------------------------------------------------------------------------
    //  Настройка прерываний
    //------------------------------------------------------------------------------
 
    PIR1 = 0;
    PIR2 = 0;
    INTCON = 0;
 
    TMR2IE = 1;         // Разрешаем прерываие по TMR2
    PEIE = 1;           // Разрешаем периферийные прерывания
                        // Глобальный бит разрешения прерываний будет
                        // установлен непосредственно перед запуском
                        // планировщика в функции main()
 
}
 
//******************************************************************************
//  main
//******************************************************************************
 
void main (void)
{
    // Инициализация периферии
    init();
 
    // Инициализация переменных системы
    OS_Init();
 
    // Создание задач
    OS_Task_Create(3, Task_LEDS_ON);
    OS_Task_Create(3, Task_LEDS_OFF);
 
    // Разрешение прерываний
    OS_EI();
 
    // Запуск планировщика
    OS_Run();
}
 
//******************************************************************************
//  end of file
//******************************************************************************

Работа программы

Без синхронизации

Соберем проект (Ctlr+F10) и прошьем его в контроллер. Увидим мы совсем не то, что задумали: вместо того, чтобы сначала по очереди зажечь все светодиоды, а потом по очереди их погасить, программа их зажигает и гасит одновременно. Дело в том, что задачи живут сами по себе и ни одна из них не знает о том, что делает другая. Вот схема работы нашей программы.

Как видно из схемы, каждая задача работает по своему алгоритму и выполняет со светодиодами те действия, которые мы ей предписали: одна зажигает светодиоды по одному, другая - гасит.

С синхронизацией

Очевидно, что мы пока не достигли своей цели. Теперь добавим блокировку задач с помощью бинарного семафора. Т.к. на момент получения управления задача не знает, свободен ресурс или нет (установлен семафор или сброшен), она становится в ожидание семафора сервисом OS_Bsem_Wait. Если семафор установлен и задача является самой приоритетной (или же сейчас ее очередь выполняться при равноприоритетности), то она получает управление. Если семафор сброшен (т.е. ресурс уже кем-то занят), то задача остается в режиме ожидания. Отметим одно важное свойство сервиса OS_Bsem_Wait:

Сервис OS_Bsem_Wait автоматически сбрасывает семафор, когда задача получает управление.

После того, как задача зажжет (погасит) все светодиоды, она должна освободить ресурс, т.е. установить семафор, чтобы другие задачи знали, что можно ресурс занимать.

/*****************************************/
void Task_LEDS_ON (void)
{
    static char s_i;      // Счетчик
    static char s_cMask;  // Маска для зажигания светодиодов
 
    for (;;)
    {
        OS_Bsem_Wait(BS_LEDS_ARE_FREE); // Ждем, когда можно будет работать
                                        // со светодиодами
        s_cMask = 1;                    // Первым зажигаем нулевой светодиод
        for (s_i = 0; s_i < 8; s_i++)
        {
            PORT_LEDS |= s_cMask;       // Зажигаем текущий светодиод
            s_cMask <<= 1;              // Берем очередной светодиод
            OS_Delay(100);              // Пауза в 100 мс
        }
        OS_Bsem_Set(BS_LEDS_ARE_FREE);  // Освобождаем ресурс
    }
}
/*****************************************/
void Task_LEDS_OFF (void)
{
    static char s_i;      // Счетчик
    static char s_cMask;  // Маска для гашения светодиодов
 
    for (;;)
    {
        OS_Bsem_Wait(BS_LEDS_ARE_FREE); // Ждем, когда можно будет работать
                                        // со светодиодами
        s_cMask = 0x80;                 // Первым гасим седьмой светодиод
        for (s_i = 0; s_i < 8; s_i++)
        {
            PORT_LEDS &= ~s_cMask;      // Гасим текущий светодиод
            s_cMask >>= 1;              // Берем очередной светодиод
            OS_Delay(150);              // Пауза в 150 мс
        }
        OS_Bsem_Set(BS_LEDS_ARE_FREE);  // Освобождаем ресурс
    }
}
/*****************************************/

Остался последний штрих. Т.к. при инициализации системы все бинарные семафоры сбрасываются, то перед началом работы мы должны установить семафор, разрешающий работу со светодиодами. Это можно сделать, например, в функции main после создания задач:

    // Создание задач
    OS_Task_Create(3, Task_LEDS_ON);
    OS_Task_Create(3, Task_LEDS_OFF);
 
    // Разрешить работу со светодиодами
    OS_Bsem_Set(BS_LEDS_ARE_FREE);
 
    // Разрешение прерываний
    OS_EI();

Если этого не сделать, то обе наши задачи будут бесконечно ждать семафор, который никогда не установится.

Соберем проект (Ctrl+F10) и прошьем контроллер. Теперь мы видим, что программа работает так, как мы задумали с самого начала. Разберемся подробнее.

Итак, начальные условия:

две готовые к запуску задачи (после создания задача сразу готова к выполнению);
задачи имеют одинаковый приоритет;
есть установленный семафор BS_LEDS_ARE_FREE.

Когда планировщик начинает работу, он перебирает все задачи в поисках готовых и сравнивает их приоритеты, чтобы вычислить, какую задачу нужно запускать. В нашем случае обе задачи готовы и имеют одинаковый приоритет, поэтому планировщик запустит ту из них, которая была создана первой, т.е. Task_LEDS_ON. Задача, получив управление, входит в свой бесконечный цикл for, где первым делом натыкается на сервис ожидания OS_Bsem_Wait. Разберемся подробнее, что произойдет. Задача видит, что семафор установлен, поэтому она могла бы продолжить выполнение. Но она ничего не знает об остальных задачах программы. Что если этот же семафор ожидает другая задача, имеющая более высокий приоритет? Ведь в этом случае более приоритетная задача должна получить управление. Поэтому задача не продолжает выполнение, а передает управление планировщику, чтобы он проверил, нет ли более важных задач. Сама задача Task_LEDS_ON останется при этом готовой к выполнению.

Планировщик проверяет все задачи на предмет готовности (обе задачи сейчас готовы) и сравнивает приоритеты. Приоритеты равны, поэтому управление получит следующая по очереди задача, т.е. Task_LEDS_OFF. Получив управление, она войдет в бесконечный цикл, где так же, как и задача Task_LED_ON, наткнется на сервис OS_Bsem_Wait. Семафор все еще установлен, и задача проделает те же операции, что и первая задача, т.е. отдаст управление планировщику, чтобы он проверил, нет ли более приоритетных задач.

Планировщик видит, что обе задачи ждут один и тот же семафор и они имеют одинаковый приоритет. Поэтому он отдаст управление следующей по очереди задаче, т.е. вновь управление получит Task_LEDS_ON. Теперь, когда известно, что нет более приоритетных задач, ожидающих этот же семафор, задача Task_LEDS_ON может продолжить выполнение. При выходе из ожидания семафора сервис OS_Bsem_Wait сбрасывает семафор, сообщая остальным задачам, что ресурс уже занят.

Далее программа входит в цикл, в котором по очереди зажгутся все 8 светодиодов. После зажигания первого светодиода задача выдерживает задержку в 100 мс, переключаясь при этом в режим ожидания и передавая управление планировщику. Планировщик, получив управление, проверяет, нет ли готовых задач. Выясняется, что нет, т.к. одна задача в задержке, а вторая ждет семафор, который был только что сброшен задачей, захватившей ресурс (управление портом со светодиодами). Поэтому в течение 100 мс ни одна задача не получит управления. По истечении 100 мс задача Task_LEDS_ON снова становится готовой к выполнению (задача Task_LEDS_OFF все еще ждет, т.к. семафор остался сброшенным). Получив управление, Task_LEDS_ON зажигает второй светодиод и снова уходит в задержку. И т.д., пока не зажгутся все 8 светодиодов.

После зажжения всех светодиодов задача вновь устанавливает семафор, сообщая остальным задачам, что ресурс (порт, к которому подключены светодиоды, свободен). Теперь она возвращается на начало своего цикла и опят натыкается на сервис OS_Bsem_Wait. Она видит, что семафор установлен, но ей надо проверить, нет ли других задач ожидающих этот же семафор, поэтому управление передается планировщику. А планировщик видит, что есть две задачи с одинаковым приоритетом, ожидающие семафор, и он отдает управление той, которая следующая по очереди (чтобы не выполнять всегда одну и ту же), т.е. задаче Task_LEDS_OFF.

Задача Task_LEDS_OFF, получив управление, сразу же сбрасывает семафор (мы уже говорили, что это автоматически делается сервисом OS_Bsem_Wait), а потом работает по той же схеме, что и задача Task_LEDS_ON, только не зажигает светодиоды, а гасит их.

Схематически работу программы можно изобразить так:

На рисунке видно, что одна задача, получив управление, блокирует другую. После выполнения своей части работы (зажжения/гашения всех светодиодов) задача устанавливает семафор, после чего оказывается сама блокированной другой задачей и остается в этом состоянии до тех пор, пока другая задача не обработает все 8 светодиодов, после чего вновь обретает возможность получить управление.

Эксперимент 1 - приоритеты

Изменим приоритет одной из задач в функции main:

    OS_Task_Create(4, Task_LEDS_OFF);

Соберем проект (Ctrl+F10) и прошьем контроллер. Мы увидим, что светодиоды зажглись с интервалом в 100 мс и остались этом состоянии. Дело в том, что теперь получается так, что одновременно семафор ожидается двумя задачами с разными приоритетами. Планировщик каждый раз выбирает ту из них, чей приоритет выше, т.е. задачу Task_LEDS_ON.

Однако, стоит нарушить условие одновременности ожидания семафора - и задача Task_LEDS_OFF получит возможность выполниться. Для этого добавим в конец цикла в задаче Task_LEDS_ON короткую задержку:

        ...
        OS_Bsem_Set(BS_LEDS_ARE_FREE);  // Освобождаем ресурс
 
        OS_Delay(1);                    // За время этой задержки задача с более
                                        // низким приоритетом успеет стать единственной
                                        // готовой к выполнению
    }

Что произойдет? После установки семафора BS_LEDS_ARE_FREE задача Task_LEDS_ON не сразу же начинает ждать этот семафор, а с некоторой задержкой, в течение которой она будет находиться в режиме ожидания. При этом планировщик увидит, что единственной готовой к выполнению задачей является Task_LEDS_OFF. тут уже приоритет первой задачи значения не имеет, т.к. в сравнении приоритетов участвуют только готовые задачи, а задача Task_LEDS_ON - в ожидании. Получив управление, Task_LEDS_OFF сразу же сбрасывает семафор и начинает выполнять свои операции по гашению светодиодов. По завершении миллисекундной задержки задача Task_LEDS_ON подходит к сервису OS_Bsem_Wait, но на этот момент семафор уже сброшен, поэтому этой задаче ничего не остается делать, кроме как ждать освобождения ресурса, занятого менее приоритетной задачей.

Исключение

Есть одно исключение: если семафор устанавливается в прерывании в промежутке между проверкой готовности планировщиком задач с высоким приоритетом (должна проверяться первой) и низким, то выполнение получит задача с более низким приоритетом. Это нужно учитывать при разработке программ, работающих с семафорами в прерываниях.

Эксперимент 2 - два сервиса ожидания подряд

Попробуем переписать задачу Task_LEDS_ON, добавив еще один сервис ожидания семафора:

    for (;;)
    {
        OS_Bsem_Wait(BS_LEDS_ARE_FREE);
        OS_Bsem_Wait(BS_LEDS_ARE_FREE);
        ...

Рассмотрим, что произойдет в этом случае. Задача Task_LEDS_ON, получив управление, первым сервисом OS_Bsem_Wait сбросит семафор. Ко второму сервису она подойдет с уже сброшенным семафором и дальше пройти не сможет. Т.е. программа повиснет, т.к. есть две задачи, ожидающие один и тот же семафор, который нигде, кроме, самих задач не устанавливается. А так как задачи управления не получают, то и семафор они установить не смогут.

Можете прошить программу с такой задачей в контроллер и убедиться, что работать она не будет.

Заключение

В этом уроке мы познакомились с простейшим механизмом синхронизации задач - бинарным семафором, - выяснили, как он может нам помочь при программировании задач, управляющих разделяемым ресурсом, и узнали важные особенности:

OS_Bsem_Wait блокирует задачу (держит ее в состоянии ожидания), пока семафор не будет установлен;
OS_Bsem_Wait сбрасывает семафор после того, как его дождется;
если две задачи одновременно ждут один и тот же семафор, то управление получит та из них, чей приоритет выше.

OSA : Учебник. Урок 5 - Расширенный приоритетый режим

2011-01-19T16:18:30+03:00

OSA : Учебник. Урок 5 - Расширенный приоритетый режим

К оглавлению

Тема

Вернемся к вопросу приоритетов. В предыдущих примерах были показаны некоторые особенности приоритетного режима. Сейчас рассмотрим приоритеты более детально.

Теория

OSA поддерживает три различных режима обработки приоритетов: неприоритетный, обычный (по умолчанию) и расширенный. Режим выбирается один раз на этапе компиляции и не может быть изменен в ходе выполнения программы. Для выбора режима в файле osacfg.h должна быть определена константа OS_PRIORITY_LEVEL. Рассмотрим, в чем их особенности, достоинства и недостатки.

Неприоритетный режим

Самый простой, самый быстрый и самый нетребовательный к ресурсам режим. Работая в неприоритетном режиме, планировщик по очереди перебирает все задачи одну за другой, проверяя их готовность к выполнению. Как только он обнаруживает готовую задачу, он сразу же передает ей управление. Этот режим чем-то сродни обычному суперциклу, за исключением некоторых удобств, привносимых самой ОС, таких как возможность прервать функцию в середине выполнения с последующим возвратом в точку выхода, синхронизация задач с помощью событий, контроль таймаутов и задержек и т.д.

Для несложных программ такой режим является самым удачным выбором. Недостатком этого режима является невозможность предоставить более важным задачам возможность получать управление чаще и быстрее. Т.е. даже если произошло событие, которого такая задача ожидала, то она должна будет подождать, пока выполнятся все предшествующие ей в очереди задачи.

Обычный приоритетный режим

В отличие от неприоритетного, в этом режиме планировщик сперва просматривает все задачи на предмет готовности, затем сравнивает приоритеты готовых к выполнению задач, а уже потом передает управление самой приоритетной из них. Т.е. в этом режиме имеется возможность каким-то задачам выделить больше процессорного времени, а каким-то меньше. Платой за это будет скорость работы планировщика: если в неприоритетном режиме для запуска следующей задачи ему иногда достаточно проверить одну, то в обычном приоритетном режиме планировщик каждый раз должен проверять все активные в данный момент времени задачи, что увеличивает время поиска в OS_TASKS раз (в среднем проверка одной задачи длится 80-100 тактов).

Если в программе есть две постоянно готовые задачи с разными приоритетами, то та из них, чей приоритет ниже, никогда не получит управления, т.к. всегда есть готовая к выполнению более высокоприоритетная задача. Это также можно отнести к недостаткам данного режима.

Если в программе есть несколько постоянно готовых задач с одинаковым приоритетом, то все они будут получать управление по очереди. За одним исключением, когда равноприоритетные задачи ожидают одно и то же событие, устанавливаемое в другой задаче. Т.к. планировщик проверяет задачи в одном и том же порядке, управление из этих равноприоритетных задач будет получать весгда та задача, которая выполняется первой после той, которая сформировала событие. Ниже это будет пояснено на примере.

Итак, обычный приоритетный режим имеет два основных недостатка:

блокировка низкоприоритетных задач высокоприоритетными;
получение управления только одной задачей из весх равноприоритетных, ожидающих одно и то же событие.

Расширенный приоритетный режим

Расширенный приоритетный режим был введен на смену обычному приоритетному режиму для устранения двух его основных недостатков. В этом режиме важность задачи поределяется не только приоритетом, но и давностью последнего получения управления. Рабтая в этом режиме, планировщик, просматривая список задач и выбирая наиболее приоритетную из готовых, делает еще две вещи:

увеличивает важность готовой к выполнению, но не получившей управления (т.к. была более приоритетная) задачи;
меняет порядок просмотра задач так, чтобы только что выполненная задача оказалась в списке последней.

Другими словами в этом режиме все задачи гарантированно получают управление пропорционально своим приоритетам. Изначально важность задачи равна ее приоритету, а порядок в очереди планировщика определен последовательностью создания задач. Если задача оказалась готовой к выполнению, но управления не получила из-за того, что событие, которого она ожидала, было сброшено более приоритетной (важной) задачей, то ее важность увеличивается пропорционально приоритету. Когда задача получает управление, ее важность опять становится равной приоритету, а сама она становится в конец очереди планировщика, эти меры увеличивают шанс других задач получить упраление при повторном возникновении события.

Недостатками этого метода являются:

более низкая, чем в обычном приоритетном режиме, скорость работы планировщика (см. Скоростные характеристики);
на каждую задачу выделяютя дополнительно по два байта ОЗУ, определяющие важность и порядковый номер в очереди планировщика.

Теперь рассмотрим работу программы под управлением данных режимов на практике.

Проект

Для разбора приоритетных режимов напишем программу, состоящую из 4х задач:

три из них будут дожидаться двоичного семафора и зажигать/гасить каждая свой светодиод;
четвертая задача имеет самый низкий приоритет, и она будет устанавливать семафор.

Следуя инструкциям, описанным в первом уроке, создадим проект в папке "c:\tutor\t5" и назовем его "tutor5.c".

Конфигурирование проекта (osacfg.h)

Теперь в секции "System" устанавливаем параметр "Tasks" = 4 (у нас будут четыре задачи). Далее нам нужно сказать системе, что мы будем использовать задержки в программе, т.к. без задержек мы на глаз не уследим за происхоящим. Для этого нам нужно включить таймеры задач: в секции "Timers" устанавливаем галочку напротив пункта "Task timers".

Также нам понадобится бинарный семафор: установим количество семафоров в "1" и зададим имя семафору BS_SIGNAL. Это имя будет использоваться нами для обращения к семафору в программе.

Убеждаемся, что файл OSAcfg.h создан в папке "c:\tutor\t5".

Описание задач

Для начала опишем задачи, управляющие светодиодами:

void Task_LED1 (void)
{
    for (;;)
    {
        OS_Bsem_Wait(BS_SIGNAL);  // Дожидаемся семафора
        PIN_LED1 ^= 1;           // Изменяем состояние первого светожиода
    }
}

Аналогичным образом будут выглядеть задачи, управляющие светодиодами LED2 и LED3.

Терь опишем задачу, сигнализирующую семафором:

void Task_Signal (void)
{
    for (;;)
    {
        OS_Bsem_Set(BS_SIGNAL);
        OS_Delay(200);
    }
}

Эта задача каждые 200 мс будет сигналить семафором.

В функцию main(), как всегда, добавляем сервисы инициализации, создания задач и запуска планировщика:

void main (void)
{
    // Инициализация периферии
    init();
 
    // Инициализация системы
    OS_Init();
 
    // Создание задач
    OS_Task_Create(3, Task_LED1);
    OS_Task_Create(3, Task_LED2);
    OS_Task_Create(3, Task_LED3);
    OS_Task_Create(3, Task_Signal);
 
    // Разрешение прерываний
    OS_EI();
 
    // Запуск планировщика
    OS_Run();
}

Полный текст программы

Итак, полный текст нашей программы теперь будет выглядеть так:

#include <htc.h>
#include <osa.h>
 
 
 
//------------------------------------------------------------------------------
// Задаем биты конфигурации:
//   - внутренний RC-генератор
//   - отключаем WDT
//   - отключаем низковольтное программирование
//   - отключаем функцию отладки
//------------------------------------------------------------------------------
 
__CONFIG(INTIO & WDTDIS & PWRTEN & MCLRDIS & LVPDIS & UNPROTECT & BORDIS
               & IESODIS & FCMDIS & DEBUGDIS);
 
 
//------------------------------------------------------------------------------
//  Определеяем выводы для управления светодиодами
//------------------------------------------------------------------------------
 
#define PIN_LED1    RD0
#define PIN_LED2    RD1
#define PIN_LED3    RD2
 
//------------------------------------------------------------------------------
//  Параметры таймера:
//  - прескейлер = 4,
//  - постскейлер = 1,
//  - предел счета = 250
//
//  Тактовая частота контроллера = 4 МГц.
//
//  Период возникновения прерывания по TMR2 получается
//  равным 4 * 1 * 250 * Tcyc = 1 ms
//
//------------------------------------------------------------------------------
 
#define PR2_CONST       250-1
#define TMR2_PRS        1                           // prs = 4
#define TMR2_POST       0                           // post = 1
#define T2CON_CONST     (TMR2_POST<<3) | TMR2_PRS
 
 
//******************************************************************************
//  Прерывание. Возникает каждую мс
//******************************************************************************
 
void interrupt isr (void)
{
    if (TMR2IF)
    {
        OS_Timer();
        TMR2IF = 0;
    }
}
 
 
 
//******************************************************************************
//  Функции-задачи
//******************************************************************************
 
void Task_LED1 (void)
{
    for (;;)
    {
        OS_Bsem_Wait(BS_SIGNAL);  // Дожидаемся семафора
        PIN_LED1 ^= 1;           // Изменяем состояние первого светожиода
    }
}
 
//-----------------------------------------------------------------------------
 
void Task_LED2 (void)
{
    for (;;)
    {
        OS_Bsem_Wait(BS_SIGNAL);  // Дожидаемся семафора
        PIN_LED2 ^= 1;           // Изменяем состояние второго светожиода
    }
}
 
//-----------------------------------------------------------------------------
 
void Task_LED3 (void)
{
    for (;;)
    {
        OS_Bsem_Wait(BS_SIGNAL);  // Дожидаемся семафора
        PIN_LED3 ^= 1;           // Изменяем состояние третьего светожиода
    }
}
 
//-----------------------------------------------------------------------------
 
void Task_Signal (void)
{
    for (;;)
    {
        OS_Bsem_Set(BS_SIGNAL);
        OS_Delay(200);
    }
}
 
//******************************************************************************
//  Инициализация периферии
//******************************************************************************
 
void init (void)
{
    //------------------------------------------------------------------------------
    //  Настройка портов I/O
    //------------------------------------------------------------------------------
 
    PORTA = 0;
    PORTB = 0;
    PORTC = 0;
    PORTD = 0;
 
    TRISA = 0;
    TRISB = 0;
    TRISC = 0;
    TRISD = 0;
 
    //------------------------------------------------------------------------------
    //  Настройка таймера 2
    //------------------------------------------------------------------------------
 
    PR2 = PR2_CONST;
    T2CON = T2CON_CONST | 0x04;
 
    //------------------------------------------------------------------------------
    //  Настройка прерываний
    //------------------------------------------------------------------------------
 
    PIR1 = 0;
    PIR2 = 0;
    INTCON = 0;
 
    TMR2IE = 1;         // Разрешаем прерываие по TMR2
    PEIE = 1;           // Разрешаем периферийные прерывания
                        // Глобальный бит разрешения прерываний будет
                        // установлен непосредственно перед запуском
                        // планировщика в функции main()
 
}
 
//******************************************************************************
//  main
//******************************************************************************
 
void main (void)
{
    // Инициализация периферии
    init();
 
    // Инициализация системы
    OS_Init();
 
    // Создание задач
    OS_Task_Create(3, Task_Signal);
    OS_Task_Create(3, Task_LED1);
    OS_Task_Create(3, Task_LED2);
    OS_Task_Create(3, Task_LED3);
 
    // Разрешение прерываний
    OS_EI();
 
    // Запуск планировщика
    OS_Run();
}
 
 
//******************************************************************************
//  end of file
//******************************************************************************

Работа программы

Неприоритетный режим

Запустим еще раз конфигуратор OSAcfg_Tool.exe, загрузим в него файл c:\tutor5\osacfg.h и в секции "System" выберем в поле "Priority level" пункт "Disabed". Сохряняем и выходим. Убеждаемся, что в файле osacfg.h появилась строка:

#define OS_PRIORITY_LEVEL  OS_PRIORITY_DISABLED

Соберем проект (Ctlr+F10) и прошьем его в контроллер. Мы увидим, что мигает только один светодиод, которым управляет задача Task_LED1. Рассмотрим подробнее, как работает программа в этом режиме. Для удобства на диаграммах рядом с именем задачи показан ее приоритет.

Начало. При старте все светодиоды погашены, а семафор сброшен (запрещен). Готовой к выполнению является только задача Task_Signal, все остальные ожидают семафор.

Шаг 1. Первой планировщиком просматривается задача Task_Signal, т.к. она была создана первой. Он видит, что она готова к выполнению и передает ей управление. После завершения ее работы семафор BS_SIGNAL установлен в "1".

Шаг 2.

Задача Task_Signal переведена в режим ожидания (OS_Delay), но три задачи, усправляющие светодиодами, становятся готовыми к выполнению. Планировщик берет для проверки следующую по очереди задачу (т.е. Task_LED1), видит, что она готова, и передает ей управление. Вспомним, что сервис OS_Bsem_Wait после того, как задача получает управление, сбрасывает семафор. Задача Task_LED1 изменяет состояние светодиода LED1.

Шаг 3.

После того, как Task_LED1 отработала и переведена в режим ожидания (сервисом OS_Bsem_Wait), семафор вновь сброшен, следовательно, задачи Task_LED2 и Task_LED3 опять переводятся в режим ожидания. Таким образом, на данный момент нет ни одной готовой к выподлнению задачи. И так будет до тех пор, пока не закончится время ожидания в задаче Task_Signal (в нашем примере 100 мс). Задачи и дальше будут проверяться по кругу. Сначала Task_LED2:

Затем Task_LED3, Task_Signal, Task_LED1, снова Task_LED2, снова Task_LED3 и т.д.

Шаг 4.

Когда время ожидания задачи Task_Signal выходит, эта задача становится готовой к выполнению и ждет своей очереди на проверку планировщиком.

Шаг 5.

Дождавшись своей очереди, задача получает управление. При этом она снова устанавливает семафор.

Шаг 6.

Семафор вновь установлен, и задачи Task_LED1, Task_LED2 и Task_LED3 опять готовы к выполнению. Первой по очереди планировщиком проверяется задача Task_LED1, она и получает управление, т.к. является готовой. Семафор BS_SIGNAL сбрасывается, а свтодиод LED1 меняет свое состояние.

Как видим, шаги 1 и 2 идентичны шагам 5 и 6. И дальше программа будет идти по кругу, а задачи Task_LED2 и Task_LED3 так и не получат управления.

Обычный приоритетный режим

Запустим конфигуратор OSAcfg_Tool.exe, загрузим в него файл c:\tutor5\osacfg.h и в секции "System" выберем в поле "Priority level" пункт "Normal". Сохряняем и выходим. Убеждаемся, что в файле osacfg.h появилась строка:

#define OS_PRIORITY_LEVEL  OS_PRIORITY_NORMAL

Для разнообразия расставим задачам разные приоритеты (в функции main()):

    // Создание задач
    OS_Task_Create(7, Task_Signal);  // Самый низкий приоритет
    OS_Task_Create(5, Task_LED1);
    OS_Task_Create(2, Task_LED2);    // Самый высокий приоритет
    OS_Task_Create(4, Task_LED3);

Соберем проект (Ctlr+F10) и прошьем его в контроллер. Мы увидим, что мигает только один светодиод, которым управляет задача Task_LED2. Рассмотрим подробнее, как работает программа в этом режиме.

Начало.

При старте все светодиоды погашены, а семафор сброшен (запрещен). Готовой к выполнению является только задача Task_Signal, все остальные ожидают семафор.

Шаг 1.

В отличие от неприоритетного, в обычном приоритетном режиме планировщик сперва проверяет готовность всех задач и выполняет сравнение приоритетов готовых. Только после этого принимает решение о передаче управления. Причем проверка идет в последовательности, определяемой очередностью создания задач. (Эта очередность может быть нарушена в случае удаления одних задач и создания на их месте новых, но в данном примере одна всегда одна и та же).

Единственной готовой задачей на данный момент является Task_Signal. И хоть она имеет низший приоритет, именно она получит управление, т.к. больше готовых задач нет. Выполнившись, она установила семафор BS_SIGNAL и перейдет в режим ожидания на 100 мс (OS_Delay).

После выполнения задачи очередь сдвигается так, что первой на проверку будет стоять следующая за выполнившейся, а только что выполнившаяся отправляется в конец очередь. Порядок очередь при этом не меняется, т.е., например, задача Task_LED2 всегда будет идти за Task_LED1, а Task_LED3 - всегда за Task_LED2 И т.д. Смысл циклического сдвига будет пояснен ниже (в Эксперименте 3).

Шаг 2.

Планировщик вновь просматривает все 4 задачи, начиная на этот раз со следующей за только что выполнившейся Task_Signal, т.е. с Task_LED1. На данный момент готовы 3 задачи: Task_LED1, Task_LED2 и Task_LED3. Планировщик сравнивает их приоритеты (помним, что 0 - высший приоритет, 7 - низший), вычисляет, что наивысший приоритет из готовых имеет задача Task_LED2, и именно ей передается управление. Эта задача в свою очередь сбрасывает семафор (это делается автоматически сервисом OS_Bsem_Wait) и изменяет состояние светодиода LED2.

После выполнения задачи снова циклически сдвигаются в очереди проверки так, что Task_LED2 оказывается в самом конце очереди. Первой становится та задача, что была за Task_LED2, т.е. Task_LED3.

Шаг 3.

Планировщик просматривает все задачи, начиная с Task_LED3, и видит, что готовых к выполнению нет (т.к. все ждут семафор, а Task_Signal выдерживает паузу). Поэтому управление ни одна задача не получает.

После проверки все задачи циклически сдвигаются на 1, и следующая проверка начнется с задачи Task_Signal. Далее они будет проверятся и проверяться, пока не закончится время задержки в задаче Task_Signal (т.е. в течение 100 мс).

Шаг 4.

Когда время задержки истекает, задача Task_Signal становится готовой к выполнению. Вне зависимости от того, с какой задачи начинается проверка все очереди задач, управление получит именно она, т.к. она на данный момент времени является самой приоритетной из всех готовых (вернее - единственной готовой). После выполнения семафор будет установлен, а задача снова переведена в решим ожидания задержки.

Обратим внимание на то, что циклический сдвиг задач в очереди в данном случае не производится, т.к. последняя выполнившаяся задача и так уже находится в самом конце очереди.

Шаг 5.

Этот шаг получается идентичным шагу 2. Т.е. снова из трех готовых к выполнению задач будет выбрана та, чей приоритет выше, т.е. Task_LED2. Она снова сбросит семафор и снова изменит состояние светодиода.

Шаг 6.

Дальше идем по кругу, т.е. шаг 6 идентичен шагу 3.

В результате программа будет крутиться, выполняя только две задачи: Task_Signal и самую приоритетную из ожидающих семафор - Task_LED2.

Эксперимент 1. Перестановка приоритетов

Только что мы наблюдали, что при работе программы мигает только один светодиод, которым управляет задача Task_LED2. Попробуем поменять приоритеты задач:

    // Создание задач
    OS_Task_Create(7, Task_Signal);  // Самый низкий приоритет
    OS_Task_Create(5, Task_LED1);
    OS_Task_Create(2, Task_LED2);
    OS_Task_Create(0, Task_LED3);    // Самый высокий приоритет

Теперь самый высокий приоритет у задачи Task_LED3. Запустим программу и убедимся, что теперь мигает только светодиод LED3. Принцип работы тот же, что и описан выше, только на шагах 2 и 5 планировщиком для запуска выбирается не Task_LED2, а Task_LED3 как более приоритетная.

Эксперимент 2. Равные приоритеты

Как поведет себя программа, если все приоритеты будет одинаковыми?

    // Создание задач
    OS_Task_Create(3, Task_Signal);  // Все приоритеты равны
    OS_Task_Create(3, Task_LED1);
    OS_Task_Create(3, Task_LED2);
    OS_Task_Create(3, Task_LED3);

Соберем эту программу (Ctrl+F10) и запустим на выполнение. Теперь мы видим, что работает только светодиод LED1. Почему? Потому что здесь мы наткнулись на недостаток обычного приоритетного режима, описанный выше: "получение управления только одной задачей из всех равноприоритетных, ожидающих одно и то же событие". Дело в том, что при сравнении приоритетов готовых задач играет роль последеовательность, в которой планировщик рассматривает задачи и преимущество отдается той, которая была рассмотрена первее. В нашем случае получается, что после работы Task_Signal (т.е. сразу после того момента, как был установлен семафор), первой в очереди оказывается именно Task_LED1. При равных приоритетах Task_LED1, Task_LED2 и Task_LED3 преимущество отдается той, которая была рассмотрена первой, т.е. Task_LED1. Этого недостатка лишен расширенный приоритетный режим.

Эксперимент 3. Замена OS_Bsem_Wait на OS_Yield

Попробуем теперь при равных приоритетах задач заменить сервис OS_Bsem_Wait на OS_Yield. Т.е. отменяем ожидание несколькими задачами одного и того же условия.

void Task_LED1 (void)
{
    for (;;)
    {
        //OS_Bsem_Wait(BS_SIGNAL);
        OS_Yield();
        PIN_LED1 ^= 1;           // Изменяем состояние первого светожиода
    }
}

по аналогии перепишем так же задачи Task_LED2 и Task_LED3. Соберем программу и запустим ее на выполнение. Мы увидим, что теперь загорелись все три светодиода. На самом деле они не горят постоянно, а очень быстро мигают (ожидания семафора-то теперь нет, следовательно нет паузы в 100мс, выдерживаемой между установками семафора).

Но на что мы должны обратить внимание: все три задачи получают управление. Вспомним еще раз: управление получает наиболее приоритетная из готовых или, если их приоритеты равны, первая готовая из рассмотренных планировщиком. В нашем случае все три задачи, управляющие светодиодом, постоянно готовы. Теперь вспомним, что планировщик после выполнения каждой задачи циклически сдвигает очередь так, чтобы выполненая оказалась в конце очереди. Таким образом получается, что из всех равноприоритетных задач планировщиком первой рассматривается не одна и та же, а разные задачи. Это отдает преимущество первой рассмотренной всем по очереди. В результате этого все задачи имеют возможность выполниться.

Теперь проделаем еще один небольшой эксперимент: одной из задач понизим приоритет:

    // Создание задач
    OS_Task_Create(3, Task_Signal);  // Все приоритеты равны
    OS_Task_Create(3, Task_LED1);
    OS_Task_Create(5, Task_LED2);    // А у этой задачи приоритет ниже
    OS_Task_Create(3, Task_LED3);

Соберем программу и запустим ее. Теперь мы видим, что горят (т.е. очень быстро мигают) только светодиоды LED1 и LED3, а LED2 потушен. Почему? Потому что здесь мы наткнулись на еще один недостаток обычного приоритетного режима: "блокировка низкоприоритетных задач высокоприоритетными". Пока есть готовые к выполнению высокоприоритетные задачи (а в нашем случае они есть), низкоприоритеные не смогут получить управление. Этого недостатка лишен расширенный приоритетный режим.

Расширенный приоритетный режим

Вернем программу в исходное состояние, т.е. расставим всем задачам равные приоритеты и восстановим вызовы сервисов OS_Bsem_Wait, убрав вызовы OS_Yield.

Запустим утилиту OSAcfg_tool.exe и в секции "System" выберем в поле "Priority level" пункт "Extended". Сохряняем и выходим. Убеждаемся, что в файле osacfg.h появилась строка:

#define OS_PRIORITY_LEVEL  OS_PRIORITY_EXTENDED

Теперь собираем программу (Ctrl+F10) и прошиваем контроллер. О чудо! Мигают все три светодиода. Разберемся, как работает программа в этом режиме. Обращу ваше внимание на то, что в данном случае рядом с именем задачи будет стоять не приоритет, а ее важность (как уже было написано, эта характеристика меняется в ходе выполнения программы; чем цифра больше, тем важность выше).

Начало.

Шаг 1. Здесь все так же, как и о бычном приоритетном режиме, т.к. готова только одна задача Task_Signal. Она устанавливает семафор и переходит в режим ожидания задержки.

Теперь только что выполненная задача перемещается в конец очереди. Замечу, что хоть внешне этот перенос и выглядит так же, как и в примере с обчным приоритетным режимом, это не совсем то же самое. Там был циклический сдвиг, а здесь просто перенос задачи в конец очереди со сдвигом всех следующих за ней, но предыдущие остаются на своих местах. Это станет понятно чуть ниже.

Шаг 2.

Три задачи готовы к выполнению, имея одинаковую важность (т.к. изначально она пропорциональна приоритету, а он у всех трех задач одинаковый). Но планировщик отдаст преимущество задаче Task_LED1, как первой рассмотренной из готовых. Она сбросит семафор и зменит состояние светодиода LED1.

Теперь важный момент: задачи Task_LED2 и Task_LED3 были готовы, но упрвление получить не смогли, т.к. Task_LED1 уже сбросила семафор. Поэтому их важность увеличивается. Важность задачи Task_LED1 должна быть понижена до минимума, т.к. она только что была выполнена, но сейчас остается неизменной, т.к. она и так минимальная. Задача Task_LED1 переносится в конец очереди, а все следующие за ней (в конкретном случае - все оставшиеся задачи) сдвигаются влево, ближе к началу очереди.

Шаг 3.

Нет ни одной готовой к выполнению программы, т.к. семафор сброшен, а задача, его устанавливающая, выдерживает паузу. Однако обратим внимание на важности задач Task_LED2 и Task_LED3: они теперь увеличились на 1, повысив вероятность быть избранными планировщиком в следующий раз.

Порядок задач не будет меняться до тех пор, пока не закончится время ожидания Task_Signal (в отличие от обычного приоритета, где все задачи циклически сдвигались при кажлой перепроверке).

Шаг 4.

Время задержки вышло, и задача Task_Signal снова готова к выполнению. Она же его и получает. т.к. является единственной готовой. Семафор устанавливается, а сама задача снова переводится в режим ожидания задержки.

Обратим внимание на то, как изменится очередь после выполнения этого шага: Task_LED2 и Task_LED3 остались на своих местах, т.к. они являются предшествующими только что выполненной; Task_Signal ставится в конец очереди, а все последующие (т.е. Task_LED1) сдвигаются на 1 позицию ближе к началу очереди.

Шаг 5.

На данный момент готовы три задачи: Task_LED1, Task_LED2 и Task_LED3. Но теперь планировщик руководствуется не приоритетами, как в обычном приоритетном режиме, а другой характеристикой - важностью. Задача Task_LED1 отпадает сразу, т.к. имеет самую маленькую важность. А из задач, имеющих одинаковые значения важности, будет выбрана та, которая была рассмотрена планировщиком первее, т.е. Task_LED2. Она же сбросит семафор и изменит состояние светодиода LED2.

Теперь важность только что выполенной задачи устанавливается минимальной, а сама задача ставится в конец очереди. Важности готовых, но не получивших управление, задач увеличивается.

Шаг 6.

Таким образом, на данный момент самой важной является та из трех ожидающих семафор, которая еще не получала управление, т.е. Task_LED3.

Шаг 7.

По завершению задержки Task_Signal становится готовой к выполнению и получает управление. Опять устанавливается семафор, а задача Task_Signal переводится в паузу.

Так же на схеме видно, что Task_LED3, стоящая в очереди до только что выполненной задачи, остается на своем месте, а Task_LED1 и Task_LED2 сдвигаются на одну позицию ближе к началу очереди. Task_Signal, как обычно, перемещается в конец очереди.

Шаг 8.

Итак снова готовы к выполнению все три задачи, ожидающие семафор. Но самой важной из них является Task_LED3, она и получит управление, сбросит семафор и изменит состояние своего светодиода.

После выполнения ее важность делается минимальной, а сама задача ставится в конец очереди. Важности задач Task_LED1 и Task_LED2 увеличиваются.

Шаг 9.

На данный момент времени все задачи отработали, а самой важной является та, которая отработала самой первой. И теперь при установке семафора управление вновь получит Task_LED1.

Таким образом, мы видим, что в расширенном приоритетном режиме нет блокированных задач.

Эксперимент 1. Изменение приоритетов

Мы рассмотрели простейший случай, когда все задачи имели одинаковый приоритет и получали управление поровну. Попробуем произвольно изменить приоритеты задач:

    // Создание задач
    OS_Task_Create(3, Task_Signal);  //
    OS_Task_Create(1, Task_LED1);    // Высший приоритет
    OS_Task_Create(3, Task_LED2);    // Средний приоритет
    OS_Task_Create(5, Task_LED3);    // Нисший приоритет

Соберем программу (Ctlr+F10) и прошьем ее в контроллер. Теперь мы видим, что светдиод LED1 мигает быстрее всех, а LED3 - медленнее всех. Это означает, что все задачи получают управление, но те, которые имеют более высокий приоритет, получают его чаще.

Не вдаваясь особо в детали, скажу, что важность увеличивается не на 1, как схематически показано в примере, а на число пропорциональное приоритету. Т.е. Важность задачи Task_LED1 будет расти быстрее, чем у Task_LED2.

Заключение

Итак, мы рассмотрели работу одной программы в трех различных режимах и выяснили, где расширенный приоритет может оказаться полезным. На практике это может выглядеть так: есть несколько задач желающих отправить данные через USART. USART в данном случае является разделяемым ресурсом, доступ к которому блокируется семафором. Если высокоприоритетным задачам всегда есть, что передать, то низкоприоритетные просто никогда не получат управление и, следовательно, никогда не передадут свои данные. И здесь может быть не важна срочность каких-то данных, просто, например, температуру нет смысла передавать чаще, чем раз в секунду, а даные с какого-т оцифрового датчика нужно гнать постоянно. Но это не значит, что температуру вовсе передавать не надо.

Зачем же тогда есть обычный приоритетный режим и, уж тем более, неприоритетный? Не будем забывать про преимущества неприоритетного режима: скорость и компактность - это делает такой режим незаменимым на малоресурсных контроллерах. А также не будем забывать, что несколько задач, ожидающих одно и то же событие, или наличие нескольких постоянно готовых задач (т.е. обе причины недостатков обычного приоритетного режима) - случаи не частые.

Наконец, следует учесть, что расширенны приоритетный режим появился недавно (с версии 101000), и появился он имено на замену обычному приоритетному режиму. Обычный же оставлен, во-первых, для совместимости со старыми версиями, а во-вторых, на те случаи, когда приоритетность нужна, но выделять дополнительно по 2 байта RAM на каждую задачу нет возможности.