PIC24 osa:articles

Статьи Виктора Тимофеева

2013-04-09T17:13:53+03:00

Статьи Виктора Тимофеева

"Текстовый VGA-терминал на PIC18"

Рассмотрена возможность применения контроллеров PIC18 для генерации сигналов, управляющих VGA-дисплеем. В качестве примера приведена программа-терминал для отображения текста.

"Пианино" на ОСРВ

В данной статье рассматривается возможность обработки сенсорной клавиатуры с применением АЦП. В качестве примера приведена разработка программы 8-голосого сенсорного 3-октавного Пианино.

"Бегущие огни" на ОСРВ

Здесь подробно рассмотрен пример разработки программы на PIC-контроллере с использованием ОСРВ OSA. Пример очень простой и подойдет даже для начинающего. Правда, требуются навыки программирования на языке Си. В качестве аппаратной базы выбраны демо-платы из комплекта PicKit2 на базе контроллеров PIC16F886, PIC16F887 и PIC16F690.

Программирование микроконтроллеров с использованием ОСРВ OSA

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

Как писать программы без ошибок

Практическое пособие для программистов разработчиков встраиваемых систем с примерами на языке Си.

Язык описания скриптов SCL

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

volatile для "чайников"

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

Как оформлять модули

Краткое пособие по оформлению модулей на языке Си для начинающих.

Как оформлять программы на ассемблере

RTOS: распространенные заблуждения

Шесть распространенных заблуждений о применении RTOS в малоресурсных МК

По просьбам: 5.4 Сторожевой таймер (WDT)

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

Как оформлять модули

2010-07-19T11:14:11+03:00

Как оформлять модули

Скачать в PDF-формате

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

Вступление

Для некоторых программистов, привыкших писать текст программы одним файлом (или включать в Си-файл другие Си-файлы директивой #include), вызывает трудность оформление и подключение независимых модулей, которые были бы изолированны от основной программы и легко переносились бы в другие проекты. Здесь я опишу, как это делается.

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

Содержание основного файла (.c)

//******************************************************************************
//  Секция include: здесь подключается заголовочный файл к модулю
//******************************************************************************
 
#include "new_module.h"      // Включаем файл заголовка для нашего модуля
 
//******************************************************************************
//  Секция определения переменных, используемых в модуле
//******************************************************************************
 
//------------------------------------------------------------------------------
// Глобальные
//------------------------------------------------------------------------------
 
char GlobalVar1;
char GlobalVar2;
...
 
//------------------------------------------------------------------------------
// Локальные
//------------------------------------------------------------------------------
 
static char LocalVar1;
static char LocalVar2;
...
 
//******************************************************************************
//  Секция прототипов локальных функций
//******************************************************************************
 
void local_func1 (void);
void local_func2 (void);
...
 
//******************************************************************************
//  Секция описания функций (сначала глобальных, потом локальных)
//******************************************************************************
 
void global_func1 (void)
{
    ...;
}
 
void global_func1 (void)
{
    ...;
}
 
...
 
void local_func1 (void)
{
    ...;
}
 
void local_func1 (void)
{
    ...;
}
 
...
 
 
//******************************************************************************
//  ENF OF FILE
//******************************************************************************

Описание секций

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

Содержание заголовочного файла (.h)

#ifndef _NEW_MODULE_H        // Блокируем повторное включение этого модуля
#define _NEW_MODULE_H
 
//******************************************************************************
//  Секция include: здесь подключаются заголовочные файлы используемых модулей
//******************************************************************************
 
#include <math.h>
#include <stdio.h>
...
 
 
//******************************************************************************
//  Секция определения констант
//******************************************************************************
 
#define MY_CONST1            1
#define MY_CONST2            2
#define ...
 
//******************************************************************************
//  Секция определения типов
//******************************************************************************
 
typedef struct
{
    ...
} T_STRUCT;
 
typedef ...
 
//******************************************************************************
//  Секция определения глобальных переменных
//******************************************************************************
 
extern char GlobalVar1;
extern char GlobalVar2;
extern ...
 
//******************************************************************************
//  Секция прототипов глобальных функций
//******************************************************************************
 
void global_func1 (void);
void global_func2 (void);
...
 
//******************************************************************************
//  Секция определения макросов
//******************************************************************************
 
#define MACRO1    ...
#define MACRO2    ...
#define ...
 
#endif                       // Закрывающий #endif к блокировке повторного включения
 
//******************************************************************************
//  ENF OF FILE
//******************************************************************************

Описание секций

Блокировка повторного включение этого модуля - один и тот же h-файл может быть включен в несколько модулей, которые также включают заголовочные файлы друг друга. Таким образом получается, что с точки зрения компилятора файл может быть включен в другой файл два или более раз. Тогда бы получалось, что все типы и константы также описаны более одного раза, что вызовет ошибку компилятора (переопределение констант, переопределение типов и т.п.). Чтобы этого не происходило, весь заголовочный файл заключается в скобки #ifndef…#endif. Если компилятор видит, что константа _NEW_MODULE_H не определена, то он включает весь текст файла, в котором, помимо всего прочего, и определяется константа _NEW_MODULE_H. При повторном включении файла компилятор уже видит, что эта константа включена, и все, что заключено в скобки #ifndef…#endif, будет им проигнорировано. (Примечание: имя константы _NEW_MODULE_H должно быть свое для каждого модуля. Для исключения путаницы и возможного повторения имен рекомендуется в качестве имени этой константы брать имя файла в верхнем регистре с суффиксом _H. Ннапример: в файле my_module.h определяем константу _MY_MODULE_H; в файле keyboard.h определяем константу _KEYBOARD_H и т.д.)
Секция include - здесь подключаются заголовочные файлы модулей, используемых нашим модулем.
Секция определения констант - определяются константы, используемые модулем (или определяющие режим работы модуля). Эти константы будут доступны как самому модулю, так и все модулям, включающим этот файл. Если какую-то константу нужно скрыть (например, она используется только в этом модуле, а есть вероятность, что в каком-нибудь стороннем модуле встретится константа с таким же именем), то ее определение можно перенести в основной файл.
Секция определения типов - здесь определяются все специфичные для этого модуля типы данных.
Секция определения глобальных переменных - здесь описываются переменные, которые будут доступны из других модулей. Следует обратить внимание на то, что в заголовочном файле переменные описываются с обязательным квалификатором extern.
Секция прототипов глобальных функций - Здесь описываются прототипы функций, которые будут видны другим модулям, чтобы компилятор знал, с какими параметрами их можно вызывать.
Секция определения макросов - здесь можно описать какие-то присущие модулю макроопределения.

Подключение к проекту

Чтобы включить созданные файлы в свой проект нужно:

В интегрированной среде добавить в проект оба файла (new_module.c и new_module.h). Можно ограничиться только си-файлом, но для удобства работы с рабочей областью (workspace) лучше добавлять оба. (Например, в MPLAB добавление файлов делается через меню: Project/Add Files to Project).
Во всех файлах проекта, в которых предполагается использование функций, типов, переменных, констант или макросов из новых файлов, вставить строчку:

#include "new_module.h"

Примечания

Примечание 1

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

Примечание 2

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

Примечание 3

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

Примечание 4

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

MPASM: как оформлять программы

2011-04-23T20:14:35+03:00

MPASM: как оформлять программы

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

Ноябрь, 2010

MPASM: простые решения для PIC16

Небольшая брошюра, где собраны несколько простых советов для увеличения эффективности кода на ассемблере для PIC16. Материал рассчитан на начинающих программистов.

Статья в pdf-формате

Январь, 2011

Виктор Тимофеев

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

"Бегущие огни" на ОСРВ

2011-01-19T11:39:28+03:00

"Бегущие огни" на ОСРВ

Статья рассматривает простой пример разработки программы на PIC-контроллере с использованием ОСРВ OSA и является пособием по применению ОСРВ¹⁾ в PIC-контроллерах для начинающих. В качестве аппаратной базы выбраны демо-платы из комплектов PicKit2 на базе контроллеров PIC16F886, PIC16F887 и PIC16F690:

DV164120 - PICkit 2 Starter Kit - Программатор PICkit2 + демонстрационная плата с PIC16F690
DV164121 - PICkit™ 2 Debug Express- Программатор PICkit2 + демонстрационная плата с контроллером PIC16F887

Введение

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

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

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

Более подробно об основах операционных систем реального времени можно прочитать здесь:

Тим Уилмсхерст, "Разработка встроенных систем с помощью микроконтроллеров PIC" - в 18-ой главе неплохое описание основ ОСРВ. Книгу можно найти в сети.
Описание ОСРВ Salvo - рекомендую прочитать вторую главу;
ОСРВ jacOS - стоит почитать описание от автора в папке "doc";
Программирование контроллеров с использованием ОСРВ OSA

Здесь мы рассмотрим применение операционной системы реального времени OSA для разработки программы "Бегущие огни". В качестве аппаратной базы будем использовать демо-плату из комплекта PicKit2 с установленным на ней контроллером PIC16F886, PIC16F887 или PIC16F690.

Итак, в нашем распоряжении 4 светодиода (на демо-плате с контроллером 16F887 - 8 светодиодов), кнопка и резистор с переменным сопротивлением. Зададимся задачей сделать программу, управляющую светодиодами так, чтобы:

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

Т.е. у нас получится некая "светодиодная картинка" примерно такого вида:

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

Как регулировать яркость светодиода

Два слова о том, как регулируется яркость светодиода. Есть два способа:

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

Какой из этих способов использовать, разработчик решает, исходя из элементной базы и требований к устройству. В нашем случае будет удобнее использовать второй способ, т.к. у нас в распоряжении только цифровое управление. В качестве источников постоянного тока будут выступать токоограничивающие резисторы в цепях светодиодов. Мы будем управлять яркостью светодиодов, подавая на них импульсы достаточно высокой частоты, чтобы глаз не замечал мигания. Обычно частоту в таких случаях выбирают в пределах 50-200 Гц. Т.е. каждый период длится от 5 до 20 мс. Сама яркость регулируется скважностью импульсов, т.е. отношением длительности периода ко времени импульса (активного состояния "1"). Очевидно, что чем скважность меньше (т.е. импульс длиннее), тем светодиод будет гореть ярче:

tи - время импульса; Т - период.

Каково должно быть разрешение активного состояния, т.е. с каким минимальным шагом может изменяться длительность активного состояния? Понятно, что чем разрешение выше (шаг меньше), тем лучше. И опять же: требования к разрешающей способности управляющего светодиодом сигнала определяются назначением устройства. Если это LED-телевизор, то разрешение как минимум должно быть 8-бит. Если же это гирлянда, или какое-нибудь оформление вывески магазина или витрины (как раз то, для чего можно будет применить нашу программу), то тут хватит 4-5 бит.

Проектирование

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

Задачи

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

формирование 4-х (8-ми для 16F887) ШИМ²⁾ каналов для управления каждым светодиодом; частотой в пределах 50-200 Гц и разрешением 5 бит;
"вращение" - подпрограмма, которая будет вращать "светодиодную картинку" с заданной скоростью;
опрос кнопки;
опрос позиции переменного резистора; другими словами: измерение напряжения на входе АЦП.

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

Данные

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

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

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

const char Brightness[] = {31, 11, 4, 0}; // Таблица яркостей
                                          // (длительностей импульсов)
 
char m_cPosition;       // Текущая фаза вращения (позиция яркости в
                        // таблице Brightness для первого светодиода)
char m_cDirection;      // Направление вращения (-1 или +1)
char m_cSpeed;          // Скорость вращения

Примечание:

префикс "m_" в именах переменных говорит о том, что эти переменные глобальные;
префикс "c" говорит о том, что переменные имеют тип char.

Реализация

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

воспользуемся внутренним тактовым генератором контроллера (8 МГц);
все обрабатываемые светодиоды подключены к выводам одного порта последовательно. Эта особенность позволит работать с ними в цикле;
кнопка имеет активное состояние "0";
напряжение на входе АЦП изменяется в пределах 0..VDD, т.е. для выбора скорости мы можем использовать весь диапазон значений 0..255.

Примечания.

Т.к. это наш первый проект с использованием ОСРВ, то мы постараемся обойтись минимальным набором системных сервисов;
Для лучшей читабельности и упрощения алгоритма работы программы некоторые фрагменты будут написаны несколько развернуто, в ущерб оптимальности.

ШИМ

Итак, нам нужно сформировать 4 (или 8) ШИМ-каналов с частотой 50-200 Гц и разрешением 5 бит. Для этой цели воспользуемся прерыванием по TMR0.

Предлагаю это сделать так:

На рисунке видно, что один период ШИМ будет проходить за 32 периода TMR0 (на картинке обозначен как t0). Т.е. мы должны завести внутреннюю переменную-счетчик, которая будет увеличиваться при каждом такте ШИМ (каждом прерывании от TMR0) и сравниваться со значениями из таблицы Brightness, которую мы описали выше. Пока переменная меньше соответствующего каналу значения таблицы, светодиод горит.

Учитывая тактовую частоту, удобно выбирать значение одного шага ШИМ кратное одному периоду TMR0, т.е. 128 мкс. Но нужно помнить, что обработка 4-х (или 8-ми) каналов ШИМ требует времени, поэтому мы для начала возьмем период побольше, с запасом. Установим прескейлер для таймера 0 равным 4 и получим длительность шага ШИМ ~0.5мс (512 мкс). Т.е. период ШИМ будет равен 32*0.5мс = 16мс, т.е. частота = 62 Гц.

Не будем забывать также, что у нас есть переменные m_cPosition, показывающая текущую фазу вращения (позицию значения яркости из массива Brightness для первого светодиода), и m_cDirection, показывающя направление вращения. Их нужно будет учесть при написании обработчика.

void interrupt isr (void)
{
    // Нам понадобятся локальные переменные для обработки ШИМ
 
    static char cCounter;   // Счетчик шагов ШИМ.
           char cPosition;  // Переменная для обеспечения вращения
           char cLedsMask;  // Маска текущего светодиода
           char i;          // Переменная для организации цикла по
                            // всем ШИМ-каналам
 
    if (T0IF && T0IE)
    {
        T0IF = 0;
        cCounter++;
 
        cPosition = m_cPosition;    // Позиция яркости для первого
                                    // светодиода
 
        i = 4;                      // Цикл по всем светодиодам
        cLedsMask = 0x01;
 
        do
        {
            //-----------------------------------------------------
            // Проверяем, не пора ли гасить светодиод. Для этого
            // сравниваем текущий шаг ШИМ со значением яркости для
            // текущего светодиода
            //-----------------------------------------------------
 
            if (cCounter > Brightness[cPosition & 3])
                   PORTLEDS &= ~cLedsMask;
            else
                   PORTLEDS |=  cLedsMask;
 
            cLedsMask <<= 1;          // Берем следующий светодиод
            cPosition += m_cDirection;// В зависимости от направления
                                      // вращения берем позицию яркости
                                      // для следующего светодиода
        } while (--i);
 
        cCounter &= 0x1F;             // ШИМ 5-разрядный, старшие
                                      // разряды обнуляются
    }   // T0IF
}

Примечание: учитывая специфику подпрограммы-прерывания, компилятор все переменные, объявленные в теле прерывания по умолчанию делает static. Тем не менее, сохраняя смысл эти переменных, мы нарочно поставили квалификатор static только перед cCounter, давая самим себе понять, что нам важно сохранение значения этой переменной после выхода из прерывания. Остальные переменные с точки зрения алгоритма - временные. Такая детализация может оказаться полезной, если код обработки ШИМ впоследствии будет вынесен из прерывания в обычную функцию.

Чтение данных с АЦП: выбор скорости вращения

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

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

В нашей программе есть переменная m_cSpeed, которая определяет скорость вращения картинки. Эту переменную мы и будем формировать в данной задаче. Очевидно, что частота обновления этой переменной должна быть пропорциональна скорости изменения напряжения на входе АЦП. Медленнее делать нельзя, т.к. пользователю нужно сразу видеть, как меняется скорость при повороте потенциометра. Быстрее - нет смысла, т.к. на глаз разница не будет заметна, а система окажется перегружена слишком частыми запусками этой задачи. Поэтому мы выберем интервал обновления, равный 100 мс. Т.е. сделаем так, чтобы задача запускалась раз в 100 мс, измеряла напряжение на входе АЦП и формировала новое значение переменной m_cSpeed. Все остальное время задача будет находиться в ожидании и не будет мешать выполняться остальным задачам.

void Task_SetSpeed (void)
{
    for (;;)
    {
        CHS0 = 0;          // Выбираем нулевой канал АЦП. В принципе,
        CHS1 = 0;          // не очень нужный код, но если впоследствии
        CHS2 = 0;          // в программу будет добавлена обработка АЦП
        CHS3 = 0;          // по другим каналам, то этот код окажется
                           // очень полезным
 
        GODONE = 1;            // Запуск измерения
 
        OS_Cond_Wait(!GODONE); // Ожидание завершения измерения.
                               // Во время ожидания могут выполняться
                               // другие задачи
 
        m_cSpeed = ADRESH;     // Установка нового значения скорости
 
        OS_Delay(100 ms);      // Говорим ОС, что следующий раз эту
                               // задачунадо запустить через 100 мс.
    }
}

Примечание: ms - макрос, определенный как "/ 1". Подробнее о нем - в параграфе "Таймер".

Здесь мы использовали два системных сервиса: OS_Cond_Wait и OS_Delay. Остановимся на них и рассмотрим, как они работают.

Сервис OS_Cond_Wait - это сервис, который переводит задачу в режим ожидания до тех пор, пока не будет выполнено условие в скобках. Что такое режим ожидания? Как уже было сказано ОС имеет встроенный механизм обеспечения многозадачности, что позволяет всем задачам выполняться параллельно (т.е., конечно, они выполняются последовательно, но быстро сменяют друг друга, что создает эффект параллельности). Если какая-то задача ждет выполнения какого-то условия, то ее нет смысла запускать, пока условие не выполнено. Это позволит системе больше внимания уделять остальным задачам. Сервис OS_Cond_Wait сообщает системе, что эту задачу не нужно запускать, пока условие !GODONE не будет выполнено. Одновременно с этим этот сервис осуществляет выход из функции-задачи (с запоминанием точки выхода), после чего управление передается планировщику ОС. Когда планировщик обнаружит, что бит GODONE сброшен, он переводит задачу в режим готовности - задача становится в очередь выполняемых задач и получит управление, когда до нее дойдет очередь, причем она продолжит свое выполнение с того места, откуда был совершен выход, т.е. сразу же за сервисом OS_Cond_Wait.

Сервис OS_Delay - это сервис, который переводит задачу в режим ожидания на указанное время. Управление передается планировщику. В течение указанного времени задача не будет получать управление, позволяя системе больше времени уделять остальным задачам. Время задается в так называемых системных тиках - периодах вызова системного сервиса OS_Timer. Подробнее см. параграф "Таймер".

Вращение с заданной скоростью

Эта задача должна выдерживать паузу в соответствии с установленным значением переменной m_cSpeed, после чего увеличивает значение переменной m_cPosition (позиция элемента яркости в массиве Brightness для первого светодиода). Напрашивается красивое использование сервиса OS_Delay:

    OS_Delay(m_cSpeed);

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

void Task_Rolling (void)
{
    static char cDelay;
 
    for (;;)
    {
        cDelay = 0;
        while (cDelay++ < m_cSpeed)      // Ждем нужное время
            OS_Delay(1);
 
        m_cPosition ++;                  // Изменяем позицию яркости
    }
}

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

Обратим внимание на объявление переменной cDelay. Эта переменная объявлена как static, т.к. нам важно сохранение ее значения после выхода из функции. Если мы не напишем static, то после выхода из функции эта переменная может затереться локальными переменными других функций.

Опрос кнопки: выбор направления вращения

Еще одна простая задача, функцией которой является изменение направления вращение при нажатии кнопки. Т.к. кнопка имеет активный уровень "0", то сперва мы ждем установки входа на ножке pin_BUTTON в "0". После того, как дождались нам нужно подавить дребезг, чтобы исключить ложные срабатывания. Для этого мы будем выжидать 40 мс и делать повторную проверку. Если состояние входа так и останется в "0", значит, кнопка нажата и можно продолжать работать. Если нет, то делаем повторное ожидание. После обработки кнопки мы таким же способом ждем отпускание кнопки.

void Task_Button (void)
{
    for (;;)
    {
        //------------------------------------------------------------
        //  Ожидаем нажатие кнопки
        //------------------------------------------------------------
        do
        {
            OS_Cond_Wait(!pin_BUTTON);
            OS_Delay(40 ms);      // Для подавления дребезга контактов
                                  // ждем 40 мс и делаем повторную
        } while (pin_BUTTON);     // проверку
 
        //------------------------------------------------------------
        //  Меняем направление вращения на противоположное
        //------------------------------------------------------------
        //
        m_cDirection = -m_cDirection;
 
        //------------------------------------------------------------
        //  Ожидаем отпускание кнопки
        //------------------------------------------------------------
        do
        {
            OS_Cond_Wait(!pin_BUTTON);
            OS_Delay(40 ms);      // Для подавления дребезга контактов
                                  // ждем 40 мс и делаем повторную
        } while (!pin_BUTTON);    // проверку
 
    }
}

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

Функция main()

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

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

Теперь отсталость только добавить инициализацию контроллера и системы. И все: можно запускать планировщик в работу.

void main (void)
{
    char prs;
 
    Init();                // Инициализация периферии
 
    OS_Init();             // Инициализация операционной системы
 
    //----------------------------------------------------------------
    // Создаем функции-задачи, которые будут работать
    // параллельно. В нашем случае все имеют одинаковый
    // высший приоритет (0)
    //----------------------------------------------------------------
 
    OS_Task_Create(0, Task_Rolling);
    OS_Task_Create(0, Task_SetSpeed);
    OS_Task_Create(0, Task_Button);
 
                           // Начальные значения:
    m_cPosition  = 0;      // для фазы вращения
    m_cDirection = 1;      // для направления вращения
 
    OS_EI();               // Разрешаем прерывания
 
    OS_Run();              // Запускаем планировщик в работу.
 
}

Помимо OS_Task_Create, мы тут встречаем еще три сервиса ОС: OS_Init, OS_EI и OS_Run.

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

OS_EI - разрешение прерываний. Можно было бы просто воспользоваться строчкой "GIE = 1;", но тогда, если мы когда-нибудь захотим перевести программу на PIC 18-ой серии, то нам придется вспомнить, что там два уровня прерываний и что, возможно, нужно добавить еще и разрешение GIEL. Этот же сервис все делает автоматически.

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

Функция Init()

Весь текст я здесь приводить не буду (его можно посмотреть в исходных текстах, прилагаемых к статье), т.к. из-за того, что эта функция предусматривает работу на 4-х разных контроллерах (16F886, 16F887, 16F690 и, "по совету друзей", 16F88), то код ее довольно громоздкий из-за наличия условных директив #ifdef…#endif.

Скажу только, что в этой функции производится инициализация:

потов ввода/вывода;
АЦП;
таймеров;
прерываний.

Таймер

Последнее, что нам осталось сделать, - это добавить обработку системного таймера. Т.к. у нас в программе вызываются системные сервисы, использующие системный таймер, то нам нужно в периодическое место в программе добавить вызов сервиса OS_Timer. Этот сервис будет следить за всеми задержками, выполняющимися через OS_Delay. Теперь нам нужно организовать периодическое место в программе, т.е. то место, куда программа будет попадать с заданным интервалом. У нас, в принципе, такое место уже есть - это прерывание по TMR0. Но мы для сохранения наглядности не будем его трогать, а организуем прерывание по таймеру TMR2. Кроме наглядности, здесь есть еще одно преимущество: мы можем отдельно изменять скорость работы ШИМ и интервал вызовов OS_Timer, если понадобится.

В подпрограмму обработки прерываний добавляем такой код:

    if (TMR2IF)
    {
        TMR2IF = 0;
        OS_Timer();
    }

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

Я не случайно упомянул возможность появления необходимости изменения интервала вызова системного таймера. Причины могут быть разные, ну, например, мы используем контроллер, имеющий на борту всего один таймер, и нам, хочешь - не хочешь, придется использовать один таймер и для генерации ШИМ-сигналов и для системного таймера. А тут может понадобиться некоторая настройка периода ШИМ. Получается, что каждый раз, меняя период прерывания (и, следовательно, - период вызова OS_Timer), нужно будет пересчитывать все константы в параметрах вызовов сервиса OS_Delay? Вот тут нам на помощь придет константа ms, о которой речь шла выше. В нашем случае эта константа определена так:

#define ms    / 1

, т.к. период таймера 2 у нас равен 1 мс. Во всех вызовах сервиса OS_Delay мы пользуемся этой константой:

    OS_Delay(100 ms);   // Компилятор сделает подстановку "100 / 1"
    ...
    OS_Delay(20 ms);    // Компилятор сделает подстановку "20 / 1"

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

#define ms    / 3

или мы уменьшили период вдвое:

#define ms    * 2

Конфигурация OSA

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

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

Все эти настройки программист указывает в файле OSAcfg.h, который должен быть расположен в папке проекта. Для каждого проекта - свой файл. Подробнее обо всех настройках можно почитать в описании OSA в параграфе Конфигурация OSAcfg.H. Создавать и сопровождать этот файл вручную довольно сложно из-за большого количества различных определений, и это могут делать только имеющие опыт работы с OSA программисты. Удобнее для конфигурирования воспользоваться утилитой из комплекта поставки OSAcfg_Tool.

Запустив эту утилиту, мы увидим на экране все настройки, которые можно сделать при конфигурировании проекта. Итак, займемся созданием файла конфигурации для нашего проекта.

1. Выбираем папку, где располагается наш проект

Для этого в самом верху окна справа нажимаем кнопку Browse. Там выбираем путь к файлу OSAcfg.h - путь к нашему проекту ("C:\TEST\PICKIT2\LIGHTS"). Нажимаем OK. Если файл еще не создан, то программа спросит у Вас, действительно ли Вы хотите создать этот файл. Смело отвечаем "Yes" и идем дальше. (Если файл уже существует, то он просто загрузится и установит в рабочем окне все галочки и параметры в соответствие со своей конфигурацией. Пока же мы считаем, что файл не создан.)

2. Выбираем имя проекта

В поле Name можно ввести имя проекта. Этот пункт необязателен, а имя вводится исключительно для наглядности, чтобы не путаться потом, какой файл от какого проекта. Мы введем в эту строку "Бегущие огни".

3. Выбираем платформу

Также необязательный пункт. Служит только для того, чтобы пользователь при конфигурировании файла в реальном времени наблюдал предполагаемый расход оперативной памяти операционной системой. Для успокоения выберем платформу: 14-бит (PIC12, PIC16)(ht-picc). Теперь при изменении настроек мы автоматически в рамке RAM statistic будем видеть, сколько байтов в каком банке памяти израсходовано.

4. Конфигурируем наш проект

Для этого есть 4 области в рабочем окне:

System - системные настройки
Data services - настройки сервисов обмена данными (счетные семафоры, сообщения, очереди сообщений)
Timers - все настройки относящиеся к таймерам
Binary semaphores - настройка двоичных семафоров

Нам понадобятся только System и Timers, т.к. сервисы обмена данными (включая бинарные семафоры) мы не используем.

Учитывая, что мы решили не использовать приоритеты (т.е. все задачи сделать равноприоритетными), можно установить галочку напротив пункта Disable priority. Это сократит размер кода ядра операционной системы и ускорит работу планировщика.

Далее, нам обязательно нужно выбрать количество задач ОС, которые будут работать одновременно. В нашем случае - 3 (по количеству задач, создаваемых сервисом OS_Task_Create; как уже было сказано раньше, 4-я задача у нас не является задачей ОС и располагается в обработчике прерывания).

Последнее, что нам понадобится, - это включить таймер задач, т.е. поставить галочку напротив пункта Task timers.

5. Сохраняем и выходим

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

/////////////////////////////////////////////////////////
//
// This file was generated by OSAcfg_Tool utility.
// Do not modify it to prevent data loss on next editing.
//
// PROJECT NAME: Бегущие огни
// PLATFORM: HT-PICC 14-bit
//
/////////////////////////////////////////////////////////
 
 
#ifndef _OSACFG_H
#define _OSACFG_H
 
#define OS_TASKS               3
#define OS_DISABLE_PRIORITY
#define OS_ENABLE_TTIMERS
 
#endif

Прошивка контроллера

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

Сборка проекта

Для работы с проектом нам нужно иметь установленную интегрированную среду MPLAB IDE, установленный компилятор HI-TECH PICC STD (PRO-версия не подойдет).

Скачиваем, если еще не скачали, файлы операционной системы OSA, распаковываем этот архив на диск C: (должна получиться папка C:\OSA).

Распаковываем файл lights.rar в папку C:\TEST\PICKIT2. При этом внутри создастся папка LIGHTS. В MPLAB IDE открываем проект, в названии которого присутствует номер контроллера, который Вы собираетесь использовать: 886, 887, 690 или 88. Например, для демо-платы на базе 16F887 нам нужно открыть файл pk2_lights_887.mcp.

Примечание. При распаковке в другую папку, отличную от C:\TEST\PICKIT2\LIGHTS, нужно будет через меню Project\Build options…\Project в закладке Directories в списке include-путей заменить путь к файлам проекта на тот, куда Вы распаковали файлы из архива.

Выполняем сборку нажатием Ctrl+F10.

Прошивка

Здесь все просто:

подключаем программатор;
в меню "Programmer\Select" programmer выбираем PicKit2;
В настройках "Programmer→Settings" выбираем «3-State on «Release from Reset»
запускаем программирование "Programmer\Program";
освобождаем вывод MCLR "Programmer\Release from reset".

Вот и все!

Заключение

Итак, в данной статье была приведена демонстрация применения операционной системы реального времени OSA для написания программы "Бегущие огни". Меньше чем за час мы спроектировали и написали программу, которая выполняет заданную задачу. При этом текст программы получился наглядным и легко читаемым.

Что хорошего мы извлекли из использования OSA:

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

Получившаяся программа может найти практическое применение, например, при оформлении вывески магазина. Для этого достаточно будет всего лишь применить кое-какие схемотехнические решения: в каждую цепь поставить не по одному светодиоду, а по несколько. Чередуя их четверками (или восьмерками, если программа для 16F887), т.е. сначала диод из первой цепи, затем из второй, потом из третей, дальше из четвертой, за ним - снова из первой, потом из второй и т.д., можно сделать длинную "гирлянду", которой оформить вывеску, витрину, объявление.

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

Спасибо за внимание.

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

¹⁾ ОСРВ - операционная система реального времени

²⁾ ШИМ - Широтно-Импульсная Модуляция

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

Сенсорное пианино

2010-05-30T17:55:41+03:00

Сенсорное пианино

Введение

В данной статье рассматривается возможность обработки сенсорной клавиатуры с применением АЦП. В качестве примера разработаем программу "Пианино", обрабатывающую 36 сенсорных кнопок (3 октавы). Для интереса сделаем его многоголосым. В качестве аппаратной базы будем использовать демо-платы из набора pickit2 на базе контроллеров PIC16F690, PIC16F887 или PIC16F886. Программа будет работать под управлением ОСРВ OSA (прим.: ОСРВ - Операционная Система Реального Времени).

Здесь 2-х минутное видео с демонстрацией того, что описывается в примере (пианист из меня, конечно, никакой).

Видео HQ (34 Mb)

Видео LQ (6.3 Mb)

Немного теории

Сенсорные кнопки

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

Два конденсатора с емкостями C1 и C2 (C1 < C2) одновременно начали заряжать одинаковым током. На графике видно, что в момент времени t0 напряжение на конденсаторе C1 успело вырасти больше, чем на C2. Итак, мы знаем, что при касании металлической пластины (емкостного датчика) пальцем, мы добавляем в схему емкость. Если мы будем периодически заряжать/разряжать конденсатор емкостного датчика и измерять напряжение на его обкладках через одно и то же время после начала заряда (t0), то мы будем получать всегда одно и то же значение (оно будет меняться от измерения к измерению, но в малых пределах). Если же мы коснемся емкостного датчика пальцем, то его емкость возрастет, и при измерении напряжения через время t0 мы обнаружим, что его значение немного меньше обычного.

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

Практическая реализация

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

Теперь нам нужен источник тока. В идеале хотелось бы иметь источник постоянного тока (в контроллерах PIC24FJ256GA110 и PIC24FJ256GB106 со встроенным модулем CTMU делается именно так, т.е. заряд конденсатора в емкостном датчике производится постоянным током). При малом количестве кнопок можно было сделать именно так. Но у нас много кнопок (36), и такое решение было бы громоздким. Можно ли обойтись без источника постоянного тока? Можно ли использовать RC-цепочку для заряда конденсатора емкостного датчика? Рассмотрим рисунок:

Конденсаторы C1 и C2 (C1 < C2) стоят в RC-цепочках с одинаковыми значениями сопротивлений резисторов. Очевидно, что конденсатор C1 будет заряжаться быстрее, чем C2. И хоть графики заряда и нелинейные, мы все равно четко сможем определить, в каком случае емкость больше, т.к. через одинаковое время напряжения на конденсаторах будут разные. Для этого мы определим некий "порог срабатывания", заданный значением напряжения Uп. Так что мы можем позволить себе сделать допуск и вместо источника тока воспользоваться RC-цепочкой.

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

Наконец, последнее, что нам нужно сделать, - это измерение напряжения. Тут мы воспользуемся встроенным в контроллер АЦП. Рассмотрим рисунок:

Справа схема управления емкостным датчиком. Контроллер устанавливает выход DOUT в "1", чтобы начать заряжать конденсатор через задающий резистор. На входе AIN производится измерение напряжения. Чтобы конденсатор был всегда гарантированно разряжен, вывод контроллера AIN почти всегда настроен как цифровой выход, установленный в "0". Для снижения энергопотребления, чтобы, пока нет измерения, через резистор не тек ток, выход DOUT тоже устанавливается в "0". Когда нужно произвести измерение емкости конденсатора, мы делаем следующую последовательность действий:

Начинаем измерение в точке t. До этого момента напряжение на конденсаторе = 0, т.к. AIN настроена как цифровой выход, установленный в "0".
В момент времени t устанавливаем DOUT в "1", а AIN настраиваем как аналоговый вход.
Выдерживаем паузу до точки t0, чтобы дать конденсатору немного зарядиться.
В момент времени t0 начинаем АЦ-преобразование установкой бита GODONE. При этом внутри контроллера происходит "защелкивание" напряжения на внутреннем конденсаторе удержания Chold (график напряжения на нем показан серым цветом; скорость заряда Chold будет всегда чуть ниже из-за наличия последовательного сопротивления внутри контроллера).
В момент t1, когда преобразование закончено, устанавливаем вывод AIN на выход и записываем в него "0", чтобы разрядить конденсатор.
После этого вывод DOUT возвращается в "0".

В результате для подключения одной кнопки мы имеем следующую схему:

В качестве емкостного датчика выступает монета. Пока мы ее не трогаем пальцем, мы будем производить измерение емкости Cp, являющейся суммой паразитной емкости входа AIN, емкости между монетой и землей, емкостью между проводниками на плате (или проводами, подводящими монеты к плате). Когда мы касаемся монеты пальцем, мы добавляем еще емкость Ch (human), в результате чего измеряемая емкость увеличивается.

Много кнопок

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

Но так мы получим максимум столько кнопок, сколько АЦП имеется на борту нашего контроллера (например, 12 у PIC16F690). А нам бы хотелось еще больше, т.к. пианино с одной октавой будет выглядеть довольно ущербно. Хотелось бы хотя бы 3 октавы (можно сделать и больше, но пока остановимся на трех). Нам нужно модифицировать схему так, чтобы один АЦП-вход имел возможность измерять напряжение на нескольких кнопках. Как же это сделать? Ответ прост: ставить разделяющие диоды.

Из рисунка видно, что, управляя цифровыми выходами DOUT1 и DOUT2, мы сможем входом AIN измерять отдельно емкость то одного, то другого емкостного датчика. Таким образом, на один аналоговый вход мы можем завести столько кнопок, сколько захотим. Ограничены мы лишь тем, сколько выводов контроллера мы сможем использовать как управляющие выходы DOUT. Комбинируя аналоговые входы и цифровые выходы, мы строим матрицу сенсорных кнопок. Очевидно, что сколько бы мы не выделили выводов под клавиатуру, максимальное количество кнопок получится, если количество аналоговых входов будет равно (или на 1 отличаться, если у нас нечетное количество выводов) количеству цифровых выходов. В рассмотренном примере "Пианино" для управления клавиатурой выделено 12 выводов, из них 6 - аналоговые входы и 6 - цифровые выходы. Получается матрица 6х6 = 36 кнопок.

В результате получаем следующую схему включения кнопок:

Примечание

Хоть описанный подход и был успешно реализован для обработки клавиатуры из 36 кнопок, он не лишен недостатков, которые следует предусматривать при проектировании устройства с использованием данного подхода.

Температурный дрейф RC-цепочки

Сопротивление резистора в цепи емкостного датчика изменяется при изменении температуры. Так же меняется емкость внутреннего удерживающего конденсатора АЦП контроллера (Chold). Это приводит к тому, что крутизна графика зарядки емкостного датчика будет меняться с изменением температуры окружающей среды.

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

Наводки при прикосновении

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

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

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

Паразитная емкость на входах

Все входы контроллера обладают некоей паразитной емкостью, которая также принимает участие в работе нашей RC-цепочки. Эта емкость - единицы пикофарад, однако в нашем случае ее влияние будет ощутимо. Проблема в том, что разные выводы контроллера имеют различные схемотехнические особенности: у них разная периферия, некоторые выводы имеют встроенный МОП-транзистор для обеспечения pull-up подтяжки (он даже в отключенном состоянии внесет свою толику в паразитную емкость) и т.п. Поэтому в программе следует предусмотреть то, что порог срабатывания на разных АЦП-входах будет различным.

Генерация звука

Генерация низкочастотным меандром

Самый распространенный способ генерации звука во встраиваемых системах - генерация меандра частоты, соответствующей частоте самого звука. Например, для генерации тона 1 КГц, мы формируем на выводе контроллера прямоугольный меандр частотой 1 КГц. В большинстве случаев такого способа вывода звука достаточно. Например, микроволновка сообщает нам, что разогрев окончен; брелок автомобильной сигнализации проигрывает мелодию при постановке/снятии с охраны; холодильник предупреждает нас, что мы забыли закрыть дверь и т.д.

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

Генерация с помощью ЦАП

Т.к. у PIC-контроллеров нет встроенного ЦАП-модуля, мы можем воспользоваться модулем ШИМ, работающим на высокой частоте. С его помощью мы сможем сгенерировать сигнал практически любой формы в заданном частотном диапазоне (частотный диапазон будет ограничен сверху в основном за счет частоты семплирования, об этом - ниже).

Генерация одноканального сигнала

Рассмотрим генерацию сигнала прямоугольной формы с помощью ШИМ.

Когда мы генерируем "1", скважность импульсов ШИМ = 1 (на рисунке взята скважность чуть больше для наглядности, чтобы было видно, что частота ШИМ выше частоты генерируемого сигнала). Когда мы генерируем "0", скважность импульсов ШИМ максимальна (в идеале скважность равна бесконечности, т.е. импульсы отсутствуют, но на рисунке, опять же, для наглядности изображены просто импульсы большой скважности).

Пропустив цифровой сигнал с выхода ШИМ-модулятора через НЧ-фильтр, мы получим сигнал "прямоугольной формы" - зеленый график (в реальности он будет больше похож на прямоугольный, поскольку частота ШИМ гораздо выше приведенной на графике; по этой же причине пульсации будут гораздо меньше). В качестве НЧ-фильтра в самом простом случае может выступать RC-цепочка.

Генерация двухканального сигнала

Теперь перед нами стоит задача сгенерировать сразу два прямоугольных сигнала различной частоты, наложенных друг на друга. Когда мы генерировали один прямоугольный сигнал, мы приняли единичное состояние за максимальное значение (скважность импульсов ШИМ = 1), а нулевое - за минимальное (скважность = бесконечности). Но теперь нам нужно сгенерировать сигнал, равный сумме двух меандров, и за максимальное значение будет принято максимально возможное при таком суммировании, то есть то состояние, при котором и первый и второй сигналы находятся в "1". На рисунке схематически приведен пример использования ШИМ для генерации сразу двух меандров разной частоты.

На рисунке видно, что на тех участках, где "1" установлена только на одном из каналов, напряжение на выходе фильтра равно половине напряжения питания (скважность импульсов ШИМ-сигнала на этих участках равна двум).

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

Генерация синуса

Генерация синусоидального сигнала, по сути, не отличается от генерации, описанной в предыдущем параграфе. Из графика синуса мы делаем точечные выборки с частотой, равной частоте ШИМ, и устанавливаем скважность текущего импульса соответствующей текущей точке выборки. Например, если мы взяли точку в самом пике синусоиды, то скважность будет равна 1; если мы взяли точку в середине периода (соответствующую 180 градусам), то скважность импульсов ШИМ-сигнала будет равна 2; если точка соответствует 45 градусам, то скважность будет равна (1 + 2^-2) ~ 2.41. Ниже приведен рисунок, показывающий генерацию синусоидального сигнала с помощью высокочастотной ШИМ:

Ну и, само собой, теперь для нас не проблема сформировать сигнал, являющийся суммой двух синусоид:

трех синусоид, пяти синусоид, двух синусоид и трех прямоугольников и т.д.

На этом введение в теорию закончим и приступим к реализации задуманного.

Проектирование программы

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

Звук мы будет выводить через аппаратный ШИМ на максимально возможной частоте при разрешении 8 бит. При тактовой частоте контроллера, равной 20 МГц, максимальная частота 8-разрядного ШИМ будет 78 КГц. Частоту семплирования синтезатора выберем равной 20 КГц (хотелось бы выше, но 8 каналов звука быстрее не обработать).

Задачи

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

Опрос клавиатуры - в этой задаче мы будем опрашивать 36 кнопок сенсорной клавиатуры по приведенной выше методике;
Генерация звука (синтезатор) - формирование скважности импульсов ШИМ в соответствие с нажатыми клавишами и выбранным инструментом.
Опрос кнопки - здесь будем ждать нажатия кнопки, и когда она будет нажата, будем выбирать новый музыкальный инструмент для синтезатора.

Задача генерации звука критична ко времени выполнения, т.к. у нас частота семплирования (т.е. изменения скважности ШИМ-сигнала) 20 КГц, то на один период выполнения задачи у нас максимум 50 мкс или 250 тактов (на самом деле еще меньше, т.к. нам нужно успевать и другие задачи обрабатывать). Есть смысл разбить эту задачу на две:

первая будет заниматься исключительно формированием ШИМ-сигнала и будет помещена в прерывание (к ней и будет относиться требование уместиться в 250 тактов);
вторая будет работать в фоновом режиме как обычная задача ОСРВ и будет заниматься формированием целеуказаний для первой в соответствие с нажатыми клавишами.

Опрос клавиатуры и опрос кнопки мы оформим в виде задач ОСРВ, т.к. они некритичны к скорости.

Итак, у нас получились 3 ОСРВ-задачи: "клавиатура", "кнопка" и "формирователь звуковых переменных" - и одна не ОСРВ-задача - "синтезатор", - которая будет помещена в прерывание.

"Клавиатура"

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

"Кнопка"

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

"формирователь данных для синтезатора"

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

"Синтезатор"

Для синтезирования звука в программе записан оцифрованный период звуковой волны (64 точки) в виде массива. Когда нужно генерировать звук, "синтезатор" при каждом запуске (1 раз в 50 мкс) выбирает из массива очередное значение и на основании него формирует скважность импульса для ШИМ-генератора. Массив оцифрованных значений звуковой волны рассматривается "синтезатором" как кольцевой, т.е. как бесконечный синус. Чем выше частота ноты, которую нам нужно синтезировать, тем с большим шагом выбираются значения из таблицы.

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

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

Данные

Здесь ответим себе на два вопроса:

Какими данными будет оперировать наша программа?
Какими данными и как будут обмениваться задачи?

Для клавиатуры

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

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

Все эти данные будут сведены в структуру:

struct
{
    unsigned char   Data[KBD_SIZE];         // Массив битов: 1 - кнопка нажата.
    unsigned char   cDataPos;               // Две переменные - указатель
    unsigned char   cDataMask;              // бита при приеме.
    unsigned char   Porogs[KBD_COLUMNS];    // Массив пороговых значений для
                                            // определения, нажата ли кнопка
} KBD;

Примечание. Мы предусмотрительно пользуемся константами KBD_SIZE (=36) и KBD_COLUMNS (=6), оставляя себе возможность минимальными силами увеличить или сократить количество клавиш.

Теперь, мы должны помнить, программа "Пианино" проектируется для разных контроллеров, а у разных контроллеров будут использованы разные выводы для матрицы клавиатуры. Поэтому нам нужно предусмотреть какой-нибудь удобный способ адресации этих выводов. Предположим, что в матрице в столбцах указываются аналоговые входы, а в строках - управляющие выходы. Рассмотрим, какие данные нам нужны для описания строк и столбцов. Со строками (управляющими выходами) все просто: нужны только адрес порта и маска бита в порту, по которой соответствующий вывод будет устанавливаться либо в "1", либо в "0". Со столбцами (аналоговыми входами), учитывая нашу методику, немного сложнее: нам нужен, во-первых, номер АЦП-канала, во-вторых, указатели на PORT и TRIS регистры, поскольку нам придется управлять и тем и другим, и, наконец, в-третьих, - маска бита в порту. Таким образом, мы формируем две структуры для шаблонов:

typedef struct          // Тип для задания аналогового входа
{                       //
    char  cADCChannel;  // Номер аналогового канала
    char *pPort;        // Указатель на регистр PORT
    char *pTris;        // Указатель на регистр направления
    char  cMask;        // Маска бита в порту
} TColumn;
 
typedef struct          // Тип для управляющего выхода
{                       //
    char *pPort;        // Указатель на регистр PORT
    char  cMask;        // Маска бита в порту
} TRow;

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

Примечание. Учитывая, что обе переменные из типа TRow присутствуют в типе TColumn, можно было бы обойтись одним типом, просто для строк поля cADCChannel и pTris заполнять нулями, но для строгости мы будем использовать различные типы.

Для синтезатора

Синтезатору для работы потребуется массив значений оцифрованных периодов синусоид для различных инструментов. Эти массивы будут храниться в программной памяти в виде констант (см. файл sinus.c). Т.к. скорость работы самого синтезатора хотелось бы максимально увеличить, то воспользуемся той особенностью, что обращение к массиву в RAM происходит быстрее, чем обращение к массиву в ROM. Поэтому для работы с массивом значений оцифрованного периода данные для текущего инструмента мы будем копировать в RAM. Т.е. нам нужно зарезервировать в RAM-памяти массив для этих целей:

char Sample[64];

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

static char s_cCurSample;

Теперь, синтезатор должен знать, какой канал "молчит", а по какому воспроизводится звук, причем ему нужно указать и частоту звука, и текущую фазу. Итак, у нас получается структура:

typedef struct          // Для переменных управления звуком
{
    unsigned int F;     // Частота
    unsigned int f;     // Фаза
    unsigned char key;  // Клавиша, которая проигрывается в данный момент. (0 - молчит)
} TSound;

Реализация

Кнопка

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

void Task_Button (void)
{
    static char s_cCurSample;
 
    s_cCurSample = 0;
 
    CopySample(s_cCurSample);
    for (;;)
    {
        //------------------------------------------------------------------------------
        //  Ожидаем нажатия на кнопку (с устранением дребезга)
        //------------------------------------------------------------------------------
 
        do
        {
            OS_Cond_Wait(!pin_BUTTON);
            OS_Stimer_Delay(ST_BUTTON, 40 ms);
        } while (pin_BUTTON);
 
        //------------------------------------------------------------------------------
        //  Изменяем номер инструмента и копируем данные об инструменте в
        //  массив Sample
        //------------------------------------------------------------------------------
 
        s_cCurSample++;
        s_cCurSample &= 3;
        CopySample(s_cCurSample);
 
        //------------------------------------------------------------------------------
        //  Ждем отпускания кнопки
        //------------------------------------------------------------------------------
 
        do
        {
            OS_Cond_Wait(pin_BUTTON);
            OS_Stimer_Delay(ST_BUTTON, 40 ms);
        } while (!pin_BUTTON);
 
 
    }
}

Обратим внимание на то, что для формирования задержек используется не таймер задач (т.е. не сервис OS_Delay), а статический таймер. Это связано с тем, что код синтезатора, находящийся в прерывании вместе с системным обработчиком таймеров, может долго выполняться, когда активны все 8 каналов. И так как нам гарантированно нужно вместиться в 50 мкс (250 тактов), то любое ускорение кода приветствуется. В данном случае для ускорения применены статические таймеры. Дело тут не в том, что инкремент статического таймера производится быстрее, чем таймера задачи, а в том, что таймеры нужны только двум задачам из трех активных. И избавляясь от обработки одного неиспользуемого таймера, мы выигрываем драгоценные такты.

Переменная s_cCurSample описана как static, т.к. нам важно сохранение ее значения после переключения на другие задачи. Функция CopySample просто копирует массив из ROM-памяти в массив Sample:

void CopySample (char c)
{
    char n;
    c &= 3;
    for (n = 0; n < 64; n++) Sample[n] = SAMPLES[c][n];
}

Клавиатура

Задача чтения состояния клавиатуры каждые 10 мс опрашивает все 6 строк с кнопками. Перед первым опросом обнуляются все значения порогов для всех столбцов (аналоговых входов). Подпрограмма чтения строки проверяет эти переменные и, если они нулевые, сохраняет туда считанные с аналоговых входов значения за вычетом 15% барьера.

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

void Task_Keyboard (void)
{
    static char n;
    static char s_cChanged;
 
    //------------------------------------------------------------------------------
    //  Один раз выполняем чтение, чтобы точно быть уверенными в том, что все
    //  TRIS'ы аналоговых входов установлены в "0" (на выход) для разряда
    //  конденсаторов
    //------------------------------------------------------------------------------
 
    ReadRow(0);
 
    //------------------------------------------------------------------------------
    //  При первом запуске все пороги устанавливаем в 0
    //------------------------------------------------------------------------------
 
    for (n = 0; n < KBD_COLUMNS; n++) KBD.Porogs[n] = 0;
 
    for (;;)
    {
        //------------------------------------------------------------------------------
        //  Перед измерением состояния всех кнопок устанавливаем маску для первой
        //  кнопки
        //------------------------------------------------------------------------------
 
        KBD.cDataPos  = 0;                  // Номер байта
        KBD.cDataMask = 0x01;               // Маска бита в байте
        s_cChanged = 0;                     // Признак того, что состояние какой-то
                                            // клавиши было изменено
 
        for (n = 0; n < KBD_ROWS; n++)      // Цикл по всем строкам
        {
            s_cChanged |= ReadRow(n);       // Измерение всех датчиков в строке
                                            // может длиться до 500 мкс, поэтому
                                            // после прочтения каждой строки
                                            // переключаем контекст
            OS_Yield();
        }
 
        //------------------------------------------------------------------------------
        //  Если были изменения в кнопках, то отправляем сообщение задаче
        //  формирования звуковых переменных
        //------------------------------------------------------------------------------
 
        if (s_cChanged)
        {
            OS_Msg_Send_Now(msg_KBD, (OST_MSG) KBD.Data);
        }
 
        OS_Stimer_Delay(ST_KEYBOARD, 10 ms);
    }
}

Здесь так же, как и в задаче Task_Button для формирования задержки применен статический таймер.

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

char ReadRow (char row)
{
    char        m, a, i, k;             // Вспомогательные переменные
    char        col;                    // Текущий канал
    TColumn     Column;                 // Для сокращения кода обработки канала его
                                        // параметры копируются из ROM в переменную
 
    static char s_Changes[KBD_SIZE];    // Изменения в состояниях кнопок
                                        // для подавления дребезга
    static bit  s_bChanged;             // Переменная для возврата
 
    //------------------------------------------------------------------------------
 
    *ROWS[row].pPort |= ROWS[row].cMask;// Управляющий выход для линии в "1"
 
    s_bChanged = 0;                     // Изначально считаем, что изменений
                                        // не было
 
    //******************************************************************************
    //   Цикл по всем каналам
    //******************************************************************************
 
    for (col = 0; col  < KBD_COLUMNS; col++)
    {
        //------------------------------------------------------------------------------
        // Копируем параметры канала в переменную
        //------------------------------------------------------------------------------
 
        Column.pPort       = COLUMNS[col].pPort;
        Column.pTris       = COLUMNS[col].pTris;
        Column.cMask       = COLUMNS[col].cMask;
        Column.cADCChannel = COLUMNS[col].cADCChannel;
 
        //------------------------------------------------------------------------------
        //  Выбираем канал ADC
        //------------------------------------------------------------------------------
 
        CHS0 = 0;
        CHS1 = 0;
        CHS2 = 0;
        if (Column.cADCChannel & 0x01) CHS0 = 1;
        if (Column.cADCChannel & 0x02) CHS1 = 1;
        if (Column.cADCChannel & 0x04) CHS2 = 1;
 
        #if defined(_16F887) || defined(_16F886) || defined(_16F690)
        CHS3 = 0;
        if (Column.cADCChannel & 0x08) CHS3 = 1;
        #endif
 
        //------------------------------------------------------------------------------
        //  Начинаем измерение
        //------------------------------------------------------------------------------
 
        GIE = 0;                        // На время заряда конденсатора блокируем
                                        // прерывания, чтобы получить фиксированную
                                        // паузу
 
        *Column.pTris |=  Column.cMask; // Начать заряд переводом порта на вход
 
        for (m = 0; m < 3; m++) NOP();  // ПАУЗА для заряда.
 
        GODONE = 1;                     // Начинаем АЦ-преобразование
        GIE = 1;                        // Теперь прерывания можно разрешить
 
        while (GODONE) continue;
 
        //------------------------------------------------------------------------------
        //  Измерение закончено, теперь разряжаем конденсатор, читаем результат
        //  и формируем массив нажатых кнопок
        //------------------------------------------------------------------------------
 
        *Column.pTris &= ~Column.cMask;
        *Column.pPort &= ~Column.cMask; // Разряжаем конденсатор переводом входа на
                                        // выход и установкой "0" на нем
        a = ADRESH;
 
        //------------------------------------------------------------------------------
        //  Устанавливаем порог срабатывания, если он еще не установлен
        //------------------------------------------------------------------------------
 
 
        m = KBD.Porogs[col];            // Для сокращения кода копируем элемент
                                        // массива в переменную
        i = 0;
        if (a < m) i = KBD.cDataMask;   // Сравниваем результат АЦП с порогом для
                                        // данного канала. Если результат меньше
                                        // порогового значения, значит,
                                        // емкость на входе превышала допустим
                                        // ое значение и кнопка считается нажатой
 
        if (!m)                         // Если значение порога еще не установлено,
        {                               // то формируем его как 88% от ADRESH
            m = a >> 3;
            KBD.Porogs[col] = a - m;
        }
 
        //------------------------------------------------------------------------------
        //  Установка нового значения кнопки с подавлением дребезга
        //------------------------------------------------------------------------------
 
        m  =  KBD.Data[KBD.cDataPos];   // Для сокращения кода работаем не с элементом
        k  =  s_Changes[KBD.cDataPos];  // массива, а с фиксированной переменной
 
        //------------------------------------------------------------------------------
        if ((m ^ i) & KBD.cDataMask)
        {                               // Состояние кнопки изменилось:
            if (!(k & KBD.cDataMask))   //   Только что
                k |=  KBD.cDataMask;    //     Устанавливаем признак изменения бита
 
            else                        //   Не только что
            {
                m ^=  KBD.cDataMask;    //     устанавливаем новое значение кнопки
                s_bChanged = 1;         //     Формируем переменную для возврата
                k &= ~KBD.cDataMask;    //     Сбрасываем признак изменения бита
            }
        //------------------------------------------------------------------------------
        } else {                        // Состояние кнопки не изменилось:
            k &= ~KBD.cDataMask;        //   Сбрасываем признак изменения бита
        }
        //------------------------------------------------------------------------------
 
        KBD.Data[KBD.cDataPos] = m;     // Восстанавливаем значения массивов из
        s_Changes[KBD.cDataPos] = k;    // временных переменных
 
        //------------------------------------------------------------------------------
        //   Устанавливаем маску для следующей кнопки
        //------------------------------------------------------------------------------
 
        KBD.cDataMask <<= 1;
        if (!KBD.cDataMask)
        {
            KBD.cDataMask = 0x01;
            KBD.cDataPos++;
        }
 
    };
 
    *ROWS[row].pPort &= ~ROWS[row].cMask;   // Сбросить управляющий выход линии
 
    return s_bChanged;
}

Обратим внимание на строку формирования паузы:

    for (m = 0; m < 3; m++) NOP();

В данном случае пауза рассчитана для сопротивления в RC-цепочке, равное 100К, что обеспечивает заряд емкости примерно до Vdd/2. При установке резисторов других номиналов константу в цикле желательно (но не обязательно) пересчитать пропорционально, т.е. для 200К нужно будет считать до 6.

Звук

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

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

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

TSound      S[MAX_CHANNELS];    // Переменные для формирования звука
 
void Task_Sound (void)
{
    OST_MSG         msg;            // Переменная для приема сообщения
    unsigned char   Data[KBD_SIZE]; // Массив, куда будут скопированы состояния
                                    // клавиш
    unsigned char   cMask;          // Две вспомогательные переменны для побитового
    unsigned char   cPos;           // индексирования кнопок в массиве Data
 
    unsigned char   cFreeSounds;    // Переменная будет показывать, сколько свободных
                                    // каналов (не воспроизводящих) есть на
                                    // данный момент
    unsigned char   i, j;           // Вспомогательные переменные
 
    //------------------------------------------------------------------------------
 
    for (;;)
    {
        //------------------------------------------------------------------------------
        //   Ждем изменения состояния кнопок.
        //   Копируем состояния кнопок в массив Data
        //------------------------------------------------------------------------------
 
        OS_Msg_Wait(msg_KBD, msg);
 
        for (i = 0; i < KBD_SIZE; i++) Data[i] = ((char*)msg)[i];
 
        //------------------------------------------------------------------------------
        //  Из списка нажатых кнопок удаляем те, которые в данный момент
        //  уже воспроизводятся. Одновременно считаем, сколько свободных каналов
        //  имеется на данный момент.
        //------------------------------------------------------------------------------
 
        cFreeSounds = 0;
 
        for (i = 0; i < MAX_CHANNELS; i++)      // Пробегаемся по всем каналам
        {
            if (S[i].key == 0)                  // Если данный канал "молчит", то
            {                                   // увеличить счетчик свободных каналов
                cFreeSounds++;
                continue;
            }
 
            j = S[i].key - 1;                   // Формируем адрес бита в массиве Data,
            cMask = 1 << (j & 7);               // соответствующего текущему каналу
            cPos = j >> 3;
 
            if (Data[cPos] & cMask)             // Если кнопка все еще нажата, то
                Data[cPos] &= ~cMask;           // Убираем ее из списка нажатых кнопок
            else
            {
                cFreeSounds++;                  // Иначе прекращаем звук и увеличиваем
                S[i].key = 0;                   // счетчик свободных каналов.
            }
        }
 
        //------------------------------------------------------------------------------
        //  На данный момент cFreeSound содержит число незадействованных каналов,
        //  которые можно использовать для воспроизведения звуков для вновь
        //  нажатых клавиш
        //------------------------------------------------------------------------------
 
        cMask = 0x01;   // Поиск клавиш начинаем с первой
        cPos = 0;
        j = 0;          // Счетчик кнопок
        i = 0;          // Счетчик каналов
 
        while ((j < KBD_KEYS) && cFreeSounds)
        {
            if (Data[cPos] & cMask)     // Клавиша нажата?
            {                           // Да.
                while (S[i].key) i++;   // Ищем свободную ячейку
 
                                        // Формируем звуковую переменную:
                S[i].F = Freq[j];       // Устанавливаем частоту
                S[i].f = 0;             // Начальная фаза
                S[i].key = j + 1;       // Запоминаем номер воспроизводимой клавиши
                cFreeSounds--;          // Уменьшаем счетчик свободных каналов
            }
 
            j++;                        // Берем следующую кнопку для анализа
            cMask <<= 1;
            if (!cMask)
            {
                cMask = 0x01;
                cPos++;
            }
        }
    }
}

Синтезатор

Как мы уже решили раньше, подпрограмма синтезатора звука будет помещена внутрь прерывания по TMR2. Таймер 2 у нас настроен и для отсчета тактов модуля ШИМ, и для генерации прерываний. ШИМ у нас выбран максимально возможной частоты для 20 МГц и 8-разрядного разрешения, т.е. 78КГц. Теперь нам нужно выбрать постделитель для TMR2 такой, чтобы обеспечить частоту семплирования 20КГц. Очевидно, что ближайшим значением будет 4 (при этом мы получим частоту 19500). Итак, каждые 51.2 мкс вызывается прерывание, в котором генерируется звук, а именно - скважность импульсов ШИМ-сигнала.

void interrupt isr (void)
{
    static  unsigned    char    prs;        // Предделитель для вызова OS_Timer
            signed      int     temp_dac;   // Сумма мгновенного значения
                                            // сигнала для всех каналов
            unsigned    char    m_cDAC;     // Переменная для вывода через ШИМ
 
 
    TMR2IF = 0;
    temp_dac = 0;
 
    //------------------------------------------------------------------------------
    //  Формируем мгновенное значение суммы всех каналов
    //------------------------------------------------------------------------------
 
    SOUND(0);
    SOUND(1);
    SOUND(2);
    SOUND(3);
    SOUND(4);
    SOUND(5);
    SOUND(6);
    SOUND(7);
 
    temp_dac >>= 3;     // Т.к. 8 каналов, то сумму делим на 8.
 
    //------------------------------------------------------------------------------
    //  Выводим полученное значение через ШИМ
    //------------------------------------------------------------------------------
 
    m_cDAC  = *((char*)&temp_dac+0) + 0x80;
    m_cDAC >>= 2;
    CCP_bit1 = 0;
    CCP_bit0 = 0;
    if (temp_dac & 2) CCP_bit1 = 1;
    if (temp_dac & 1) CCP_bit0 = 1 ;
    CCPR1L = m_cDAC;
 
}

Обратим внимание на вызов макросов SOUND(x). Этот макрос написан просто для удобства добавления/удаления каналов в зависимости от требований к качеству звука и тактовой частоты контроллера (Например, понизив тактовую частоту в два раза, мы за 50 мкс будем успевать обработать только 4 канала; или, снизив частоту семплирования до 10 КГц, мы сможем обработать 16 каналов). Сам макрос выглядит так:

#define SOUND(x)                                        \
    if (S[x].key) {                                     \
        temp_dac += Sample[*((char*)&S[x].f+1) & 0x3F]; \
        *((char*)&S[x].f+1) += *((char*)&S[x].F+1);     \
        *((char*)&S[x].f+0) += *((char*)&S[x].F+0);     \
        if (CARRY) *((char*)&S[x].f+1) += 1;            \
    }

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

Теперь в прерывание осталось добавить обработку системных таймеров. Выбираем интервал для таймера равный 10 мс, или двумстам вызовам прерывания.

    //------------------------------------------------------------------------------
    //  1 раз в 200 вызовов (200 * 50мкс = 10мс) вызываем системный таймер
    //------------------------------------------------------------------------------
    if (!--prs)
    {
        OS_Timer();     // Обработка системных таймеров
        prs = 200;
    }

main()

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

void main (void)
{
    //------------------------------------------------------------------------------
    //  Инициализация периферии
    //------------------------------------------------------------------------------
 
    Init();
 
    //------------------------------------------------------------------------------
    //  Инициализация системы
    //------------------------------------------------------------------------------
 
    OS_Init();
 
    //------------------------------------------------------------------------------
    //  Создание задач (все задачи имеют одинаковый высший приоритет)
    //------------------------------------------------------------------------------
 
    OS_Task_Create(0, Task_Sound);
    OS_Task_Create(0, Task_Button);
    OS_Task_Create(0, Task_Keyboard);
 
    //------------------------------------------------------------------------------
    //  Разрешаем прерывания и запускаем планировщик
    //------------------------------------------------------------------------------
 
    OS_EI();
    OS_Run();
}

Init()

Весь текст я здесь приводить не буду (его можно посмотреть в исходных текстах, прилагаемых к статье), т.к. из-за того, что эта функция предусматривает работу на 4-х разных контроллерах (16F886, 16F887, 16F690 и 16F88), то код ее довольно громоздкий из-за наличия условных директив #ifdef…#endif.

Скажу только, что в этой функции производится инициализация:

потов ввода/вывода;
АЦП;
таймеров;
модуля ШИМ;
прерываний.

Конфигурация OSA

Для конфигурирования работы операционной системы в нашем проекте воспользуемся утилитой OSAcfg_Tool.

1. Выбираем папку, где располагается наш проект

Для этого в самом верху окна справа нажимаем кнопку Browse. Там выбираем путь к файлу OSAcfg.h - путь к нашему проекту ("C:\TEST\PICKIT2\PIANO"). Нажимаем OK. Если файл еще не создан, то программа спросит у Вас, действительно ли Вы хотите создать этот файл. Смело отвечаем "Yes" и идем дальше.

2. Выбираем имя проекта

3. Выбираем платформу

4. Конфигурируем наш проект

Учитывая, что сама программа использует много переменных, есть смысл все системные переменные затолкать в какой-нибудь верхний банк памяти, например bank2 (в поле OSA variables bank).

Теперь нам нужно сказать системе, что нам требуются два статических таймера для работы. В поле Static timers устанавливаем 2 и в таблице ниже вводим имена идентификаторов статических таймеров: ST_KEYBOARD и ST_BUTTON. Кроме того, учитывая, что нам не потребуются задержки длиннее 256 системных тиков, установим тип статического таймера char.

И последнее: для ускорения обработки сервиса OS_Timer установим галочку напротив пункта Use in-line OS_Timer().

5. Сохраняем и выходим

/******************************************************************************/
//
// This file was generated by OSAcfg_Tool utility.
// Do not modify it to prevent data loss on next editing.
//
// PROJECT NAME: ПИАНИНО
// PLATFORM:     HT-PICC 14-bit
//
/******************************************************************************/
 
#ifndef _OSACFG_H
#define _OSACFG_H
 
//------------------------------------------------------------------------------
// SYSTEM
//------------------------------------------------------------------------------
 
#define OS_TASKS               3  // Number of tasks that can be active at one time
#define OS_DISABLE_PRIORITY       //
 
//------------------------------------------------------------------------------
// ENABLE CONSTANTS
//------------------------------------------------------------------------------
 
#define OS_USE_INLINE_TIMER        // Make OS_Timer service as in-line function
 
//------------------------------------------------------------------------------
// BANKS
//------------------------------------------------------------------------------
 
#define OS_BANK_OS             2  // RAM bank to allocate all system variables
 
//------------------------------------------------------------------------------
// TYPES
//------------------------------------------------------------------------------
 
#define OS_STIMER_SIZE         1  // Size of static timers (1, 2 or 4)
 
//------------------------------------------------------------------------------
// STIMERS
//------------------------------------------------------------------------------
 
#define OS_STIMERS             2  // Number of static timers
 
enum OSA_STIMERS_ENUM
{
    ST_KEYBOARD,          // Для формирования задержек в Task_Keyboard
    ST_BUTTON             // Для формирования задержек в Task_Button
};
 
#endif

Прошивка контроллера

Сборка проекта

Распаковываем файл piano.rar в папку C:\TEST\PICKIT2. При этом внутри создастся папка PIANO. В MPLAB IDE открываем проект, в названии которого присутствует номер контроллера, который Вы собираетесь использовать: 886, 887, 690 или 88. Например, для демо-платы на базе 16F887 нам нужно открыть файл pk2_piano_887.mcp.

Примечание. При распаковке в другую папку, отличную от C:\TEST\PICKIT2\PIANO, нужно будет через меню Project\Build options…\Project в закладке Directories в списке include-путей заменить путь к файлам проекта на тот, куда Вы распаковали файлы из архива.

Выполняем сборку нажатием Ctrl+F10.

Прошивка

Здесь все просто:

подключаем программатор;
в меню "Programmer\Select" programmer выбираем PicKit2;
В настройках "Programmer→Settings" выбираем <3-State on <Release from Reset>
запускаем программирование "Programmer\Program";
освобождаем вывод MCLR "Programmer\Release from reset".

Вот и все!

Схемы подключения клавиатурной матрицы

Здесь я просто приведу к каким выводам подключается матрица, чтобы работала наша программа. Рассмотрены контроллеры PIC16F88, PIC16F690, PIC16F886, PIC16F887.

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

Аналоговые входы контроллера дополнительно защищены от статики согласно документа от MicrochipLayout and Physical Design Guidelines for Capacitive Sensing (PDF). Хоть контроллер и имеет встроенную защиту, тем не менее, во-первых, в некоторых случаях ее может оказаться недостаточно, а во-вторых, защиту имеют не все выводы (например, RA4 ее не имеет).

Заключение

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

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

Зачем мы воспользовались RTOS?

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

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

хотим кнопки перевесить на другие выводы контроллера - на здоровье: правим массивы ROWS и COLUMNS в файле const.h;
хотим больше кнопок - пожалуйста, переопределяем константы KBD_ROWS и KBD_COLUMNS и добавляем данные о новых выводах в массивы ROWS и COLUMNS;
хотим больше каналов - увеличиваем константу MAX_CHANNELS и снижаем частоту семплирования;
хотим новых инструментов - правим массив SAMPLES в файле sinus.c.
и т.д.

Все ограничивается только фантазией!

Удачи!

Ссылки

Поделки по данной статье:

http://b612.h16.ru/pianino.htm - пианино на PIC16F690 с выводом звука на динамик через усилитель. Прилагается схема, печатная плата, файлы проекта для Proteus, а также небольшой файл с демо (mp3)

Виктор Тимофеев, апрель 2009
osa@pic24.ru

RTOS: распространенные заблуждения

2011-05-14T12:11:59+03:00

RTOS: распространенные заблуждения

Шесть распространенных заблуждений о применении RTOS в малоресурсных МК

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

Заблуждение 1

«Моя программа очень простая. Зачем там RTOS?»

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

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

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

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

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

Заблуждение 2

«RTOS – черный ящик, а я хочу контролировать все»

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

Когда кто-то задается вопросом «а как я буду все контролировать?», хорошо бы еще ответить на вопрос «действительно ли это нужно в конкретной программе?». Оглянитесь вокруг: нас окружают десятки, сотни и тысячи разнообразных устройств. Попробуйте мысленно спроектировать программу для любого устройства дома: будильник, пульт д/у, музыкальный звонок, холодильник и т.д. Выйдите на улицу: светодиодные вывески над магазинчиками, сигнализации почти в каждом автомобиле, домофоны. Зайдите в магазин: кассовые аппараты, система освещения, турникет с магнитной рамкой. А теперь ответьте себе на вопрос: какие из узлов программы, которую бы вы написали для управления этими устройствами, требуют абсолютного контроля генерируемого кода со стороны программиста?

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

Заблуждение 3

«RTOS отнимает слишком много ресурсов»

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

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

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

Кроме того, есть какая-то опрометчивость в том, чтобы еще на этапе проектирования предположить, что программа будет использовать все ресурсы под завязку. В самом деле, нельзя же быть уверенным в том, что любая программа потребует «почти 1кб» программной памяти, или «почти 2кб», или «почти 4кб», или «почти 8кб» и т.д.

В результате получается, что проблема нехватки ресурсов при использовании RTOS касается немногих программистов, да и то – далеко не на всех проектах. Поэтому проблема надуманна, и ее вряд ли можно всерьез рассматривать как аргумент в пользу отказа от RTOS.

Заблуждение 4

«Код написан дядей. Он ошибется, а я – расхлебывай!»

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

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

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

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

Заблуждение 5

«Если используешь RTOS, то контроллер и язык программирования можно изучить только поверхностно»

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

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

Заблуждение 6

RTOS делает контроллер мощнее

Как ни странно, распространенное заблуждение о том, что если мощности контроллера не хватает для полноценного функционирования программы, то добавление в программу RTOS может решить проблему, - присуще даже опытным программистам. Нередко можно услышать от них довод: «Зачем тут RTOS? Я вот писал такое, да растакое на ассемблере – и справился без всяких RTOS!» Довод довольно нелепый и скорее говорит за невладение вопросом, чем за умение обходиться ассемблером (или Си).

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

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

Заключение

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

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

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

Программирование микроконтроллеров с использованием ОСРВ OSA

2010-12-08T15:44:11+03:00

Программирование микроконтроллеров с использованием ОСРВ OSA

Виктор Тимофеев, osa@pic24.ru (февраль, 2009)

(ОСРВ - операционная система реального времени)

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

Статья разделена на несколько частей:

Зачем контроллеру "ось"? - здесь приводятся предпосылки и аргументы в пользу использования ОСРВ в некоторых проектах;
Общие рекомендации - некоторые рекомендации по использованию ОСРВ;
FAQ по ОСРВ OSA - самые частые вопросы от программистов;
Советы по оптимизации - некоторые приемы и рекомендации по конфигурированию OSA для поднятия производительности системы;
Заключение

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

Зачем контроллеру "ось"?

Что хорошего дает использование ОСРВ

Так зачем же нужна операционная система в контроллерах? Я бы назвал несколько причин.

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

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

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

В-третьих, ОСРВ берет на себя отсчет временных задержек. Часто в программе нужно выдержать паузу (например при записи в EEPROM мы ждем 5-10 мс). Выполняя задержку явно, т.е., зацикливая программу до тех пор, пока какой-нибудь счетчик не достигнет нужного значения, мы блокируем работу всей программы на время выполнения этой задержки. Не страшно, если нам нужно подождать 10 мс после записи одного байта в EEPROM. А если нам нужно записать 100 байт? Придется "вешать" программу на секунду? ОСРВ же дает возможность организовать программу так, чтобы во время выполнения задержки одной задачей могли выполняться остальные задачи. Т.е. отсутствует время пустого простоя системы. Кроме того, часто в программах требуется ожидать некоего события, но так, чтобы была возможность прервать ожидание, если событие не происходит в течение какого-то времени. Простейший пример - набор номера в GSM-модеме и ожидание ответа. Мы не можем ждать вечно, поэтому дополняем программу неким механизмом, который по истечении заданного времени прервет ожидание. Для этого мы заводим отдельный таймер (тактируемый, например, в прерывании) и следим за его значением. В этом есть некоторые неудобства. Во-первых, на время ожидания все остальные задачи блокированы; во-вторых, нужна отдельная глобальная переменная нужной размерности, имеющая осмысленное имя (например, ModemAnswerTimer); в-третьих, нужно не забыть все такие переменные инкрементировать в обработчике прерываний; есть еще в-четвертых и в-пятых, но это уже мелочи. ОСРВ же может обеспечить ожидание события с выходом по таймауту так, что оно будет лишено перечисленных недостатков, особенно - главного из них: система не будет простаивать впустую во время ожидания.

(Комментарий Alex B.) Тут дело даже не в какой-то абстрактной блокировке остальных задач. Очень часто 5 мс это действительно незаметный отрезок. До тех пор, пока во вводных основной проблемой не станет энергопотребление. Несмотря на то, что устройство может быть не автономным, уменьшение интегрального потребления есть серьезный плюс к ТТХ вашего девайса.

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

В-пятых, использование ОСРВ улучшает читабельность и наглядность программного кода. То, что реализуется без ОСРВ в 10-15 строках кода, с ОСРВ может быть записано одной строкой. Здесь я не буду приводить конкретных примеров, пока поверьте мне на слово, а когда дойдет дело до написания программы, сами убедитесь в том, что это так.

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

Что мы теряем, используя ОСРВ

За все выше перечисленные полезности придется платить.

Платим мы в первую очередь памятью контроллера. Сама ОСРВ требует под себя некоторые ресурсы, пусть небольшие, но все-таки. Чем больше параллельных задач, тем больше RAM потребуется для хранения их текущих состояний, адресов возврата и внутренних таймеров. Кроме того, система оперирует еще и своими внутренними переменными, такими как указатель на текущую задачу, лучший приоритет и пр. Ну, естественно, сами системные сервисы и планировщик требуют под себя программную память.

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

В третью очередь, как ни печально, мы платим непереносимостью программного кода. Т.е. переносимость программы с одной платформы на другую возможна только при том условии, что другая платформа так же поддерживается выбранной ОСРВ. Здесь конкретно для OSA выбор пока ограничен только PIC-контроллерами серий 10, 12, 14, 16, 18, 24, 30 и 33. Расширение планируется, но не сегодня и не завтра. Эта задача на перспективу. (Примечание: с версии 100311 OSA поддерживает 8-битные контроллеры AVR фирмы Atmel)

Наконец, опасениями, что "код разработан не мной, а каким-то дядей", и кто знает, что у этого дяди было на уме. Я сам работал с чужими библиотеками и помню, что когда натыкался на какую-то ошибку, всегда в первую очередь грешил на библиотеки. Некоторые идут дальше: не в библиотеке - так в компиляторе, не в компиляторе - так в программаторе, не в программаторе - так в контроллере! И вот уже строчат письмо на support.microchip.com: "Я лажу нашел! В ваших контроллерах RA4 неправильно работает!" Однако, 99% всех ошибок - на совести программиста. Тем не менее, не исключены и ошибки библиотек, компиляторов, программаторов, наконец, самих контроллеров (не случайно ведь появляются документы ERRATA). И ОСРВ здесь - не исключение. Те, кто отписываются мне по OSA, бывает, обнаруживают неправильное поведение системы, помогают отлавливать баги. И чем больше народа отписывается, тем более безглючной становится "ось". После отлова очередного бага (а они все хитрее и все трудноуловимее) всегда кажется, что вот теперь-то багов точно нет. Тем не менее, нет-нет, да обнаружится еще один (еще более хитрый). Поэтому вряд ли я когда-нибудь скажу: "Все, пользуйтесь. Багов нет!" (Да и ни один производитель ПО такого не скажет). Поэтому сидеть и ждать, когда система станет абсолютно безглючной, - это так никогда и не приступить к работе с ней. А попробовать стоит хотя бы из любопытства. Если и решите: "нет, это не для меня", - то хотя бы, я уверен в этом, почерпнете для себя что-то новое.

Можно ли обойтись без ОСРВ?

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

Резюме

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

Общие рекомендации

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

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

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

Не используйте ОСРВ там, где это не нужно

Далеко не все задачи удобно решать с помощью ОСРВ (а в некоторых случаях ОСРВ даже будет мешать). Кроме того, следует помнить, что микроконтроллеры (в особенности те, на которые в первую очередь была ориентирована OSA, т.е. PIC10, PIC12, PIC16) имеют дефицит ресурсов. Некоторые программисты после написания одной-двух программ с использованием ОСРВ так привязываются к ней, что, формулируя для себя очередную задачу еще в проблемно-ориентированных терминах, уже сразу пытаются подогнать эту формулировку под принципы ОСРВ. Т.е., фактически, при проектировании программы пропускается важный этап - выбор инструмента. Это не совсем правильно; вернее - совсем неправильно.

Например, простая задача для PIC10: "пока на входе контроллера есть меандр 1 КГц, горит зеленый светодиод; если частота меандра выходит за пределы допуска +/- 10% - гасим зеленый светодиод и зажигаем красный". Здесь использование ОСРВ совсем не оправдано, более того, просто вредно, поскольку работа планировщика отнимет скоростные ресурсы контроллера и не позволит обеспечить требуемую точность. Тем не менее, некоторые (не буду говорить, кто) создадут 3 независимых задачи: одна следит за меандром, вторая обрабатывает светодиоды, третья следит за первыми двумя - и будут усердно пытаться всю остальную программу оформить и утрамбовать так, чтобы эти три задачи справлялись со своими функциями, причем - в ущерб наглядности текста, прозрачности алгоритма и, наконец, надежности самой программы.

Другой пример - какую-нибудь простую задачу затолкают в малоресурсный контроллер вместе с ОСРВ, на этапе компиляции обнаружат, что памяти (или ROM, или RAM, или и той и другой) не хватает, и начинают вытворять какие-то немыслимые фокусы по оптимизации вплоть до использования машинных кодов в inline-ассемблере (есть такая возможность в HT-PICC), чтобы программу вообще хоть как-то запустить (Михаил, без обид :) ), при этом даже не рассмотрев вариант написания программы без использования ОСРВ.

В ответ на мои рассуждения о ОСРВ и малоресурсных контроллерах мне приводят в пример мою же программу led3, мол, она-то с использованием ОСРВ написана; зачем тогда такой пример, если Вы сами не рекомендуете так делать? Здесь ответ простой. Представьте, что Вы пришли на базар, чтобы купить топор для колки дров. Продавец, демонстрируя свои топоры, одним из их разрубает стальной трос. На топоре при этом - ни зазубрины. Это не значит, что все стальные тросы нужно непременно рубить этими топорами, забыв при этом о специальных для таких целей инструментах, но это кое-что говорит о возможностях этих топоров в работе по дереву. Так же и с этим примером для PIC10. Он приведен не для того, чтобы показать, что любая программа для любого контроллера может и должна быть написана под операционной системой; он приведен для того, чтобы показать, насколько конкретная ОСРВ нетребовательна к ресурсам (в частности, ни jacOS ни Salvo с такой задачей не справятся). Другими словами, этот пример показывает, что само ядро операционной системы будет почти незаметно для программы при использовании контроллера помощнее, например, PIC16F628 (не говоря уже о PIC18 и выше).

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

"выполняет возложенные на нее функции";
"лишь бы влезла в выбранный контроллер";
"использованы продвинутые решения (ОСРВ)".

Важно учитывать также второстепенные:

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

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

Есть религиозные войны "Си & асм". Изучение перепалок на эту тему позволяет сделать вывод, что самые ярые "вояки" - это те, которые с противоположной стороной вопроса не очень знакомы. Возможно, на подходе религиозные войны "RTOS & !RTOS". Я предлагаю не участвовать на передовой, ударяя себя пяткой в грудь и крича, что RTOS - сила, а осваивать и ОСРВ, и суперлуп, и прерывания (есть и такой вариант), и выбирать оптимальный для решения конкретной задачи.

Не злоупотребляйте использованием сервисов ОСРВ

В присланных мне проектах я также замечал маниакальное использование сервисов ОСРВ везде: где нужно и где не нужно. Складывается такое ощущение, что некоторые программисты рассматривают ОСРВ как язык программирования, просто еще более высокого уровня, чем Си. И как при программировании на Си избегают использования встроенного ассемблера, так и при программировании под ОСРВ избегают использования самого Си. В результате такого подхода исходный текст программы сильно пестрит изобилием сервисных вызовов, которое просто затрудняет чтение программы. Применительно к OSA, возможно, есть и моя вина в том, что некоторые так пишут программы. OSA предоставляет изобилие сервисов для, в общем-то, простых операций, не требующих каких-то сложных пассажей с передачей управления ядру (достаточно посмотреть на сервисы установки/сброса флагов). По существу же, большое количество сервисов - это просто формализация простых операций в терминах конкретной ОС. Применительно к флагам эта формализация звучит так: есть сервисы ожидания флагов, значит должны быть и сервисы установки/сброса флагов (хотя по сути - это простые побитовые операции and и or) и их проверки ( == и != ). Т.е. есть некий объект ОС (флаг), следовательно, ОС должна обеспечить программиста сервисами по всевозможным операциям с объектом. На деле же получается довольно трудночитаемый текст.

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

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

    OS_Csem_SetValue(csem, 10);
    do {
        /*...*/
        OS_Csem_Accept(csem);
    } while (OS_Csem_Check(scem));

    i = 10;
    do {
        /*...*/
    } while (--i);

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

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

    // CLC - ножка CLOCK
    // DIO - ножка DATA
    // (прим. - В.Т.)
 
    OS_Cond_Wait(CLC);
 
    if (DIO)  OS_Flag_Set_1(data, mask);
    else      OS_Flag_Set_0(data, mask);
 
    mask <<= 1;
    if (!mask) ...

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

    OS_Cond_Wait(CLC);
 
    if (DIO)  data |=  mask;
    else      data &= ~mask;
 
    mask <<= 1;
    if (!mask) ...

Еще в одной присланной мне программе человек так увлекся бинарными семафорами, что на них построил всю логику работы программы. У него было под 40 этих семафоров, и в результате он в них запутался, т.к. его программа выглядела уже не как последовательность действий, а как какая-то МДНФ на ПЛМ, которая хоть и выполняет свою функцию, но без пристальнейшего вглядывания имеет совсем непонятную логику работы. И модификация такой программы становится весьма затруднительной (Семен, это я о тебе :) ).

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

Поэтому я подведу итог:

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

Не забывайте о прерываниях

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

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

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

void Task_Iinterrupt_INTF (void)
{
    for (;;)
    {
        OS_Cond_Wait(INTF);
        INTF = 0;
        /* Далее следует ко добработки прерывания */
    }
}

Неэффективность такого подхода очевидна:

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

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

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

О глобальных переменных

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

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

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

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

Как разбить программу на задачи

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

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

void Task_Relay1 (void)
{
    for (;;)
    {
        OS_Bsem_Wait(BS_RELAY1);
        RELAY1 = 1;
        OS_Delay(100);
        RELAY1 = 0;
    }
}

Но что у нас получается на практике? Если программа управляет десятком таких силовых выходов, то у нас заводится десять таких задач. С виду - все красиво и аккуратно. Но не следует забывать, что каждая активная задача в ОСРВ требует несколько байт оперативной памяти, где хранится ее текущее состояние, адрес возврата, ее таймер (все эти параметры хранятся в так называемом дескрипторе задачи). Например, для PIC16 размер дескриптора задачи 5 байт (он может быть и меньше, но мы рассматриваем общий случай), и для десяти задач потребуется 50 байт ОЗУ, что для PIC16 - просто расточительство. Кроме того, еще одна проблема, возникающая при большом количестве задач, - увеличивается время работы планировщика, т.е. то время, за которое планировщик успеет перебрать все задачи, определить, какие из них готовы к выполнению, и из этих готовых найти самую важную (т.е. имеющую высший приоритет).

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

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

Вторая крайность - это когда программист пытается все, что не является обработкой кнопок, затолкать в одну задачу. Она занимается и приемом даных по USART, и записью данных в EEPROM, и … да чем только не занимается! Зато информацию о кнопках получает извне. Зато есть многозадачность! Бессмысленность такого подхода очевидна (тем не менее, он часто встречается): нет преимущества использования ОСРВ. В чем преимущество параллельности выполнения задач, если задача всего одна? В чем преимущество очередей сообщений, если задача сообщения отсылает сама себе? Какова будет реакция на событие, если задача занимается сразу всем? Про читабельность кода, написанного с таким подходом, я вообще молчу. Единственное, что полезного можно ухватить от ОСРВ в таком случае, - это удобство формирования задержек (OS_Delay - и все!).

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

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

Другими словами: если какой-то внешний модуль допускает замену, то управление этим модулем нужно выносить в отдельную задачу. К таким модулям, помимо индикаторов, можно также отнести внешнюю память, протоколы обмена данными, клавиатуру, GPS- и GSM-модули и т.д.

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

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

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

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

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

В одном из присланных мне проектов был реализован интересный подход, который тоже можно взять на вооружение. В программе было описано около 20 функций-задач. Но в один момент времени могли работать только 4. 3 из них работали постоянно, а 4-я в зависимости от текущего режима все время пересоздавалась. Преимущество такого подхода - скорость работы планировщика (чем меньше активных задач, тем планировщик OSA работает быстрее). Недостаток - нужно очень внимательно следить за создаваемыми/удаляемыми задачами, а так же за тем, чтобы при удалении они не забывали освобождать занимаемые ресурсы.

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

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

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

Как расставлять приоритеты

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

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

Тем не менее, в программах под кооперативными ОСРВ бывают случаи, когда приоритетность выручает.

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

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

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

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

Высокоприоритетными задачами нужно делать те, которые действительно критичные ко времени реакции. Представьте себе устройство управления автоматическими воротами. Задачами этого устройство являются: прием по радиоканалу команд от ПДУ на открытие/закрытие, управление двигателями дверей, а также - аварийный реверс двигателей, если на пути створок дверей оказалось препятствие. Последняя задача является критичной ко времени. Например, оператор нажал копку на ПДУ - ворота открылись, машина поехала, а оператор нажал кнопку закрытия ворот раньше времени. В результате створки ворот упрутся в кузов автомобиля. Чем быстрее устройство сообразит, что надо дать дверям обратный ход, тем дешевле будут последствия.

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

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

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

Можно ли вызывать сервисы ожидания из функций, вызываемых задачами?
Ожидание события в цикле
Можно ли создать задачу по указателю на функцию?
Что будет, если отсылать/принимать сообщения из неинициализированной очереди?
Изменение типов сообщений
Если две задачи ожидают одного и того же события
Модификация тела сообщения до того, как оно будет принято
Использование таймеров вне задач
Почему виснет OS_Delay?

FAQ по ОСРВ OSA

Здесь я собрал ответы на самые распространенные вопросы по OSA.

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

Ответ: нет.

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

    // В этом примере просто напрашивается вынос OS_Delay(10) в отдельную функцию.
    // Сам вызов сервиса занимает около 10 слов ROM, и его, конечно, хочется
    // заменить одним вызовом.
    ...
    OS_Delay(10);
    ...
    if (...) OS_Delay(10);
    ...
    do {
        ...
        OS_Delay(10);
        ...
    } while (...);
    ...

или когда есть несколько задач, ожидающих одно и то же событие:

    ...
    // Ждем, когда освободится доступ в EEPROM
    OS_Bsem_Wait(BS_EEPROM_FREE);
    ...

К сожалению в ОСРВ OSA такое недопустимо. Дело в том, что при таком подходе произойдет путаница с адресами возврата в стеке. Рассмотрим на примере:

//-----------------------------------------------
void Delay10 (void)
{
    OS_Delay(10);
}
 
//-----------------------------------------------
void Bsem_Wait (void)
{
    OS_Bsem_Wait(BS_BINSEM);
}
 
//-----------------------------------------------
void TaskA (void)
{
    for (;;)
    {
        Delay10();
        /*...*/
        Delay10();
        /*...*/
        Delay10();
        /*...*/
    }
}
 
//-----------------------------------------------
void TaskB (void)
{
    for (;;)
    {
        Bsem_Wait();
        /*...*/
        Bsem_Wait();
        /*...*/
        Bsem_Wait();
        /*...*/
    }
}
 
//-----------------------------------------------

Итак, у нас есть две задачи: TaskA и TaskB. Обе вызывают разные функции, в каждой из которых есть сервис, содержащий код возврата в планировщик (в перечне сервисов все такие сервисы в примечании отмечены буквой "T"). Для простоты рассмотрим работу этого примера на PIC16. (Примечание: планировщик в этих контроллерах передает управление задачам присвоением адреса задачи паре регистров PCLATH:PCL, а задачи возвращают управление планировщику, совершая переход на него по GOTO. Таким образом экономится стек, т.к. ни задачи, ни планировщик не вызываются через CALL). При выполнении программы возможна такая последовательность:

.	Действие	Передача управления	Стек
1	Планировщик запускает задачу TaskA	PCLATH:PCL=TaskA	-
2	Задача TaskA вызывает функцию Delay10()	CALL Delay10.	ret_addr_A -
3	Функция Delay10 вызывает системный сервис OS_Delay, который, инициализировав задержку, передает управление планировщику	GOTO sched	ret_addr_A -
4	Планировщик запускает задачу TaskB	PCLATH:PCL=TaskB	ret_addr_A -
5	Задача TaskB вызывает функцию Bsem_Wait()	CALL Bsem_Wait	ret_addr_B ret_addr_A -
6	Функция Bsem_Wait вызывает системный сервис OS_Bsem_Wait, который передает управление планировщику	GOTO sched	ret_addr_B ret_addr_A -
7	Планировщик крутится вхолостую, пока идет задержка, запущенная в задаче TaskA и пока не установлен семафор, которого ожидает задача TaskB		ret_addr_B ret_addr_A -
8	Задержка закончилась, плнировщик передает управление задаче TaskA в то же место, откуда был возврат в планировщик, а именно - в середину функиции Delay10	PCLATH:PCL=Delay10	ret_addr_B ret_addr_A -
9	И теперь - кульминация: функция делает возврат, при котором из стека берется последний положенный туда адрес, а именно - ret_addr_B	RETURN	ret_addr_A -

Как видно, после 9-ой операции мы из функции Delay10 вернемся в функцию-задачу TaskB, хотя должны были вернуться в TaskA.

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

Ожидание события в цикле

Некоторые из присланных мне программ содержали однотипную ошибку, которую я бы хотел здесь обрисовать. Иногда бывает так, что в ходе ожидания какого-либо события требуется выполнять какое-то действие. Поэтому код этого ожидания некоторые писали без использования сервисов OS_xxx_Wait, заменяя их циклом do {…} while. Рассмотрим отвлеченный пример: пока ожидаем установки какого-то двоичного семафора, нам нужно сравнивать напряжения на двух входах АЦП и, в зависимости от результата сравнения, зажигать либо красный либо зеленый светодиод.

Код такого ожидания выглядел так:

    do
    {
        if (ADC_Read(0) > ADC_Read(1))    // Сравниваем напряжения на двух аналоговых входах
        {
            GREEN_LED = 1;
            RED_LED = 0;
        } else {
            GREEN_LED = 0;
            RED_LED = 1;
        }
 
        OS_Yield();                       // Возврат в планировщик
 
    } while (!OS_Bsem_Check(BS_START));

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

Как быть в таких случаях? Здесь есть несколько вариантов решения этой коллизии.

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

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

OST_TASK_POINTER tp;
 
/******************************************************************************/
//  Отдельная задача для работы с АЦП и светодиодами
/******************************************************************************/
 
void Task_ADC_Leds (void)
{
   tp = OS_GetCurTask();
   for (;;)
   {
        /*...*/
        /* Здесь сравниваем напряжения */
        /*...*/
 
        OS_Yield();                       // Возврат в планировщик
   }
}
 
/******************************************************************************/
//  Наша задача
/******************************************************************************/
 
void Task (void)
{
    for (;;)
    {
        /*...*/
        // Перед ожиданием создаем задачу сравнения напряжений
        OS_Task_Create(7, Task_ADC_Leds);
 
        // Ждем наш семафор
        OS_Bsem_Wait(BS_START);
 
        // Удаляем задачу сравнения напряжений
        OS_Task_Delete(tp);
 
        /*...*/
    }
}

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

2. Понизить приоритет на время ожидания

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

    static char prio;
    /*...*/
    prio = OS_Task_GetPriority(this_task);   // Запоминаем текущий приоритет задачи
    OS_Task_SetPriority(this_task, 7);       // Понижаем приоритет до минимального
    do {
        /*...*/
        /* Здесь сравниваем напряжения */
        /*...*/
        OS_Yield();
    } while (!OS_Bsem_Check(BS_START));
 
    OS_Task_SetPriority(this_task, prio);    // После цикла восстанавливаем сохраненный
                                             // приоритет

Примечание: рекомендуется понижать приоритет не до самого низкого (7-го), а до предпоследнего (6-го), т.к.низший приоритет удобно использовать для задачи SLEEP'а.

3. Вставить в цикл небольшую задержку

Заменив OS_Yield() на OS_Delay(1), мы гарантировано на время одного системного тика ставим задачу в режим ожидания (время задержки можно увеличить, если одного тика мало):

    do {
        /*...*/
        /* Здесь сравниваем напряжения */
        /*...*/
        OS_Delay(1);
    } while (!OS_Bsem_Check(BS_START));

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

Можно ли создать задачу по указателю на функцию?

Ответ: да

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

typedef struct
{
    const char* strMenu;
    void  (*Func)(void);
} TMenuItem;

Далее в программе определен массив этих структур:

const TMenuItem UserMenu[] = {
    {"Load", Task_Load},
    {"Save", Task_Save},
    {"View", Task_View}
    {"Edit", Task_Edit}
};

Все эти задачи описываются как обычно, например:

void Task_Load (void)
{
    for (;;)
    {
        /*...*/
    }
}

Далее - одна тонкость. Чтобы компилятор правильно строил дерево вызовов подпрограмм, ему нужно указать, что функции, которые мы перечислили в массиве, являются задачами. Для этого в main() нужно для каждой такой функции вызвать сервис OS_Task_Reserve:

void main (void)
{
    /*...*/
    OS_Task_Reserve(Task_Load);
    OS_Task_Reserve(Task_Save);
    OS_Task_Reserve(Task_View);
    OS_Task_Reserve(Task_Edit);
    /*...*/
}

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

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

    LCD_Out(UserMenu[i].strMenu);        // Выводим на экран название функции
    OS_Task_CreateP(0, UserMenu[i].Func); // Создаем задачу с высшим приоритетом

Что будет, если отсылать/принимать сообщения из неинициализированной очереди?

Ответ: ничего хорошего

Это относится не только к неинициализированной очереди, но и к неинициализированным: счетным семафорам, коротким сообщениям, указателям на сообщения. Неизвестно, что содержат в себе эти переменные на момент обращения к ним. Поэтому нужно всегда следить за тем, чтобы эти объекты ОС инициализировались до первого обращения к ним.

Рекомендую проанализировать работу следующего примера:

OST_QUEUE q;
OST_MSG   smsg;
OST_MSG   rmsg;
 
void Task1 (void)
{
    OS_Queue_Create(q);          // Создаем очередь (инициализируем)
    for (;;)
    {
        OS_Queue_Send(q, smsg);  // Отсылаем сообщение в очередь
    }
}
 
void Task2 (void)
{
    for (;;)
    {
        OS_Queue_Wait(q, rmsg);  // Ожидаем сообщение из очереди
    }
}
 
void main (void)
{
    OS_Init();
    OS_Task_Create(1, Task1);
    OS_Task_Create(0, Task2);
    OS_Run();
}

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

Изменение типов сообщений

OSA имеет два вида сообщений: указатель на сообщение и короткое однобайтовое сообщение. Различаются они тем, что с помощью первого можно передавать любой объем информации, т.к. фактически передается только указатель на нее, а с помощью второго - только одно значение (по умолчанию это значения от 1 до 255). Учитывая архитектурные особенности PIC-контроллеров, программистам оставлена возможность изменять типы этих сообщений.

Сначала поговорим о типе указателя на сообщение. По умолчанию указатель на сообщение имеет тип void* , т.е. указатель на область RAM-памяти. Учитывая, что ядро PIC-контроллера построены по гарвардской архитектуре (раздельные шины адреса для памяти данных и программы), указатели на данные в ОЗУ и указатели на константы, хранящиеся в программной памяти, - это разные вещи. Поэтому ОСРВ OSA предоставляет программисту возможность на этапе написания программы выбрать тип указателей на сообщения. Этот тип нужно указать в файл конфигурации osacfg.h:

#define OS_MSG_TYPE    const char *

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

OST_MSG_CB  msg_cb;        // Дескриптор сообщения
 
const char * MenuStrings[] = {"Load", "Save", "Save as...", "Exit"};
 
void Task_Menu (void)
{
    for (;;)
    {
        for (i = 0; i < 4; i++)
            OS_Msg_Send(msg_cb, MenuString[i]);
        /*...*/
    }
 
}

Примечание: в программе может быть применен только один тип для указателей на сообщения, и он не может меняться в ходе выполнения программы. (Исключение составляют указатели в HT-PICC18, когда указан ключ компиляции -CP24.)

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

typedef struct {
    char*   name;
    int     age;
    int     weight;
} TMyStruct;
 
#define OS_MSG_TYPE   TMyStruct *

Т.е. программист создает некую свою структуру и тип сообщения заменяет указателем на нее. Ошибки здесь, конечно, нет. Но концептуально такой подход довольно спорный. За год программист может написать одну программу, а может и 10, и 20. Каждая программа может быть индивидуальна, и данные, которыми будут обмениваться задачи, - тоже. Если в каждой программе подменять тип указателя на сообщение каким-то специфичным указателем вместо void*, то возникнет некоторая неразбериха, да и проблемы с переносом модулей. Если предполагается работать с указателями на эти структуры, расположенные в RAM-области памяти, то лучше оставить тип void*. Это же замечание касается указателей на структуры, расположенные в ROM-области памяти - их лучше определять как const void* .

Теперь два слова о изменении типа короткого сообщения. Для чего оно вообще сделано? Две причины: экономия RAM и повышение скорости. Довольно часто между программами нужно обмениваться незначительными объемами информации: "нажата кнопка 5", "переключиться в режим 3", "зажечь светодиод 12". Преимущества перед указателями на сообщения:

если бы мы использовали для передачи такой информации указатели на сообщения, нам бы пришлось тратить 2 байта ОЗУ (3 - для PIC18, 4 для PIC24 и dsPIC) на дескриптор сообщения и 1 байт на тело сообщения, куда будет указывать дескриптор, итого - 3 байта. При использовании короткого сообщения нам понадобится всего 1 байт.
при приеме указателя на сообщение программе потребуется сперва сформировать указатель в FSR, а только потом уже получить доступ к информации. При приеме же короткого сообщения мы получаем информацию напрямую.
для указателей на сообщения нельзя менять содержимое отправленных данных, пока задача-приемник не получила сообщение. При использовании короткого сообщения это ограничение снимается, т.к. все сообщение помещается в дескриптор.

По умолчанию короткое сообщение имеет тип unsigned char. Этот тип может быть заменен на любой перечислимый тип (int, long, float, bit) заданием константы в файле osacfg.h:

#define OS_SMSG_TYPE   unsigned long

Такое, хоть и редко, но бывает нужно.

У короткого сообщения есть две особенности, которые нужно учитывать при проектировании программы:

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

Если две задачи ожидают одного и того же события.

При написании программы с использованием ОСРВ OSA нужно учитывать одну особенность ее планировщика. При поиске лучшей готовой задачи для выполнения планировщик в цикле пробегается по всем дескрипторам, проверяет готовность задач и сравнивает их приоритеты. Управление получит готовая задача с высшим приоритетом. Если есть несколько задач с одинаковым приоритетом, то управление получит та, которая была рассмотрена планировщиком раньше. Дескрипторы задач хранятся в массиве, который планировщиком рассматривается как кольцевой. Каждый раз он начинает поиск готовой задачи со следующей после последней выполненной. Например, у нас 5 задач. Последней задачей выполнялась 3-я. Тогда порядок проверки задач при следующей работе планировщика будет таким: 4, 5, 1, 2, 3.

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

/******************************************************************************/
//  Задача, устанавливающая семафор
/******************************************************************************/
 
void Task1 (void)
{
    for (;;) {
        OS_Bsem_Set(bsem);
        OS_Delay(10);
    }
}
 
/******************************************************************************/
//  Первая задача, ожидающая семафор
/******************************************************************************/
 
void Task2 (void)
{
    for (;;) {
        OS_Bsem_Wait(bsem);
        /*...*/
    }
}
 
/******************************************************************************/
//  Вторая задача, ожидающая семафор
/******************************************************************************/
 
void Task3 (void)
{
    for (;;) {
        OS_Bsem_Wait(bsem);
        /*...*/
    }
}
 
/******************************************************************************/
//
/******************************************************************************/
 
void main (void)
{
    OS_Init();
 
    OS_Task_Create(1, Task1);   // Все задачи с равными приоритетами
    OS_Task_Create(1, Task2);
    OS_Task_Create(1, Task3);
 
    OS_Run();
}

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

Task1 устанавливает семафор bs;
Task2 и Task3 становятся готовыми к выполнению;
после работы Task1 планировщик начинает поиск задачи, начиная со следующей после последней выполненной, т.е. начиная с Task2;
планировщик рассматривает Task2, видит, что она готова; лучший приоритет пока не выбран, поэтому лучшим на данный момент планировщик будет считать 1 (приоритет задачи Task2). Планировщик ее запоминает как кандидата на запуск;
планировщик рассматривает Task3, видит, что она готова, но ее приоритет не лучше, чем текущий лучший, поэтому он эту задачу пропускает;
планировщик рассматривает Task1, видит, что она не готова к выполнению (она в задержке);
управление передается задаче Task2;
Task2 сбрасывает семафор (сервис OS_Bsem_Wait делает это автоматически), отрабатывает какие-то свои действия и возвращается в планировщик;
планировщик начинает просмотр списка задач, начиная с Task3, но уже видит, что семафор сброшен, поэтому Task3 опять ставится в ожидание;
следующей управление получит Task1 по истечении времени задержки, а потом все начнется сначала.

Как тут быть? Единого способа решения нет. Можно ретранслировать семафор дальше, т.е. дождавшись его в Task2, сразу же установить его, чтобы и Task3 смогла получить управление. Но это не лучший вариант, т.к. неизвестно, сколько задач в цепочке, и на какой нужно останавливать установку семафора. Можно использовать счетный семафор, но опять же нужно знать, сколько задач его ожидают, чтобы установить в нем правильное число. На мой взгляд, самым удобным в таком случае будет использование флагов. В задаче-отправителе устанавливать все биты флага:

    /*...*/
    OS_Flag_Set_1(flag, 0xFF);
    /*...*/

а в задачах-приемниках ожидать только своего.

    /* В задаче Task2 */
    OS_Flag_Wait(flag, 0x01);
    OS_Flag_Set_0(flag, 0x01);
 
    /* В задаче Task3 */
    OS_Flag_Wait(flag, 0x02);
    OS_Flag_Set_0(flag, 0x02);

В общем, способы решения есть, а какой применять, - на усмотрение программиста. Главное - надо помнить об этой особенности планировщика.

Модификация тела сообщения до того, как оно будет принято

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

OST_MSG_CB msg_cb;
 
void Task (void)
{
    static char buf[3];
 
    for (;;) {
       // Формируем первое сообщение
       buf[0] = '1';
       buf[1] = '2';
       buf[2] = '3';
       OS_Msg_Send(msg_cb, buf);
       OS_Yield();
 
       // Формируем второе сообщение
       buf[0] = '5';
       buf[1] = '6';
       buf[2] = '7';
       OS_Msg_Send(msg_cb, buf);
       OS_Yield();
 
       /*...*/
   }
}

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

Что произойдет в нашем примере, если после первого OS_Yield задача-адресат не успеет принять отправленное ей сообщение? Фактически ей отправляется только адрес области памяти, где располагается массив buf, в котором на момент отправки лежат значения '1', '2' и '3'. Итак, после выполнения OS_Yield сообщение не было принято. Планировщик возвращает управление задаче отправителю, и она продолжает свое выполнение с того места, откуда вышла, т.е. со следующей строки после OS_Yield. Здесь у нас происходит замена элементов буфера buf на '5', '6' и '7'. После этого задача Task пытается отправить очередное сообщение, но так как предыдущее еще не получено адресатом, то эта задача становится в ожидание, когда дескриптор освободится.

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

Как этого избежать? Всего-навсего перед формированием нового сообщения в том же буфере нужно проверять, было ли предыдущее сообщение доставлено.

       // Формируем первое сообщение
       buf[0] = '1';
       buf[1] = '2';
       buf[2] = '3';
       OS_Msg_Send(msg_cb, buf);
 
       OS_Wait(!OS_Msg_Check(msg_cb));        // Ставим задачу в режим ожидания до тех пор,
                                              // пока сообщение не будет принято
 
       // Формируем второе сообщение
       buf[0] = '5';
       buf[1] = '6';
       buf[2] = '7';
       OS_Msg_Send(msg_cb, buf);
       OS_Yield();

Использование таймеров вне задач

Как статические, так и динамические таймеры могут использоваться в любом месте программы (за исключением сервисов Wait и Delay). Это позволяет:

1. В любом месте программы ожидать какого-то условия с выходом по таймауту.

char MyFunc1 (void)
{
    /*...*/
    OS_Stimer_Run(0, 10);                  // Запускаем статический таймер 0
                                           // на отсчет 10 системных тиков
    while (!RB0 && !OS_Stimer_Check(0))    // Ожидаем установки RB0
        continue;
    /*...*/
}

2. Формировать задержку внутри фоновых функций (не задач).

void MyFunc2 (void)
{
    /*...*/
    OS_Stimer_Run(0, 10);                  // Запускаем статический таймер 0
                                           // на отсчет 10 системных тиков
    while (!OS_Stimer_Check(0)) continue;  // Ожидаем конца счета
    /*...*/
}

3. Выделять квант времени для работы какой-либо функции.

char buffer[10];
 
void Task (void)
{
    static OST_DTIMER dt;
 
    OS_Dtimer_Create(dt);                   // Инициализируем таймер
 
    for (;;)
    {
        OS_Dtimer_Run(dt, 50);              // Выделяем для функции Receive квант
                                            // времени в 50 тиков
        if (Receive(&dt) == 1)
        {
            /*...*/
        }
        /*...*/
    }
}
 
char Receive (OST_DTIMER *dt)
{
    static bit b;
    do
    {
        b = GetBit();                       // Принимаем бит данных
        ShiftBit(b);                        // Вдвигаем его в буфер
 
        if (CheckSumOK()) return 1;         // Проверяем контрольную сумму
 
    } while (!OS_Dtimer_Check(*dt));        // Висим в цикле, пока таймер не досчитает
 
    // Попали сюда, значит ничего не приняли за отведенное время
    return 0;
}

Почему виснет OS_Delay?

"Почему после вызова OS_Delay() задача подвисает, значение таймеров не изменяется, хотя в osacfg.h определена константа OS_ENABLE_TTIMERS?". Как ни странно, вопрос довольно частный.

Ответ: счет таймеров выполняет сервис OS_Timer, который должен периодически вызываться.

Советы по оптимизации

Здесь будут описаны правила, советы и рекомендации по конфигурированию OSA, а также по применению сервисов OSA с целью увеличения эффективности использования ресурсов микроконтроллера. Есть три ресурса, которые хотелось бы сэкономить: RAM, ROM и время. Сначала я предполагал разбить этот раздел на три части, посвятив каждую из них своему параметру. Однако, получилось так, что приемы и советы по экономии RAM и ROM практически идентичны, поэтому им будет посвящена одна часть.

Оптимизация памяти

Оптимизация скорости

Оптимизация памяти

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

Отключение приоритетов

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

По умолчанию приоритетность включена. Отключить ее можно, задав в файле osacfg.h константу:

#define OS_DISABLE_PRIORITY

Размерность таймеров

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

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

По умолчанию размерность таймера равна двум байтам. Это покрывает большую часть потребностей в организации задержек в программах. Такие таймеры могут отсчитывать до 65535 системных тиков (периодов вызова OS_Timer). Больше обычно не нужно. Но зато часто встречаются случаи, когда все задержки (и ожидания событий с таймаутами) не длиннее 255 тиков. Например, OS_Timer вызывается в обработчике прерывания по TMR2, настроенного так, чтобы его период был 10 мс. В этом случае, используя отсчет таймера в 255 тиков, мы получаем задержку в 2.5 секунды. Для многих приложений этого более чем достаточно.

Поэтому во многих случаях есть смысл таймеры задач сделать однобайтовыми. Делается это заданием размерности таймера в файле osacfg.h:

#define OS_TTIMER_SIZE      1

Что мы выигрываем, уменьшив размерность таймеров задач?

Во-первых, функция инициализации таймера в своих параметрах будет получать не 2 байта, а один (кто знаком со внутренней организацией HT-PICC, знают, что однобайтовый параметр передается напрямую через WREG, в то время как двухбайтовый требует для передачи дополнительную ячейку памяти);
Во-вторых, сильно сокращается код функции OS_Timer(). Дело в том, что эта функция для сокращения размера кода и скорости работы увеличивает все таймеры не в цикле, а по очереди напрямую. Поэтому уменьшение размерности таймера задач уменьшит размер функции пропорционально количеству задач (чем больше задач, тем сильнее сократится OS_Timer);
В-третьих, все дескрипторы задач станут на один байт меньше (при 10 задачах в системе уже экономия в 10 байт, а для PIC16 это немало).

Примечание 1. Размерность можно также менять и у статических, и у динамических таймеров.
Примечание 2. Для 16-разрядных контроллеров (PIC24 и dsPIC) уменьшение размерности таймера до одного байта не приведет к сокращению кода или экономии RAM.

Замена таймеров задач статическими таймерами

Иногда при дефиците ресурсов может оказаться полезным воспользоваться статическими таймерами, вместо таймеров задач. При включении таймеров задач (включаются определением константы OS_ENABLE_TTIMERS) появляется возможность использовать в задачах задержки (OS_Delay) и ожидание событий с выходом по таймауту (OS_xxx_Wait_TO). За каждым дескриптором задачи при этом закрепляется свой таймер (так называемый таймер задач), и их будет столько, сколько дескрипторов зарезервировано в osacfg.h (константа OS_TASKS). Получается, что если у нас 10 задач, а таймеры используются, например, только в трех, то мы имеем в памяти 7 переменных, которые не используются, но занимают место.

В таких случаях имеет смысл отключить таймеры задач и воспользоваться статическими таймерами. Для нашего примера мы определяем константу в osacfg.h:

#define OS_STIMERS     3

И теперь у нас только 3 ячейки памяти занято таймерами, а мы сэкономили 7 ячеек. При двухбайтовых таймерах это 14 байт оперативной памяти. Теперь задержки в задачах будут выглядеть так:

    OS_Stimer_Delay(ST_ID, 100);

где ST_ID - номер статического таймера (от 0 до 2 в нашем примере).

Как заменить сервисы ожидания с выходом по таймауту, если все сервисы OS_xxx_Wait_TO требуют наличия таймеров задач? Очень просто, воспользовавшись сервисом OS_Cond_Wait, который позволяет ожидать в задаче любое условие. Например, мы ждем сообщение из очереди:

    // С таймерами задач
    OS_Queue_Wait_TO(queue, msg, 100);
    if (!OS_IsTimeout)
    {
        /* обрабатываем сообщение */
    }
 
    // Без таймеров задач, но со статическими таймерами
    OS_Stimer_Run(0, 100);
    OS_Cond_Wait(OS_Queue_Check(queue) && !OS_Stimer_Check(0));
    if (!OS_Stimer_Check(0))
    {
        OS_Queue_Accept(queue, msg);
        /* обрабатываем сообщение */
    }

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

Итак, что мы выигрываем от замены таймеров задач статическими таймерами?

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

Теряем мы удобство и наглядность.

Еще одно применение статических таймеров можно рассмотреть в контексте предыдущего параграфа (Размерность таймеров). Там мы указали, что часто бывает так, что задержки в задачах не превышают 255 системных тиков. Но бывает и так, что в 9-ти задачах не превышают, а 10-ой, хоть тресни, нужен 32-разрядный таймер. Понятно, что из-за одной задачи не хотелось бы всем приделывать 4-байтовые таймеры. Поэтому удобно организовать один 4-байтовый статический таймер для этой задачи, а всем остальным определить 1-байтовые. Вот фрагмент файла osacfg.h:

#define OS_ENABLE_TTIMERS          // Разрешаем использование таймеров задач
#define OS_TTIMER_SIZE      1      // Размерность таймеров задач
#define OS_STIMERS          1      // Определяем один статический таймер
#define OS_STIMER_SIZE      4      // Размерность статического таймера

OS_Timer inline

Сервис OS_Timer вызывает системную функции _OS_Timer(). Учитывая, что чаще всего вызов этого сервиса производят по переполнению какого-либо таймера (TMR0, TMR1, TMR2), обычно он располагается внутри функции-прерывания. Компиляторы от HTSoft в таком случае ведут себя следующим образом: т.к. сама функция _OS_Timer() относительно функции прерывания находится во внешнем другом модуле, то функция прерывания ничего не знает о ресурсах, которые использует _OS_Timer(), поэтому при входе в прерывание сохраняются все критичные регистры, которые, по предположению компилятора, может изменить внешняя функция. К ним относятся: все FSR, пара PRODH:PROLH, 15 регистров btemp, и тройка регистров TABLAT, TBLPTRH:TBLPTRL. Возможно в самом прерывании они и не используются, а все прерывание выглядит так:

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

Но на этапе компиляции файла, содержащего код прерывания, компилятор не знает, что творится внутри функции, вызываемой сервисом OS_Timer. Сохранение/восстановление при входе/выходе из прерывания занимает более 100 слов памяти ROM и, соответственно, более 100 машинных циклов. Т.е. если у нас таймер запрограммирован так, чтобы прерывание происходило каждые 256 циклов, то более 40% всего процессорного времени будет тратиться только на вход и выход из прерывания.

В ОСРВ OSA есть возможность вместо вызова функции _OS_Timer подставлять ее тело напрямую. Для этого нужно определить константу в файле osacfg.h:

#define OS_USE_INLINE_TIMER

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

Размещение переменных

(Этот параграф имеет отношение не столько к OSA, сколько к PIC18)

Для PIC18 некоторый выигрыш по программной памяти даст размещение переменных в ACCESS-банке (первые 128 или 96 байт RAM-памяти). Обращение к таким переменным производится без предварительной установки регистра BSR, следовательно, при частом обращении к ним можно сэкономить на всех инструкциях movlb. Свои переменные можно размещать в этом банке вручную. Например, для HT-PICC18:

near char a;
near int  i;

для MCC18:

#pragma udata access my_vars
near char a;
near int  i;

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

#define OS_BANK_OS          0         // Размещение системных переменных
#define OS_BANK_TASKS       1         // Размещение дескрипторов задач
#define OS_BANK_BSEMS       0         // Размещение двоичных семафоров
#define OS_BANK_OS          1         // Размещение статических таймеров

Отправка сообщений

Обычно сообщения отправляются сервисом OS_Msg_Send. Как этот сервис работает? Предварительно он проверяет, занят дескриптор сообщения или свободен (т.е. обработано ли предыдущее сообщение или еще нет). Если дескриптор занят, то задача становится в режим ожидания и передает управление планировщику. Иногда бывает так, что не принципиально, обработалось предыдущее сообщение или нет. Например, задача измеряет напряжение бортовой сети автомобиля и сообщением отправляет его головной задаче. Головной задаче не важна последовательность изменений напряжения, ей нужно текущее значение. Поэтому иногда нет смысла выполнять лишние операции по проверки занятости дескриптора, по формированию адреса возврата, да еще задержки на неопределенное время. Для отправки сообщения, не дожидаясь освобождения дескриптора (т.е. фактически для перетирания старого тела сообщения новым), можно пользоваться сервисом:

    OS_Msg_Send_Now(msg_cb, msg);

Например, для PIC16 этот сервис занимает 7 слов программной памяти, в то время как OS_Msg_Send требует 17 слов.

Примечание. Это же относится к отправке коротких сообщений, а также к отправке сообщений и коротких сообщений в очередь.

Очереди сообщений

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

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

#define OS_QUEUE_SQUEUE_IDENTICAL

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

Оптимизация скорости

Выбор приоритетов

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

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

Учитывая, что полное время проверки готовности одной задачи (с выбором адреса задачи, с передачей ей управления для проверки готовности, с самой проверкой и с возвратом в планировщик) длится около 70 тактов. И если у нас 10 задач, то общий поиск будет длиться около 700 тактов. Если же присутствует задача с нулевым приоритетом, то в случае ее готовности время работы планировщика сократится в среднем вдвое (это время будет колебаться от 70 до 700 тактов в зависимости от того, с какой задачи планировщик начинает просмотр).

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

Полное отключение приоритетов

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

Замена ожидания на задержку

Два слова о том, как проверяется условие при ожидании. Например, задача ожидает установку двоичного семафора. Что при этом происходит:

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

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

Теперь рассмотрим поведение планировщика, когда какая-либо задача находится в ожидании задержки OS_Delay. Что происходит, когда задача выполняет OS_Delay(100):

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

(Примечание. Бит bDelay сбрасывается обработчиком сервиса OS_Timer).

Т.е. при выполнении задачей задержки OS_Delay планировщик не передает управление задаче до конца задержки. Т.е. не теряет 50 тактов на заход внутрь задачи и проверку условия.

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

    // Обычное ожидание события
    OS_Bsem_Wait(0);
 
    // Ожидание, которое ускорит работу планировщика
    do {
        OS_Delay(10);              // Проверяем условие с интервалом в 10 системных тиков
    } while (!OS_Check_Bsem(0));

Примечание. Эффективной будет только задержка с использованием таймеров задач. Статический и динамические таймеры здесь не подойдут.(К списку советов по оптимизации)

Проверка условия перед ожиданием

Вернемся к описанию работы планировщика при ожидании события в какой-либо задаче, описанному в предыдущем параграфе. Как видно, вне зависимости от того, произошло событие на момент проверки или нет, мы по-любому передаем управление планировщику. Объяснение такому поведению уже приводилось: среди задач может оказаться более приоритетная, ожидающая этого же события, и управление должно быть сперва передано ей. Но допустим, что мы на 100% уверены, что второй задачи, ожидающей того же события нет. А нам жалко терять время на выход из задачи и на ожидание того, когда она станет самой приоритетной. Поэтому в таком случае можно прибегнуть к следующему приему:

    if (!OS_Bsem_Check(0)) OS_Bsem_Wait(0);

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

Заключение

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

Возможно, в этой статье я не коснулся каких-то важных моментов, которые нужно было рассмотреть, или Вы, читая статью, не нашли ответ на свой вопрос, или из-за местами непонятного изложения появился какой-то новый вопрос. Может, есть какие-то замечания или предложения, - не стесняйтесь, пишите на мейл osa@pic24.ru или testerplus@mail.ru.

Все личные имена, встречающиеся в статье, приведены с разрешения личностей, эти имена носящих.

На сайте www.pic24.ru статья размещена с разрешения Alex'а B.

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

Программирование микроконтроллеров с использованием ОСРВ OSA

2010-02-23T23:07:07+03:00

Программирование микроконтроллеров с использованием ОСРВ OSA

Виктор Тимофеев, osa@pic24.ru (февраль, 2009)

(ОСРВ - операционная система реального времени)

Статья разделена на несколько частей:

Зачем контроллеру "ось"? - здесь приводятся предпосылки и аргументы в пользу использования ОСРВ в некоторых проектах;
Общие рекомендации - некоторые рекомендации по использованию ОСРВ;
FAQ по ОСРВ OSA - самые частые вопросы от программистов;
Советы по оптимизации - некоторые приемы и рекомендации по конфигурированию OSA для поднятия производительности системы;
Заключение

Зачем контроллеру "ось"?

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

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

OSA относится к системам мягкого реального времени, т.к., являясь кооперативной, допускает захват ресурсов низкоприоритетной задачей на длительное время, не давая выполниться более приоритетным, т.е. не давая остальным задачам среагировать на событие в заданный промежуток времени. Этого недостатка лишены вытесняющие ОСРВ, в которых ядро в любой момент может прервать выполнение низкоприоритетной задачи и передать управление готовой к выполнению более приоритетной. Однако, вытесняющая ОСРВ не сможет работать на платформе без программно доступного стека. Контроллеры PIC серий 10, 12, 14 и 16 имеют именно такую платформу. Но зачем же тогда OSA поддерживает и старшие семейства этих контроллеров, если для них уже возможно использование вытесняющих ОСРВ? Здесь есть две причины:

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

Что хорошего дает использование ОСРВ

Так зачем же нужна операционная система в контроллерах? Я бы назвал несколько причин.

Что мы теряем, используя ОСРВ

За все выше перечисленные полезности придется платить.

Можно ли обойтись без ОСРВ?

Резюме

Общие рекомендации

2010-02-23T23:08:04+03:00

Общие рекомендации

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

Не используйте ОСРВ там, где это не нужно

"выполняет возложенные на нее функции";
"лишь бы влезла в выбранный контроллер";
"использованы продвинутые решения (ОСРВ)".

Важно учитывать также второстепенные:

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

Не злоупотребляйте использованием сервисов ОСРВ

    OS_Csem_SetValue(csem, 10);
    do {
        /*...*/
        OS_Csem_Accept(csem);
    } while (OS_Csem_Check(scem));

    i = 10;
    do {
        /*...*/
    } while (--i);

    // CLC - ножка CLOCK
    // DIO - ножка DATA
    // (прим. - В.Т.)
 
    OS_Cond_Wait(CLC);
 
    if (DIO)  OS_Flag_Set_1(data, mask);
    else      OS_Flag_Set_0(data, mask);
 
    mask <<= 1;
    if (!mask) ...

    OS_Cond_Wait(CLC);
 
    if (DIO)  data |=  mask;
    else      data &= ~mask;
 
    mask <<= 1;
    if (!mask) ...

Поэтому я подведу итог:

Не забывайте о прерываниях

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

void Task_Iinterrupt_INTF (void)
{
    for (;;)
    {
        OS_Cond_Wait(INTF);
        INTF = 0;
        /* Далее следует ко добработки прерывания */
    }
}

Неэффективность такого подхода очевидна:

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

О глобальных переменных

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

Как разбить программу на задачи

void Task_Relay1 (void)
{
    for (;;)
    {
        OS_Bsem_Wait(BS_RELAY1);
        RELAY1 = 1;
        OS_Delay(100);
        RELAY1 = 0;
    }
}

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

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

Как расставлять приоритеты

Тем не менее, в программах под кооперативными ОСРВ бывают случаи, когда приоритетность выручает.

FAQ по ОСРВ OSA

2010-02-23T23:09:16+03:00

FAQ по ОСРВ OSA

Здесь я собрал ответы на самые распространенные вопросы по OSA.

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

Ответ: нет.

    // В этом примере просто напрашивается вынос OS_Delay(10) в отдельную функцию.
    // Сам вызов сервиса занимает около 10 слов ROM, и его, конечно, хочется
    // заменить одним вызовом.
    ...
    OS_Delay(10);
    ...
    if (...) OS_Delay(10);
    ...
    do {
        ...
        OS_Delay(10);
        ...
    } while (...);
    ...

или когда есть несколько задач, ожидающих одно и то же событие:

    ...
    // Ждем, когда освободится доступ в EEPROM
    OS_Bsem_Wait(BS_EEPROM_FREE);
    ...

//-----------------------------------------------
void Delay10 (void)
{
    OS_Delay(10);
}
 
//-----------------------------------------------
void Bsem_Wait (void)
{
    OS_Bsem_Wait(BS_BINSEM);
}
 
//-----------------------------------------------
void TaskA (void)
{
    for (;;)
    {
        Delay10();
        /*...*/
        Delay10();
        /*...*/
        Delay10();
        /*...*/
    }
}
 
//-----------------------------------------------
void TaskB (void)
{
    for (;;)
    {
        Bsem_Wait();
        /*...*/
        Bsem_Wait();
        /*...*/
        Bsem_Wait();
        /*...*/
    }
}
 
//-----------------------------------------------

.	Действие	Передача управления	Стек
1	Планировщик запускает задачу TaskA	PCLATH:PCL=TaskA	-
2	Задача TaskA вызывает функцию Delay10()	CALL Delay10.	ret_addr_A -
3	Функция Delay10 вызывает системный сервис OS_Delay, который, инициализировав задержку, передает управление планировщику	GOTO sched	ret_addr_A -
4	Планировщик запускает задачу TaskB	PCLATH:PCL=TaskB	ret_addr_A -
5	Задача TaskB вызывает функцию Bsem_Wait()	CALL Bsem_Wait	ret_addr_B ret_addr_A -
6	Функция Bsem_Wait вызывает системный сервис OS_Bsem_Wait, который передает управление планировщику	GOTO sched	ret_addr_B ret_addr_A -
7	Планировщик крутится вхолостую, пока идет задержка, запущенная в задаче TaskA и пока не установлен семафор, которого ожидает задача TaskB		ret_addr_B ret_addr_A -
8	Задержка закончилась, плнировщик передает управление задаче TaskA в то же место, откуда был возврат в планировщик, а именно - в середину функиции Delay10	PCLATH:PCL=Delay10	ret_addr_B ret_addr_A -
9	И теперь - кульминация: функция делает возврат, при котором из стека берется последний положенный туда адрес, а именно - ret_addr_B	RETURN	ret_addr_A -

Ожидание события в цикле

Код такого ожидания выглядел так:

    do
    {
        if (ADC_Read(0) > ADC_Read(1))    // Сравниваем напряжения на двух аналоговых входах
        {
            GREEN_LED = 1;
            RED_LED = 0;
        } else {
            GREEN_LED = 0;
            RED_LED = 1;
        }
 
        OS_Yield();                       // Возврат в планировщик
 
    } while (!OS_Bsem_Check(BS_START));

Как быть в таких случаях? Здесь есть несколько вариантов решения этой коллизии.

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

OST_TASK_POINTER tp;
 
/******************************************************************************/
//  Отдельная задача для работы с АЦП и светодиодами
/******************************************************************************/
 
void Task_ADC_Leds (void)
{
   tp = OS_GetCurTask();
   for (;;)
   {
        /*...*/
        /* Здесь сравниваем напряжения */
        /*...*/
 
        OS_Yield();                       // Возврат в планировщик
   }
}
 
/******************************************************************************/
//  Наша задача
/******************************************************************************/
 
void Task (void)
{
    for (;;)
    {
        /*...*/
        // Перед ожиданием создаем задачу сравнения напряжений
        OS_Task_Create(7, Task_ADC_Leds);
 
        // Ждем наш семафор
        OS_Bsem_Wait(BS_START);
 
        // Удаляем задачу сравнения напряжений
        OS_Task_Delete(tp);
 
        /*...*/
    }
}

2. Понизить приоритет на время ожидания

    static char prio;
    /*...*/
    prio = OS_Task_GetPriority(this_task);   // Запоминаем текущий приоритет задачи
    OS_Task_SetPriority(this_task, 7);       // Понижаем приоритет до минимального
    do {
        /*...*/
        /* Здесь сравниваем напряжения */
        /*...*/
        OS_Yield();
    } while (!OS_Bsem_Check(BS_START));
 
    OS_Task_SetPriority(this_task, prio);    // После цикла восстанавливаем сохраненный
                                             // приоритет

3. Вставить в цикл небольшую задержку

    do {
        /*...*/
        /* Здесь сравниваем напряжения */
        /*...*/
        OS_Delay(1);
    } while (!OS_Bsem_Check(BS_START));

Можно ли создать задачу по указателю на функцию?

Ответ: да

typedef struct
{
    const char* strMenu;
    void  (*Func)(void);
} TMenuItem;

Далее в программе определен массив этих структур:

const TMenuItem UserMenu[] = {
    {"Load", Task_Load},
    {"Save", Task_Save},
    {"View", Task_View}
    {"Edit", Task_Edit}
};

Все эти задачи описываются как обычно, например:

void Task_Load (void)
{
    for (;;)
    {
        /*...*/
    }
}

void main (void)
{
    /*...*/
    OS_Task_Reserve(Task_Load);
    OS_Task_Reserve(Task_Save);
    OS_Task_Reserve(Task_View);
    OS_Task_Reserve(Task_Edit);
    /*...*/
}

    LCD_Out(UserMenu[i].strMenu);        // Выводим на экран название функции
    OS_Task_CreateP(0, UserMenu[i].Func); // Создаем задачу с высшим приоритетом

Что будет, если отсылать/принимать сообщения из неинициализированной очереди?

Ответ: ничего хорошего

Рекомендую проанализировать работу следующего примера:

OST_QUEUE q;
OST_MSG   smsg;
OST_MSG   rmsg;
 
void Task1 (void)
{
    OS_Queue_Create(q);          // Создаем очередь (инициализируем)
    for (;;)
    {
        OS_Queue_Send(q, smsg);  // Отсылаем сообщение в очередь
    }
}
 
void Task2 (void)
{
    for (;;)
    {
        OS_Queue_Wait(q, rmsg);  // Ожидаем сообщение из очереди
    }
}
 
void main (void)
{
    OS_Init();
    OS_Task_Create(1, Task1);
    OS_Task_Create(0, Task2);
    OS_Run();
}

Изменение типов сообщений

#define OS_MSG_TYPE    const char *

OST_MSG_CB  msg_cb;        // Дескриптор сообщения
 
const char * MenuStrings[] = {"Load", "Save", "Save as...", "Exit"};
 
void Task_Menu (void)
{
    for (;;)
    {
        for (i = 0; i < 4; i++)
            OS_Msg_Send(msg_cb, MenuString[i]);
        /*...*/
    }
 
}

typedef struct {
    char*   name;
    int     age;
    int     weight;
} TMyStruct;
 
#define OS_MSG_TYPE   TMyStruct *

если бы мы использовали для передачи такой информации указатели на сообщения, нам бы пришлось тратить 2 байта ОЗУ (3 - для PIC18, 4 для PIC24 и dsPIC) на дескриптор сообщения и 1 байт на тело сообщения, куда будет указывать дескриптор, итого - 3 байта. При использовании короткого сообщения нам понадобится всего 1 байт.
при приеме указателя на сообщение программе потребуется сперва сформировать указатель в FSR, а только потом уже получить доступ к информации. При приеме же короткого сообщения мы получаем информацию напрямую.
для указателей на сообщения нельзя менять содержимое отправленных данных, пока задача-приемник не получила сообщение. При использовании короткого сообщения это ограничение снимается, т.к. все сообщение помещается в дескриптор.

#define OS_SMSG_TYPE   unsigned long

Такое, хоть и редко, но бывает нужно.

У короткого сообщения есть две особенности, которые нужно учитывать при проектировании программы:

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

Если две задачи ожидают одного и того же события.

/******************************************************************************/
//  Задача, устанавливающая семафор
/******************************************************************************/
 
void Task1 (void)
{
    for (;;) {
        OS_Bsem_Set(bsem);
        OS_Delay(10);
    }
}
 
/******************************************************************************/
//  Первая задача, ожидающая семафор
/******************************************************************************/
 
void Task2 (void)
{
    for (;;) {
        OS_Bsem_Wait(bsem);
        /*...*/
    }
}
 
/******************************************************************************/
//  Вторая задача, ожидающая семафор
/******************************************************************************/
 
void Task3 (void)
{
    for (;;) {
        OS_Bsem_Wait(bsem);
        /*...*/
    }
}
 
/******************************************************************************/
//
/******************************************************************************/
 
void main (void)
{
    OS_Init();
 
    OS_Task_Create(1, Task1);   // Все задачи с равными приоритетами
    OS_Task_Create(1, Task2);
    OS_Task_Create(1, Task3);
 
    OS_Run();
}

Task1 устанавливает семафор bs;
Task2 и Task3 становятся готовыми к выполнению;
после работы Task1 планировщик начинает поиск задачи, начиная со следующей после последней выполненной, т.е. начиная с Task2;
планировщик рассматривает Task2, видит, что она готова; лучший приоритет пока не выбран, поэтому лучшим на данный момент планировщик будет считать 1 (приоритет задачи Task2). Планировщик ее запоминает как кандидата на запуск;
планировщик рассматривает Task3, видит, что она готова, но ее приоритет не лучше, чем текущий лучший, поэтому он эту задачу пропускает;
планировщик рассматривает Task1, видит, что она не готова к выполнению (она в задержке);
управление передается задаче Task2;
Task2 сбрасывает семафор (сервис OS_Bsem_Wait делает это автоматически), отрабатывает какие-то свои действия и возвращается в планировщик;
планировщик начинает просмотр списка задач, начиная с Task3, но уже видит, что семафор сброшен, поэтому Task3 опять ставится в ожидание;
следующей управление получит Task1 по истечении времени задержки, а потом все начнется сначала.

    /*...*/
    OS_Flag_Set_1(flag, 0xFF);
    /*...*/

а в задачах-приемниках ожидать только своего.

    /* В задаче Task2 */
    OS_Flag_Wait(flag, 0x01);
    OS_Flag_Set_0(flag, 0x01);
 
    /* В задаче Task3 */
    OS_Flag_Wait(flag, 0x02);
    OS_Flag_Set_0(flag, 0x02);

Модификация тела сообщения до того, как оно будет принято

OST_MSG_CB msg_cb;
 
void Task (void)
{
    static char buf[3];
 
    for (;;) {
       // Формируем первое сообщение
       buf[0] = '1';
       buf[1] = '2';
       buf[2] = '3';
       OS_Msg_Send(msg_cb, buf);
       OS_Yield();
 
       // Формируем второе сообщение
       buf[0] = '5';
       buf[1] = '6';
       buf[2] = '7';
       OS_Msg_Send(msg_cb, buf);
       OS_Yield();
 
       /*...*/
   }
}

       // Формируем первое сообщение
       buf[0] = '1';
       buf[1] = '2';
       buf[2] = '3';
       OS_Msg_Send(msg_cb, buf);
 
       OS_Cond_Wait(!OS_Msg_Check(msg_cb));   // Ставим задачу в режим ожидания до тех пор,
                                              // пока сообщение не будет принято
 
       // Формируем второе сообщение
       buf[0] = '5';
       buf[1] = '6';
       buf[2] = '7';
       OS_Msg_Send(msg_cb, buf);
       OS_Yield();

Использование таймеров вне задач

1. В любом месте программы ожидать какого-то условия с выходом по таймауту.

char MyFunc1 (void)
{
    /*...*/
    OS_Stimer_Run(0, 10);                  // Запускаем статический таймер 0
                                           // на отсчет 10 системных тиков
    while (!RB0 && !OS_Stimer_Check(0))    // Ожидаем установки RB0
        continue;
    /*...*/
}

2. Формировать задержку внутри фоновых функций (не задач).

void MyFunc2 (void)
{
    /*...*/
    OS_Stimer_Run(0, 10);                  // Запускаем статический таймер 0
                                           // на отсчет 10 системных тиков
    while (!OS_Stimer_Check(0)) continue;  // Ожидаем конца счета
    /*...*/
}

3. Выделять квант времени для работы какой-либо функции.

char buffer[10];
 
void Task (void)
{
    static OST_DTIMER dt;
 
    OS_Dtimer_Create(dt);                   // Инициализируем таймер
 
    for (;;)
    {
        OS_Dtimer_Run(dt, 50);              // Выделяем для функции Receive квант
                                            // времени в 50 тиков
        if (Receive(&dt) == 1)
        {
            /*...*/
        }
        /*...*/
    }
}
 
char Receive (OST_DTIMER *dt)
{
    static bit b;
    do
    {
        b = GetBit();                       // Принимаем бит данных
        ShiftBit(b);                        // Вдвигаем его в буфер
 
        if (CheckSumOK()) return 1;         // Проверяем контрольную сумму
 
    } while (!OS_Dtimer_Check(*dt));        // Висим в цикле, пока таймер не досчитает
 
    // Попали сюда, значит ничего не приняли за отведенное время
    return 0;
}

Почему виснет OS_Delay?

Ответ: счет таймеров выполняет сервис OS_Timer, который должен периодически вызываться.

Советы по оптимизации

2010-02-23T23:13:16+03:00

Советы по оптимизации

Оптимизация памяти

Отключение приоритетов
Размерность таймеров
Замена таймеров задач статическими таймерами
OS_Timer inline
Размещение переменных
Отправка сообщений
Очереди сообщений

Оптимизация скорости

Выбор приоритетов
Отключение приоритетов
Замена ожидания на задержку
Проверка условия перед ожиданием

Оптимизация памяти

Отключение приоритетов

По умолчанию приоритетность включена. Отключить ее можно, задав в файле osacfg.h константу:

#define OS_DISABLE_PRIORITY

Размерность таймеров

#define OS_TTIMER_SIZE      1

Что мы выигрываем, уменьшив размерность таймеров задач?

Во-первых, функция инициализации таймера в своих параметрах будет получать не 2 байта, а один (кто знаком со внутренней организацией HT-PICC, знают, что однобайтовый параметр передается напрямую через WREG, в то время как двухбайтовый требует для передачи дополнительную ячейку памяти);
Во-вторых, сильно сокращается код функции OS_Timer(). Дело в том, что эта функция для сокращения размера кода и скорости работы увеличивает все таймеры не в цикле, а по очереди напрямую. Поэтому уменьшение размерности таймера задач уменьшит размер функции пропорционально количеству задач (чем больше задач, тем сильнее сократится OS_Timer);
В-третьих, все дескрипторы задач станут на один байт меньше (при 10 задачах в системе уже экономия в 10 байт, а для PIC16 это немало).

Замена таймеров задач статическими таймерами

#define OS_STIMERS     3

    OS_Stimer_Delay(ST_ID, 100);

где ST_ID - номер статического таймера (от 0 до 2 в нашем примере).

    // С таймерами задач
    OS_Queue_Wait_TO(queue, msg, 100);
    if (!OS_IsTimeout)
    {
        /* обрабатываем сообщение */
    }
 
    // Без таймеров задач, но со статическими таймерами
    OS_Stimer_Run(0, 100);
    OS_Cond_Wait(OS_Queue_Check(queue) && !OS_Stimer_Check(0));
    if (!OS_Stimer_Check(0))
    {
        OS_Queue_Accept(queue, msg);
        /* обрабатываем сообщение */
    }

Итак, что мы выигрываем от замены таймеров задач статическими таймерами?

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

Теряем мы удобство и наглядность.

#define OS_ENABLE_TTIMERS          // Разрешаем использование таймеров задач
#define OS_TTIMER_SIZE      1      // Размерность таймеров задач
#define OS_STIMERS          1      // Определяем один статический таймер
#define OS_STIMER_SIZE      4      // Размерность статического таймера

OS_Timer inline

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

#define OS_USE_INLINE_TIMER

Размещение переменных

(Этот параграф имеет отношение не столько к OSA, сколько к PIC18)

near char a;
near int  i;

для MCC18:

#pragma udata access my_vars
near char a;
near int  i;

#define OS_BANK_OS          0         // Размещение системных переменных
#define OS_BANK_TASKS       1         // Размещение дескрипторов задач
#define OS_BANK_BSEMS       0         // Размещение двоичных семафоров
#define OS_BANK_OS          1         // Размещение статических таймеров

Отправка сообщений

    OS_Msg_Send_Now(msg_cb, msg);

Например, для PIC16 этот сервис занимает 7 слов программной памяти, в то время как OS_Msg_Send требует 17 слов.

Очереди сообщений

#define OS_QUEUE_SQUEUE_IDENTICAL

Оптимизация скорости

Выбор приоритетов

Полное отключение приоритетов

Замена ожидания на задержку

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

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

(Примечание. Бит bDelay сбрасывается обработчиком сервиса OS_Timer).

    // Обычное ожидание события
    OS_Bsem_Wait(0);
 
    // Ожидание, которое ускорит работу планировщика
    do {
        OS_Delay(10);              // Проверяем условие с интервалом в 10 системных тиков
    } while (!OS_Check_Bsem(0));

Проверка условия перед ожиданием

    if (!OS_Bsem_Check(0)) OS_Bsem_Wait(0);

Заключение

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

Язык SCL

2010-05-28T09:44:20+03:00

Язык SCL

Виктор Тимофеев, ноябрь 2009
osa@pic24.ru

Введение

Интегрированная среда MPLAB IDE имеет в своем составе встроенный симулятор, который позволяет отлаживать программу еще до программирования микросхемы. Для приближения к реальным условиям MPLAB предоставляет возможность имитировать входные сигналы с помощью встроенного инструмента Stimulus. С помощью него можно имитировать уровни на портах ввода вывода и значения регистров, причем можно привязывать эти события ко времени, к состояниям или изменениям состояний портов и регистров. Для этого интегрированной средой MPLAB предоставляется диалоговое окно (доступно через меню "Debugger/Stimulus"), в котором пользователю предлагается задать внешние воздействия.

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

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

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

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

Помимо самой этой статьи, я бы рекомендовал ознакомиться с двумя ветками на форуме microchip.com (на английском языке):

SCL PRIMER / TUTORIAL - краткое описание языка SCL;
SCL Code repository - несколько примеров скриптов на языке SCL.

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

Описание языка

Идентификаторы

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

MyVariable
My_Variable
My_Variable_1

Имена идентификаторов чувствительны к регистру. Имена идентификаторов не могут совпадать с зарезервированными словами.

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

Основное тело программы заключено в операторные скобки testbench:

configuration for "pic16f877a" is
end configuration;
 
testbench for "pic16f877a" is
 
-- Тело программы
 
end testbench;

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

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

Label: process [(sensitivity_list)] is
    [Определения]
begin
 
    [Тело процесса]
 
end process Label;

Здесь:

Label	необязательное поле - идентификатор процесса
process … is	ключевое слово, обозначающее блок описания процесса
sensitivity_list	необязательное поле - список сигналов, по изменению которых процесс запускается.
begin … end process;	операторные скобки, внутри которых заключается тело процесса
Определения	необязательная секция, где определяются пользовательские типы, переменные и константы
Тело процесса	это уже последовательность действий, описанная операторами языка. После ключевой фразы "process is" идет необязательная секция описания типов, констант и переменных. Для программы на языке SCL типы, константы и переменные являются глобальными для всех процессов, описанных ниже (для процессов описанных выше они невидимы)

Примеры:

-- При каждом изменении состояния портов RA0 или RB1 переменная i будет увеличиваться на 1
TEST: process (RA0,RB1) is
    variable i:    integer;
begin
    i := i + 1;
end process TEST;

-- генерация меандра 1 KHz
process is
begin
    RB0 := not RB0;
    wait for 500 us;
end process;

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

Комментарии в языке SCL могут начинаться с "--", как в VHDL, или с "//", как в Си. Все, что следует за символами "--" или "//" считается комментарием и игнорируется при трансляции.

Типы

Язык SCL является строго типизированным, т.е. в нем не допускается смешение типов в одной операции (например, нельзя присваивать переменной типа integer переменную типа bit; или нельзя суммировать переменную типа byte с переменной типа time).

На данный момент язык SCL поддерживает следующие типы данных:

Перечислимые

integer	32-битное целое знаковое
byte	= integer
word	= integer
boolean	Логический тип, может принимать значения true или false
bit	Битовый тип, может принимать значения '0' или '1'
character	Символьный.
paddress	Адрес в памяти программы. 24-битовое беззнаковое целое.
daddress	Адрес в памяти данных. 24-битовое беззнаковое целое.

Временные

time	Временной. Знаковое 64-битное целое, задается в пикосекундах. Однако можно указать другие единицы измерения: ns, us, ms, sec, min, hr.
cycle	Схожий с временным типом, только время задается в циклах. Задается в виде числа с указанием единиц измерения ic (instruction cycle).
frequency	Частотный. Задается в герцах (от 0 до 1e9). Может задаваться с явным указанием единиц измерения: hz, khz, mhz.

Строковые

string	Текстовая строка. Представляет собой массив character'ов (type string is array (integer range <>) of character;). Применяется для вывода информации по ходу симуляции
line	Строка для обработки данных. Может быть прочитана из файла и обработана.

Файловые

text	Файловый. Применяется для чтения файлов (запись через этот тип произвести не удается).
file_open_kind	Тип открываемого файла. Может принимать значения: read_mode, write_mode, append_mode. (Удалось заставить работать только в режиме read_mode)
file_open_status	Состояние открытого файла. Может принимать значения: open_ok, status_error, name_error, mode_error

Остальные

severity_level	тип сообщения в операторе report. Может принимать значения: note, warning, error, failure.
array	позволяет определять массивы. Но в настоящее время толку от них мало, т.к. нет возможности обращаться к элементу массива по индексу
bit_vector	массив битов. Также нет возможности обращаться к элементам по индексу
record	Структура. Позволяет обращаться к битовым переменным SFR (например, ADCON.ADON).

Константы

Способы задания констант

Целые числа можно задавать с указанием системы счисления или без нее (по умолчанию число считается записанным в десятичной системе):

система_счисления#число# Причем поле "число" может содержать не только цифры (и буквы A,B,C,D,E,F), но и символ подчеркивания '_', что очень удобно для более наглядного представления длинных чисел. Например, число 168 можно записать так:

168
10#168#
16#A8#
2#10101000#
2#1010_1000#

Времена можно задавать в виде целого или вещественного числа с указанием единиц измерения:

  100 ic    -- в тактах
10534 ps    -- в пикосекундах
  120 ns    -- в наносекундах
 83.3 us    -- в микросекундах
 0.11 ms    -- в миллисекундах
    5 sec   -- в секундах
  0.1 min   -- в минутах
    3 hr    -- в часах

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

Определение констант в программе

Константы определяются внутри процесса перед операторными скобками begin … end с ключевым словом constant и указанием типа и значения:

process is
    constant Start : time    := 100 us;
    constant Stop  : time    := 300 us;
    constant Max   : integer := 16#7FFFFFFF#;
    constant Hello : string  := "Hello world!";
begin
    --...
end process;

Переменные

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

process is
    variable I:    integer;
    variable B:    byte    := 10;
    variable S:    string  := "Hello world";
begin
    --...
end process;

Определение файловых переменных производится с ключевым словом file:

process is
    file     DataFile   :  text;             -- переменная, которая будет связана с
                                             -- конкретным файлом
    variable FileStatus :  file_open_status; -- переменная, куда будет записан результат
                                             -- функции открытия файла
begin
    --...
end process;

Операторы

Операции

Математические операции: +, -, *, /
Логические операции: not

(остальные операции: ^, <<, >>, %, and, or и т.д. - не поддерживаются)

Операторы сравнения

>, <, >=, <=, ==, != (или /=)

Оператор присваивания

a := 10;
s := "This is a string";

Оператор назначения

Оператор назначения "<=" служит для задания уровней сигналов на портах ввода/вывода:

RB0 <= '1';
RC0 <= '0';

Для языка SCL (в отличие от VHDL) этот оператор не отличается от оператора присваивания (разве что только его применение допустимо только к сигнальным линиям).

Условный оператор if

if <expression> then
    ...
elsif <expression2> then
    ...
elsif <expression3> then
    ...
else
    ...
end if;

Здесь expression - простое выражение, результат которого может быть 'true' или 'false'. Например:

if i == 10 then
    RB0 <= '0';
else
    RB0 <= '1';
end if;
 
if i + 3 >= 5 then
    ...
end if;
 
if s == "Hello world" then
    ...
elsif s == "Wellcome" then
    ...
else
    ...
end if;

Оператор ожидания wait

Есть четыре применения этого оператора:

1. wait - вечное ожидание

2. wait for - ожидание заданного времени

    wait for <time>;

Время может быть указано как в виде константы, так и в виде переменной.

    wait for 100 ic;
 
    MyTime := 150 us;
    wait for MyTime;

3. wait until - ожидание события

    wait until <event> [for <time>];

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

Примеры:

    wait until RB0 != RB1;           -- ожидание неравенства RB0 и RB1
    wait until RB0 == '1' for 1 ms;  -- в течение 1 мс ждем положительного фронта на RB0

Обращу внимание на то, что если на момент начала выполнения wait until условие выполняется, то это не считается событием. Например, "wait until RB0 == '1'" будет ожидать не единичное состояние, а переход '0'→'1'. Т.е. если на момент выполнения wait у нас RB0 уже в состоянии '1', то это не считается уже случившимся событием и оператор wait будет ждать сначала перехода '1'→'0', а потом '0'→'1'.

4. wait on - ожидание изменения сигнала

    wait on <signals_list> [for <time>];

Параметры этого оператора указываются так же, как и в описании списка для process. Оператор переводит процесс в ожидание, пока не изменится состояние одного из сигналов, указанных в списке:

    wait on RB0, RB1, RB2;         -- Ждем изменения состояния на одном из трех выводов
    wait on RA0, RA1 for 10 ms;    -- В течение 10мс ждем изменения состояния RA0 или RA1

Оператор цикла loop

Безусловный цикл:

loop
    ...
end loop;

Цикл будет выполняться бесконечно. Прервать его выполнение можно оператором exit (безусловное прерывание) или exit when … (условное):

-- Генератор на RB0, пока на RB1 высокий уровень
loop
    exit when RB1 == '0'; -- Прерываем цикл
    RB0 <= not RB0;
    wait for 1 us;
end loop;

Т.е. exit является аналогом break в Си. Аналога continue в SCL, к сожалению, нет (вернее, он есть - next, - но он не поддерживается)

Внутри тела цикла должен быть хотя бы один оператор wait.

Оператор цикла while

while <expression> loop
    ...
end loop;

Цикл похож на предыдущий, но с предустановленным условием выполнения. Например, цикл из предыдущего примера выглядел бы так:

-- Генератор на RB0, пока на RB1 высокий уровень
while RB1 == '1' loop
    RB0 <= not RB0;
    wait for 1 us;
end loop;

Вывод информации report

Этот оператор выводит отладочную информацию в MPLAB IDE в окно "Output: MPLAB_SIM". Может использоваться совместно с оператором severity, который обозначает тип сообщения. Вывод информации служит для визуализации текущего состояния работы SCL-файла. В качестве параметра может быть как строковая константа, так и строковая переменная. Например:

process is
    variable s : string;
begin
    report "This is string-constant";
    s := "This is string-variable";
    report s;
    wait;
end process;

Выведет в окно:

(0)  SIM-N0001 Note: This is string-constant
(0)  SIM-N0001 Note: This is string-variable

Здесь SIM-N0001 - номер процесса, Note - тип сообщения. По умолчанию все сообщения имеют тип Note. Однако, с помощью оператора severity можно изменять тип сообщений на: note, warning, error, failure. Причем, note, warning и error позволяют скрипту SCL выполняться дальше, в то время как failure прерывают выполнение скрипта. Код:

process is
begin
    report "This is a note";
    report "This is a warning" severity warning;
    report "This is an error"  severity error;
    report "This is a failure" severity failure;
    report "This text will not be reported";
    wait;
end process;

выведет следующую последовательность сообщений:

(0)  SIM-N0001 Note: This is a note
(0)  SIM-W0001 Warning: This is a warning
(0)  SIM-E0001 Error: This is an error
(0)  SIM-F0001 Failure: This is a failure

Обратим внимание, что последняя строка уже не выводится, т.к. severity failure прервало работу скрипта.

Функции

На данный момент мне известны следующие функции:

Стимуляция регистров
- accessin - назначить файл для асинхронной записи в регистр
- triggerin - назначить файл для синхронной записи в регистр
- packetin - отправить данные
История регистра
- accessout - назначить файл для асинхронного сохранения значений регистра
- triggerout - назначить файл для синхронного сохранения значений регистра
- triggerout_gpr - назначить файл для синхронного сохранения значений произвольного регистра
Чтение текстовых файлов
- file_open - открыть файл
- file_close - закрыть файл
- endfile - проверка конца файла
- readline - читать строку из файла
Обработка строк
- match - проверить совпадение строк
- read - читать параметр из строки
Время
- now - получение текущего времени
- random_time - получить случайное время
Для отладки
- print - вывод информации в отчет

Стимуляция регистров

accessin (FileName: string, FileMode: mode, Reg: register, Wrap: boolean)

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

Параметры:

FileName: Имя файла
FileMode: Тип файла: hex_mode, dec_mode, binary_mode, formatted_mode (см. ниже)
Reg: Стимулируемый регистр
Wrap: ?

Типы файла:

hex_mode - Данные записаны в шестнадцатеричном ASCII представлении (на каждой строке по одномму числу)
dec_mode - Данные записаны в десятичном ASCII представлении (на каждой строке по одномму числу)
binary_mode - Двоичный файл
formatted_mode - Форматированный файл (как он форматирован я пока не разобрался)

process is
begin
    accessin("adc_data.txt", binary_mode, ADRESH, true);
    wait;
end process;

triggerin (FileName: string, FileMode: mode, Reg: register, PC: paddress, Wrap: boolean)

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

Параметры:

FileName: Имя файла
FileMode: Тип файла: hex_mode, dec_mode, binary_mode, formatted_mode (см. выше)
Reg: Стимулируемый регистр
PC: Значение программного счетчика, при котором производить стимуляцию регистра (может быть указан в виде имени функции)
Wrap: ?

Если значение PC указывается в виде имени функции, то это имя должно быт ьобъявлено в секции configuration с ключевыми словами shared label (нечто вроде extern в Си).

Пример:

configuration for "pic16f877a" is
    shared label usart_getch;      -- Объявляем скрипту имя функции
end configuration;
 
testbench for "pic16f877a" is
begin
    process is
    begin
        -- формируем значение PORTB при каждом входе в прерывание
 
        triggerin("portb.txt", hex_mode, PORTB, 16#0004#, true);
 
        -- формируем значение приемного регистра USART при каждом
        -- входе в функцию usart_getch()
 
        triggerin("portb.txt", hex_mode, RCREG, usart_getch, true);
 
        wait;
    end process;
end testbench;

packetin (Data: line, Reg: register, Wrap: boolean)

Стимуляция значения регистра вручную. Регистр будет принимать значения, указанные в строке. Эта функция может быть применена тогда, когда регистр нужно стимулировать по более сложному алгоритму, чем допускают функции accessin и triggerin.

Параметры:

Data: Пакет данных (список значений, разделяемых пробелами), которые нужно занести в регистр
Reg: Имя регистра
Wrap: 'true' - добавить в очередь к уже имеющимся в пакете данным; 'false' - затереть старые данные новым пакетом

Пример стимулирования принятых данных по UART:

process is
    variable DataLine : line := "1 2 3 4 5 6 7 8 9 10";
begin
    wait for 10 ms;
    packetin(DataLine, RCREG, false);   -- Стимулируем принимаемые данные
    wait until RCREG_packet_done;       -- Ожидание завершения приема
    ...
end process;

История регистра

accessout (FileName: string, FileMode: mode, Reg: register, Wrap)

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

Параметры:

FileName: Имя файла
FileMode: Тип файла: hex_mode, dec_mode, binary_mode, formatted_mode (см. выше)
Reg: Наблюдаемый регистр
Wrap: ?

process is
begin
    accessout("eeprom_data.txt", hex_mode, EEDATA);
    wait;
end process;

triggerout (FileName: string, FileMode: mode, Reg: register, PC: paddress)

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

Параметры:

FileName: Имя файла
FileMode: Тип файла: hex_mode, dec_mode, binary_mode, formatted_mode (см. выше)
Reg: Наблюдаемый регистр
PC: Значение программного счетчика, при котором производить запись значения регистра в файл (может быть указан в виде имени функции)

Если значение PC указывается в виде имени функции, то это имя должно быт ьобъявлено в секции configuration с ключевыми словами shared label.

Пример:

configuration for "pic16f877a" is
    shared variable eewrite;      -- Объявляем скрипту имя функции
end configuration;
 
testbench for "pic16f877a" is
begin
    process is
    begin
 
        -- Сохраняем все значения регистра PORTA на момент входа в прерывание
 
        triggerout("porta.txt", hex_mode, PORTA, 16#0004#);
 
 
        -- Сохраняем все записываемые в EEPROM данные
 
        triggerout("eeprom.txt", hex_mode, EEDATA, eewrite);
 
        wait;
    end process;
end testench;

triggerout_gpr (FileName: string, FileMode: mode, GPR: ???, PC: paddress, Size: integer)

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

Параметры:

FileName: Имя файла
FileMode: Тип файла: hex_mode, dec_mode, binary_mode, formatted_mode (см. выше)
GPR: Имя переменной
PC: Значение программного счетчика, при котором производить запись значения регистра в файл (может быть указан в виде имени функции)
Size: Количество байт на одну запись (в текстовом режиме будут разделены пробелами)

Для того, чтобы скрипт знал имя используемой переменной, ему нужно его сообщеть в секции configuration c ключевыми словами shared variable:

Пример:

configuration for "pic16f877a" is
    shared variable MyCounter;           -- Объявляем скрипту имя переменной
end configuration;
 
testbench for "pic16f877a" is
begin
 
    process is
    begin
 
        -- Сохраняем все значения переменной MyCounter при входе в прерывание
 
        triggerout("counter.txt",dec_mode, MyCounter, 16#0004#);
        wait;
    end process;
 
end testbench;

Чтение текстовых файлов

file_open (Status: file_open_status, F: text, Name: string, Kind: file_open_kind

Открывает указанный файл и связывает его с файловой переменной.

Параметры:

Status: в эту переменную будет записан результат открытия файла (open_ok, status_error, name_error, mode_error)
F: файловая переменная
Name: имя файла в текстовом виде
Kind: режим работы файла (read_mode,write_mode,append_mode). Хоть SCL и позволяет открывать файлы в режимах write и append, и даже создает файлы с указанным именем на диске, но произвести запись в эти файлы так и не удалось. Так что на сегодняшний день реально из файлов можно только читать.

Пример:

process is
    file     MyFile    : text;
    variable Result    : file_open_result;
begin
    file_open(Result, MyFile, "data.txt", read_mode);
    if Result != open_ok then
        report "Error opening file data.txt!" severity failure;
    end if;
end process;

file_close (F: text)

Закрывает открытый файл

Параметр:

F: файловая переменная

Пример:

process is
    file     MyFile    : text;
    variable Result    : file_open_result;
begin
    file_open(Result, MyFile, "data.txt", read_mode);
    ...
    file_close(MyFile);
end process;

endfile (F: text)

Проверка конца файла. Возвращает 'true', если конец файла, иначе - 'false'.

Параметр:

F: файловая переменная

Пример:

process is
    file     MyFile    : text;
    variable Result    : file_open_result;
begin
    file_open(Result, MyFile, "data.txt", read_mode);
    while endfile(MyFile) == false loop
        ...
    end loop;
end process;

readline (F: text, Data: line)

Читает строку из файла.

Параметр:

F: файловая переменная
Data: переменная, куда будет помещена прочитанная строка

Пример:

process is
    file     MyFile    : text;
    variable Result    : file_open_result;
    variable Data      : line;
begin
    file_open(Result, MyFile, "data.txt", read_mode);
    while endfile(MyFile) == false loop
        readline(MyFile, Data);
        ...
    end loop;
end process;

Обработка строк

match (Line: line, Pattern: string)

Проверить совпадение строк. Вернее, совпадение начала первой строки со второй строкой. Функция возвращает 'true', если начало первой строки совпадает со второй строкой, и 'false', - если не совпадает.

Параметры:

Line: здесь содержится строка, начало которой мы проверяем
Pattern: здесь находится шаблон для сравнения

Пример:

process is
    variable MyLine    : line := "This is a line";
begin
    if match(MyLine, "This") == true then       -- условие выполнится
        ...
    end if;
 
    if match(MyLine, "This is ") == true then   -- условие выполнится
        ...
    end if;
 
    if match(MyLine, "is") == true then         -- условие не выполнится
        ...
    end if;
 
    if match(MyLine, "") == true then           -- Проверка на пустую строку
        ...
    end if;
 
end process;

read (Line: line, Data: any type)

читает слово из строки и заносит результат в переменную Data. Само слово затем из строки удаляется. Длина слова зависит от типа Data:
- string - будет прочитана вся строка
- time или cycle - будут прочитаны два слова, разделенные пробелами
- integer, byte, word - будет прочитано одно слово

Параметры:

Line: Исходная строка
Data: Переменная, куда будет помещен результат

Пример:

process is
    variable Line  : line := "wait 100 ms";
    variable Delay : time;
    variable Dummy : integer;
begin
    if match(Line, "wait") == true then
        read(Line, Dummy);                -- Убираем слово "wait", теперь Line = "100 ms"
        read(Line, Delay);                -- Delay = 100 ms, Line = ""
        wait for Delay;
    end if;
    ...
    wait;
end process;

Обращу внимание на чтение в переменную Dummy. Когда мы попадаем внутрь блока if, у нас строка до сих пор содержит "wait 100 ms". Нам нужно убрать одно слово из нее, для чего мы выполняем функцию read, занося результат в любую переменную типа integer (т.е. читаем до первого пробела). После этого прочитанное слово удаляется из исходной строки. Далее выполняем read еще раз с параметром Delay, который имеет тип time, т.е. читаем два слова: "100 ms". После этого строка Line становится пустой.

Время

now ()

Получение текущего времени. Возвращает текущее время симуляции. В зависимости от того, какого типа переменную мы используем для хранения результата (cycle или time), будут выбраны соответствующие единицы измерения.

Пример:

process is
    variable Time  : time;
    variable Cycle : cycle;
begin
    wait for 10 ms;
    Time  := now();      -- получение времени в пикосекундах
    Cycle := now();      -- получение времени в тактах контроллера
end process;

random_time (LowerLimit: integer, UpperLimit: integer, Units: string, Seed1: integer, Seed2: integer, Result: time)

Формирует случайное значение для переменной типа time.

Параметры:

LowerLimit: Нижний предел
UpperLimit: Верхний предел
Units: Единицы измерения (""ps", "ns", "us", "ms", "sec", "min", "hr")
Seed1, Seed2: параметры генератора случайных чисел (в самом простом случае можно задать любыми ненулевыми значениями)
Result: Результат работы функции

Пример (генератор шума):

testbench for "pic16f877a" is
begin
 
    process is
        variable RandTime  : time;
        variable RandSeed1, RandSeed2: integer;
    begin
 
        RandSeed1 := 1234;
        RandSeed2 := 5678;
        loop
            random_time(1, 100, "us", RandSeed1, RandSeed2, RandTime);
            wait for RandTime;
            RB0 <= not RB0;
        end loop;
 
    end process;
 
end testbench;

Для отладки

print (…)

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

Параметры: эта функция может принимать не более 5 параметров различных типов: line, string, integer, character, boolean, bit, time, cycle.

Пример:

    I := 25;
    print("Current I = ", I);

Выведет:

(0)  SIM-N0001 Note: Current I = 25

Работа с файлами

Мы уже упоминали функции для стимуляции регистров значениями из файлов (assignin, triggerin). Эти функции при своей простоте имеют недостатки:

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

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

Рассмотрим порядок обработки файла data.txt следующего содержания (задача взята наобум):

porta 0
portb 0
wait 10 ms
rcreg 1 2 3 4 5 6 7
porta 16 portb 255
wait 10 ms
porta 0 portb 0

Сначала мы обнуляем значения регистров PORTA и PORTB. Через 10 мс отправляем данные по USART, после чего устанавливаем порты в значения PORTA = 0x10, PORTB = 0xFF. А еще через 10 мс порты снова обнуляются.

testbench for "pic16f877a" is
begin
 
process is
 
    file     InFile  : text;               -- Файловая переменная для связи с файлом
    variable Status  : file_open_status;   -- Для проверки правильности открытия файла
    variable InLine  : line;               -- Для обработки прочитанных данных
    variable Delay   : time;               -- Для формирования задержек
    variable Work    : integer;            -- Рабочая переменная для обработки данных
 
begin
 
    file_open(Status, InFile, "data.txt", read_mode);
    if Status != open_ok then                                    -- Обработка ошибки
        report "Ошибка открытия файла data.txt!" severity failed;
    end if;
 
    -- Работаем с файлом, пока в нем есть данные
 
    while endfile(InFile) == false loop
 
        readline(InFile, InLine);                -- Читаем строку
 
        -- Обрабатываем строку, пока в ней есть данные
 
        while match(InLine, "") == false loop
 
            -- Обработка команды
 
            if     match(InLine, "porta") == true then
 
                read(InLine, Work);              -- Убираем из InLine слово "porta"
                read(InLine, Work);              -- Читаем параметр
                PORTA <= Work;
 
            elsif match(InLine, "portb") == true then
 
                read(InLine, Work);              -- Убираем из InLine слово "portb"
                read(InLine, Work);              -- Читаем параметр
                PORTB <= Work;
 
            elsif match(InLine, "rcreg") == true then
 
                read(InLine, Work);              -- Убираем из InLine слово "rcreg"
                packetin(InLine, RCREG, true);   -- Перенаправляем остаток строки в приемный буфер
 
            elsif match(InLine, "wait")  == true then
 
                read(InLine, Work);              -- Убираем из InLine слово "wait"
                read(InLine, Delay);             -- Читаем параметр задержки
                wait for Delay;                  -- Выдерживаем задержку
 
            else
                report "Неизвестная команда";
            end if;
 
        loop end;  -- line == ""
    loop end;  -- endfile
 
    report "Готово!";
    wait;
 
end process;
 
end testbench;

В этом примере следует сосредоточить внимание на двух циклах: while endfile(InFile) == false и while match(InLine, "") == false. Эти два цикла - основа работы с файлами и присутствуют почти в любой программе на языке SCL, которая занимается обработкой входного файла. Внутри этих вложенных один в другой циклов и происходит вся обработка данных. Т.е. если файл еще содержит данные (проверяем функцией endfile), то читаем строку, а затем по одной достаем из строки команды (вспоминаем, что функция read из строки удаляет прочитанное слово) и их параметры, пока строка не закончится.

Отметим одно важное свойство: с одним и тем же файлом параллельно могут работать несколько процессов.

Программирование

В этом параграфе рассмотрим некоторые особенности и сложности работы с SCL файлами при работе с интегрированной средой MPLAB.

Подключение программы SCL к симулятору

После того, как программа генерации входных сигналов написана, нам нужно ее подключить. Для этого нужно (действия для версии MPLAB 8.xx):

выбрать в качестве отладчика MPLAB SIM (меню "Debugger/Select Tool");
создать рабочую книгу через меню "Debug/Stimulus/New Workbook" (или Open Workbook, если книга уже была создана);
в открывшемся диалоговом окне "Stimulus" нажать кнопку "Advanced…" в нижнем левом углу; откроется маленькое диалоговое окно "Advanced operations";
в этом новом окне нажать кнопку "Attach" (прикрепить SCL-файл); выбрать файл с программой SCL.

Если программа была написана правильно, то в поле "Override Workbook with Stimulus File" появится имя выбранного файла. Если нет, значит, в программе есть ошибки и их нужно исправлять. Как - описано в следующем параграфе.

Сложности отладки

Отладка SCL-файлов - дело довольно трудоемкое, поскольку сама среда MPLAB предоставляет довольно скудный инструментарий для отладки. Начать можно с того, что встроенный парсер SCL-файлов выдает очень лаконичные сообщения по поводу ошибок, и часто долго не понимаешь, что ему может не нравиться.

Работая с SCL-файлами, желательно, чтобы на виду было рабочее окно "Output" с открытой вкладкой "MPLAB SIM". Все сообщения об ошибках, а также вся отладочная информация, формируемая самим SCL-скриптом (print и report) будут выводиться в это окно. Чем нам MPLAB IDE помогает при отладке? Во-первых, он обеспечивает подсветку синтаксиса для файлов SCL, что позволяет избежать некоторых малозаметных помарок. Во-вторых, при прикреплении SCL-файла в окно "Output" выводится информация с номером строки, содержащей ошибку, и тип ошибки (здесь он довольно скуп на сообщения и чаще всего пишет "syntax error"); кроме того, двойным щелчком мышки по сообщению в окне "Output" мы попадаем на строку с ошибкой в исходном файле.

Я бы рекомендовал подключать файл SCL еще на начальном этапе программирования. Т.е., сначала создаем пустой файл:

testbench for "pic16f877a" is
begin
 
end testbench;

потом подключаем его по описанному выше алгоритму, убеждаемся, что он подключился (в окне Output должно появиться сообщение "Stimulus: SCL file attached successfully."). Теперь можно писать SCL-скрипт, причем для проверки того, что все написано правильно уже не нужно делать "Detach/Attach", а достаточно всего лишь нажать кнопку F6 (Reset при отладке). По этой кнопке файл SCL автоматически перезагружается и проходит повторную проверку. В окне Output будут появляться сообщения об ошибках, если они есть, или ничего не будет появляться, если ошибок нет. (Когда ничего не появляется, это несколько настораживает, поэтому я во все свои SCL-скрипты встраиваю такой процесс:

    process is
    begin
        report "======================== SCL loaded OK! ==========================";
        wait;
    end process;

Если нет ошибок, то по нажатию F6 в окне Output будет появляться надпись "SCL-file loaded OK.")

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

Недостаток операторов

Язык SCL хоть и является подмножеством языка VHDL, но все-таки имеет далеко не все его возможности. Стоит отметить отсутствие некоторых операторов (case, for, after), типов (real, полноценных массивов), математических и логических операций (xor, and, or, %, сдвиги) и пр. Это все доставляет некоторые неудобства, но, тем не менее, большинство конструкций могут быть заменены.

Во-первых, у нас нет возможности использовать сложные выражения в условных операторах. Мы не можем написать:

   if RA0 == '1' and RA1 == '1' then
       ...

Нам придется делать вложенные условия:

   if RA0 == '1' then
       if RA1 == '1' then
           ...

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

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

    i := j and 16#0E#;

потому, что такой операции нет в языке SCL. Или, что еще обиднее, нет простого механизма сдвига числа с извлечением младшего бита. Однако это не значит, что такое невозможно. Например, наш предыдущий пример с j & 0x0E может быть решен с помощью математических операций *, /, -:

    i := j / 16;
    i := j - i * 16;    -- Отрезаем все биты выше 3-го
    i := i / 2;
    i := i * 2;         -- Отрезаем нулевой бит

Примерно так же решается задача сдвига с извлечением младшего бита:

    b := 65;            -- Данные, которые надо последовательно втолкнуть на вход RB0
    i := 8;             -- обрабатываем 8 бит
    while i > 0 loop
        i := i - 1;
        j := b / 2;
        j := b - j * 2; -- Получили в j младший бит из переменой b
 
        if j == 1 then  -- Вталкиваем этот бит в RB0
            RB0 <= '1';
        else
            RB0 <= '0';
        end if;
 
        b := b / 2;     -- деление на 2 - эквивалент сдвига влево
        wait for 100 us;
    end loop;

Доступ к регистрам контроллера

Во время выполнения SCL-скрипта у нас есть возможность обращаться к регистрам контроллера. Мы можем получить текущее значения программно счетчика, значение регистра FSR, значения таймеров, регистров управления модулем CCP и т.д. Здесь я особо глубоко исследования не проводил. Но с сожалением должен заметить, что не все регистры можно прочитать. Например, на это:

    i := PORTA;

парсер ругается "Type error in assignment". В то время как значения остальных регистров прочитать таким образом удается. (Также не читаются TRISx, TXREG и еще некоторые периферийные регистры). В принципе, это не страшно, т.к., во-первых, операция чтения регистра PORTA довольно редкая, а во-вторых, ее можно заменить побитовым заполнением:

    i := 0;
    if RA0 == '1' then
        i := i + 1;
    end if;
    if RA1 == '1' then
        i := i + 2;
    end if;
    if RA2 == '1' then
        i := i + 4;
    end if;
    if RA3 == '1' then
        i := i + 8;
    end if;
    if RA4 == '1' then
        i := i + 16;
    end if;
    if RA5 == '1' then
        i := i + 32;
    end if;

Встроенный в MPLAB симулятор сам накладывает кое-какие ограничения. Их поиском я не занимался, а когда и натыкался на них, то старался обходить, при этом, к сожалению, не отмечая для себя на будущее. По отзывам с форума на microchip.com есть ограничения на стимуляцию регистров АЦП для dsPIC'ов, но я лично не проверял.

Примеры

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

Генератор 1 KHz

Для начала самый простой пример - генератор.

testbench for "pic16f877a" is
begin
 
process is
begin
 
    RB0 <= '0';
    loop
        RB0 <= not RB0;    -- каждые 0.5мс меняем состояние порта
        wait for 500 us;
    end loop;
 
end process;
 
end testbench;

В результате работы данного скрипта мы получим такой сигнал на входе RB0:

Можем его немного усложнить, добавив управление из самой отлаживаемой программы:

-------------------------------------------------------------------------------
--
-- Данный скрипт демонстрирует управляемый генератор 1 KHz. Генерируемый сигнал
-- подается на вход RB0. Управляется выходом RB1 (=1 - есть генерация, =0 - нет)
--
-------------------------------------------------------------------------------
 
testbench for "pic16f877a" is
begin
 
process is
begin
 
    RB0 <= '0';
 
    loop
        if RB1 == '1' then    -- Меняем состояние порта, только если есть сигнал
            RB0 <= not RB0;   -- разрешения ("1" на выходе RB1)
        else
            RB0 <= '0';
        end if;
        wait for 500 us;
    end loop;
 
end process;
 
end testbench;

Теперь в программе для микроконтроллера, устанавливая порт RB1 в "1", мы включаем генерацию на RB0 из SCL-скрипта. Для примера была написана небольшая программа, которая формирует на выводе RB1 меандр частотой 50 Гц для управления генератором. На графике видно, что как только на RB1 появляется "1", скрипт начинает генерировать на вход RB0 меандр частотой 1 КГц.

Генератор программного UART

Большинство контроллеров PIC младшего и среднего семейства имеют на борту всего один аппаратный USART-модуль, но часто бывает нужно управлять двумя и более устройствами посредством этого интерфейса. При отладке программы хорошо бы убедиться в том, что прораммный UART-приемник работает корректно. Вот пример скрипта, который генерирует на вход ПИКу сигнал UART. Скорость выбирается пользователем (по умолчанию 9600), данные берутся из файла.

Пример исходного файла data_uart.txt:

baudrate 19200
wait 1 ms
10 20 30 40 50 60
wait 3 ms
55 66 77 88

Здесь baudrate - команда на изменение скорости, wait - команда на выдержку паузы. Числа даны в десятичной системе счисления (как их задавать в шестнадцатеричной или в символьном виде, - не знаю).

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

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

Для синхронизации служит общая переменная UART_Work. Когда она = 0, процесс отправки байта свободен. Для отправки байта головной процесс должен подготовить данные для отправки (записать нужное значение в UART_Data), а потом установить UART_Work в "1", тем самым сообщив процессу отправки, что можно начинать работать. Процесс отправки сам обнулит эту переменную, когда байт будет полностью передан, сообщем тем самым основному процессу, что передатчик вновь свободен.

-------------------------------------------------------------------------------
--
-- Данный скрипт демонстрирует формирование программного UART сигнала на входе
-- контроллера PORTC, 5. Данные читаются из файла "data_uart.txt"
--
-------------------------------------------------------------------------------
-- Пример файла с данными:
-------------------------------------------------------------------------------
--  baudrate 19200
--  wait 1 ms
--  10 20 30 40 50 60
--  wait 3 ms
--  55 66 77 88
-------------------------------------------------------------------------------
 
testbench for "pic16f877a" is
begin
 
 
process is
begin
    report "======================== SCL loaded OK! ==========================";
    wait;
end process;
 
---------------------------------------------------
 
uart_send_byte: process is              -- Подпрограмма вывода одного байта по последовательному
                                        -- интерфейсу UART через вход RC5
 
    variable UART_Delay   : time;       -- Длительность одного бита
    variable UART_Data    : byte;       -- Передаваемый байт
    variable UART_Bit     : byte;       -- Для выделения бита при передаче
    variable UART_Counter : integer;    -- Счетчик битов
    variable UART_Work    : integer;    -- Установкой этой переменной в 1 из другого
                                        -- процесса мы инициируем начало передачи.
 
begin
 
    RC5 <= '1';
    UART_Work := 0;                     -- Сообщаем головной программе, что процесс свободен,
                                        -- моно передавать новый байт
 
    while UART_Work == 0 loop           -- Ожидаем команду на старт от основного процесса
        wait for 1 ic;
    end loop;
 
    RC5 <= '0';                         -- Формируем стартовый бит
    wait for UART_Delay;
 
    UART_Counter := 8;                  -- цикл для 8 бит данных
 
    while UART_Counter > 0 loop
 
        UART_Counter := UART_Counter - 1;
        UART_Bit := UART_Data / 2;      -- Выделяем младший бит
        UART_Bit := UART_Data - UART_Bit * 2;
        UART_Data := UART_Data / 2;
 
        if UART_Bit == 0 then           -- Отправляем его
            RC5 <= '0';
        else
            RC5 <= '1';
        end if;
 
        wait for UART_Delay;
 
    end loop;
 
    RC5 <= '1';                         -- Формируем стоповый бит
    wait for UART_Delay;
 
end process uart_send_byte;
 
---------------------------------------------------
 
uart: process is                            -- Читаем данные из файла и формируем
                                            -- из них сигнал для контроллера
 
    file     InFile : text;                 -- Рабочий файл
    variable Status : file_open_status;
    variable InLine : line;                 -- Строка, прочитанная из файла
    variable i      : integer;              -- Рабочая переменная
    variable Delay  : time;                 -- Рабочая задержка
 
begin
 
    UART_Delay := 1 sec / 9600;             -- скорость по умолчанию 9600
 
                                            -- Открываем файл с данными
    file_open(Status, InFile, "data_uart.txt", read_mode);
    if Status != open_ok then
        report "Ошибка открытия файла data_uart.txt" severity failure;
    end if;
 
 
    while endfile(InFile) == false loop     -- Обрабатываем, пока файл не пуст
 
        readline(InFile, InLine);
        print("Прочитана строка: ", InLine);
 
        while match(InLine, "") == false loop
 
            -- Проверяем строку на наличие команды
 
            if match(InLine, "baudrate") == true then   -- Изменение скорости
 
                read(InLine, i);            -- Удаляем из строки слово "baudrate"
                read(InLine, i);            -- Читаем значение скорости
 
                if i != 0 then
                    UART_Delay := 1 sec / i;            -- Устанавливаем новую скорость
                    print("Новая скорость UART = ", i);
                else
                    print("ОШИБКА в файле: Скорость не может быть = 0!");
                end if;
 
            elsif match(InLine, "wait") == true then    -- Задержка
 
                read(InLine, i);            -- Удаляем из строки слово "wait"
                read(InLine, Delay);        -- Читаем значение задержки
                print("Ждем ", Delay);
                wait for Delay;             -- формируем задержку
 
            else                                        -- Передача байта
 
                read(InLine, UART_Data);                -- Читаем байт
                print("Отправка байта ", UART_Data);
                UART_Work := 1;                         -- Даем команду на начало передачи
 
                while UART_Work == 1 loop               -- Ожидаем завершения передачи
                    wait for 1 ic;
                end loop;
 
            end if;
 
        end loop; -- match InLine
 
    end loop; -- endfile
 
    file_close(InFile);
 
end process uart;
 
end testbench;

Ниже приведен график генерируемого сигнала. На нем отчетливо видно, что данные передаются двумя пакетами с интервалом 3 мс.

Генератор аналогового сигнала

Симулятор в интегрированной среде MPLAB IDE не позволяет имитировать разные уровни напряжения на аналоговых входах. Однако он позволяет симулировать регистры ADRESH и ADRESL напрямую. Этим мы можем воспользоваться для имитации аналоговых сигналов.

Ниже приведен пример, который будет заполнять регистры ADRESH:ADRESL значениями из файла. Это будет происходить в тот момент, когда программа будет обращаться к АЦП. Это пример является только демонстрацией необходимых действия для формирования регитсров ADRES, он не подходит для практического применения, поскольку входные данные синхронизированы только с обращениями программы к АЦП. Т.е. если обращений не будет, то и сигналы формироваться не будут (или другими словами: когда бы мы не обратились к АЦП, мы всегда прочитаем один и тот же сигнал). На практике такое не встречается.

testbench for "pic16f877a" is
begin
 
process is
begin
    report "======================== SCL loaded OK! ==========================";
    wait;
end process;
 
---------------------------------------------------
 
ADC: process is
 
    file     InFile : text;                     -- Рабочий файл
    variable Status : file_open_status;
    variable InLine : line;                     -- Строка, прочитанная из файла
    variable Value  : integer;                  -- Рабочая переменная
 
    constant FileName : string := "data_adc.txt";
 
begin
 
    file_open(Status, InFile, FileName, read_mode);
 
    if Status != open_ok then
        report "Ошибка открытия файла!" severity failure;
    end if;
 
 
    while endfile(InFile) == false loop         -- Обрабатываем, пока файл не пуст
 
        readline(InFile, InLine);
        print("Прочитана строка: ", InLine);
 
        while match(InLine, "") == false loop   -- Обрабатываем строку, пока она не пуста
 
            wait until ADCON0.GO_nDONE == '1';  -- Ждем, когда программа начнет чтение ADC
            read(InLine, Value);
 
            if ADCON0.ADON == '1' then
 
                print("Формируем значение ", Value);
 
                while ADCON0.GO_nDONE == '1' loop -- Ждем завершения измерения (для 877a
                    wait for 1 ic;                -- этот бит сбрасывается MPLAB SIM'ом
                end loop;                         -- автоматически. Но, мо-моему, для неко-
                                                  -- торых контроллеров эту нужно делать
                                                  -- вручную)
 
                if ADCON1.ADFM == '0' then        -- Левое выравнивание
 
                    ADRESH <= Value /  4;
                    ADRESL <= Value * 64;
 
                else
                                                  -- Правое выравнивание
                    ADRESH <= Value / 256;
                    ADRESL <= Value;
 
                end if;
 
            end if; -- ADON
 
        end loop; -- match InLine
 
    end loop; -- endfile
 
    file_close(InFile);
    report "Конец скрипта";
    wait;
 
end process ADC;
 
end testbench;

Генератор DTMF

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

Напомню: DTMF сигнал - это сигнал, получаемый суммированием двух синусоидальных сигналов из двух наборов частот:

697 Hz, 770 Hz, 852 Hz, 941 Hz
1209 Hz, 1336 Hz, 1477 Hz, 1633 Hz

Скрипт будет состоять из 4-х процессов:

FREQ1 - генератор синуса заданной частоты
FREQ2 - генератор синуса заданной частоты
WORK - Управляющий - будет читать файл с данными и формировать целеуказания для FREQ1 и FREQ2
ADC - независимый процесс, который при обращении пользовательской программы к АЦП будет формировать значения регистров ADRESH:ADRESL по мгновенным значениям синусов, генерируемых процессами FREQ1 и FREQ2.

(Примечание: еще добавлены пятый процесс, в который для удобства вынесены объявления глобальных переменных, и шестой, который содержит строку "SCL loaded OK!")

Формат файла "data_dtmf.txt"

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

freq <c> <f>: Генерировать синус частоты f на канале c (c = 1 или 2)
stop: остановить генерацию (отключает оба канала)
duration <d>: задать длительность тонов (по умолчанию 100 мс)
pause <p>: задать паузу между тонами (по умолчанию 100 мс)
level: задать уровень сигнала от 0% до 100% (по умолчанию 100%)

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

Пример рабочего файла:

  
// Задаем временные параметры тонов
duration 30 ms
pause 30 ms

// Генерируем все тоны по очереди
1 2 3 4 5 6 7 8 

// Уменьшаем уровень сигнала втрое 
level 33

9 10 11 12 13 14 15 16

// Генерируем опорную частоту 1 КГц на первом канале
freq 1 1000
wait 100 ms
stop

// Генерируем опорную частоту 2 КГц на втором канале
freq 2 2000
wait 100 ms
stop

Вот отчет его обработки:

(0)  SIM-N0001 Note: ======================== SCL loaded OK! ==========================
(0)  SIM-N0001 Note: Line:  // Задаем временные параметры тонов
(0)  SIM-N0001 Note: Line:  duration 30 ms
(0)  SIM-N0001 Note: Установлено время гудка  30000000 ns
(0)  SIM-N0001 Note: Line:  pause 30 ms
(0)  SIM-N0001 Note: Установлено время паузы  30000000 ns
(0)  SIM-N0001 Note: Line:
(0)  SIM-N0001 Note: Line:  // Генерируем все тоны по очереди
(0)  SIM-N0001 Note: Line:  1 2 3 4 5 6 7 8
(0)  SIM-N0001 Note: Генерируется тон:  1
ADC-W0001:	Tad time is less than 1.60us
ADC-W0008: No stimulus file attached to ADRESL for A/D.
(60000)  SIM-N0001 Note: Генерируется тон:  2
(120000)  SIM-N0001 Note: Генерируется тон:  3
(180000)  SIM-N0001 Note: Генерируется тон:  4
(240000)  SIM-N0001 Note: Генерируется тон:  5
(300000)  SIM-N0001 Note: Генерируется тон:  6
(360000)  SIM-N0001 Note: Генерируется тон:  7
(420000)  SIM-N0001 Note: Генерируется тон:  8
(480000)  SIM-N0001 Note: Line:
(480000)  SIM-N0001 Note: Line:  // Уменьшаем уровень сигнала втрое
(480000)  SIM-N0001 Note: Line:  level 33
(480000)  SIM-N0001 Note: Установлен уровень сигнала =  33 %
(480000)  SIM-N0001 Note: Line:
(480000)  SIM-N0001 Note: Line:  9 10 11 12 13 14 15 16
(480000)  SIM-N0001 Note: Генерируется тон:  9
(540000)  SIM-N0001 Note: Генерируется тон:  10
(600000)  SIM-N0001 Note: Генерируется тон:  11
(660000)  SIM-N0001 Note: Генерируется тон:  12
(720000)  SIM-N0001 Note: Генерируется тон:  13
(780000)  SIM-N0001 Note: Генерируется тон:  14
(840000)  SIM-N0001 Note: Генерируется тон:  15
(900000)  SIM-N0001 Note: Генерируется тон:  16
(900000)  SIM-N0001 Note: Line:
(900000)  SIM-N0001 Note: Line:  // Генерируем опорную частоту 1 КГц на первом канале
(900000)  SIM-N0001 Note: Line:  freq 1 1000
(900000)  SIM-N0001 Note: Частота канала 1 =  1000
(900000)  SIM-N0001 Note: Sample rate =  976 ns
(900000)  SIM-N0001 Note: OK
(900000)  SIM-N0001 Note: Line:  wait 100 ms
(900000)  SIM-N0001 Note: Ждем  100000000 ns
(1000000)  SIM-N0001 Note: Line:  stop
(1000000)  SIM-N0001 Note: Line:
(1000000)  SIM-N0001 Note: Line:  // Генерируем опорную частоту 2 КГц на втором канале
(1000000)  SIM-N0001 Note: Line:  freq 2 2000
(1000000)  SIM-N0001 Note: Частота канала 2 =  2000
(1000000)  SIM-N0001 Note: OK
(1000000)  SIM-N0001 Note: Line:  wait 100 ms
(1000000)  SIM-N0001 Note: Ждем  100000000 ns
(1100000)  SIM-N0001 Note: Line:  stop
(1100000)  SIM-N0001 Note: Line:
(1100000)  SIM-F0001 Failure: Работа скрипта успешно завершена

Текст скрипта

Наконец, сам скрипт:

(файл с таблицей синуса прилагается sinus.rar)

testbench for "pic16f877a" is
begin
 
-------------------------------------------------------------------
 
process is
begin
    report "======================== SCL loaded OK! ==========================";
    wait;
end process;
 
 
-------------------------------------------------------------------
--
-- Определение глобальных переменных (использующиеся более чем одним
-- процессом) вынесены в отдельный пустой процесс для наглядности
--
-------------------------------------------------------------------
 
variables : process is
 
    constant DTMFFileName   : string  := "data_dtmf.txt";   -- Файл с командами
    constant SinusFileName  : string  := "sinus.txt";       -- Файл, содержащий 1024 выборки
                                                            -- одного периода синусоиды
    constant NumOfSinPoints : integer := 1024;
 
    variable SignalLevel    : integer := 100;               -- Уровень сигнала (в процентах)
 
                                                            -- ДЛЯ КАНАЛА 1:
    variable SampleRate_1   : time;                         -- Скорость выборки
    variable AnalogSignal_1 : integer := 0;                 -- Мгновенное значение сигнала
    variable FreqEnable_1   : boolean := false;             -- true - генерировать сигнал
                                                            -- false - молчать
 
                                                            -- ДЛЯ КАНАЛА 2:
    variable SampleRate_2   : time;                         -- Скорость выборки
    variable AnalogSignal_2 : integer := 0;                 -- Мгновенное значение сигнала
    variable FreqEnable_2   : boolean := false;             -- true - генерировать сигнал
                                                            -- false - молчать
 
begin
    SampleRate_1 := 1 sec / 697;
    SampleRate_1 := SampleRate_1 / NumOfSinPoints;
    SampleRate_2 := 1 sec / 1209;
    SampleRate_2 := SampleRate_2 / NumOfSinPoints;
 
    wait;
end process variables;
 
 
 
 
-------------------------------------------------------------------
--
-- Основной процесс. Читает из файла data_dtmf.txt команды и
-- выполняет их, выдавая целеуказания процессам FREQ1 и FREQ2.
--
-------------------------------------------------------------------
 
WORK: process is
 
    file     DTMF_File      : text;
    variable Status         : file_open_status;
    variable i, j           : integer;
    variable DTMF_Line      : line;
 
    variable DTMF_Pause     : time := 100 ms;
    variable DTMF_Duration  : time := 100 ms;
 
    variable WaitTime       : time;
 
begin
 
    file_open(Status, DTMF_File, DTMFFileName, read_mode);
    if Status != open_ok then
        print("Ошибка открытия файла ", DTMFFileName);
        report "Скрипт приостановлен" severity failure;
    end if;
 
    while endfile(DTMF_File) == false loop
 
        readline(DTMF_File, DTMF_Line);
        print("Line: ",  DTMF_Line);
 
        while match(DTMF_Line, "") == false loop
 
            -----------------------------------------------------
            -- Пропускаем комментарии
            -----------------------------------------------------
 
            if match(DTMF_Line, "//") == true then
 
                exit;                               -- выходим из цикла
 
            -----------------------------------------------------
            -- Пауза в обработке скрипта
            -----------------------------------------------------
 
            elsif match(DTMF_Line, "wait") == true then  --
 
                read(DTMF_Line, i);                 -- Удаляем команду из строки
                read(DTMF_Line, WaitTime);
                print("Ждем ", WaitTime);
                wait for WaitTime;
 
            -----------------------------------------------------
            -- Длительность сигнала
            -----------------------------------------------------
 
            elsif match(DTMF_Line, "duration") == true then
 
                read(DTMF_Line, i);                 -- Удаляем команду из строки
                read(DTMF_Line, DTMF_Duration);
                print("Установлено время гудка ", DTMF_Duration);
 
            -----------------------------------------------------
            -- Длительность паузы
            -----------------------------------------------------
 
            elsif match(DTMF_Line, "pause") == true    then
 
                read(DTMF_Line, i);                 -- Удаляем команду из строки
                read(DTMF_Line, DTMF_Pause);
                print("Установлено время паузы ", DTMF_Pause);
 
            -----------------------------------------------------
            -- Выбор произвольной частоты
            -----------------------------------------------------
 
            elsif match(DTMF_Line, "freq") == true     then
 
                read(DTMF_Line, i);                 -- Удаляем команду из строки
                read(DTMF_Line, i);                 -- Читаем номер канала
 
                if i == 1 then
 
                    read(DTMF_Line, i);
                    if i > 0 then
 
                        SampleRate_1 := 1 sec / i;
                        SampleRate_1 := SampleRate_1 / NumOfSinPoints;
                        FreqEnable_1 := true;
                        print("Частота канала 1 = ", i);
                        print("Sample rate = ", SampleRate_1);
 
                    end if;
 
                elsif i == 2 then
 
                    read(DTMF_Line, i);
                    if i > 0 then
 
                        SampleRate_2 := 1 sec / i;
                        SampleRate_2 := SampleRate_2 / NumOfSinPoints;
                        FreqEnable_2 := true;
                        print("Частота канала 2 = ", i);
 
                    end if;
 
                else
                    print("В команде freq неправильно задан номер канала: ", i, "(должен быть 1 или 2)");
                    read(DTMF_Line, i);
                end if;
 
                report "OK";
 
            -----------------------------------------------------
            -- Прекратить генерацию обоих синусов
            -----------------------------------------------------
 
            elsif match(DTMF_Line, "stop") == true then
 
                read(DTMF_Line, i);                 -- Удаляем команду из строки
                FreqEnable_1 := false;
                FreqEnable_2 := false;
 
            -----------------------------------------------------
            -- Задать уровень сигнала (в процентах)
            -----------------------------------------------------
 
            elsif match(DTMF_Line, "level") == true then
 
                read(DTMF_Line, i);                 -- Удаляем команду из строки
                read(DTMF_Line, i);
 
                if i >= 0 then
                    if i <= 100 then
                        SignalLevel := i;
                        print("Установлен уровень сигнала = ", SignalLevel, "%");
                    end if;
                end if;
 
 
            -----------------------------------------------------
            -- Выдать DTMF-тон
            -----------------------------------------------------
 
            else
 
                read(DTMF_Line, i);
                if i < 0 then
                    print("Неправильный тон: ", i);
                elsif i > 16 then
                    print("Неправильный тон: ", i);
                else
 
                    print("Генерируется тон: ", i);
 
                    if    j == 1 then                   -- 1
                        SampleRate_1 := 1 sec / 697;
                        SampleRate_2 := 1 sec / 1209;
                    elsif j == 2 then                   -- 2
                        SampleRate_1 := 1 sec / 697;
                        SampleRate_2 := 1 sec / 1336;
                    elsif j == 3 then                   -- 3
                        SampleRate_1 := 1 sec / 697;
                        SampleRate_2 := 1 sec / 1477;
                    elsif j == 4 then                   -- 4
                        SampleRate_1 := 1 sec / 770;
                        SampleRate_2 := 1 sec / 1209;
                    elsif j == 5 then                   -- 5
                        SampleRate_1 := 1 sec / 770;
                        SampleRate_2 := 1 sec / 1336;
                    elsif j == 6 then                   -- 6
                        SampleRate_1 := 1 sec / 770;
                        SampleRate_2 := 1 sec / 1477;
                    elsif j == 7 then                   -- 7
                        SampleRate_1 := 1 sec / 852;
                        SampleRate_2 := 1 sec / 1209;
                    elsif j == 8 then                   -- 8
                        SampleRate_1 := 1 sec / 852;
                        SampleRate_2 := 1 sec / 1336;
                    elsif j == 9 then                   -- 9
                        SampleRate_1 := 1 sec / 852;
                        SampleRate_2 := 1 sec / 1477;
                    elsif j == 10 then                  -- 0
                        SampleRate_1 := 1 sec / 941;
                        SampleRate_2 := 1 sec / 1209;
                    elsif j == 11 then                  -- *
                        SampleRate_1 := 1 sec / 941;
                        SampleRate_2 := 1 sec / 1336;
                    elsif j == 12 then                  -- #
                        SampleRate_1 := 1 sec / 941;
                        SampleRate_2 := 1 sec / 1477;
                    elsif j == 13 then                  -- A
                        SampleRate_1 := 1 sec / 697;
                        SampleRate_2 := 1 sec / 1633;
                    elsif j == 14 then                  -- B
                        SampleRate_1 := 1 sec / 770;
                        SampleRate_2 := 1 sec / 1633;
                    elsif j == 15 then                  -- C
                        SampleRate_1 := 1 sec / 852;
                        SampleRate_2 := 1 sec / 1633;
                    else                                -- D
                        SampleRate_1 := 1 sec / 941;
                        SampleRate_2 := 1 sec / 1633;
                    end if;
 
                    SampleRate_1 := SampleRate_1 / NumOfSinPoints;
                    SampleRate_2 := SampleRate_2 / NumOfSinPoints;
 
                    FreqEnable_1 := true;               -- Включаем звук
                    FreqEnable_2 := true;
 
                    wait for DTMF_Duration;
 
                    FreqEnable_1 := false;              -- Выключаем звук
                    FreqEnable_2 := false;
 
                    wait for DTMF_Pause;
 
                end if;
 
            end if;
 
        end loop; -- while DTMF_Line != ""
 
    end loop; -- while not eof
 
    file_close(DTMF_File);
    report "Работа скрипта успешно завершена";
    wait;
 
end process WORK;
 
 
 
-------------------------------------------------------------------
--
-- Процесс формирования регистров ADRESH:ADRESL. Когда пользовательская
-- программа устанавливает бит GODONE, этот процесс берет мгновенные
-- значения сигнала, складывает их, умножает на переменную, показывающую
-- уровень сигнала, и отправляет в регистры ADRESH:ADRESL, соблюдая
-- выравнивание (левое или правое)
--
-------------------------------------------------------------------
 
ADC: process is
    variable AnalogSignal : integer;
begin
 
    wait until ADCON0.GO_nDONE == '1';  -- Ждем, когда программа начнет чтение ADC
 
    if ADCON0.ADON == '1' then
 
        while ADCON0.GO_nDONE == '1' loop
            wait for 1 ic;
        end loop;
 
        AnalogSignal := AnalogSignal_1/2  + AnalogSignal_2/2; -- Сумма мгновенных
                                                              -- значений сигналов
        AnalogSignal := AnalogSignal * SignalLevel; -- Вычисление уровня сигнала
        AnalogSignal := AnalogSignal / 100;         -- (в процентах)
        AnalogSignal := AnalogSignal + 512;         -- Средняя точка (Vdd/2)
 
        if AnalogSignal < 0 then                    -- Ограничение снизу
            AnalogSignal := 0;
        end if;
 
        if AnalogSignal > 1023 then                 -- Ограничение сверху
            AnalogSignal := 1023;
        end if;
 
        if ADCON1.ADFM == '0' then                  -- Левое выравнивание
            ADRESH <= AnalogSignal /  4;
            ADRESL <= AnalogSignal * 64;
        else                                        -- Правое выравнивание
            ADRESH <= AnalogSignal / 256;
            ADRESL <= AnalogSignal;
        end if;
 
    end if; -- ADON
 
end process ADC;
 
 
 
 
 
-------------------------------------------------------------------
--
-- Генерация синуса 1. Период выборки значений из таблицы синуса
-- оределяется переменной SampleRate_1. Файл со значениями синуса
-- читается по кругу.
--
-- FreqEnable_1 разрешает/запрещает генерацию синуса
--
-------------------------------------------------------------------
 
FREQ1: process is
 
    file     InFile_1 : text;
    variable Status_1 : file_open_status;
    variable InLine_1 : line;
    variable i_1      : integer;
    variable Time_1   : time;
    variable Now_1    : time;
 
begin
 
    file_open(Status_1, InFile_1, SinusFileName, read_mode);
    if Status_1 != open_ok then
        print("Ошибка открытия файла ", SinusFileName);
        report "Скрипт приостановлен" severity failure;
    end if;
 
 
    while endfile(InFile_1) == false loop           -- Читаем весь файл
        readline(InFile_1, InLine_1);               -- построчно
 
        while match(InLine_1, "") == false loop     -- Выбираем значения из строки
            if FreqEnable_1 == true then            -- Генерация разрешена
                read(InLine_1, AnalogSignal_1);
            else                                    -- Генерация запрещена
                read(InLine_1, i_1);
                AnalogSignal_1 := 0;
                wait for 1 us;
            end if;
 
            Now_1  := now();                        -- Компенсация ошибки, вносимой
            Time_1 := Time_1 + SampleRate_1;        -- несоответствием длительности
                                                    -- машинного цикла и SampleRate
            if  Time_1  < Now_1 then
                Time_1 := Now_1;
            end if;
 
            wait for Time_1 - Now_1;                  -- Пауза, равная периоду выборки
 
        end loop;
 
    end loop;
 
    file_close(InFile_1);
 
end process FREQ1;
 
 
 
-------------------------------------------------------------------
--
-- Генерация синуса 2. Период выборки значений из таблицы синуса
-- оределяется переменной SampleRate_2. Файл со значениями синуса
-- читается по кругу.
--
-- FreqEnable_2 разрешает/запрещает генерацию синуса
--
-------------------------------------------------------------------
 
FREQ2: process is
 
    file     InFile_2 : text;               -- Файл со значениями синуса
    variable Status_2 : file_open_status;
    variable InLine_2 : line;               -- Рабочая строка для чтения файла
    variable Time_2   : time;               --
    variable Now_2    : time;
    variable i_2      : integer;
 
begin
 
    file_open(Status_2, InFile_2, SinusFileName, read_mode);
    if Status_2 != open_ok then
        print("Ошибка открытия файла ", SinusFileName);
        report "Скрипт приостановлен" severity failure;
    end if;
 
 
    while endfile(InFile_2) == false loop           -- Читаем весь файл
        readline(InFile_2, InLine_2);               -- построчно
 
        while match(InLine_2, "") == false loop     -- Выбираем значения из строки
            if FreqEnable_2 == true then            -- Генерация разрешена
                read(InLine_2, AnalogSignal_2);
            else                                    -- Генерация запрещена
                read(InLine_2, i_2);
                AnalogSignal_2 := 0;
                wait for 1 us;
            end if;
 
            Now_2  := now();                        -- Компенсация ошибки, вносимой
            Time_2 := Time_2 + SampleRate_2;        -- несоответствием длительности
                                                    -- машинного цикла и SampleRate
            if  Time_2  < Now_2 then
                Time_2 := Now_2;
            end if;
 
            wait for Time_2 - Now_2;                -- Пауза, равная периоду выборки
 
        end loop;
 
    end loop;
 
    file_close(InFile_2);
 
end process FREQ2;
 
 
end testbench;

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

Ниже приведен фрагмент графика сигнала, сформированного данным скриптом для команды "1" (697 Гц + 1209 Гц):

Заключение

Итак, в статье были описаны известные мне конструкции языка SCL, а также приведены несколько небольших примеров использования этого языка для имитации цифровых и аналоговых сигналов в симуляторе. Я надеюсь, что описанное здесь поможет упростить процесс отладки, а главное - поможет вам утвердиться во мнении, что симулятор в MPLAB IDE - это действительно мощное средство, и не такое оно неудобное, как может показаться, если пользоваться только диалоговым окном Stimulus, пренебрегая самим языком SCL. Так что теперь, я думаю, такие задачи, как имитация 128-битного манчестерского кода, трудностей больше не вызовут.

Тем, кто раньше пользовался диалоговым окном Stimulus для задания входных сигналов, а после прочтения статьи задумался: "А как бы мне то же самое сделать на SCL?" - напомню, что в MPLAB IDE есть возможность сформировать файл SCL для заданных в диалоговом окне сигналов. Для этого нужно в диалоговом окне "Stimulus" нажать кнопку "Advanced…" и в открывшемся окне нажать кнопку "Generate SCL File". Все заданные вами воздействия будут автоматически переведены в скрипт на языке SCL.

Виктор Тимофеев, ноябрь, 2009
osa@pic24.ru

Видеоигра на PIC18

2015-11-26T21:12:26+03:00

Видеоигра на PIC18

Введение

Можно поставить под сомнение эффективность использования микроконтроллеров PIC для формирования сигналов управления монитором VGA, но нельзя отрицать того, что такое их применение возможно. Данный пример демонстрирует применение микроконтроллера PIC18F2550 в качестве самостоятельной игровой приставки. В 2004-м году была написана программа-терминал, позволяющая использовать PIC18 для формирования цветного текстового изображения на мониторе VGA. Я немного расширил возможности этой программы, добавив анимацию, полифонический звук и кнопочное управление. В далеких 80-х, когда у меня была игровая приставка "Синклер" я был без ума от игрушки Boulder Dash фирмы First Star Software. Сейчас я сделал попытку перенести ее на ПИК. Что из этого вышло, - выкладываю здесь с исходниками.

Исходные тексты программы: vga_game.rar

Программа написана на Си (HT-PICC18), за исключением обработчика прерывания, который целиком написан на ассемблере. Выполнением программы управляет ОСРВ OSA.

Характеристики программы:

Контроллер	PIC18F2550
Таковая частота	48 MHz (12 MIPS)
RTOS	OSA
VGA	256x200 пикселей, 15 цветов
Полифония	5 голосов (4 - музыка, 1 - игровые эффекты). Частота семплирования 15 КГц
Игровое поле	40x20 клеток
Видимая область игрового поля	16x12 клеток

Видео HQ (34 Mb)

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

К сожалению, в лучшем качестве снять не удалось. На самом деле изображение гораздо четче:

Описание

Схема

Схема устройства довольно простая:

Логически схему можно разбить на 4 части:

Сердце устройства - микроконтроллер;
3 резистора и 6 диодов для формирования цветного изображения;
фильтр низких частот второго порядка для вывода звука;
пять кнопок с резистивной подтяжкой к +5В.

Принцип формирования изображения описан здесь.

А вот фото самого устройства:

Распределение ресурсов

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

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

На обработчик прерывания возлагаются следующие задачи:

формирование VGA-синхроимпульсов;
формирование RGB-сигналов;
синтезатор звуков;
чтение кнопок и устранение дребезга.

Вне прерывания будет выполняться все остальное:

формирование данных анимации;
игровой алгоритм;
формирование данных для синтезатора (музыка и игровые эффекты).

Учитывая, что обработчик прерывания функционально сильно перегружен, весь его код полностью написан на ассемблере. Это позволяет не только с точностью до такта синхронизировать задачу формирования VGA-сигналов, но и максимально оптимизировать код вручную так, как компилятору будет сделать не по силам. Например, при прорисовке игрового поля и текстовой строки программа загружена по-разному и имеет свободное время для обработки звука в разные моменты времени. Поэтому код обработки звука разбит на несколько маленьких кусочков, которые втиснуты в "щели", образующиеся при формировании изображения. Например, на прорисовку каждой клеточки игрового поля уходит ровно 14 команд, а время прорисовки - 16 тактов, следовательно, есть 2 свободных такта. Прорисовка сделана так, что нечетные клеточки имеют эти два свободных такта в конце прорисовки, а четные - в начале, и т.к. они идут последовательно, то на стыках "нечетная-четная" (а таких стыков 8) появляются "щели" по 4 такта (в общей сложности 32 такта), куда и втискиваются части кода для формирования звука. При прорисовке текстовой строки эти "щели" образуются в других местах. Использование ассемблера позволило утрамбовать код так, чтобы программа успевала сделать все за выделенные ей 380 тактов (380 * 83.3 нс = 31.7 мкс - период горизонтального синхроимпульса)

Кроме того, нам нужно помнить, что для выполнения всех остальных задач остается совсем немного времени. Фактически во время прорисовки 400 строк видеоизображения у контроллера нет ни такта свободного времени для выполнения второстепенных задач, т.к. все остальное время (время синхроимпульса и левого и правого бордюра) тратится на управление синтезатором и подготовку данных для вывода на экран, а также на сохранение/восстановление контекста прерывания. Таким образом, из всего времени, за которое прорисовываются 525 строк одного кадра, есть всего 125, во время обработки которых контроллер более или менее разгружен (в это время он занят только синтезатором). Следовательно, нам нужен механизм, который позволил бы наиболее эффективно распределять оставшееся время между остальными задачами.

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

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

Формирование изображения

Формирование изображения практически такое же, как и в проекте "Терминал". Разница состоит в том, что на один пиксель выделяется две строки растра, а размер спрайта не 8x16 пикселей, а 16x16. Т.е. вся информация выводится в виде двухцветных матриц (один из цветов всегда черный). Эффект анимации создается за счет быстрой смены матриц. Пои прорисовке очередной строки из массива спрайтов, расположенного в ROM, программа выбирает байты, соответствующие текущему номеру строки. На каждый спрайт по два байта в одной строке.

Синтезатор

Синтезатор построен по тому же принципу, что и в программе "Квартет". Т.е. на каждый канал заведена переменная типа структуры, содержащей информацию о частоте, текущей фазе, громкости и пр. для данного канала. Исходя из данных содержащихся в этой структуре, выбирается байт из массива, в котором хранится оцифрованный период синусоиды (на самом деле это не совсем синусоида, а функция, вычисленная как (6*sin(x)+3*sin(2x)+sin(3x))/10). Сумма мгновенных значений амплитуд для всех каналов выводится через ШИМ. Одновременно пересчитывается громкость, затухание, для игрового канала - шум, сдвиг частоты, затухание шума. (Единственное отличие от синтезатора из "Квартета" - это добавление для канала игровых звуков эффекта шума.)

Синтезатор формирует мгновенные значения амплитуд для всех каналов в два прохода (т.е. за время прорисовки двух строк растра): на четных строках просчитываются амплитуды для каналов 0,1 и 2, а на нечетных - 3 и 4 (игровой). Поэтому и частота семплирования в два раза ниже частоты горизонтальных синхроимпульсов и равна 15.74 КГц.

Музыка

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

Анимация

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

Задача обработки анимации Task_Animate запускается после прорисовки каждого 8-го кадра (т.е. 7.5 раз в секунду).

Игра

Это была самая простая часть программы. Задача обработки игрового алгоритма Task_Game активируется после прорисовки каждого 16-го кадра (4 раза в секунду) и выполняет один шаг обновления игрового поля. Пробегаясь по всем его клеткам, задача ищет объекты, которые должны двигаться, вычисляет для них, в зависимости от траектории, следующее местоположение, а также следит за правилами игры: например, столкновение движущегося объекта (человечка или бабочки) с летящим камнем должно приводить к взрыву; взрыв уничтожает все в радиусе 2 клеток, кроме титановой стены; бабочка после смерти превращается в несколько алмазов и т.д.

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

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

Управление:

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

Создание новых уровней

За вами остается возможность создавать свои игровые уровни. В файле game_data.c инициализируется массив const char MAP[][][], в котором хранятся карты игровых полей. Количество карт определяется константой NUMBER_OF_MAPS (в моей программе = 3, но можно увеличить и создать больше карт). Каждая карта представляет собой массив char'ов размерностью (MAP_SIZE_Y+1)x(MAP_SIZE_X+1). Первая строка содержит определения цветов для разных типов объекта для конкретной карты (см. константы CL_xxx), а также требуемое количество алмазов для прохождения уровня. Далее следуют MAP_SIZE_Y строк, в которых задается сама карта с описанием объектов:

(пробел) - пустота;
# титановая не ломаемая стена;
= - кирпичная стена;
. - земля;
m - человечек;
h - домик;
x - бабочка;
f - огневушка;
o - камень;
+ - алмаз.

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

Сборка проекта

Проект создан в интегрированной среде MPLAB IDE. Для сборки использовался компилятор HT-PICC18 STD 9.51pl2.

Скачиваем файлы операционной системы OSA, распаковываем архив на диск C: (должна получиться папка C:\OSA).

Распаковываем файл vga_game.rar в папку C:\TEST\VGA. При этом внутри создастся папка VGA_GAME. В MPLAB IDE открываем проект.

Примечание. При распаковке в другую папку, отличную от C:\TEST\VGA\VGA_GAME, нужно будет через меню Project\Build options…\Project в закладке Directories в списке include-путей заменить путь к файлам проекта на тот, куда Вы распаковали файлы из архива.

Выполняем сборку нажатием Ctrl+F10.

Заключение

Создавая данный проект, я преследовал несколько целей:

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

Само устройство можно совершенствовать дальше. Например, применив внешнюю SRAM-память, можно расширить графические возможности (и количество цветов и избавиться от ограничения "1 цвет на спрайт"). Повесив внешний музыкальный контроллер (пускай просто второй ПИК), можно значительно расширить музыкальные возможности устройства (например, повысить частоту семплирования, увеличить разрядность ШИМ, увеличить количество звуковых каналов, добавить имитацию различных музыкальных инструментов и барабанов, сделать стерео и т.д.). Можно добавить внешнюю EEPROM для подгрузки карт, спрайтов, музыки и сохранения игр. Разгрузив контроллер, оставив на нем только правила игры и VGA-вывод (что, собственно, тоже можно разнести по разным контроллерам), мы можем усложнять алгоритм игры, добавлять интересные видеоэффекты и т.д. и т.п.

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

Удачи!

Виктор Тимофеев, май, 2009

Ссылки

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

http://bdash.gpio.dk/ - более близкая к оригиналу игра на ATMega
http://avga.prometheus4.com/ - несколько цветных видеоигр с выводом на VGA (ATmega).
http://www.linusakesson.net/scene/craft/ - очень интересная демка с анимацией и полифонией (ATmega).
http://www.rickard.gunee.com/projects/ - цветные игры "Тетрис" и "Pong" с выводом на телевизор (Scenix)
http://www.belogic.com/uzebox/index.htm - видеосистема на ATmega644: 240x224 пикселей, 256 цветов. Можно встроить в свою программу.

И еще ссылки:

http://z80speccy.narod.ru/ - отличный эмулятор ZX Spectrum
http://andygame.narod.ru/zx/game/index.html - игрушки для него (в том числе и Boulder Dash)

(Если у кого-то есть еще интересные ссылки по использованию 8-разрядников для формирования VGA-изображений, - пришлите, пожалуйста. Заслуживающие внимания я добавлю в список).

Текстовый VGA-терминал на PIC18

2011-06-18T21:02:14+03:00

Текстовый VGA-терминал на PIC18

Введение

Вашему вниманию предлагается программа для PIC18, в которой реализована функция простой видеокарты для вывода текстовой информации на VGA-дисплей. Конечно, PIC18 не совсем подходит для решения подобных задач, тем не менее, данный пример показывает, что это не невозможно. Эта программа была написана в 2004 году, и здесь она приводится для пояснения принципов работы проекта "Видеоигра на PIC18".

Исходные тексты программы терминала можно взять здесь: terminal.rar

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

Текстовое разрешение	30x30 символов
Графическое разрешение	240x480 пикселей
Размер матрицы знакогенератора	8x16 пикселей
Количество цветов	15
Эмуляция курсора	Есть. С возможностью изменения размера.
Наборы символов	Латинский, кириллица, псевдографика
Интерфейс управления	SPI, до 250 кбит/с

Хоть видеокарта и способна отображать 15 цветов, но есть некоторые ограничения:

фон может быть только черным;
один символ может быть только одного цвета (не считая цвета фона).

Вот тестовая картинка, сгенерированная видеокартой (сама программа была написана еще в 2004 году, но функция демо-экрана была добавлена только что для демонстрации):

Управление VGA

Немного теории

VGA-монитор управляется по 5 линиям: 2 цифровых (синхронизация горизонтальная и вертикальная) и 3 аналоговых (красный, зеленый, синий). Линии синхронизации служат для того, чтобы монитор знал, где начало кадра, какое разрешение и какова частота кадров. Аналоговые входы служат для задания цвета. Чем выше напряжение мы подаем на аналоговый вход, тем более яркий оттенок соответствующего цвета мы получим. Регулируя уровни напряжения на трех аналоговых линиях в различных комбинациях, можно получить различные оттенки цветов. Например, подав одинаковые уровни на входы управления красным и зеленым цветом (при нулевом синем) можно получить желтый цвет.

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

Для того чтобы человеческим глазом не было видно мерцания, частота обновления кадров выбирается не менее 60 Гц. Т.е. за секунду должно быть прорисовано 60 кадров. Каждый кадр в стандартном VGA-режиме состоит из 525 строк, из которых 480 являются информативными (содержащими информацию для вывода на экран), а остальные составляют передний и задний фронты синхронизации, а также нижний и верхний бордюр и не несут в себе информации о цвете. Каждая строка также логически разбита на несколько участков: передний и задний фронты синхронизации, левый и правый бордюры, видеоинформация для вывода на экран и гасящий синхроимпульс.

Нетрудно подсчитать, что время одной строки = 1с/60 кадров / 525 строк = 31.75 мкс

Ниже приведен рисунок, поясняющий порядок передачи информации на VGA-монитор:

Генерация изображения

Генерация синхроимпульсов

Здесь все просто. Все, что нам нужно, - это генерировать импульсы отрицательной полярности длительностью 3.9 мкс с постоянным периодом в 31.75 мкс. Это будут импульсы горизонтальной синхронизации. Во время каждых 524-го и 525-го импульсов будем формировать отрицательный импульс вертикальной синхронизации. Очевидно, что для этой цели удобно воспользоваться прерыванием по таймеру.

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

Формирование цветного изображения

Как мы будем формировать сигналы RGB? Вариантов несколько, но, учитывая специфику выводимой информации, т.е. цветной текст, состоящий из символов шириной по 8 пикселей, где каждый символ может быть прорисован только одним цветом, было принято решение организовать вывод следующим образом (есть еще одна причина, но о ней чуть ниже): одним выводом генерируем значение пикселя "зажжен"/"погашен", тремя выводами с открытым стоком модулируем пиксель для получения нужного цвета и одним выводом регулируем яркость. Схематически это можно изобразить так:

Когда на выходе Data уровень "0", вне зависимости от состояний остальных выходов все линии RGB будут в "0", что будет соответствовать черному цвету. Но когда на выходе Data уровень "1", то состояние линий RGB будет выбираться сигналами контроллера ~R, ~G и ~B. Если вывод установлен в "0" и соответствующий транзистор закрыт, то "1" с выхода Data будет проходить на управление цветом VGA. Если же вывод установлен в "1" и соответствующий транзистор открыт, то на соответствующей линии управления цветом будет "0". Таким образом, генерируя нули и единицы на выходе Data, мы можем каждой светящейся точке задавать цвет, устанавливая выводы ~R, ~G, ~B в нужное значение. Например, для получения точки голубого цвета нам нужно убрать красную составляющую, оставив синюю и зеленую. Т.е. устанавливаем выход ~R в "1", а ~G и ~B - в "0".

У нас есть еще один выход - ~Y. Это управление яркостью. Когда он установлен в "0", транзистор закрыт, и уровни напряжений на линиях VGA-R, VGA-G и VGA-B будут сформированы резистивным делителем, верхнее плечо которого - резистор в стоке транзисторов управления цветом, а нижнее плечо - входное сопротивление VGA = 75 Ом. Но когда выход ~Y устанавливается в "1", все три линии управления цветом прижимаются к земле через диоды, понижая тем самым напряжение на активных линиях до 0.35В (используются диоды 1N5819).

Таким образом, мы получаем 16 цветов: 8 обычных + 8 пониженной яркости. (На самом деле мы получаем 15 цветов, т.к. при данном подходе получаются два черных цвета.)

На практике транзисторы с открытым стоком мы можем реализовать на самом контроллере, установив защелку выходов в "0" и управляя регистром направления выводов (TRIS). Поэтому в устройстве для задания цвета будут присутствовать только диоды и резисторы.

Формирование последовательности пикселей

Как видно из рисунка, поясняющего порядок синхронизации, видимая часть строки длится 25.17 мкс. Это означает, что, имея контроллер с производительностью 10 MIPS (на момент написания программы это была максимальная производительность для PIC18), т.е. со временем программного цикла = 100 нс, мы можем сформировать видимую область с максимальным разрешением 251 пиксель по горизонтали. Но тут можно возразить, что потребуется как минимум один такт на формирование данных и один такт на вывод, т.е. уже 200 нс. Но мы прибегнем к возможностям периферии, а именно - воспользуемся модулем USART, который сможет сгенерировать нам последовательность из 8-ми нулей и единиц длительностью по 100 нс каждый (для этого нужно будет запустить USART в синхронном режиме на максимальной скорости). Таким образом, нам понадобятся всего два такта для формирования 8 пикселей. И еще 6 тактов остаются на всякие дополнительные нужды: чтение таблицы знакогенератора и формирование цвета.

(Использование USART является второй причиной, по которой мы для формирования последовательности "зажженных"/"погашенных" пикселей используем один вывод контроллера).

Т.к. предполагается использовать шрифт шириной 8 пикселей, то и разрешение у нас будет кратным 8, т.е. максимально возможное - 248 точек (31 символ). Однако для простоты и удобства возьмем 30. Таким образом, разрешение видеоизображения по горизонтали будет 240 точек. Для вывода изображения нам нужно после генерации синхроимпульса выдержать паузу (левый бордюр), затем выполнить прорисовку текущей линии изображения, затем выдержать еще паузу (правый бордюр). Порядок обработки прерывания будет таким:

При такой организации у нас от каждой строки остается 3.9 мкс (39 инструкций, за вычетом 5-6 на вход/выход в прерывание и сброс бита прерывания) на обработку данных от SPI. Паузы здесь отмечены условно, т.е. на самом деле это время используется на сопутствующие вычисления (эмуляцию курсора, подсчет строк, формирование указателей).

В нашей программе применяется шрифт шириной 8 пикселей. Знакогенератор хранится во внутренней ROM контроллера и представляет собой массив, в котором на описание каждого символа выделяется 16 байт (по одному байту на каждую строку растра). Например, буква 'A' записана так:

И для вывода этого символа мы будем в течение прорисовки 16 линий через один и тот же промежуток времени после начала горизонтального синхроимпульса записывать в регистр TXREG все байты, описывающие этот символ: в первой и второй линиях байты 0х00, в третьей - 0x10, в четвертой - 0x38 и т.д. Тогда на экране это будет выглядеть так:

Здесь ts - момент начала строки, tc - момент старта символа.

Для вывода одной строки растра каждого символа у нас есть 8 тактов. За это время мы должны успеть выбрать текущий байт из массива знакогенератора для следующего символа и подготовить значение цвета для него. Ровно через 8 тактов после начала вывода предыдущего символа мы выводим следующий, еще через 8 - очередной и так выводятся все 30 символов.

Принципиальная схема

Два слова о некоторых схемных решениях.

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

Во вторую очередь обратим внимание на RC-цепочку, стоящую на выходе RC7 (R4-C8). При отладке программы было обнаружено несоответствие поведения контроллера PIC18F252 (такое же несоответствие было установлено для PIC18F258, PIC18F452 и PIC18F458) с описанием в документации: там сказано, что импульсы USART, работающего в синхронном режиме на максимальной скорости, синхронизированы с тактом Q4. Однако на практике выяснилось, что они синхронизированы с тактом Q2. Для задания цвета каждому символу регистр цвета (TRISB) обновлялся одновременно с началом передачи по USART очередного байта. Проблема в том, что запись в регистр TRISB в этих контроллерах производится как раз по такту Q4. Т.е. запись в регистр управления цветом рассинхронизирована с началом передачи очередного байта по USART на Q4-Q2 = 50 нс (при тактовой частоте 40 МГц). На экране эта рассинхронизация проявляется в виде "заползания" цвета соседних символов друг на друга. Для того чтобы избавиться от этого эффекта, в схему и была внедрена RC-цепочка, задерживающая сигнал с выхода RC7 на 50 нс.

Примечание. Это несоответствие было обнаружено только на PIC18F252, PIC18F258, PIC18F452 и PIC18F458. Если будет использован контроллер более новой модификации (например, 2520), то RC-цепочку ставить не нужно.

Организация программы

Структура видеопамяти

Видеопамять содержит следующую информацию:

массив символов, выводимых на экран (8 бит на символ);
массив цветов для всех знакомест (4 бита на символ).

Экранное поле разбито на 900 знакомест (30 по вертикали и 30 по горизонтали). Таким образом, требуется 900 байт для хранения символов и 450 байт для хранения массива цветов. Учитывая требования по минимизации времени обработки данных в этих двух массивах, было решено организовать видеопамять в виде массива 3-х байтовых блоков:

xy	XX	YY

где:

x - 4 бита, задающие цвет символа XX;
y - 4 бита, задающие цвет символа YY;
XX - символ в четной позиции знакоместа;
YY - символ в нечетной позиции знакоместа.

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

Распределение SFR

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

FSR1	всегда указывает на активный блок в массиве видеопамяти, куда производится запись (фактически - текущая позиция курсора).
FSR2	Всегда указывает на текущий выводимый на экран символ
TBLPTR	Всегда указывает на массив знакогенератора (на текущую линию; подробнее см. Знакогенератор)
PCLATH	Всегда содержит значение 0х4 - старший байт адреса подпрограммы обработки SPI (т.к. там присутствует таблица переходов, обращение к которой реализовано присвоением регистру PCL)

Такое закрепление регистров позволит сэкономить время, которое могло быть затрачено на:

формирование указателей (и RAM и ROM);
сохранение/восстановление SFR при входе/выходе в/из прерывания.

Знакогенератор

Знакогенератор организован в виде массива байтов для хранения информации о 256-ти символах по 16 байт на символ. Эти данные нам нужно разместить в определенном порядке, чтобы максимально сократить время выборки требуемого для вывода на экран байта с учетом того, что за один проход (за прорисовку одной строки растра) из всех 16-байт, описывающих конкретный символ, для каждого символа будет выбран только один байт, причем с одним и тем же индексом. Т.е., выводя строку номер 5, нам потребуются только 5-е байты из 16-ти, описывающих каждый символ. Поэтому массив знакогенератора организован не в виде массива 16-байтов блоков, каждый их которых описывает один символ, а в виде массива из 16-ти 256-байтовых блоков, каждый из которых содержит на каждый символ по одному байту, который будет выводиться при прорисовке текущей линии.

Такая организация позволит при прорисовке очередной строки растра один раз сформировать значение регистра TBLPTRH, который будет указывать на 256-байтный блок, и для каждого символа просто прописывать его значение в регистр TBLPTRL, получая тем самым адрес байта для вывода на экран. С учетом такого подхода у нас есть одно требование: таблица знакогенератора должна быть выровнена по границе 256 байт. В нашей программе знакогенератор будет храниться по адресу 0x1000.

Таблица символов

(Символы с кодами с 0x80 по 0x98, выстроенные в 5 рядов по 5 символов, образуют графическое изображение логотипа Microchip.)

Курсор

Терминал способен отображать мигающий курсор в текущей позиции. Это может оказаться полезным для более удобной организации ввода данных пользователем. Скорость мигания курсора определяется периодом таймера TMR0 (курсор мигает с частотой 2.5 Гц). Вывод курсора в программе организован следующим образом: при прорисовке той строки символов, которая содержит курсор, 2.5 раза в секунду символ, в позиции которого находится курсор, подменяется символом с кодом 0x00 (он представляет собой закрашенный символ), а после прорисовки строки - восстанавливается.

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

Демонстрация

Если при подаче питания удерживать вход RA0 в "0", то программа войдет в режим демонстрации, в котором будет отображаться тестовая картинка (см. выше). Как только на RA0 появляется "1", экран очищается, и программа начинает работать в обычном режиме.

Управление терминалом

Интерфейс SPI

Наш терминал управляется внешним устройством по SPI по четырем линиям: notSS, SDI, SDO, SCK. При передачи на терминал (или при приеме от терминала) каждого байта линия notSS должна быть установлена в 0, а по завершении передачи (приема) байта - возвращена в единичное состояние. Данные (входные и выходные) синхронизируются по отрицательному фронту линии SCK. Ввиду того, что большую часть времени программа занята прорисовкой изображения, и из 31.5 мкс остается только около 2.5 мкс, т.е. 7.5% времени. Это накладывает некоторые ограничения на скорость обмена данными с терминалом. Программу удалось организовать так, что за 2.5 мкс будет успевать полностью обработаться один байт данных, т.е. за время прорисовки одной строки растра терминал может принять и полностью обработать один байт. Таким образом, частота следования байтов не может превышать частоты прорисовки строк растра, т.е. 1/31.5 мкс ~ 31.5 Кбайт/сек.

Т.е. частота SPI не должна превышать 250 кбит/сек.

Вывод данных на экран

Для вывода символа на экран в текущей позиции курсора нужно просто передать терминалу по SPI его код от 0x10 до 0xFF. Байты с 0x00 до 0x0F зарезервированы для команд (см. команды управления). При этом:

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

Команды управления

Байты 0x00-0x0F зарезервированы для передачи терминалу управляющих команд (установка позиции курсора, текущего цвета, размера курсора и пр.)

Код	Команда	Параметры	Описание
00	SPI_CMD_NOP	-	Команда ничего не делает
01	SPI_CMD_SET_X	X	Установить позицию курсора по горизонтали (0..X_SIZE-1)(пр.1)
02	SPI_CMD_SET_Y	Y	Установить позицию курсора по вертикали (0..Y_SIZE-1)(пр.1)
03	SPI_CMD_SET_CURSOR	S	Выбор размера курсора (0..15)
04	SPI_CMD_SET_COLOR	C	Установка текущего цвета (0..15)
05	SPI_CMD_SET_SYMBOL_COLOR	C	Установка цвета символа, находящегося в текущей позиции курсора (0..15). Текущий цвет при этом не меняется.
06	SPI_CMD_CLRSCR	-	Очистить экран, установить текущий цвет = 15, установить курсор в позицию 0,0. Выполнение данной команды требует длительного времени (около 2.5 мс). В течение этого времени терминал не будет обрабатывать никаких других команд, кроме команды SPI_CMD_CHECK. Есть два пути определить, что выполнение команды завершено: выдержка паузы 2.5 мс или запрос состояния выполнения этой команды командой SPI_CMD_CHECK до тех пор, пока не будет получен ответ 0x55
07	SPI_CMD_CHECK	state (пр.2)	Команда проверки состояния выполнения команды очистки экрана. Возвращает 0x55, если очистка экрана завершена (или не производится в данный момент)
08	SPI_CMD_GET_SYMBOL	char (пр.2)	Прочитать символ из видеопамяти в текущей позиции курсора
09	SPI_CMD_GET_X	X (пр.2)	Прочитать текущую позицию курсора по горизонтали
0A	SPI_CMD_GET_Y	Y (пр.2)	Прочитать текущую позицию курсора по вертикали
0B	SPI_CMD_GET_CURSOR	S (пр.2)	Прочитать текущий размер курсора
0C	SPI_CMD_GET_COLOR	C (пр.2)	Прочитать текущий цвет
0D	SPI_CMD_GET_SYMBOL_COLOR	C (пр.2)	Прочитать значение цвета символа в текущей позиции курсора
0E	SPI_CMD_GET_X_SIZE	X_SIZE (пр.2)	Получить размер экрана по горизонтали (пр.3)
0F	SPI_CMD_GET_Y_SIZE	Y_SIZE (пр.2)	Получить размер экрана по вертикали (пр.3)

Примечания:

Значения констант X_SIZE и Y_SIZE можно получить командами 0x0E и 0x0F, соответственно;
Чтение любого параметра из терминала производится в три этапа:
1. на терминал отправляется команда (см. таблицу);
2. выдерживается пауза не менее 32 мкс;
3. производится чтение байта.
Эти команды добавлены для того, чтобы осталась возможность расширения возможностей программы терминала. Например, при переносе программы на более мощный контроллер (PIC24, PIC32, ATMEGA и т.д.) появится возможность увеличить разрешение и, следовательно, количество символов в строке. Или кто-нибудь решит переделать программу так, чтобы размер символа был не 8x16, а 8x8, увеличив тем самым количество текстовых строк.

Исходные тексты

Исходные тексты программы терминала можно взять здесь: terminal.rar

Библиотека

Для удобства разработки собственных приложений, управляющих терминалом, создан файл библиотеки. Он расположен в папке APPNOTE. Файл "vga_terminal.c" добавляется в проект, а файл "vga_terminal.h" включается во все файлы, из которых предполагается делать вызов функций терминала, директивой #include.

Ниже приведен список Си-фукций модуля vga_terminal.

Функция	Описание
Вывод данных
void vga_outchar (char c);	Вывести символ в текущей позиции курсора
void vga_outcharxy (char x, char y, char c);	Вывести символ в указанной позиции курсора.
void vga_outtext (const char *t);	Вывести текст (строка, заканчивающаяся нулевым символом, расположенная в ROM) в текущей позиции курсора
void vga_outtextxy (char x, char y, const char *t);	Вывести текст (строка, заканчивающаяся нулевым символом, расположенная в ROM) в указанной позиции.
void vga_outstr (char *s);	Вывести текст (строка, заканчивающаяся нулевым символом, расположенная в RAM) в текущей позиции курсора
void vga_outstrxy (char x, char y, char *s);	Вывести текст (строка, заканчивающаяся нулевым символом, расположенная в RAM) в указанной позиции
void vga_window (char x1, char y1, char x2, char y2, char color);	Нарисовать пустое прямоугольное окно в указанных координатах с рамкой указанного цвета.
char vga_getchar (void);	Прочитать символ в текущей позиции курсора
Очистка экрана
void vga_clrscr (void);	Начать очистку экрана. После этой функции нужно либо выдержать паузу 2.5 мс, либо проверять окончание ее выполнения функцией vga_check() (пока она не вернет "1")
char vga_check (void);	Возвращает "1", если терминал готов принимать данные. Иначе возвращает "0". Применяется в основном для проверки окончания выполнения очистки экрана.
Управление цветом
void vga_setcolor (char color);	Установить текущий цвет.
char vga_getcolor (void);	Прочитать текущий цвет.
char vga_getcharcolor (void);	Прочитать цвет символа расположенного в текущей позиции курсора
Управление курсором
void vga_gotoxy (char x, char y);	Переместить курсор в указанное место
void vga_setcursorsize (char size);	Установить размер курсора (0 - спрятать)
char vga_getx (void);	Получить текущую X-позицию курсора
char vga_gety (void);	Получить текущую Y-позицию курсора
char vga_getwidth (void);	Получить ширину экрана (в символах)
char vga_getheight (void);	Получить высоту экрана (в символах)

Тест-приложение

Маленькая программа для PIC16F88, демонстрирующая использование библиотеки vga_terminal для управления терминалом: terminal_test.rar Для связи используется аппаратный SPI.

Программа выводит на экран следующую картинку:

Поделки читателей

Терминал с разрешением 51x30 символов - читатель Ковалев Игорь переделал терминал для работы на 16МГц (PIC18F46K20). За счет увеличения скорости он увеличил горизонтальное разрешение; символы визуально сузились, что сделало изображение более симпатичным

Ссылки

VGA-Терминал на PIC24 - 60х25 символов, 8 цветов, 2 размера шрифта, PS/2 клавиатура, USART. Схема, исходники, отличное описание (англ.)

http://www.micro-examples.com/public/microex-navig/doc/089-pic-pal-tv.html - PIC PAL Video Library - проект для PIC18F4620, написанный на mikorC

http://www.mikrocontroller.net/topic/53140 - текстовый терминал на ATmega8, 40x25, управление UART 19200 (вывод PAL)

http://neil.franklin.ch/Projects/SoftVGA/ - Еще один проект для atmega32.

http://mondo-technology.com/dcvideo.html - текстовый терминал на PIC16F819 с видео выходом. Разрешение 20x10 символов, управление: UART 9600

volatile для "чайников"

2023-02-03T03:54:13+03:00

volatile для "чайников"

Скачать в PDF-формате

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

Вступление

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

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

Большинство примеров, приведенных в этой статье, написаны для компилятора GCC (Mplab C30), потому что, учитывая архитектуру ядра PIC24 и особенности компилятора, для него проще всего синтезировать маленькие наглядные примеры, в которых будет проявляться неправильное обращение с volatile. Многие из этих примеров будут собираться совершенно корректно на других (более простых) компиляторах, таких как PICC или MicroC. Но это не значит, что при работе с этими компиляторами ошибки неиспользования volatile не проявляются вовсе. Просто код демонстрации для этих компиляторов выглядел бы намного больше и сложнее.

Определение

(volatile в переводе с английского означает "нестабильный", "изменчивый")

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

Что это значит? Известно, что одной из характеристик компиляторов, говорящих за их качество, является способность оптимизировать генерируемый объектный код. Для этого они объединяют повторяющиеся конструкции, сохраняют в регистрах общего назначения промежуточные результаты вычислений, выстраивают последовательность команд так, чтобы минимизировать долго выполняющиеся фрагменты кода (например, обращение через косвенную адресацию), и т.д. Выполняя такую оптимизацию, они немного преобразует наш код, подменяя его идентичным с точки зрения алгоритма, но более быстрым и/или компактным. Но такую подмену можно делать не всегда. Рассмотрим пример:

   char a = 0;
   ...
   a |= 1;
   a |= 2;
   ...

С точки зрения алгоритма устанавливаются два младших разряда в переменной a. Оптимизатор может сделать подмену такого кода одним оператором:

    a |= 3;

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

    PORTB |= 1;
    PORTB |= 2;

Вот в этом случае оптимизация с заменой на "PORTB |= 3" нас может не устроить! Управляя напрямую состояниями выводов контроллера, нам часто бывает важна последовательность изменения сигналов. Например, мы формируем сигналы SPI, и один вывод (PORTB.0) - это данные, а другой (PORTB.1) - синхроимпульсы. В этом случае нам нельзя изменять состояния этих выводов одновременно, т.к. при этом нельзя гарантировать, что управляемая микросхема по синхроимпульсу получит правильные данные. И уж тем более, нам бы не хотелось, чтобы оптимизации подвергся код, формирующий синхроимпульс длительностью в один такт:

    PORTB |= 2;
    PORTB &= ~2;

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

extern volatile      unsigned char PORTB @ 0x06;                   // В HT-PICC
extern volatile near unsigned char PORTB;                          // В MCC18
extern volatile near unsigned int  PORTB __attribute__((__sfr__)); // В MCC30
и т.д.

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

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

Ошибки, связанные с volatile

Есть три основных типа ошибок, касающихся квалификатора volatile:

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

Неиспользование volatile

Глобальные переменные

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

Модификация переменной в прерывании

Рассмотрим пример для PIC24:

unsigned char Counter;
 
void __attribute__((__interrupt__, __auto_psv__)) _T1Interrupt (void)
{
    IFS0bits.T1IF = 0;
    Counter++;
}
 
void wait (unsigned char Time)
{
    Counter = 0;
    while (Counter < Time) continue;
}

При отключенной оптимизации данный код будет работать. Но стоит включить оптимизацию, как программа начнет зависать в функции wait(). Что происходит? Компилятор, транслируя функцию wait(), не знает про то, что переменная Counter может измениться в любой момент при возникновении прерывания. Он видит только то, что мы ее обнуляем, а затем сразу сравниваем с параметром Time. Другими словами компилятор предполагает, что переменная Time всегда сравнивается с нулем, и листинг функции wait() при включенной оптимизации будет выглядеть так:

0x5B4   wait:   clr.b   Counter
0x5B6           cp0.b   w0          ; <-----
0x5B8           bra     nz, 0x5B6
0x5BA           return

(Примечание: компилятор Си единственный однобайтовый аргумент передает в функцию через регистр w0)

Что мы видим в этом коде: производится обнуление переменной Counter, а затем параметр функции Time, переданный в нее через регистр w0, сравнивается с нулем, больше не обращая внимания на истинное значение переменной Coutner, которая исправно увеличивается при каждом прерывании по таймеру. Другими словами, мы попали в вечный цикл. Как уже говорилось, дело в том, что компилятор не предполагает, что функция будет прервана каким-то кодом, который будет производить операции над переменными, участвующими в работе функций. Здесь нам на помощь и приходит квалификатор volatile:

volatile unsigned char Counter;
 
void __attribute__((__interrupt__)) _T1Interrupt (void)
{
    IFS0bits.T1IF = 0;
    Counter++;
}
 
void wait (unsigned char Time)
{
    Counter = 0;
    while (Counter < Time) continue;
}

Теперь при трансляции компилятор сгенерит код, который будет каждый раз обращаться к переменной Counter:

0x5B4   wait:   mov.b   w0, w1
0x5B6           clr.b   Counter
0x5B8           mov.b   Counter, w0      ; <-----
0x5BA           sub     w0, w1, [w15]
0x5BC           bra     nc, 0x5B8
0x5BE           return

Модификация переменной в параллельной задаче

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

unsigned char Button;
 
void Task_Button (char NewLevel)
{
    unsigned int Temp;
 
    for (;;)
    {
        //...
        // Переключение контекста
        //...
 
        Temp = PORTB;
        //...
        // Обработка дребезга
        //...
 
        Button = 0;
        if (Temp & 1) Button = 1;
        if (Temp & 2) Button = 2;
        if (Temp & 4) Button = 3;
    }
}
 
void Task_Work ()
{
    if (!Button) PIN_RED_LED = 1;
    for (;;)
    {
        //...
        // Переключение контекста
        // и пр.
        //...
 
        switch (Button)
        {
            case 1: //... Действия по кнопке 1
                    break;
            case 2: //... Действия по кнопке 2
                    break;
            case 3: //... Действия по кнопке 3
                    break;
        }
    }
}

Программа хорошо работала, будучи собранной компилятором HT-PICC18, но при переносе этого же кода на PIC24 (компилятор MCC30) работать перестала, т.е. совсем не реагировала на кнопки. Проблема была в том, что оптимизатор MCC30, в отличие от оптимизатора HT-PICC18, учел, что на момент выполнения switch значение переменной Button уже хранится в одном из регистров общего назначения (w0) (в PIC18 всего 1 аккумулятор, поэтому при работе с ним такое поведение менее вероятно):

;                            if (!Button) PIN_RED_LED = 1;
    mov.b   Button, w0
    bra     nz, 1f
    bset.b  PORTB, 0
1:
    ...
    ...
;                            switch (Button)
    sub.b   w0, #2, [w15]
    bra     z, Case2
    sub.b   w0, #3, [w15]
    bra     z, Case3
    sub.b   w0, #1, [w15]
    bra     nz, SwithEnd
Case1:
    ...
Case2:
    ...
Case3:
    ...
SwithEnd:

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

После правильного объявления переменной:

volatile unsigned char Button;
 
void Task_Button (char NewLevel)
{
    ...
}
 
void Task_Work ()
{
    ...
}

проблема исчезла:

;                            if (!Button) PIN_RED_LED = 1;
    mov.b   Button, w0
    bra     nz, 1f
    bset.b  PORTB, 0
1:
    ...
    ...
;                            switch (Button)
    mov.b   Button, w0
    sub.b   w0, #2, [w15]
    bra     z, Case2
    mov.b   Button, w0
    sub.b   w0, #3, [w15]
    bra     z, Case3
    mov.b   Button, w0
    sub.b   w0, #1, [w15]
    bra     nz, SwithEnd
Case1:
    ...
Case2:
    ...
Case3:
    ...
SwithEnd:

Локальные переменные

Часто для создания небольших задержек пользуются такими функциями:

void Delay (char D)
{
    char i;
    for (i = 0; i < D; i++) continue;
}

Однако, некоторые компиляторы видят в этих функциях бесполезный код и вообще не включают его в результирующий объектный код. Если эта задержка применялась для снижения скорости программного i2c (или SPI) под компилятором, например, HT-PICC, то при переносе на ядро AVR с компилятором WinAVR программа перестанет работать, вернее, она будет работать так быстро, что управляемая микросхема не будет успевать обрабатывать сигналы из-за того, что все вызовы функции Delay будут упразднены.

Чтобы этого не происходило, нужно использовать квалификатор volatile:

void Delay (char D)
{
    volatile char i;
    for (i = 0; i < D; i++) continue;
}

Указатели на volatile

Также распространенной ошибкой является использование обычного указателя (не указателя на volatile) на volatile-переменную. Чем это может нам навредить? Рассмотрим пример (из реальной программы), в котором был использован указатель на регистр порта ввода/вывода. Программа по SPI управляла двумя одинаковыми микросхемами, подключенными на разные выводы микроконтроллера, порт, к которому подключена активная микросхема, выбирался через указатель:

unsigned int *Port;
 
void SPI_Send (unsigned char Data)
{
    char i = 8;
 
    do
    {
        if (Data & 0x80) *Port |=  1;      // Set data bit
        else             *Port &= ~1;
 
        *Port |=  2;                       // Make clock pulse
        Data <<= 1;                        // Shift data
        *Port ^= ~2;
    } while (--i);
 
}
 
void main (void)
{
    //...
    Port = &PORTB;
    //...
    SPI_Send(0x55);
    SPI_Send(0x66);
    //...
 
}

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

   0050C   SPI_Send:        mov.w   port,w1
   0050E                    mov.b   #0x8,w2         ;    i = 8
   00510   While:           cp0.b   w0,#0           ;      if (Data & 0x80)
   00512                    bra     ges, 0x000518
   00514                    bset    [w1],#0         ;        *Port |=  1
   00516                    bra     0x00051a
   00518                    bclr    [w1],#0         ;        *Port &= ~1
                                                    ;        *Port |=  2     <=======
   0051A                    add.b   w0,w0,w0        ;        Data <<= 1
   0051C                    bclr    [w1],#1         ;        *Port &= ~2
   0051E                    dec.b   w2,w2           ;    while (--n)
   00520                    bra nz, 0x000510
   00522                    return

Обратим внимание на то, что компилятор "выкинул" установку бита 1 ("*Port |= 2"), посчитав ее лишней, т.к. почти сразу же за ней этот бит снова обнуляется, т.е. он выполнил оптимизацию без учета особенностей регистра, на который указывала переменная Port, а сделал он так потому, что программист не объяснил компилятору, что регистр непростой. Для исправления ошибки нужно было объявить переменную Port как указатель на volatile переменную:

volatile unsigned int *Port;
 
void SPI_Send (unsigned char Data)
{
    ...
}

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

   0050C   SPI_Send:        mov.w   port,w1
   0050E                    mov.b   #0x8,w2         ;    i = 8
   00510   While:           cp0.b   w0              ;      if (Data & 0x80)
   00512                    bra     ges, 0x000518
   00514                    bset    [w1],#0         ;        *Port |=  1
   00516                    bra     0x00051a
   00518                    bclr    [w1],#0         ;        *Port &= ~1
   0051A                    bset    [w1],#1         ;        *Port |=  2    <-----------
   0051C                    add.b   w0,w0,w0        ;        Data <<= 1
   0051E                    bclr    [w1],#1         ;        *Port &= ~2
   00520                    dec.b   w2,w2           ;    while (--n)
   00522                    bra nz, 0x000510
   00524                    return

Аргумент функции

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

void SPI_Send (unsigned char Data, volatile unsigned int *Port)
{
   ...
}
 
 
void main (void)
{
    //...
    SPI_Send(0x55, &PORTB);
    SPI_Send(0x66, &PORTB);
    //...
 
}

В противном случае мы получим все те же ошибки, что и в предыдущем примере.

Неправильное использование volatile

volatile != атомарность

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

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

Рассмотрим пример обращения к переменной, занимающей более чем одну ячейку памяти (для 16-разрядных контроллеров это int32, int64, float, double; для 8-разрядных - еще и int16). Я часто приводил этот пример, приведу еще раз (для HT-PICC18):

volatile unsigned int ADCValue;    // Результат чтения АЦП (производится в прерывании)
 
void interrupt isr (void)
{
    if (ADIF && ADIE)
    {
        ADIF     = 0;
        ADCValue = (ADRESH << 8) | ADRESL;  // Читаем последнее измерение
        ADGO     = 1;                       // Запускаем следующее
    }
}
 
void main ()
{
    //...
    while (1)
    {
        //...
        if (ADCValue < 100) Alarm();       // Сравнение напряжения с пороговыми
        if (ADCValue > 900) Alarm();       // значениями и вызов тревоги
        //...
    }
}

Обратим внимание, что переменная ADCValue имеет размерность 2 байта (для хранения 10-битного результата АЦП). Чем опасен данный код? Рассмотрим листинг одного из сравнений (допустим, первого):

;                  if (ADCValue < 100) Alarm();
    MOVLW    0
    SUBWF    ADCValue + 1, W
    MOVLW    100
    BTFSC    STATUS, Z
    SUBWF    ADCValue, W
    BTFSS    STATUS, C
    RCALL    Alarm

Допустим, значение напряжения на входе АЦП такое, что результат преобразования равен 255 (0x0FF). И последнее значение переменной ADCValue, соответственно, тоже = 0x0FF. С этим значением начинает выполняться код сравнения со значением 100 (0x064). Сначала сравниваются старшие байты переменной и константы (0x00 с 0x00), а затем - младшие (0x64 и 0xFF). Результат, казалось бы, очевиден. Однако здесь кроется неприятность. Хоть результат АЦ-преобразования и равен 0xFF, на него влияют несколько факторов: стабильность напряжения питания (или опорного напряжения), стабильность входного сигнала, близость уровня измеряемого напряжения к порогу смены единицы младшего разряда, наводки, шумы и пр. Поэтому результат АЦ-преобразования имеет некий джиттер в одну-две единицы младшего разряда. Т.е. результат АЦП может скакать между значениями 0xFF и 0x100. И если между выполнением сравнений возникнет прерывание, то может произойти следующее:

значение ADCValue = 0x0FF;
произведено сравнение старших байтов: 0x00 и 0x00;
возникло прерывание по ADIF, в котором значение переменной ADCValue обновилось на 0x100;
производится сравнение младших байтов: 0x64 и уже 0x00!
т.к. программа думает, что было сравнение 0x000 < 0x064, то она вызывает функцию Alarm.

И квалификатор volatile здесь не спасает. Здесь спасет только запрет прерываний на время выполнения сравнений.

        ADIE = 0;
        if (ADCValue < 100) { ADIE = 1;  Alarm();}
        if (ADCValue > 900) { ADIE = 1;  Alarm();}
        ADIE = 1;
...
 
void Alarm (void)
{
    ADIE = 1;		// Не забыть включить прерывание при выполнении условий
    ...

Так может быть, volatile вообще не нужен? Прерывания-то все равно запрещаются? Да, прерывания запрещаются, но volatile, все-таки нужен. Зачем? Рассмотрим почти такой же код для компилятора C30:

unsigned int ADCValue;
 
void main (void)
{
    //...
    Temp = ADCValue;
 
    while (1)
    {
        //...
        IEC0bits.ADIE = 0;
        if (ADCValue < 100) { IEC0bits.ADIE = 1; Alarm();}
        if (ADCValue > 900) { IEC0bits.ADIE = 1; Alarm();}
        IEC0bits.ADIE = 1;
        //...
    }
}

Вот здесь-то volatile и пригодится! Обратим внимание на строчку перед вечным циклом - присваивание значения переменной ADCValue переменной Temp. А заодно посмотрим листинг:

00536      mov.w    ADCValue, w1
00538      mov.w    w1, Temp
;                                   while (1)
;                                   {
;                                       IEC0bits.AD1IE = 0;
0053A      bclr.b   0x0095,#5
;                                       if (ADCValue < 100) { IEC0bits.AD1IE = 1; Alarm();}
0053C      mov.w    #0x63,w0
0053E      sub.w    w1,w0,[w15]
00540      bra      leu, 0x000548
;                                       if (ADCValue > 900) { IEC0bits.AD1IE = 1; Alarm();}
00542      mov.w    #0x384,w0
00544      sub.w    w1,w0,[w15]
00546      bra      leu, 0x00054c
00548      bset.b   0x0095,#5
0054A      rcall    Alarm
;                                       IEC0bits.AD1IE = 1;
0054C      bset.b 0x0095,#5

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

volatile указатели

Иногда бывает такое, что сам указатель на какую-то переменную должен быть защищен от оптимизации (например, есть его модификация в теле прерывания). Часто программисты совершают одну и ту же ошибку, т.е. при объявлении такого указателя ставят volatile не туда, куда нужно:

volatile char *p;
или
char volatile *p;

Обе записи идентичны, но они не делают саму переменную p volatile-переменной. Обе записи означают "переменная p является указателем на volatile char". Последствия такого определения очевидны: при изменении значения указателя в прерывании или в параллельной задаче программа этого может не заметить, т.к. будет работать с указателем через РОН.

Правильное определение выглядит так:

char * volatile p;

Если же нужен volatile-указатель на volatile-переменную, то он объявляется так:

volatile char * volatile p;

Использование volatile не к месту

Скажу два слова об этой проблеме. У некоторых однажды нарвавшихся на проблемы, связанные с отсутствием volatile там, где он должен был быть, появляется какой-то комплекс volatile-мании (или оптимизация-фобии), когда в страхе, что "а вдруг компилятор этот код выкинет", чуть ли не все переменные объявляются с квалификатором volatile. В принципе, ничего криминального в таком использовании volatile нет, код будет работать правильно, но он будет громоздкий и неповоротливый. volatile не позволит компилятору применять оптимизацию, и некоторые фрагменты, которые, будучи оптимизированы, выполнились бы за 50-100 тактов, будут выполняться за 1000-2000 тактов. То же самое касается объемов кода (в десятки раз он, конечно, не вырастет, а вот раза в два - запросто). Другими словами появится неудовлетворенность оттого, что "и контроллер быстрый, и компилятор хороший, а код все равно тормозит".

Здесь четких рекомендаций я дать не смогу. В большинстве случаев при написании программ на Си я стараюсь придерживаться следующих правил:

глобальные переменные, используемые и в прерываниях, и в программе (или в прерываниях различных приоритетов), нужно объявлять как volatile;
глобальные переменные, обрабатываемые двумя и более задачами при работе под многозадачной ОС, нужно объявлять как volatile;
указатели на периферийные регистры, а также на переменные, объявленные как volatile, нужно объявлять как указатели на volatile;
все, что не попадает под первые три правила и не связано с периферией, рекомендуется писать, абстрагируясь от железа. Тогда становится понятно, что циклы вида "for (i = 0; i<100; i++) {};" не несут на себе никакой алгоритмической нагрузки и могут быть удалены. А если они должны быть оставлены, то переменные следует объявлять как volatile.
во всех остальных случаях volatile будет лишним.

Дополнительно

Еще несколько замечаний:

volatile можно ставить в любое место в типе

Как уже указывалось выше, следующие записи эквивалентны:

volatile static int N;
static volatile int N;
static int volatile N;

Лично я для наглядности volatile выношу вперед.

volatile и typedef

volatile может быть использован при определении типов по всем правилам:

typedef volatile char vchar;

Теперь все переменные типа vchar будут volatile-переменными.

volatile и структуры

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

typedef volatile struct
{
    unsigned char  Counter;
    unsigned char *Buffer;
} T_BUFFER;

(Обращу ваше внимание на то, что здесь Buffer является volatile-указателем на не-volatile переменную. Т.е. эквивалент определения: "unsigned char * volatile Buffer", а не "volatile unsigned char *Buffer".)

А в этой - только счетчик:

typedef struct
{
     volatile unsigned char  Counter;
              unsigned char *Butter;
} T_BUFFER;

volatile и extern

Если переменная во внешнем модуле объявлена как volatile:

volatile int Counter;

, то и в заголовочном файле она должна быть объявлена с квалификатором volatile:

extern volatile int Counter;

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

5.4 Сторожевой таймер

2013-09-04T22:35:51+03:00

5.4 Сторожевой таймер

Данная статья является наброском к главе "5.4 Сторожевой таймер" книги "Отказоустойчивое ПО для МК".

Определение

WDT - сторожевой таймер (watchdog timer) - аппаратный механизм защиты от зависания программы. В самом простом случае WDT представляет собой счетчик, тактируемый системным или независимым генератором. При переполнении счетчика схема WDT генерирует сигнал сброса микроконтроллера, который приводит к его перезагрузке. Программа должна периодически посылать схеме WDT сигнал о том, что все в порядке; этот сигнал говорит сторожевому таймеру, что программа работает корректно, и счетчик сторожевого таймера обнуляется (в некоторых контроллерах обновляется константой).

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

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

Типы WDT

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

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

Внутренний WDT

Встроенный в МК сторожевой таймер является самым ненадежным из перечисленных и на него можно полагаться только в малоответственных системах. Есть две причины:

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

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

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

во-первых, он может пробуждать контроллер из Sleep-режима с заданным интервалом (если WDT тактируется независимым генератором);
во-вторых, он является единственной возможностью выполнить программный сброс в контроллерах, в которых не предусмотрена инструкция RESET (AVR, PIC16, LPC213x);
в-третьих, возможность программного отключения WDT позволяет максимально снизить потребление микроконтроллера за счет отключения независимого генератора;
в-четвертых, некоторые контроллеры при переполнении WDT перед формированием сигнала сброса генерируют немаскируемое прерывание, которое позволяет успеть выполнить минимальный набор операций по переводу микроконтроллера и каких-то внешних устройств в безопасный режим перед сбросом, а также записать в ОЗУ какие-то данные, которые при перезагрузке могут использоваться для идентификации сбоя и анализа его причин;
в-пятых, есть возможность изменять интервал в зависимости от режима работы.

Внешний WDT в виде специализированной микросхемы

Более эффективным с точки зрения надежности (и в большинстве случаев достаточным) является внешний WDT, выполненный в виде отдельной микросхемы. Обычно такие микросхемы комбинируют в себе функции сторожевого таймера и монитора напряжения питания. Такие микросхемы (они называются супервизорами, микропроцессорными мониторами или просто сторожевыми таймерами) выпускаются разными фирмами в различных вариантах. Сигналом "все хорошо" сторожевому таймеру в составе такой микросхемы обычно служит изменение логического уровня ("0"→"1" или "1"→"0") на специальном входе. Изменение уровня сбрасывает внутренний счетчик. Супервизоры имеют выход для управления сбросом микроконтроллера (обычно такие микросхемы имеют два выхода для управления сбросом: прямой и инверсный, - т.к. микроконтроллеры различных производителей имеют различные активные уровни входа сброса). Когда супервизор обнаруживает, что напряжение питания опустилось ниже какого-то предустановленного уровня или сигнал "все хорошо" отсутствует длительное время, он формирует активный уровень на выходе управления сбросом и удерживает его в активном состоянии либо в течение какого-то времени (если произошел сброс по переполнению счетчика сторожевого таймера) либо до того момента, как напряжение питания не придет в норму. Это общая функция, присущая всем супервизорам со встроенным WDT, в остальном микросхемы-супервизоры могут отличаться:

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

В зависимости от задач, которые мы хотим возложить на WDT, помимо его основной функции, мы можем выбирать ту или иную микросхему. Для управления WDT в составе такой микросхемы нам понадобится один вывод контроллера, настроенный на выход, для генерации сигналов обнуления WDT (в случае контроля выхода WDO потребуется еще один вывод МК, настроенный на вход).

Также при выборе микросхемы супервизора следует обращать внимание на следующие параметры:

потребление (варьируется от единиц микроампер до единиц миллиампер);
тип корпуса: от SOT23 до DIP16;
диапазон рабочих температур;
цена.

Ниже приведены примеры микросхем-супервизоров, в составе которых имеется WDT (это краткий список, на самом деле таких микросхем великое множество):

    MCP131x - 4 интервала WDT (6.3, 102, 1600, 25600 мс), потребление 5мкА, нет ножки WDO
    ADM699 - фиксированное и довольно длительное время переполнения (тип. 1.6с),
             имеет выход ~WDO, позволяющий определить, что сброс был вызван переполнением WDT.
             Нет внешнего тактирования. Нет входа для батарейки. 600 мкА.
    ADM705
    MAX69x (x - четный) -  Имеет выход ~WDO. Можно подключать батарейку. 2мА.
    MAX69x (x - нечетный) - есть внешнее тактирование, два режима счета (1.6сек или 100 ms).
             Имеет выход ~WDO. Можно подключать батарейку. 2мА.
    EM6151 - оконный (67/33 или 33/67), без батарейки, 35 мкА (+ слип-режим 25 мкА), нет WDO
    TC1232, ADM1232, MAX1232 - три режима интервала (150мс, 600мс, 1200мс), не имеет выхода WDO
    MAX6746-6753 - 5 мкА, регулируемое время WDT, маленький корпус (sot23-8), оконный
    MAX6369 - 8мкА, регулируемое время, корпус sot23-8, есть WDO

TODO: дополнить и разъяснить

Внешний WDT в виде устройства

Отдельное устройство разрабатывается индивидуально с учетом особенностей конкретного устройства, используемого в нем микроконтроллера и конкретной программы. Сердцем такого устройства может быть маленький, например, 8-разрядный микроконтроллер (чаще OTP, например, PIC12CE518), который, помимо стандартного набора функций WDT, может иметь ряд дополнительных возможностей. Т.е. преимущества таких WDT в расширенном функционале и гибкости настройки.

Недостатками таких WDT являются габариты, а также то, что программа в маленьком МК должна соответствовать всем требованиям безопасности (начиная с самодиагностики и заканчивая контролем собственного внутреннего WDT), а также требует тщательнейшей отладки. Кроме того, сам микроконтроллер, используемый в качестве WDT, также подвержен всем видам сбоев, вызванных помехами. Но это компенсируется, во-первых, тем, что такие контроллеры выполнены по более грубой технологии, чем тот, которым они будут управлять, следовательно, они помехам подвержены гораздо меньше; во-вторых, есть возможность организовать "круговую поруку", когда маленький МК следит за большим, а большой следит за маленьким, что во много раз повышает вероятность самовосстановления работоспособности системы после сбоя.

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

контроль частоты тактирующего генератора - это позволит формировать сигнал аварии, если по каким-то причинам тактовая частота контролируемого МК не соответствует ожидаемой (например, частота внутреннего RC-генератора ушла на морозе);
контроль последовательности действий - в некоторых случаях может являться дополнением к run-time тестам, описанным в предыдущем параграфе;
может принимать более сложные сигналы управления, чем простая смена уровня - смена логического уровня (являющаяся сигналом для большинства специализированных микросхем WDT) довольно мало информативна, она может происходить и при сбитой частоте, и при логическом зацикливании программы (когда требуемые действия выполняются, но не в той последовательности);
может изменять параметры окна в широком диапазоне - в зависимости от режима работы целевого МК могут понадобиться различные временные интервалы: где-то скорость реакции на сбой должна быть максимальной, а где-то выполняются длинные критические секции, которые нельзя прерывать;
формирование предварительного сигнала для генерации немаскируемого прерывания - крайне полезная функция, которая позволит целевому микроконтроллеру (если он, конечно, не завис наглухо) попасть в обработчик аварийного прерывания, в котором он может успеть перевести внешнее оборудование в безопасный режим.

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

Предпосылки к использованию

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

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

(Детально о причинах отказов ПО см. "2. Причины и последствия сбоев")

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

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

Но, во-первых, средствами программы всего проверить и перепроверить нельзя. И ограничения здесь не только в памяти, используемой для тестов, и времени, которое тесты отнимут, но и в том, что сами тесты, являясь частью программы, нужно бы проверять. А потом проверять и эти проверщики и т.д. Поэтому run-time тесты всегда неполные. Во-вторых, существуют непредвиденные сбои, при которых программный счетчик может прыгнуть в такую точку программы, в которой при текущем состоянии ячеек RAM-памяти и текущих настройках периферии, можно задержаться очень надолго. Например, сбоем программного счетчика, программа попала в код передачи байта в программной реализации интерфейса SPI:

    void spi_send_byte (unsigned char Data)
    {
        int i;
 
        i = 8;
 
        <---- Сюда попали из-за сбоя PC
 
        do
        {
            if (Data & 0x80) PIN_DO = 1;
            else             PIN_DO = 0;
 
            spi_delay();
            PIN_CLK = 1;
            spi_delay();
            PIN_CLK = 0;
 
            Data <<= 1;
        } while (--i);
    }

На момент сбоя в ячейке памяти, где располагается переменная i, могло находиться любое значение, и безобидный цикл на 8 проходов может превратиться в цикл на 50000 проходов. В общем случае от подобных сбоев может спасти только WDT. В предыдущем параграфе (5.3 run-time контроль) было сказано о контроле стека и сигнатурах, которые могли бы сигнализировать о том, что что-то идет не так, но подобные тесты, во-первых, нецелесообразно применять во всех функциях без исключения, а во-вторых, при большом значении числа в ячейках памяти, занятых переменной i, WDT может успеть переполниться раньше, чем программа дойдет до проверок в конце функции.

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

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

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

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

Порядок обнуления WDT

Примечание: в данном параграфе применяюся вызовы псевдо-функций wdt_clear() и soft_reset().

Предполагаем, что wdt_clear() выполняет необходимую последовательность действий по обнулению счетчика WDT (например, для внешнего WDT она будет инвертировать управляющий выход, для микроконтроллеров AVR это будет последовательная запись 1 и 0 в регистр WDTCR.4, для МК PIC это выполнение инструкции CLRWDT),
Предполагаем, что soft_reset() производит последовательность действий по сбросу микроконтроллера: где-то это будет выполнение инструкции RESET, где-то вечный цикл с блокировкой прерываний, который даст переполниться WDT, а где-то - прыжок на начальный адрес ROM, где произойдет переинициализация стека (в реальности этим действиям должны предшествовать действия по переводу внешнего оборудования в безопасный режим, но для наглядности пока это опустим).

Что такое порядок обнуления WDT

Порядок обнуления WDT - это правила, по которым программа выполняет проверки и принимает решение о том, что на данный момент времени она выполняется корректно и, следовательно, можно давать команду WDT на обнуление счетчика. Т.е. счетчик WDT можно обнулять только тогда, когда программа считает, что все в порядке. Здесь кроются две проблемы:

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

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

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

Часто совершаемая ошибка - безусловное обнуление

Довольно часто можно встретить такой подход, при котором счетчик WDT безусловно обнуляется в главном цикле программы, в прерывании по таймеру, возникающему раз в миллисекунду, или несколько раз в программе с интервалом в 5-10 инструкций (или операторов). Другими словами, программист делает все, чтобы сторожевой таймер не успел переполниться ни при каких условиях. Доходит даже до комичного кода:

    char uart_getch (void)
    {
        while (!USART_RX) wdt_clear();
        return USART_RXREG;
    }

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

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

Периодическое обнуление с проверкой флагов

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

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

union
{
    struct {                    // Каждый бит обнуляется в соответствующей подпрограмме
        UINT8   bKeyboard : 1;  // Обработка кнопок
        UINT8   bLCD      : 1;  // Ввывод данных на экран
        UINT8   bRelay    : 1;  // Включение/выключение реле
        UINT8   bClock    : 1;  // Часы
    } Bits;
 
    UINT8 NotDone;              // Когда все биты сброшены, эта переменная = 0
 
} g_WDT;

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

void main (void)
{
    g_WDT.NotDone = 0;// При инициалиации считаем, что программа выполняется корректно
    ...
    while (1)         // Основной цикл программы
    {
        if (!g_WDT.NotDone)   // Первый проход цикла или все подпрограммы отработали
        {
            // Устанавливаем флаги функций, требуемых к выполнению
            g_WDT.Bits.bKeyboard = 1;
            g_WDT.Bits.bLCD      = 1;
            g_WDT.Bits.bRelay    = 1;
            g_WDT.Bits.bClock    = 1;
 
            // Обнуляем счетчик WDT
            wdt_clear();
        }
        KeyboardWork();
        LCDWork();
        RelayWork();
        ClockWork();
    }
}

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

void KeyboardWork (void)
{
    if (!KeyboardTimeout) return;    // Обрабатываем кнопки с определенным периодом. Если время еще не
                                     // настало, то выходим из функции (примечание: данный флаг может
                                     // устанавлиается, например, в прерывании по таймеру
 
    // Читаем кнопки и обрабатываем дребезг
    ...
 
    g_WDT.Bits.bKeyboard = 0;  // Обнуляем флаг, сообщая, что функция отработала успешно
}

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

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

он прост и легок в проектировании;
он легко контролируется, т.к. программа содержит единственное место, где производится обнуление;
он практически не требует ресурсов (ни ROM, ни RAM, ни времени).

Однако он имеет и свои недостатки:

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

Обнуление с контролем отдельных функций

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

    uint16 g_WDT_Temp; // глобальная переменная
 
    ...
    g_WDT_Temp = 0;
    process_func1();   // В теле этой функции к WDT_Temp прибавляется 0x1111
    if (g_WDT_Temp == 0x1111) wdt_clear(); 
    else soft_reset();
 
    process_func2();   // В теле этой функции к WDT_Temp прибавляется 0x2222
    if (g_WDT_Temp == 0x3333) wdt_clear();
    else soft_reset();
 
    process_func3();   // В теле этой функции к WDT_Temp прибавляется 0x3333
    if (g_WDT_Temp == 0x6666) wdt_clear();
    else soft_reset();
 
    ...

Метод является комбинацией с одним из видов run-time проверок. Если мы случайно пропускаем выполнение какой-либо функции (например из-за сбоя PC), то run-time проверка сигнатуры функции вызовет обработчик soft_reset(). Вне комбинации с run-time проверками этот метод не только малоэффективен, но даже опасен, т.к. если убрать во всех условиях ветку else, то даже после обнаружения сбоя (т.е. сбой не только произошел, но уже замечен) мы позволим программе выполнить еще несколько функций, уже находясь во внештатном режиме.

Т.е. данный метод является дополнением к run-time проверкам. На мой взгляд, он не очень эффективен, т.к.:

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

Однако он имеет два преимущества:

быстрая реакция на сбой при использовании оконного сторожевого таймера. Например, функция process_func1() отработала, выставила сигнатуру, но из-за сбоя выполнилась не за 5 мс, как предполагалось, а за 100 мкс. И тогда даже при правильно установленной сигнатуре реакция на сбой будет моментальная, что не позволит выполняться остальным функциям уже при наличии сбоя.
возможность использования при низкой тактовой частоте, когда скорость программы мала и время переполнения сторожевого таймера близко ко времени выполнения несложной функции (это особенно актуально при обработке исключения по срыву генерации).

Периодическое обнуление с контролем состояния

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

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

int g_Mode = 0;
 
void TIMER1_ISR (void)
{
    static bool bAllowClearWDT;
 
    switch (g_Mode)
    {
        case MODE_IDLE:
             ...
             break;
 
        case MODE_COOKING:
             ...
             break;
 
        case MODE_SETUP:
             ...
             break;
 
        default:            // Несуществующий режим
             // Выполняем какие-то действия по оживлению устройства, если это
             // возможно, или производим программный сброс, предварительно
             // запротоколировав сбой
             break;
    }
    if (bAllowClearWDT) wdt_clear();
    ...
}

Этот метод лишен основных недостатков двух предыдущих методов обнуления (с контролем флагов и контролем функций), а именно:

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

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

Однако, при своей универсальности этот метод не лишен недостатков:

он требует тщательной проработки алгоритма;
он требует свободных ресурсов RAM (для переменных состояния) и ROM (для кода проверки);
скорость реакции на сбой - один период WDT, т.е. нельзя применять с оконными WDT;
при неаккуратном программировании время кода проверок всех условий может оказаться затянутым.

Комбинированный метод

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

При выборе любого метода обнуления WDT нужно помнить главные правила:

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

Выбор интервала

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

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

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

Максимальная скорость реакции

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

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

Время выполнения проверок

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

Критические участки кода

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

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

Работа с библиотечными функциями

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

    printf(" %5.3f\n", sin(t));

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

    wdt_clear();
    printf(" %5.3f\n", sin(t));
    wdt_clear();

не всегда может спасти от переполнения WDT. Выхода здесь два:

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

Увеличение интервала - довольно сомнительное решение в данном случае. Тому есть несколько причин:

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

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

volatile struct
{
    UINT8    ucActive;
    INT16    nCounter;
 
} g_WDT_Library;
 
void TIMER1_ISR (void)
{
    static bool bAllowClearWDT;
    ...
    bAllowClearWDT = true;
    if (g_WDT_Library.ucActive ==  0x55)       // Проверяем, не выполнятеся ли сейчас библиотечная функция
    {
        if (g_WDT_Library.nCounter <= 0)
            bAllowClearWDT = false;
        else
            g_WDT_Library.nCounter--;
    }
    ...
    if (bAllowClearWDT) wdt_clear();
    ...
}

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

void wdt_lib_start (UINT16 value)
{
    g_WDT_Library.ucActive = 0xAA;    // Блокируем моификацию счетчика в прервании (любое число != 0x55)
    g_WDT_Library.nCounter = value;
    g_WDT_Library.ucActive = 0x55;    // Запускаем отсчет
}
 
void wdt_lib_stop (UINT16 value)
{
    g_WDT_Library.ucActive = 0xAA;   // останавливаем контроль WDT для библиотечной функции
                                     // Пишем любое число != 0x55
}
 
void main (void)
{
    ...
    while (1)
    {
        ...
        wdt_lib_start(100);            // Выделяем 100 мс на выполнение функции
        printf(" %5.3f\n", sin(t));
        wdt_lib_stop();
        ...
    }
}

Работа в программе под управлением RTOS

При работе программы под управлением RTOS порядок обнуления WDT несколько усложняется, из-за того, что потребуется следить сразу за несколькими процессами (задачами). Построение полноценного алгоритма обнуления WDT в случае использования RTOS - это совсем нетривиальная задача; сложности, с которыми мы сталкиваемся приведены ниже:

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

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

Но, даже реализуя проверки по упрощенной схеме, не стоит забывать о некоторых особенностях, превносимых RTOS:

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

Тестирование WDT при включении питания

В особо ответственных системах WDT как контролирующий узел обязательно должен быть протестирован (иначе полагаться на него нельзя). Такие проверки предписывают делать европейский стандарт IEC 60730 (Annex H 11.12.7 п. 8) или американский стандарт UL1998 (A2.1 п.8). В зависимости от условий работы тестирование может производиться единожды при включении питания или с каким-то периодом, но не нарушая при этом целостность выполнения программы (т.е. в случае периодического тестирования перед проведением теста все внешнее оборудование должно быть переведено в безопасный режим, сохранены в энергонезависимую память данные, которые необходимо восстановить после перезагрузки.

Более детально тестирование WDT описано в "5.2 Самодиагностика", здесь повторю только основные принципы проверки:

В оперативной памяти выделяется несколько байт для сигнатуры, отвечающей за стадию проведения теста.
При рестарте программы в первую очередь проверяется эта сигнатура на соответствие контрольного слова заданному шаблону (примечание: шаблон хранится в ROM). Если оно:
1. соответствует шаблону рабочего режима, а причиной сброса был WDT, то переходим к тестированию WDT (п. 3), иначе проверяем причины сброса (п.3).
2. Если причиной сброса был сигнал от WDT, то тест считается успешно пройденным и можно переходить на п.8. Иначе повторяем проверку с п.4 (такая ситуация может случиться, если сброс микроконтроллера произошел по каким-то другим причинам во время проведения теста на WDT).
Записать шаблон в сигнатуру.
Запрограммировать WDT на короткий интервал. Лучше всего, если это будет интервал, используемый в программе. Если в программе используется длительный интервал, то для теста можно взять укороченный, но так, чтобы под контролем оказалось максимальное количество битов счетчика WDT.
Настроить необходимый минимум периферии, чтобы не было висячих выводов.
Повисаем в вечном цикле.
Настраиваем WDT на рабочий интервал и продолжаем работу. В сигнатуру прописываем шаблон, соответствующий рабочему режиму.

Поведение программы при сбросе от WDT

Основной параграф, описывающий поведение программы при сбросе, это "5.5 Что делать при обнаружении сбоя". Здесь опишу только основные моменты, касающиеся сброса контроллера, вызванного переполнением WDT.

Все действия делятся на два этапа:

протоколирование;
восстановление работы.

Протоколирование

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

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

Какие данные нужно сохранять:

все те переменные, которые участвуют в проверках на возможность обнуления, т.е. те, которые являются индикаторами правильности работы программы;
содержимое стека. Здесь есть три сложности:
1. Некоторые компиляторы используют стек для обмена данными между функциями, в результате чего используемая часть стека сильно разрастается, что потребует большего объема энергонезависимой памяти для протоколирования;
2. При работе программы под управлением вытесняющей RTOS будет уже несколько стеков, что также требует большего объема энергонезависимой памяти.
3. некоторые контроллеры имеют аппаратный стек без возможности программного доступа.
некоторые регистры микроконтроллера остаются неизменными после сбоя, и их тоже есть смысл сохранить;
счетчик сбоев и причину сброса (в данном случае WDT).
если есть возможность, то полезно сохранить дату и время.

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

TODO:

- Восстановление работы -
- Зависание и преждевременный сброс WDT -
- RC-генератор и температура -
- Другие применения WDT -

Виктор Тимофеев, сентябрь 2010

Ошибка WinAVR

2010-06-16T09:15:51+03:00

Ошибка WinAVR

Вступление

Компилятор WinAVR GCC один из самых распространенных Си-компиляторов для микроконтроллеров фирмы AVR. Он был первым кандидатом на портирование OSA. В процессе изучения его особенностей (версия 20090313) была найдена ошибка, которая не позволяет полноценно портировать на него кооперативную ОС. Что значит "полноценно"? Это значит, что есть возможность использовать ОС только при отключенной оптимизации (ключ компилятору "-o0"). Это очень неприятно, т.к. при включенной оптимизации генерируется код в полтора и более раза компактнее, чем с выключенной. Кроме того, оптимизированный код получается более быстрым.

Примечание: В OSA версии 100531 найден механизм обхода проблемы

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

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

Описание ошибки

Стек в WinAVR

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

первым делом сохраняет пару регистров r28:r29 (Y-указатель);
затем выделяет стек для локальных переменных (это делается либо командами push для выделения одного байта, либо call $+1 для выделения сразу двух байт);
на последнем этапе указатель стека SP копируется в Y-указатель.

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

; void func (void)
    push    r28          // Сохраняем в стеке Y-указатель
    push    r29
    rcall   $+1          // Выделяем фрейм под 5 локальных переменных
    rcall   $+1
    push    r17
    in      r28, SPL     // Присваиваем Y = SP
    in      r29, SPH
    ...

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

Кооперативная ОС и локальные переменные

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

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

void Task (void)
{
    char x, y;
    lcd_init();               // инициализация модуля ЖКИ
 
    OS_Yield();               // передача управления другим задачам (фактически - планировщику)
 
    x = lcd_getx();           // вывод "Hello world" в строке под курсором
    y = lcd_gety();
    lcd_outtext(x, y + 1, "Hello world");
 
    OS_Yield();               // передача управления
 
    ...
}

В данном примере задача может потерять управление только в двух местах: при вызове системного сервиса OS_Yield(). Эта определенность позволяет минимизировать объем сохраняемых при переключении задачи данных. Объем этих данных зависит не только от типа микроконтроллера (программный счетчик, указатель стека и пр.), но и от особенностей конкретного компилятора. Например WinAVR предполагает, что регистры r2..r17 сохраняются самой функцией (если используются в ней), а регистры r18..r27, r30, r31 - применяются только для сиюминутных операций (т.е. подразумевается, что при возврате из вызываемой функции значения этих регистров будет утеряно). Это как минимум позволяет при переключении контекста не сохранять эти регистры. Кроме того, WinAVR предоставляет возможность определять некоторые функции с атрибутом __returns_twice__, который избавляет нас от необходимости сохранять и r2..r17. Т.е. весь сохраняемый контекст будет состоять из: программного счетчика и указателя фрейма (r28:r29).

Остается проблема с локальными переменными. Есть два пути:

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

Первый вариант требует наличия сравнительно большого объема оперативной памяти. Т.е. такого объема, который уже позволит использовать вытесняющую ОС, которая гораздо предпочтительнее кооперативной при прочих равных условиях. А вот второй вариант выглядит более приемлемым. Т.е. мы условились, что переменные x и y будут терять свои значения после каждого вызова OS_Yield() (т.е. после каждой передачи управления планировщику), и если нам понадобится текущая позиция экрана после вызова OS_Yield(), то мы уже не сможем воспользоваться прежними значениями x и y, т.к. они уже утеряны, и нам нужно будет снова воспользоваться функциями lcd_getx() и lcd_gety(). Почему значения x и y теряются? На этот вопрос мы уже отвечали: потому что в малоресурсных контроллерах приходится использовать одну область памяти для локальных переменных всех задач, и после переключения задачи значения локальных переменных текущей функции просто затрутся значениями локальных переменных параллельно выполняющейся задачи.

Как быть, если все-таки нужно сохранить значения переменных и после переключения контекста? Очень просто: объявлять из с квалификатором static:

void Task (void)
{
    static char x, y;         // Объявляем переменные вне стека
 
    lcd_init();               // инициализация модуля ЖКИ
 
    OS_Yield();               // передача управления другим задачам (фактически - планировщику)
 
    x = lcd_getx();           // вывод "Hello world" в строке под курсором
    y = lcd_gety();
    lcd_outtext(x, y + 1, "Hello world");
 
    OS_Yield();               // передача управления
 
    lcd_outtext(x, y + 2, "All animals are equal");
    ...
}

В этом примере мы не боимся потерять x и y, т.к. они имеют статические адреса и стек других задач их не сможет перетереть.

А теперь мы подошли к самой проблеме.

Проблема

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

Тестовая программа

Описание

Для описания ошибки я написал небольшую программу. Я умышленно не стал подключать OSA и сделал все исключительно средствами самого компилятора, а именно - воспользовался парой функций setjmp/longjmp. Суть программы проста: есть две функции task1 и task2, которые по очереди передают друг другу управление. Одна функция вызывает подпрограмму, копирующую в строковую переменную Hello слово "HELLO", а вторая вызывает подпрограмму, копирующую в строковую переменную World слово "WORLD".

Как работают функции setjmp() и longjmp, надеюсь, объяснять не нужно. В двух словах для тех, кто с ними не знаком:

функция setjmp() выполняет сохранение контекста (PC, SP, SREG, r2..r17);
функция longjmp() выполняет безусловный переход с восстановлением ранее сохраненного контекста.

Текст программы

(Можно скачать текст программы с файлами проекта для AVR Studio 4.18)

#include <avr/io.h>
#include <avr/interrupt.h>
#include <setjmp.h>
 
//******************************************************************************
//  Переменные
//******************************************************************************
 
char Hello[6];  // Буфер для хранения слова "HELLO"
char World[6];  // Буфер для хранения слова "WORLD"
 
 
jmp_buf     j_task1, j_task2;   // Контекст задач
 
 
//******************************************************************************
//  Прототипы функций
//******************************************************************************
 
void task1          (void);
void task2          (void);
void strcpy_hello   (char * data) __attribute__((noinline));
void strcpy_world   (char * data) __attribute__((noinline));
 
//******************************************************************************
//  Функции
//******************************************************************************
 
 
void main (void)
{
    task1();                // Инициализируем задачи
    task2();
 
    longjmp(j_task1, 1);    // Запускаем поочередное выполнение,
                            // начиная с задачи Taks1
}
 
//------------------------------------------------------------------------------
 
void strcpy_hello (char * str)      // Cкопировать слово "HELLO" в str
{
    str[0] = 'H';
    str[1] = 'E';
    str[2] = 'L';
    str[3] = 'L';
    str[4] = 'O';
    str[5] = 0;
}
 
//------------------------------------------------------------------------------
 
void strcpy_world (char * str)      // Cкопировать слово "WORLD" в str
{
    str[0] = 'W';
    str[1] = 'O';
    str[2] = 'R';
    str[3] = 'L';
    str[4] = 'D';
    str[5] = 0;
}
 
//------------------------------------------------------------------------------
 
void task1 (void)                                   // ЗАДАЧА 1
{
    if (!setjmp(j_task1)) return;                   // Инициализируем контекст
 
    for (;;)
    {
        Hello[1] ^= Hello[0];                       // Обращение к двум элементам массива
                                                    // на чтение и запись
        if (!setjmp(j_task1)) longjmp(j_task2, 1);  // Переключение контекста
        strcpy_hello(Hello);                        // Копируем константу "HELLO" в массив
    }
}
 
//------------------------------------------------------------------------------
 
void task2 (void)                                   //  ЗАДАЧА 2
{
    if (!setjmp(j_task2)) return;                   // Инициализируем контекст
 
    for (;;)
    {
        World[1] ^= World[0];                       // Обращение к двум элементам массива
                                                    // на чтение и запись
        if (!setjmp(j_task2)) longjmp(j_task1, 1);  // Переключение контекста
        strcpy_world(World);                        // Копируем константу "WORLD" в массив
    }
}

Обращу ваше внимание на некоторые моменты:

функции strcpy_hello() и strpy_world() объявлены с атрибутом __noinline__, чтобы предотвратить оптимизацию прямой подстановкой тела функции в код, т.к. для синтезирования ошибки нам обязательно нужно, чтобы это были именно вызываемые (через rcall) функции;
в функциях task1() и task2() есть бессмысленные строчки: "Hello[1] ^= Hello[0];" и "World[1] ^= World[0];". Они не несут никакого функционала, просто для синтезирования ошибки нужно, чтобы перед переключением контекста было произведено обращение к нулевому и первому элементам массива, причем нулевой должен быть на чтение, а первый - на запись.

Запуск программы

Откройте проект в AVR Studio и соберите его (F7). Установите две точки останова:

Запустите Start-Debugging (Ctlr+Shift+Alt+F5). Далее кнопкой F5 перемещайтесь по программе, а в окне Watch наблюдайте содержимое переменых Hello и World. Вы увидите, что программа постоянно переключается между функциями task1() и task2(). Но самое главное - вы увидите, что присваиваемые слова "HELLO" и "WORLD" копируются только в одну переменную - World, а переменная Hello остается нетронутой.

Почему?

Детальный разбор

Рассмотрим листинг функции task1() (листинг task2() аналогичен):

000000c2 <task1>:
}

//------------------------------------------------------------------------------

void task1 (void)                                   // ЗАДАЧА 1
{
  c2:   df 93           push    r29
  c4:   cf 93           push    r28
  c6:   00 d0           rcall   .+0
  c8:   cd b7           in      r28, SPL
  ca:   de b7           in      r29, SPH

  cc:   80 e6           ldi     r24, 0x60       ; if (!setjmp(j_task1)) return;
  ce:   90 e0           ldi     r25, 0x00
  d0:   28 d0           rcall   setjmp
  d2:   89 2b           or      r24, r25
  d4:   29 f4           brne    .+10

  d6:   0f 90           pop     r0
  d8:   0f 90           pop     r0
  da:   cf 91           pop     r28
  dc:   df 91           pop     r29
  de:   08 95           ret

                                                ; for (;;)
                                                ; {
  e0:   8d e7           ldi     r24, 0x7D       ;     примечание: 0x7D - адрес переменной Hello
  e2:   90 e0           ldi     r25, 0x00       ;
  e4:   89 83           std     Y+1, r24        ;
  e6:   9a 83           std     Y+2, r25        ;
  e8:   03 c0           rjmp    .+6             ;

  ea:   89 81           ldd     r24, Y+1        ;     strcpy_hello(Hello);
  ec:   9a 81           ldd     r25, Y+2        ;
  ee:   a5 df           rcall   strcpy_hello    ;

  f0:   ed e7           ldi     r30, 0x7D       ;     Hello[1] ^= Hello[0];
  f2:   f0 e0           ldi     r31, 0x00       ;
  f4:   80 81           ld      r24, Z
  f6:   ee e7           ldi     r30, 0x7E       ;
  f8:   f0 e0           ldi     r31, 0x00       ;
  fa:   90 81           ld      r25, Z
  fc:   89 27           eor     r24, r25
  fe:   80 83           st      Z, r24


 100:   80 e6           ldi     r24, 0x60       ; if (!setjmp(j_task1))
 102:   90 e0           ldi     r25, 0x00       ;
 104:   0e d0           rcall   setjmp          ;
 106:   89 2b           or      r24, r25
 108:   81 f7           brne    0xEA

 10a:   83 e8           ldi     r24, 0x83       ; longjmp(j_task2, 1);
 10c:   90 e0           ldi     r25, 0x00       ;
 10e:   61 e0           ldi     r22, 0x01       ;
 110:   70 e0           ldi     r23, 0x00       ;
 112:   28 d0           rcall   longjmp         ;

В адресах 0xC2..0xCA производится выделение 2-байтового фрейма в стеке. Далее, в адресах 0xCC..0xDE производится формирование контекста. Нас же интересует работа программы в адресах 0xE0..0x112, т.е. работа цикла.

Сразу же обратим внимание на код 0xE0..0xE6, в котором адрес строки Hello копируется во временную локальную переменную [Y+1]:[Y+2] (еще раз посмотрим код и убедимся, что сами мы локальных переменных не создавали). Далее (адрес 0xE8) происходит переход на операцию Hello[1]^=Hello[0] (адреса 0xF0..0xFE), затем попадаем на сохранение контекста setjmp() (0x100..0x104) и передачу управления задаче task2() через longjmp() (0x10A..0x112).

При передаче управления восстанавливается контекст для функции task2, в том числе указатель фрейма r28:r29 (т.е. Y). Т.к. функции идентичны, то и фрейм для них будет одного размера (2 байта) и расположен по одним и тем же адресам. Функция task2() выполняет абсолютно те же действия, что и task1(), а что самое главное - производит копирование адреса переменной World во временную переменную [Y+1]:[Y+2], затирая значение, записанное туда функцией task1(). Дойдя тем же путем, что и task1(), до вызова longjmp(), функция task2() передает управление task1() через сохраненный контекст j_task1.

Тут и начинаются проблемы. Программный счетчик восстанавливается и указывает на следующую за вызовом setjmp() команду, т.е. на адрес 0x89. После чего выполняется переход на адрес 0xEA (после перехода longjmp() r25 != r24), где и располагается вызов функции копирования строки strcpy_hello(). Обратите внимание, что в качестве параметра ей передается не фактический адрес переменной Hello, а значение, запомненное во временной переменной [Y+1]:[Y+2], т.е. то, которое было перетерто функцией task2(), и теперь по этим адресам хранится адрес не переменной Hello, а переменной World. Поэтому функция strcpy_hello запишет слово "HELLO" в переменную World, а не в Hello.

Вот такая проблема.

Заключение

Почему я это назвал ошибкой

Хоть я и создал пример, синтезирующий описанную ошибку, но мне так и не удалось четко сформулировать условия ее проявления. Попробуйте модифицировать код (например, убрать выражение Hello[1] ^= Hello[0], или поменять в нем индексы, или убрать setjmp/longjmp) и программа заработает, т.е. начнет передавать в функцию strcpy_hello() фактический адрес переменной, а не его копию. Т.е. я не могу точно сказать, что в таком-то случае ошибка будет проявляться, а в таком не будет. Заметить удалось только то, что между выражением, обращающимся к тому же адресу, что и вызов функции strcpy_hello(), должен находиться вызов функции с атрибутом __returns_twice__.

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

__returns_twice__:
  The returns_twice attribute tells the  compiler that a function may return
  more than one time. The compiler will ensure that  all registers are  dead
  before calling such a function and will emit a warning about the variables
  that may be clobbered after the second return from the function.  Examples
  of such functions are  setjmp  and  vfork. The longjmp-like counterpart of
  such function, if any, might need to be marked with the noreturn attribute.

Как решить проблему

Для OSA с версии 100531 найден механизм обхода этой проблемы

Я нашел только одно проявление этой проблемы, могут быть и другие. Как побороть компилятор и заставить его не пользоваться временными переменными при обнаружении вызовов функций __returns_twice__, я пока не придумал. Объявление переменных с квалификатором volatile не спасает (ни глобальных переменных, ни параметров функций).

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

Если у кого-то есть какие-то соображения, буду рад любой помощи.

Виктор Тимофеев, март 2010