Стивен Барретт - Встраиваемые системы. Проектирование приложений на микроконтроллерах семейства 68HC12/HCS12 с применением языка С

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

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

Я провожу много времени в поездках. Однажды я проезжал от Ларами до Форта Коллинз, где должен был подготовить конференцию. На прекрасном и живописном шоссе U.S. 287, мне встретился протяженный участок ремонтируемой дороги. Эта магистраль — асфальтированная дорога с двумя встречными полосами.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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