Встраиваемые системы. Проектирование приложений на микроконтроллерах семейства 68HC12/HCS12 с применением языка С - Стивен Барретт
Шрифт:
Интервал:
Закладка:
}
/* сохранить результаты ATD-преобразования*/
/* в глобальном массиве char */
sens[0] = ADR7H; /*крайний левый датчик */
sens[1] = ADR6H; /*средний левый датчик */
sens[2] = ADR5H; /*центральный датчик */
sens[3] = ADR4H; /*средний правый датчик */
sens[4] = ADR3H; /*крайний правый датчик */
sens[5] = ADR2H; /*Датчик Холла */
code_section = 2; /*update code_section variable */
break;
case 2:
/*анализ информации датчиков для решения о повороте. Примечание: пороги для*/
/*датчика Холла(hes_threshold) и для ИК-датчиков (opto_threshold)являются*/
/* глобальными переменными и определены экспериментально*/
if (sens[5] < hes_threshold) { /*сигнал с датчика Холла, объезд*/
pwm_motors(back_up); /* робот дает задний ход*/
/*действия, следующие после того */
/* как робот отъехал назад */
if (sens[0] > opto_threshold) pwm_motors(right_turn);
else pwm_motors(left_turn);
for (i=0; i<0xFFFF; i++) { /*задержка перед вращением двигателя */
for(j=0; j<15; j++) {
;
}
}
}
/*если обнаружен тупик - задний ход*/
else if ((sens[2]>opto_threshold) && (sens[0]>opto_threshold) && (sens[4]>opto_threshold)) {
pwm_motors(back_up);
}
/*если стенки спереди и слева, */
/*поворот робота направо */
else if((sens[0]>opto_threshold) && (sens[2]>opto_threshold)) {
pwm_motors(right_turn);
}
/*если стенки спереди и справа, */
/*поворот робота налево */
else if((sens[2]>opto_threshold) && (sens[4]>opto_threshold)) {
pwm_motors(left_turn);
}
/*если стенка перед средним правым */
/* датчиком, то полуповорот направо */
else if (sens[1] > opto_threshold) {
pwm_motors(half_right);
}
/*если стенка перед средним левым */
/* датчиком, то полуповорот налево */
else if (sens[3]>opto_threshold) {
pwm_motors(half_left);
}
/*если сигналов от датчиков нет */
/*продолжить движение вперед */
else {
pwm_motors(forward);
}
code_section = 0; /* изменить переменную code_section */
break;
}/*конец switch*/
return code_section;
}
Когда задача, связанная с функцией process_turn, переходит из состояния готовности в активное состояние, ОСРВ вызывает функцию с параметром 0. Функция process_turn затем выполняется до первой отметки прерывания в коде. Достигнув этой отметки, функция возвращает управление ОСРВ, которая модифицирует TCB, связанный с процессом и продолжает выполнение второй части кода, когда задача в очередной раз переходит в активное состояние. Затем задача снова возвращается в состояние готовности и ждет, когда ОСРВ выделит ей процессорное время. Повторим снова, что причина, по которой мы делим код на логические части, состоит в том, чтобы позволить задаче работать до завершения определенной части и затем позволить другой задаче выполнить часть связанного с ней кода, и т.д. Это дает возможность выполнять несколько появившихся задач практически одновременно, хотя в любой момент времени процессор выполняет только одну задачу.
В этом примере мы использовали глобальные переменные, чтобы сохранять информацию между последовательными обращениями к функции process_turn. Использование глобальных переменных может быть не самое лучшее использование дефицитных ресурсов памяти RAM. Далее в этой главе мы рассмотрим альтернативные методы движения информации между задачами.
Как можно предположить из этого примера, ядро ОСРВ должно быть довольно сложным, чтобы позволить следить за множеством задач, эффективно планировать использование процессорного времени и полностью выполнять функции, необходимые для конкретного применения. В следующем разделе мы исследуем составляющие части ядра ОСРВ и их взаимодействие друг с другом, позволяющие удовлетворить требования применения.
8.4.3. Компоненты многозадачных систем
Чтобы выполнить многозадачную операционную систему, разработчик системы (которым являетесь вы) должен рассматривать управление прикладным устройством как группу независимых, но взаимодействующих задач. Каждая задача выполняет ряд связанных с ней действий. Цель многозадачной системы состоит в том, чтобы выполнить требования к прикладному устройству, изменяя задачи, планируя и реализуя их осуществление и решая конфликты, возникающие между различными задачами, из-за использования только одного процессора. Как вы могли уже себе представить, многозадачная система может быть очень сложной. Однако мы разбиваем систему на составные части и исследуем каждую из них отдельно.
Операционная система должна следить за состоянием каждой из управляемых ей задач. Обратимся снова к примеру с автомобильными дилерами, в котором мы использовали списки с указателями, чтобы учесть текущее состояние каждого автомобиля: включение его в партию, предназначенную для продажи, продажу, ремонт, перекраску и т.д.; мы удаляли его из одного списка и добавляли в другой при изменении состояния. ОСРВ также использует подобные методы, чтобы проследить за состоянием каждой задачи.
Обычно ОСРВ позволяет частично выполнять задачу на некотором ограниченном временном промежутке. Когда время, выделенное для задачи истекает, ОСРВ сохраняет текущий контекст задачи в связанном с ней блоке управления TCB. Затем ОСРВ решает, какой из задач предоставить очередную часть процессорного времени. Для принятия этого решения может использоваться ряд алгоритмов планирования. Но какой бы алгоритм планирования не был выбран, он должен удовлетворять основному требованию: каждой задаче должна быть выделена оптимальная доля процессорного времени.
Прежде, чем задача сможет перейти в состояние готовности, ОСРВ должна гарантировать, что ей будут доступны все необходимые ресурсы. Под ресурсами понимаются специфические данные, аппаратные подсистемы и т. д. Например, если задача должна использовать одну из подсистем микроконтроллера 68HC12, ОСРВ должна гарантировать, что этот ресурс доступен для задачи, переходящей в состояние готовности. Задача же, которая ожидает необходимого ресурса, должна быть переведена в состояние ожидания.
Процессор должен также иметь возможность приостановить задачу на некоторое время, чтобы предоставить процессорное время задачам с более низким приоритетом. Если мы не сделаем этого, выполняя все время задачи с самым высоким приоритетом, то ряд задач просто никогда не получит процессорного времени. Чтобы предотвратить эту ситуацию, активные задачи с высоким приоритетом должны временно переводиться в ждущее состояние, чтобы позволить частично выполнить низкоприоритетные задачи, находящиеся в состоянии готовности. Операционная система должна также иметь механизмы, позволяющие выполнять критические задачи с наивысшим приоритетом по мере их появления. Это подразумевает использование прерываний в обработке ОСРВ.
Для выполнения этих действий ядро ОСРВ использует ряд инструментов, включая системные таблицы, отслеживающие состояние задач и диспетчеры/планировщики, исследующие данные системы, чтобы определить, какая из задач должна выполняться в любой момент. ОСРВ также обеспечивает возможность осуществления межзадачных связей, которую мы рассмотрим далее в этой главе.
Системные таблицы. Операционная система используют ряд таблиц/блоков, чтобы проследить состояние задач, устройств ввода–вывода и услуг системы. Мы уже обсудили в общих чертах блок управления задачами TCB в разделе 8.4. Кроме TCB, операционная система также поддерживает управляющий блок устройства (DCB), чтобы отслеживать состояние связанных c системой устройств. Это позволяет операционной системе гарантировать, что все требуемые задачей ресурсы доступны для использования, до того как будет дано разрешение на переход задачи в состояние готовности. В зависимости от числа устройств и ресурсов в системе, DCB может быть введен с помощью простого двумерного массива, который может динамически изменяться при изменении состояния устройства.
Пример: Когда мы наблюдали по телевидению феноменальную игру в гольф Лесного Тигра (Matt Christopher, прим. переводчика), то были заинтригованы тем, как же обслуживающий персонал поля для гольфа способен проследить за состоянием большого числа игроков в гольф (задач) на турнире, чтобы предоставлять им лунки (ресурсы). В процессе передачи, мы увидели большое табло, на котором отслеживалось состояние игроков и лунок. Обслуживающий персонал поля для гольфа мог сообщить состояние данного игрока или лунки. Табло состояния постоянно изменялось в течение турнира. ОСРВ использует тот те же методы (TCB и DCB) чтобы проследить состояние задач, ресурсов и услуг в процессе выполнения программы.
