Читать онлайн «Встраиваемые системы. Проектирование приложений на микроконтроллерах семейства 68HC12/HCS12 с применением языка С». Страница 135

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

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

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

• Запрет на прерывания: Прерывания блокируются, когда задача выполняет критическую часть программного кода. В микроконтроллере 68HC12 это выполняется с помощью команды SEI (установить маскирование прерывания). Как только критическая часть кода закончена, прерывания могут быть снова разрешены командой CLI (очистить маскирование прерывания).

• Использование семафоров или блокировок; семафор или блокировка может использоваться, чтобы указать, что критический ресурс не доступен для использования, потому что это используется в настоящее время другой задачей. Регулировщики с флажками из нашего рассказа как раз и использовали семафоры (знаки «остановиться» и «продолжать осторожное движение») чтобы запрещать или разрешать доступ к критическому ресурсу. Прежде, чем часть программы сможет использовать критическую часть кода, она должна выяснить, доступен ли ресурс.

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

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

• Запрет на прерывания: Прерывания заблокированы при выполнении критических частей некоторой функции.

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

• Использование регистров микропроцессора: регистры микропроцессора могут использоваться, чтобы сохранить критические переменные внутри повторно используемой функции. Если функция прервана, переменные автоматически сохраняются в стеке микропроцессора.

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

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

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

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

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

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

Проблема безопасности — ключевой фактор при решении вопроса: написать ли вам собственную операционную систему или приобрести стандартную.

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

• Применение: Для чего система будет использоваться? Если это используется в системе, где безопасность — критичная проблема, разумно использовать систему, сертифицированную для безопасного использования. Это не подразумевает высокой стоимости. Пакеты ОСРВ для безопасной работы могут быть и дешевыми [Labrosse 2002].

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

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

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

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

1. Полностью понять все системные требования. Определить, действительно ли вам требуется ОСРВ. Если вы разрабатываете простой алгоритм управления, то вас может удовлетворить обычная последовательная программа; ОСРВ необходима только тогда, когда ваша прикладная программа должна управлять целым рядом событий.

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