PIC24 osa:ref:appendix

Пример использования OSA: 3LEDS_PIC10F

2011-01-17T18:44:20+03:00

Пример использования OSA: 3LEDS_PIC10F

Проект

Данный пример демонстрирует использование OSA для написания программы под 12-разрядные контроллеры. Файл 3leds.rar нужно распаковать в папку "C:\TEST\3LEDS". В папке проект для PIC10F222 (его можно пересобрать также для F202 и F206).

Программа управляет 7-цветным светодиодом с помощью ШИМ. В ходе работы плавно создаются разные комбинации яркости всех трех светодиодов. Есть 4 режима скорости (от очень медленного до очень быстрого).

Принципиальная схема

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

Кнопка S1 делает активным красный цвет.
Кнопка S2 делает активным зеленый цвет.
Кнопка S3 делает активным синий цвет.
Кнопка S4 изменяет скорость работы (4 скорости).

Примечание. Значение сопротивлений токозадающих резисторов R11, R12 и R13 подбираются под конкретные светодиоды.

Описание работы

Программа состоит из 3-х задач:

Task_Leds - формирует импульсы управления светодиодами нужной длительности.
Task_Work - формирует значения интенсивностей для всех светодиодов
Task_Buttons - обрабатывает кнопки

Task_Leds

Большую часть времени программа находится в задаче Task_Leds. Эта задача ждет, когда таймер TMR0 переполнится, и в этот момент подает "1" на все светодиоды. Далее в цикле отмеряются правильные длительности импульсов. Для этого в программе есть 3 переменные (по одной для каждого цвета), в которых содержится информация о текущей интенсивности. Как только таймер TMR0 становится больше значения интенсивности, соответствующий светодиод гаснет. Когда погаснут все 3 светодиода, управление передается остальным задачам.

Две другие задачи: Task_Work и Task_Buttons - находятся в ожидании установки битов bRunTaskWork и bRunTaskButtons, соответственно. Эти биты устанавливает задача Task_Leds после того, как обработает 1 период управления светодиодами.

Task_Work

При получении управления Task_Work проверяет, пора ли изменять интенсивность светодиодов. Для этого есть переменная Work, которая увеличивается каждый раз при попадании в задачу. Скорость увеличения (фактически - скорость изменения интенсивности) определяется 2-мя старшими битами переменной. Как только младшие 5 бит переменной Work переполняются, задача вызывает функцию ChangeIntensity(), которая делает один шаг изменения интенсивности в соответсвие со значениями переменных Red, Green и Blue.

В данной программе применен простой способ: интенсивности всех светодиодов изменяются с одинаковой скоростью. Но каждый может сам под себя переписать функцию ChangeIntensity().

Task_Button

Эта задача, так же как и Task_Work, запускается один раз в период, т.е. в 16 мс. При получени управления все ножки устанавливаются на вход, после чего проверяется, нет ли "1" на каком-либо входе. Если есть, то нажатая кнопка обрабатывается. Кнопки SW1, SW2 и SW3 устанавливают яркость соответствующего светодиода максимальной (остальные гасятся) и устанавливает переменную Mode.cState в режим, соответствующий цвету. Кнопка SW4 изменяет скорость работы (всего 4 скорости). После обработки кнопок все ножки обратно устанавливаются на выход и задача становится в режим ожидания отпускания кнопок.

Фото

Качество фото не очень, но примерно видно, что должно получиться.

Конфигурация OSAcfg.h

2010-09-24T17:50:34+03:00

Конфигурация OSAcfg.h

Файл OSAcfg.h для каждой программы должен быть свой, и его желательно держать в той же директории, где и сама программа. Этот файл автоматически включается файлом OSA.h и является настроечным (в нем определяется, где хранятся какие данные, сколько максимально может быть задач, семафоров, таймеров и пр.). Шаблон этого файла лежит в папке OSA\PROJECT.

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

Для упрощения создания/редактирования файла конфигурации можно воспользоваться утилитой OSAcfg_Tool

Системные константы

Имя константы	Описание
OS_ENABLE_ALL	Разрешить все
OS_ENABLE_CSEM	Если определена эта константа, то в программу включается код по работе с счетными семафорами
OS_ENABLE_QUEUE	Если определена эта константа, то в программу включается код по работе с очередями сообщений
OS_ENABLE_SQUEUE	Если определена эта константа, то в программу включается код по работе с очередями коротких однобайтовых сообщений
OS_QUEUE_SQUEUE_IDENTICAL	Если используются сразу и очереди сообщений и очереди коротких сообщений, и есть уверенность в том, что размерность указателя на сообщение (тип OST_MSG) и короткого соощения (тип OST_SMSG) одинакова, то можно определить эту константу, чтобы для работы с обоими типами очередей выполнялась одними и теми же функциями. Особенно актуально для PIC10, PIC12 и PIC16.
OS_ENABLE_CRITICAL_SECTION	Если определена, то в программу включаются функции входа в критическую секцию и выхода из нее

Управление приоритетами

Имя константы	Допустимые значения	Описание
OS_PRIORITY_LEVEL	OS_PRIORITY_NORMAL	(defaul) Обычный приоритетный режим с последовательной проверкой задач на готовность в порядке их создания
	OS_PRIORITY_DISABLED	Принудительно устанавливает всем задачам высший приоритет. Можно использовать для ускорения работы планировщика, если приоритетность не важна
	OS_PRIORITY_EXTENDED	Расширенный приоритетный режим, который распределяет ресурсы ядра микроконтроллера между задачами пропорционально весам их приоритетов
OS_DISABLE_PRIORITY	old style consant	То же, что и OS_PRIORITY_DISABLE

Управление таймерами

Имя константы	Описание
OS_ENABLE_TTIMERS	Если эта константа определена, то в программу будут включены функции по определению задержек в задачах и таймеры в OST_TCB. Если в программе не планируется использовать OS_Delay или ожидание событий с таймаутами, то эту константу можно не определять (тогда получится меньший код и освободится RAM).
OS_ENABLE_DTIMERS	Если определена, то в программе можно использовать динамические таймеры
OS_ENABLE_QTIMERS	Если определена, то в программе можно использовать очкркдь таймеров
OS_STIMERS	Количество статических таймеров. Если определена, то создается массив статических таймеров такой размерности
OS_STIMERS_ENABLE_ALLOCATION	Если определена, то в код включаются функции по назначению статических таймеров в ходе выполнения программы
OS_STIMERS_OPTIMIZE_SPEED	Если определена, то код по управлению статическими таймерами в OS_Timer будет оптимизирован по размеру (иначе - по скорости)
OS_TTIMERS_OPTIMIZE_SPEED	Если определена, то код по управлению таймерами задач в OS_Timer будет оптимизирован по размеру (иначе - по скорости)

Сервисы в прерываниях

Имя константы	Описание
OS_ENABLE_INT_BSEM
OS_ENABLE_INT_CSEM	Разрешает отправлять счетные семафоры из прерываний
OS_ENABLE_INT_FLAG	Разрешает работать с флагами внутри прерывания
OS_ENABLE_INT_MSG	Разрешает отправку сообщений из прерываний
OS_ENABLE_INT_SMSG	Разрешает отправку коротких сообений из прерываний
OS_ENABLE_INT_QUEUE	Разрешает отправку сообщений и коротких сообщений через очередь из прерываний
OS_ENABLE_INT_ALL	Если определена, то включает все выше перечисленные константы

Содержание данных

Имя константы	Описание	Требуется памяти
OS_TASKS	Количество задач, которые одновременно могут быть активны	На каждую задачу: Для PIC12 - по 2 байта. Для PIC16 - по 3 байта. Для PIC18 - по 4 байта. Для PIC24 и dsPIC - по 20 байт. Для AVR - по 5 байт. Если в программе используются таймеры (определена константа OS_ENABLE_TTIMERS), то а каждую задачу добавляется OS_TTIMER_SIZE байт.
OS_BSEMS	Количество бинарных семафоров	Для 8-разрядных: По 1 байту на каждую неполную восьмерку семафоров. Для 16-разрядных: По 1 слову, на каждые 16 семафоров.
OS_TIMERS8 (устаревшая)	Количество пользовательских 8-разрядных таймеров	На каждый по 1 байту
OS_TIMERS16 (устаревшая)	Количество пользовательских 16-разрядных таймеров	На каждый по 2 байту
OS_TIMERS24 (устаревшая)	Количество пользовательских 24-разрядных таймеров	На каждый по 2 байту (в этих таймерах нет младшего байта)
OS_TIMERS32 (устаревшая)	Количество пользовательских 32-разрядных таймеров	На каждый по 4 байта

Типы данных

Имя константы	Значение по умолчанию	Описание
OS_TIMER_SIZE	2	Количество байт, занимаемых системным таймером. Может быть = 1, 2 или 4.
OS_STIMER_SIZE	OS_TIMER_SIZE	Количество байт, занимаемых статическим таймером. Может быть = 1, 2 или 4.
OS_TTIMER_SIZE	OS_TIMER_SIZE	Количество байт, занимаемых таймером задачи. Может быть = 1, 2 или 4.
OS_QTIMER_SIZE	OS_TIMER_SIZE	Количество байт, занимаемых таймерами в очереди таймеров. Может быть = 1, 2 или 4.
OS_DTIMER_SIZE	OS_TIMER_SIZE	Количество байт, занимаемых динамическим таймером. Может быть = 1, 2 или 4.
OS_CSEM_SIZE	1	Количество байт, выделяемое под каждый счетный семафор. Определяет, в каких пределах может меняться счетный семафор. Может быть = 1, 2 или 4
OS_SMSG_TYPE*	unsigned char	Тип коротких сообщений, которыми обмениваются задачи.
OS_MSG_TYPE*	void *	Тип сообщений для MSG и QUEUE.

* - эти типы нельзя переопределять при использовании PIC12.

Размещение данных для PIC10, PIC12, PIC16 и PIC18

Константы OS_BANK_xxx могут принимать значения:

Для PIC10, PIC12, PIC16: 0, 1, 2 или 3 - выбор банка bank0, bank1, bank2, bank3, соотвт.
Для PIC18: 0, не 0 - accsess и не access, соотв.
Для PIC24: 0, не 0 - near и не near, соотв.
Для STM8: 0, не 0 - near и не near, соотв.

Имя константы	Значение по умолчанию	Описание
OS_BANK_OS*	0	Определяет, где будут храниться все переменные системы (если для них не указаны другие).
OS_BANK_BSEMS*	OS_BANK_OS	Для двоичных семафоров.
OS_BANK_TASKS*	OS_BANK_OS	Банк, в котором будут размещены дескрипторы задач
OS_BANK_STIMERS*	OS_BANK_TIMERS	Для статических таймеров
OS_ADDRESS_TASK	-	Для mikroC PRO for PIC16: Для размещения дескрипторов задач по определенному адресу памяти (например в 0x120 (для bank2) или 0x190 (для bank3)
OS_BANK_TIMERS*	OS_BANK_OS	Для статических таймеров старрого типа
OS_BANK_TIMERS8* (устаревшая)	OS_BANK_TIMERS	Для 8-разрядных статических таймеров
OS_BANK_TIMERS16* (устаревшая)	OS_BANK_TIMERS	Для 16-разрядных статических таймеров
OS_BANK_TIMERS24* (устаревшая)	OS_BANK_TIMERS	Для 24-разрядных статических таймеров
OS_BANK_TIMERS32* (устаревшая)	OS_BANK_TIMERS	Для 32-разрядных статических таймеров
OS_BANK_TIMEOUTS* (устаревшая)	OS_BANK_TIMERS	Для битовых полей - флагов переполнения (таймаутов) пользовательских статических таймеров.

* - игнорируется в CCS и mikroC PRO, а также для контроллеров AVR

OSA : Динамические таймеры

2010-02-04T22:15:38+03:00

OSA : Динамические таймеры

С версии 100210 динамические таймеры заменены более эффективной "очередью таймеров" (Qtimers). Все сервисы поддержки динамических таймеров остаются для совместимости со старыми проектами, и в будущем упразднятся не будут. Просто динамические таймеры признаны неэффективными из-за низкой скорости их обработки при пересчетет в OS_Timer()

Описание

Для использования динамических таймеров в OSAcfg.h должна быть определена константа:

#define OS_ENABLE_DTIMERS

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

OST_DTIMER mytimer;

В памяти будет создана переменная, содержащая сам счетчик таймера, флаги его состояния и указатель на следующий таймер. Разрядность счетчика таймера задается константой OS_DTIMER_SIZE.

Для PIC16 динамические таймеры могут располагаться только в банках bank0 и bank1.

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

Состояния

Динамический таймер может находится в одном из 4-х состояний:

Не создан (или удален)	таймер не добавлен в список активных таймеров. Система про него ничего не знает и, следовательно, не обрабатывает.
Активен	таймер создан сервисом OS_Dtimer_Create и присутствует в списке активных таймеров. Чем больше активных таймеров, тем дольше выполняется их обработка в OS_Timer (в среднем по 18 тактов на активный таймер для PIC16 и 23 - для PIC18). Поэтому неиспользуемые таймеры желательно удалять сервисом OS_Dtimer_Delete.
Считает	запускается сервисом OS_Dtimer_Run или OS_Dtimer_Continue и при каждом вызове OS_Timer увеличивается на 1.
Остановлен	остановлен сервисом OS_Dtimer_Stop, при этом таймер активен (т.е. есть в списке), но не изменяется при вызове OS_Timer.

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

Пример использования

Ниже приведен пример использования таймера для генерации импульса заданной длительности с частотным заполнением (предполагаем, что интервал OS_Timer = 1 ms:

OST_SMSG smsg;
 
void Task1 (void)
{
    for (;;) {
        ...
        OS_Smsg_Send(smsg, 200);  // Нам нужен импульс 200 мс
        ...
    }
}
 
 
void Task2 (void)
{
    OST_SMSG msg;
    static OST_DTIMER myTimer;
    RB0 = 0;
    OS_Dtimer_Create(myTimer);
    for (;;) {
        OS_Smsg_Wait(smsg, msg);
        OS_Dtimer_Run(myTimer, msg);
        do {
            RB0 ^= 1;
            OS_Delay(5);	// Частота генерации = 100 Гц
        } while (!OS_Dtimer_Check(myTimer));
        RB0 = 0;
    }
}

Сервисы для работы с динамическими таймерами

Сервис	Аргументы	Описание
Создание/Удаление
OS_Dtimer_Create	`(dtimer)`	Добавляет dtimer в очередь активных таймеров. После создания таймер обнулен остановлен, флаг переполнения сброшен.
OS_Dtimer_Delete	`(dtimer)`	Удаляет dtimer из очереди активных таймеров.
Управление
OS_Dtimer_Run	`(dtimer, newtime)`	Запустить dtimer на отсчет времени newtime с момента вызова этого сервиса. Флаг переполнения сбрасывается.
OS_Dtimer_Break	`(dtimer)`	Останавливаем таймер. Он остается активным, но не увеличивается при выполнении OS_Timer(). Флаг переполнения устанавливается.
OS_Dtimer_Wait	`(dtimer)`	Ожидаем завершения счета таймера.
OS_Dtimer_Delay	`(dtimer, delay)`	Выдержать задержку с использованием динамического таймера dtimer
Проверка
`_OST_DTIMER` OS_Dtimer_Get	`(dtimer)`	Получить оставшееся время счета (необходимо запрещать прерывания)
`bool` OS_Dtimer_Check	`(dtimer)`	Проверить, было ли переполнение.
`bool` OS_Dtimer_IsRun	`(dtimer)`	Проверить, считает ли таймер
Дополнительно
OS_Dtimer_Pause	`(dtimer)`	Останавливаем таймер. Он остается активным, но не увеличивается при выполнении OS_Timer(). Флаг переполнения остается без изменений.
OS_Dtimer_Continue	`(dtimer)`	Восстанавливаем счет таймера.
OS_Dtimer_Update	`(dtimer, time)`	Запустить таймер на отсчет времени time с момента последнего переполнения. Флаг переполнения сбрасывается.
OS_Dtimer_Add	`(dtimer, addtime)`	Добавить время к таймеру во время счета. Флаг переполнения остается без изменений.
`bool` OS_Dtimer_IsActive	`(dtimer)`	Проверить, есть ли таймер в списке активных таймеров.
`bool` OS_Dtimer_IsStopped	`(dtimer)`	Проверить, остановлен ли таймер

OSA : Error list

2011-01-22T15:03:34+03:00

OSA : Error list

#1 : Unknown compiler!

OSA работает только со следующими компиляторами:

HI-TECH PICC STD
HI-TECH PICC18 STD
Microchip C18
Microchip C30
CCS PICC
microC PRO for PIC

Остальные компиляторы пока не поддерживаются.

#2 : Constants OS_xxx_BANK are not allowed now (use OS_BANK_xxx instead)

Эта ошибка возникает, когда вы пытаетесь разместить переменные OSA с помощью устаревших констант. Новые константы имеют префикс имени "OS_BANK_" (См. конфигурация.)

#3 .. #12 : Incorrect OS_BANK_xxx value (should be 0, 1, 2 or 3)

Одна или несколько констант OS_BANK_xxx имеют недопустимое значение (в файле OSAcfg.h). Разрешены только значения 0, 1, 2 и 3.

#13 : OST_TIMER is not supported! Use OS_TIMER_SIZE instead

Вы пытаетесь переопределить тип таймера через устаревшую константу OST_TIMER. В старых версиях этой константе приравнивалось имя типа напрямую (например, char или unsigned long). Теперь тип таймеров задается указанием размерности переменной. Например:

#define OS_TIMER_SIZE    4      // таймеры будет типа unsigned long

#14 .. #15 : Can't redefine name OST_xxx in 'OSAcfg.h'. Use OS_xxx_TYPE instead.

Начиная с версии 90200 типы OST_MSG и OST_SMSG не могут быть переопределены напрямую. Теперь они переопределяются через константы OS_MSG_TYPE и OS_SMSG_TYPE. Причина описана ниже:

Например OST_MSG определена в файле OSAcfg.h так:

#define OST_MSG    void *

Когда определяется несколько переменных:

OST_MSG msg1, msg2, msg3;

компилятор делает подстановку:

void * msg1, msg2, msg3;

Как видно, толь msg1 будет указателем, а msg2 and msg3 будет иметь просто тип void.

Ситуацию можно было бы исправить так:

typedef void * OST_MSG;

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

#define OS_MSG_TYPE     int *

а сам OST_MSG определяется без вмешательства пользователя в файле OSA.h:

typedef OS_MSG_TYPE   OST_MSG;

#16 : Incorrect OS_CSEM_SIZE value (m.b. only 1, 2 or 4)! (see OSAcfg.h)

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

1 - для unsigned char
2 - для unsigned int
4 - для unsigned long

#17 .. #21 : Bad OS_xxx size (must be 1, 2 or 4)

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

1 - для unsigned char
2 - для unsigned int
4 - для unsigned long

#22: Qtimers are not supported under 12-bit controllers (PIC10 and PIC12)

Qtimers are not supported with 12-bit controllers. Actualy, there is no needness to use them on 12-bit PICs, since benefit is noticed only with large number of timers.

#25: STM8 with ROM > 64K are not supported yet

Контроллеры STM8 с ROM > 64K пока что не поддерживаются

OSA : Приложения

2009-06-19T02:37:04+03:00

OSA : Приложения

Пример использования OSA: LEDS_28PINS

2009-07-07T12:45:00+03:00

Пример использования OSA: LEDS_28PINS

Проект

Данный пример демонстрирует некоротые возможности RTOS OSA. Файл leds_28pins.rar нужно распаковать в папку "C:\TEST\LEDS_28PINS". В папке с примером созданы 3 проекта:

leds_28pins_picc.mcp	для HT-PICC (PIC16F873)
leds_28pins_picc18.mcp	для HT-PICC18 (PIC18F252)
leds_28pins_mcc18.mcp	для Microchip C18 (PIC18F252)

Принципиальная схема

Ниже приведена схема включения PIC'а для проверки работы примера.

Описание работы

Описание работы устройства

К ПИКу подсоединены 4 кнопки и 4 трехцветных светодиода. Каждому светодиоду соответствует своя кнопка. При коротком нажатии на любую кнопку соответсвующий ей светодиод выдает серию из 5 коротких вспышек. Длительным нажанием на кнопку изменяется цвет мерцания соответсвующего кнопке светодиода. Кнопки можно нажимать в любой последовательности и любой комбинации.

Описание логики программы

Логически программа состоит из 9-ти простых задач:

Task_Buttons - Обработка кнопок (в файле Task_Buttons.c):
- определение нажатия кнопки
- устранение дребезга
- определение длительного удерживания кнопки

Task_Leds - Обработка светоидов (в файле Task_Leds.c). Используется в самом простом варианте. Включает и выключает светодиоды.

Task_Work - основная задача. Принимает сообщения от Task_Buttons о состоянии кнопок. В зависимости от принятого сообщения:
- отправляет сообщения задаче Task_ChangeColors поменять цвет светодиода, начать мигать.
- устанавливает счетные семафоры для задач TaskBlinkX()

Task_ChangeColors -получая сообщения из очереди сообщений от Task_Work, меняет цвета светодиодов.

Task_Blink0-TaskBlink3 - задачи, мигающие каждая своим светодиодом с заданным цветом и заданным количеством импульсов (задается счетными семафоами в Task_Work)

Task_Sleep - кладет контроллер в SLEEP. Если нет готовых к выполнению задач, то на 18мс кладется в SLEEP (из SLEEP'а выходит по WDT)

При нажатии на кнопку задача Task_Buttons, устранив дребезг, отсылает сообщение SMsgButton = BUTTON_PRESSED. Это сообщение принимается задачей Task_Work, и зажигается соответсвующий светодиод.

При отпускании кнопки Task_Buttons отсылает сообщение BUTTON_SHORT (короткое нажатие на кнопку). Task_Work ловит его и устанавливает счетный семафор в значение 5 для конкретной кнопки (в программе 4 счетных семафора: csem[0], csem[1], csem[2], csem[3] - по одному на каждую кнопку).

Задачи Task_Blink0 - Task_Blink3 ждут каждая свой семафор. Как только он оказывается не равным нулю, задача вспыхивает светодиодом 1 раз и уменьшает значение счетного семафора на 1. Таким образом, учитывая, что Task_Work устанавливает все семафоры = 5, получается по 5 вспышек.

Если Task_Buttons обнаруживает, что кнопка удерживается длительное время (1 сек), то она отправляет сообщение BUTTON_HOLD, а Task_Work, приняв такое сообщение, отсылает сообщение в очередь сообщений для задачи Task_ChengeColor, которая, достав сообщение из очереди, изменяет цвет соответствующего светодиода и устанавливает счетный семафор в 1, чтобы получить одну короткую вспышку новым цветом.

Если Task_ChangeColor не получает сообщение из очереди долгое время (дольше 3 секунд), то она вспыхивает одиночными вспышками поочереди всеми светодиодами.

Ножка RA0

Большую часть времени контроллер находится в Sleep'е. Ножка RA0 устанавливается в 1, когда контроллер просыпается и сбрасывается в 0, когда опять засыпает. По этой ножке можно смотреть, сколько времени уходит на обработку всех задач.

OSA : Рекомендации по оптимизации

2009-06-19T02:15:19+03:00

OSA : Рекомендации по оптимизации

Здесь будут описаны правила, советы и рекомендации по конфигурированию 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: QUARTET

2010-06-02T22:59:35+03:00

Пример использования OSA: QUARTET

Проект

Программа quartet синтезирует мелодию по заданным нотам (используется фрагмент произведения И.С.Баха N1067). Файл quartet4.rar нужно распаковать в папку "C:\TEST\QUARTET". В папке проект для PIC16F628A.

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

Вот MP3 (скачать), записанный с выхода этого устройства.

Принципиальная схема

Ниже приведена схема включения ПИКа. 8-разрядный цифровой ШИМ-сигнал сглаживается RC-фильтром R22-C3 и через резистор R24 (для регулирования громкости) поступает на наушники.

Переключатель SW1 включает/отключает басс.
Переключатель SW2 включает/отключает скрипку.
Переключатель SW3 включает/отключает первую гитару.
Переключатель SW4 включает/отключает вторую гитару.

Описание работы

Программа состоит из следующих файлов:

quartet_main.c - основная программа: задачи, функции по чтению нот.
music.c - формальное описание музыки: содержит 4 массива с нотами для каждого канала.
sinus.c - содержит по одному периоду синуса для каждого иструмента. Из этих таблиц генерируется сигнал.
interrupt.c - содержит код синтезатора звука. Он весь помещен в прерывание по TMR2 (вызывается раз в 100 мкс).

Ниже подробно рассмотрим работу задач из файла quartet_main.c.

Наша программа состоит из 5 задач. Грубо говоря, 4 задачи - музыканты, каждый со своим инструментом, и 5-я задача - дирижер, который синхронизирует работу первых 4-х.

Управление звуком

Для уравления звуком в прорамме определен тип TSound, который содержит всю информацию о звуке для "музыканта":

какую ноту играем;
и из какой нотной тетради;
держим ли паузу;
повторяем ли фрагмент;

для "дирижера":

когда он должен дать следующую команду;
закончились ли ноты у "музыканта";

для синтезатора:

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

"Музыканты"

В программе 4 "музыканта": Task_BASS, Task_VIOLIN, Task_GUITAR1, Task_GUITAR2. Все "музыканты" постоянно находятся в режиме ожидания команды от "дирижера" (в виде бинарного семафора). Получив команду, "музыкант" вычитывает следующую ноту из своего нотного стана, играет ее (формирует данные для синтезатора звука в interrupt.c).

Обработка ноты происходит в функции NoteWork(), куда в качестве параметра передается переменная управления звуком TSound. По ней вычитывается следуюая нота (или инструкция: повтор, пауза и пр.) и выполняются операции по формированию указаний синтезатору, а также формируется длительность текущей ноты (паузы), которая уменьшается на 1 каждый раз при получении команды от "дирижeра".

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

"Дирижер"

Задача Task_CONDUCTOR ("дирижер") имеет низший приоритет, чтобы не мешать выполнению задач "музыкантов". Дирижер" отсчитывает такты (как метроном) и следит за тем, чтобы музыканты вовремя получали команды. Задача "дирижер" запускается один раз в 150 мс и при каждом запуске проверяет состояние проигрываемой мелодии. Как только "дирижер" замечает, что все "музыканты" доиграли свои партии до конца (т.е. все биты во флаге flag_Playing сброшены), он дает команду "музыкантам" играть сначала.

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

Синтезатор реализован в функции прерывания в файле interrupt.c. Подпрограмма пробегается по всем четырем переменным управления звуком и формирует цифровой сигнал. Для формирования цифрового сигнала у синтезатора есть:

три таблицы "паттернов": bass[], violin[], guitar[] - где записано по одному периоду сигнала с разными частотными характеристиками;
формулы для формирования огибающей сигнала (помечены комментариями FORMING_SIGNAL_xxx): атака, спад, сустейн.
макрос быстрого перемножения (signed char)*(unsigned char), чтобы перемножать синусоиду на амплитуду огибающей.

Все четыре мгновенных значения амплитуды для каждого инструмента суммируются, делятся на 4 и записываются в переменную m_cDAC, которая при следующем входе в прерывание будет скопирована в буферный регистр PWM CCPR1L (два младших разряда копируются в биты CCP1X и CCP1Y регистра CCP1CON).

О нотах

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

В файле music.c есть буквенные определения нот (C0 - до первой октавы, C0_ - до диез первой октавы, D0 - ре и т.д.) Всего в программе выделены частоты под 4 с половиной октавы (57 нот). Но при задании ноты в нотном стане (в массивах notelist_xxx) для задания номера ноты (макрос play()) используются только 5 бит, т.е. можно пронумеровать только 32 ноты. Поэтому введена возможность установки базовой октавы (макрос setbase()). Длительность ноты задается только двумя битами, поэтому всего 4 варианта длительностей. Если нужно нота большей длительности, то следует ее либо добить паузой (макрос pause()), либо командой продолжения звучания (макрос playmore()). Список нот должен заканчиваться макросом stop(), чтобы "музыканты" не обращались к неинициализированным ячейкам пямяти.

OSA : Статистика используемой ядром памяти

2012-03-12T12:45:01+03:00

OSA : Статистика используемой ядром памяти

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

Компилятор	min, ROM/RAM	normal, ROM/RAM	full, ROM/RAM	Байт на задачу*, RAM
PIC10 (PIC12)
Hi-tech PICC	153 / 11	250 / 14	363 / 14	2
PIC16 (PIC12)
HT-PICC STD	152 / 8	258 / 11	396 / 13	3
microC PRO	180 / 14	307 / 17	474 / 17	3
CCS PICC	254 / ..	399 / ..	573 / ..	3
PIC18
HT-PICC18 STD	336 / 7	548 / 10	982 / 16	3
MPLAB C18	598 / 7	862 / 10	1214 / 16	4
microC PRO	426 / 11	746 / 16	1136 / 17	3
CCS PICC	436 / ..	696 / ..	1046 / ..	3
PIC24 (dsPIC)
MPLAB C30	846 / 10	1065 / 16	1305 / 16	20
AVR
WinAVR	602 / 8	1030 / 13	1348 / 15	10
IAR	550 / 8	958 / 13	1108 / 15	5
STM8
Cosmic	462 / 8	729 / 13	974 / 15	5
IAR	664 / 8	1053 / 13	1388 / 15	13
Raisonance	434 / 8	709 / 13	918 / 15	5

* см. примечания ниже

Расшифровка режимов тестирования:

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

(Во всех трех режимах доступны сервисы переключения контекста, ожидания событий, управения задачами, установки/запрета прерываний)

Примечания:

параметр ROM:
- для PIC10, PIC12 и PIC16 память ROM отображается в словах, для всех остальных - в байтах;
- для MCC18 параметр ROM включает в себя сектор инициализации;
- для MCC30 параметр ROM включает в себя сектор инициализации;
все программы собирались с максимально доступной оптимизацией;
дополнительно в RAM выделяется память под OS_TASKS дескрипторов задач
в таблице приведен базовый размер дескриптора задач. Он может увеличиться:
- при наличии таймера задач (OS_ENABLE_TTIMERS) - на количество байт, занимаемых таймером (по умолчанию 2);
- для контроллеров с ROM >64K - на 2 байта (для хранения старший байтов адреса)
- при использовании режима OS_PRIORITY_EXTENDED - на 2 байта
Варьируя параметры системной конфигурации (osacfg.h), можно выбрать наиболее оптимальный режим. Например, изменив размерность таймера, можно сократить используемую RAM и ROM. Можно в полном режиме отключить приоритеты, получив выигрыш в ROM и скорости. И т.д.

OSA : Скоростные характеристики

2012-03-12T12:44:43+03:00

OSA : Скоростные характеристики

Здесь приведены цифры для оценки времени, требуемого операционной системе для выбора очередной задачи для запуска в разных режимах под разными компиляторами. Что это значит? Допустим, вы пишете программу для PIC16 под компилятором HTPICC, и у вас возникает вопос: "сколько временых ресурсов отнимет OSA?" или "как быстро произойдет переключение с одной задачи на другую?" (для кооперативных RTOS эти вопросы равнозначны). Ответ на этот вопрос приведен в таблице, где вы находите строку с используемым компилятором, затем столбец с используемым режимом работы (неприоритетный, приоритетный, расширенный приоритетный) и видите среднее количество тактов, требуемое OSA для переключения с одной задачи на другую (это число пропорционально зависит от количества активных задач). Далее найденное число умножаем на время выполнения инструкции и получаем время переключения.

Compiler	PRIORITY_DISABLED	PRIORITY_NORMAL	PRIORITY_EXTENDED
PIC10 (PIC12)
Hi-tech PICC	54*N	84*N	-
PIC16 (PIC12)
HT-PICC STD	49*N	80*N	123*N
microC PRO	74*N	119*N	224*N
CCS PICC	62*N	107*N	167*N
PIC18
HT-PICC18 STD	45*N	70*N	85*N
MPLAB C18	55*N	96*N	117*N
microC PRO	73*N	99*N	187*N
CCS PICC	49*N	88*N	101*N
PIC24 (dsPIC)
MPLAB C30	60*N	87*N	113*N
AVR
WinAVR	108*N	172*N	190*N
IAR	100*N	148*N	177*N
STM8
Cosmic	35*N	58*N	71*N
IAR	93*N	118*N	238*N
Raisonance	61*N	80*N	120*N

N - количество активных задач

Оценка среднего времени переключения. Пример 1 Исходные данные:

Контроллер PIC16F628
компилятор HT PICC STD
4 задачи (N = 4)
расширенный приоритетный режим (PRIORITY_EXTENDED)
тактовая частота 20 МГц (т.е. время выполнения инструкции = 200нс)

Находим в таблице значение, соответствующее контроллеру, компилятору и используемому режиму. В нашем случае оно равно 123*N. N у нас равно 4, т.е. предполагается, что одновременно работают 4 задачи.

Среднее время переключения (с момента выполнения, например, OS_Yield() в одной задачи до момента получения управления другой задачей) будет:

t = 123 * 4 * 200нс = 492 * 200нс = 98.4 мкс

Оценка среднего времени переключения. Пример 2 Исходные данные:

Контроллер STM8S105C6
компилятор Cosmic
8 задач (N = 8)
обычный приоритетный режим (PRIORITY_NORMAL)
тактовая частота 16 МГц (т.е. время выполнения инструкции = 62.5нс)

Находим в таблице значение, соответствующее контроллеру, компилятору и используемому режиму. В нашем случае оно равно 58*N. N у нас равно 8, т.е. предполагается, что одновременно работают 8 задач.

Среднее время переключения будет:

t = 58 * 8 * 62.5ns = 464 * 62.5ns = 29 us

OSA : Статические таймеры старого типа

2008-12-24T00:41:25+03:00

OSA : Статические таймеры старого типа

Введение

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

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

Описание

Есть четыре типа статических таймеров (они отличаются разрядностью): 8-, 16- 24- и 32-разрядные. 8-разрядные занимают по одному байту на таймер, 16- и 24-х разрядные – по 2, 32-х – 4 байта. Тип таймера следует выбирать исходя из максимального времени работы этого таймера. Одновременно в программе могут работать статические таймеры всех 4-х типов.

В погоне за экономией RAM и ROM организация работы с таймерами не очень удобна. Количество используемых таймеров и их тип должны быть определены на этапе компиляции. Количество таймеров задается в файле OSAcfg.h:

// Количество 8-разрядных таймеров
#define OS_TIMERS8    5
// Количество 16-разрядных таймеров
#define OS_TIMERS16   2
// Количество 24-разрядных таймеров
#define OS_TIMERS24   0
// Количество 32-разрядных таймеров
#define OS_TIMERS32   1

При этом в памяти создаются массивы соответствующих типов, где и будут храниться таймеры. Кроме того, если в программе есть хотя бы один статический таймер, то создаются битовые переменных для индикации переполнения. Например, в программе используются 5 8-разрядных таймеров, 2 16-разрядных и 1 32-разрядный. Всего 8, следовательно, создастся байтовая переменная, каждый бит которой будет отвечать за свой таймер.

Обращение к статическим таймерам производится через их ID – порядковый номер, причем младшие номера принадлежат 8-разрядным таймерам, а старшие – 32-разрядным. Все номера последовательны. Для нашего примера определено 8 таймеров: 0..4 – 8-разрядные таймеры 5..6 – 16-разрядные 7 – 32-разрядный

Удобно все ID таймеров определять через enum:

enum OSA_TIMERS_ENUM
{
            // 8-битные
    T8_TIMER0,
    T8_TIMER1,
    T8_TIMER2,
    T8_TIMER3,
    T8_TIMER4,
            // 16-битные
    T16_TIMER0,
    T16_TIMER1,
            // 24-битные
 
            // 32-битные
    T32_TIMER0
};

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

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

// Определения в OAScfg.h
#define OS_ENABLE_TIMER
#define OS_TIMERS8  1
 
enum OS_TIMERS_ENUM {
   T8_Timer                  // Таймер для выделения кванта времени задаче поиска
}
 
----------------------------------------------------------------------
 
// Фрагмент программы (предполагаем, что интервал OS_Timer = 1 ms)
OST_MSG pmsg, pmsg2;
 
void Task1 (void)
{
    OST_MSG msg;
    static unsigned long Data;
    for (;;) {
        ...
        OS_SendMsg(pmsg, (OST_MSG)&Data);    // Нужно найти данные Data
        OS_WaitMsg(pmsg2, msg);              // Ждем завершения поиска
        ...
    }
}
 
 
void Task_SearchData (void)
{
    OST_SMSG msg;
    static unsigned long Data;
    static unsigned long Addr;
 
    for (;;) {
       OS_WaitMsg(pmsg, msg);
       Data = (unsigned long)(*msg);
 
       OS_RunTimer(T8_Timer, 10);                 // Запустить таймер на 10 мс
       for (Addr = 0; Addr < MAX_ADDRESS; Addr++) {
           if (MemoryRead(Addr) == Data) {        // Если нашли нужные данные,
               OS_SendMsg(pmsg2, (OST_MSG)&Addr); // отправить сообщение и выйти из цикла
               break;
           }
           if (OS_CheckTimer(T8_Timer)) {         // Таймер переполнился?
                OS_Yield();                       // Передать управление планировщику
                OS_RunTimer(T8_Timer, 10);        // Запустить таймер снова
           }
       }
       if (Addr == MAX_ADDRESS) {                 // Если не нашли данных
            Addr = 0xFFFFFFFF;
            OS_SendMsg(pmsg2, (OST_MSG)&Addr);    // Отправляем -1
       }
    }
}

После получения задания на поиск (после получения сообщения pmsg) задача Task_Search будет полностью захватывать время процессора, передавая упарвление другим задачам раз в 10мс.

Примечания для статических таймеров

Размещение статических таймеров в памяти

Размещение статических таймеров программист указывает в файле OSAcfg.h. Для этого есть константы OS_BANK_TIMEOUTS и OS_BANK_TIMERSx (x = 8, 16, 24, 32). Эти константы описаны в главе Конфигурация.

Примечание о 24-х разрядных таймерах

Эти таймеры фактически 16-разрядные, но увеличиваются они один раз в 256 тиков. Они не годятся для формирования точных задержек из-за такой дискретности, но позволяют формировать довольно большие задержки, не прибегая к использованию 32-разрядного. Получается экономия RAM на 2 байта с одного такого таймера и некоторая экономия ROM за счет работы с 2-х, а не 4-х байтовыми переменными.

Максимальные задержки статических таймеров

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

Интервал вызова OS_Timer	8-разрядные	16-разрядные	24-разрядные	32-разрядные
1 ms	256 мс	65.5 сек	4 ч 40 мин	49 суток
10 ms	2.5 сек	10 мин	46 ч	497 суток
18.2 ms	4.6 сек	19 мин	84 ч	900 суток
256 us	65 мс	16 сек	1 ч 10 мин	12 суток
512 us	130 мс	32.5 сек	2 ч 20 мин	24 суток
1024 us	260 мс	67 сек	4 ч 45 мин	50 суток
2048 us	528 мс	2 мин 15 сек	9 ч 30 мин	100 суток
4096 us	1 с	4 мин 30 сек	19 ч	200 суток
8192 us	2 с	9 мин	38 ч	400 суток

Для всех таймеров, кроме 24-разрядных, дискретность = 1 системному тику. Для 24-разрядных дискретность = 256 системным тикам = полному периоду 8-разрядного таймера.

Сервисы управления статическими таймерами.

Сервис	Описание	Свойства
Запуск
OS_RunTimer8 (timer8_id, time)	Запустить 8-разрядный таймер для отсчета
OS_RunTimer16 (timer16_id, time)	Запустить 16-разрядный таймер для отсчета
OS_RunTimer24 (timer24_id, time)	Запустить 24-разрядный таймер для отсчета
OS_RunTimer32 (timer32_id, time)	Запустить 32-разрядный таймер для отсчета
Остановка
OS_StopTimer (timer_id)	Останавливаем таймер (при этом устанавливается флаг Timeout для этого таймера)
Проверка
bool OS_CheckTimer (timer_id)	Проверить, закончил ли таймер счет.
Ожидание
OS_WaitTimer (timer_id)	Ожидаем завершения счета таймера

OSA : UNDER CONSTRUCTION

2009-02-01T14:26:06+03:00

UNDER CONSTRUCTION

OSA : Regulator - урок

Здесь приводится небольшой урок по проектированию программы с использованием ОСРВ OSA. Допустим, нам нужно написать программу управления скоростью вращения вентилятора. Вентилятор питается от сети 220В 50Гц и управляется симисторным регулятором. Назовем ее Regulator.

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

Задачи

Сперва наперво определимся со структурой программы.

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

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

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

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

Задача интерфейса пользователя (Task_User)

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

Т.е. это задача будет:

ждать сигнала, что кнопка нажата (не заботясь о таких деталях, как полярность кнопки, дребезг

контактов - обо всем этом будет думать задача обработки кнопок);

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

всем этом будет думать задача-индикатор);

сообщать низким звуковым сигналом о достижении минимального или максимального режима (не

заботясь о том, какой динамик подключен).

Задача управления силовой частью (Task_Regulator)

Эта задача должна быть синхронизирована с частотой сети 100 Гц (т.к. мы управляем полуволнами). Как тольконачинается полуволна, мы открываем симистор, тем самым включая мотор вентилятора. Выдерживая какую-то паузу, мы закрываем симистор. (Длительность паузы определяется текущим режимом работы и выбирается пользователем с помощью кнопок в задаче Task_User).

Итак, эта задача:

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

(рисунок)

Задача обработки кнопок (Task_Buttons)

Эта задача будет с итервалом в 10 мс опрашивать состояния кнопок. При нажатии отпускании кнопки должен подавляться дребезг (возьмем 50 мс) во избежании ложного срабатывания. При каждом нажатии кнопки должен издаваться звуковой сигнал (для "+" более высокой частотой, для "-" менее высокой)

Т.е. в функции этой задачи входит:

раз в 10 мс считавание текущего состояния портов, к которым подключены кнопки "+" и "-";
сравнение текущего состояния портов с предыдущим и отсчет, сколько времени состояния портов не

изменялись (для подавления дребезга);

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

Задача индикации (Task_Indicator)

В этой задаче будем выводить номер текущего режима (от 0 до 9) на 7-сегментный индикатор.

Эиа задача будет:

ждать сигнала о том, что нужно вывести цифру;
после получения сигнала выводить ее на индиатор.

Задача вывода звука (Task_Sound)

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

Перечислим функции этой задачи:

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

Взаимосвязь задач

Итак, у нас есть 5 задач, которые работают параллельно. Конечно же, это псевдопараллельность, т.к. в один момент времени может выполняться только одна задача, но за счет того, что ядро операционной системы бысто по очереди перебирает все задачи, сосдается эффект параллельности. В чем прелесть? Напрмер, задаче интерфейса требуется издать звуковой сигнал длительностью 0.5 сек. Она всего навсего выдает команду параллельной задаче вывода звука и, забывая о ней, продолжает заниматься своими делами, в то время как пауза в 0.5 секунды ложится на плечи задачи вывода звука. Задача интерфейс тем временем может продолжать принимать/отправлять команды другим задачам.

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

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

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

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

    unsigned char m_ucMode;

Задача Task_Buttons будет сообщать задаче Task_User какая кнопка нажата. Т.е. эта задача должна иметь возможноть передать два значения: нажата кнопка "-" или нажата кнопка "+". Нам нужно выбрать объект операционной системы, через который задача будет сообщать о нажатых кнопках. В арсенале OSA есть следующие объекты для передачи данных: бинарный семафор (Bsem), счетный семафор (Csem), флаг (Flag), указатель на сообщение (Msg), короткое однобайтовое сообщение (SMsg).

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

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

Остаются три способа передачи информации, которые нам подходят: Flag, Msg, SMsg. Учитывая, что предпочтительнее выбирать наименее ресурсоемкий инструмент, мы отказываемся от указателя на сообщение, т.к. в памяти занимает 2 байта на дескриптор указателя и 1 байт самого сообщения, в отличие от Flag и SMsg, которые занимают по одному байту.

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

    OST_FLAG    flag_Buttons;

Кроме того, задача обработки кнопок должна заставлять динамик пищать:

более высокой частотой - при нажатии на "+";
менее высокой частотой - при нажатии на "-".

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

    typedef struct _TSound
    {
        unsigned char    ucFreq;
        unsigned int     wDuration;
    }
 
    OST_MSG_CB    msg_Sound;

Task_User при получении сообщения от задачи Task_Buttons должна изменить режим. Если режим уже максимальный или минимальный, то выдать звуковой сигнал низкой частоты (это делается через уже определенную переменную msg_Sound). При смене режима задача-координатор должна сообщить задаче-индикатору, что нужно отобразить текущий режим. Т.к. сам режим - глобальная переменная, то задаче Task_Indicator нужно только махнуть флажком, что пора выводить цифру на экран. Для этого нам достаточно одного бита информации, т.е. есть возможность воспользоваться Bsem - бинарным семафором.

enum ENUM_BSEMS {
    ...
    BS_INDICATE
    ...
}

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

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

Приоритеты

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

Итак, иерархия приоритетов будет такова:

Задача	Имя функции	Приоритет
Управление силовой частью	Task_Regulator	0 (высший)
Вывод звука	Task_Sound	1
Координатор	Task_Coordinator	2
Обработка кнопок	Task_Buttons	2
Индикация	Task_Indicate	2

Реализация

Реализация задач

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

Task_User

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

void Task_User (void)
{
    static TSound s_Sound;
 
    for (;;)
    {
        // Ждем нажатия кнопки (утановки любого бита в переменной flag_Buttons)
 
        OS_Flag_Wait_1x(flag_Buttons);
 
        // Проверка кнопки "+"
 
        if (flag_Buttons & 1)
        {
            m_ucMode++;
            if (m_ucMode >= MAX_MODE)
            {
                m_ucMode = MAX_MODE;
                s_Sound.ucFreq = 50;
                s_Sound.wDuration = 4000;   // 4000 * 100 us = 400 ms
                OS_Msg_Send(msg_Sound, (OST_MSG)&s_Sound);
            }
        }
 
        // Проверка кнопки "-"
 
        if (flag_Buttons & 2)
        {
 
            if (m_ucMode == 0)
            {
                m_ucMode = MAX_MODE;
                s_Sound.ucFreq = 50;
                s_Sound.wDuration = 4000;   // 4000 * 100 us = 400 ms
                OS_Msg_Send(msg_Sound, (OST_MSG)&s_Sound);
            }
 
            else m_ucMode--;
 
        }
 
        // Ждем отпускания кнопок
 
        OS_Flag_Wait_00(flag_Buttons);
    }
}

Task_Regulator

#define MAX_MODE    10                  // Количество режимов скорости
 
const unsigned char Speeds[MAX_MODE] =  // Длительности управляющих импульсов
    {0, 2, 3, 4, 5, 6, 7, 8, 9, 10};    // для всех режимов
 
 
void Task_Regulator (void)
{
    for (;;)
    {
        pin_REGULATOR = 0;          // Выключаем симистор
        OS_Cond_Wait(INTF);         // Ждем начала фазы сети
 
        if (m_ucMode)               // Открываем симистор, только если ненулевой режим
            pin_REGULATOR = 1;
 
        INTF = 0;
 
        if (m_ucMode >= MAX_MODE) m_ucMode = 0;
 
        OS_Delay(Speeds[m_ucMode]); // Выдерживаем задержку, сооиветствующую режиму.
                                    // Чем дольше задержка, тем быстрее будет
                                    // вращаться вентилятор.
    }
}

Task_Buttons

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

void Task_Buttons (void)
{
    // Переменные, которые должны сохранять
    // свое значение после переключения контекста
    static unsigned char s_ucButtons;       // Текуще состояние кнопок
    static unsigned char s_ucJitter;        // Счетчик для устранения дребезг
    static TSound        s_Sound;           // Переменная для отправки сообщения
                                            // задаче вывода звука
 
    // Временные переменные.
    char cTemp;
 
    for (;;)
    {
        s_ucButtons = cTemp;                        // Запоминаем последнее состояние входов
 
        OS_Delay(100);                      // Интервал опроса = 100 * 100uS = 10 ms
        cTemp = 0;
 
        if (!pin_BUTTON_PLUS)  cTemp |= 1;  // Копируем сотояния кнопок во временную переменую
        if (!pin_BUTTON_MINUS) cTemp |= 2;
 
        // Обработка дребезга
 
        if (!(s_ucButtons & 0x80)) s_ucButtons++;       // Обработка дребезга. Счетчик будет
        if (cTemp != s_ucButtons) s_ucJitter = 0;       // расти только тогда, когда
                                                        // сотояние кнопок не изменяется.
 
        if (s_ucJitter != 5) continue;
 
        // Попали сюда, значит, после нажатия/отпускания кнопки и устоявшегося состояния
        // на входе прошло 50 мс.
 
        OS_Flag_Init(flag_Buttons, cTemp);
 
        if (cTemp & (cTemp ^ s_ucButtons))      // Звук выдаем, только если кнопка была нажата
        {
            s_Sound.ucFreq = 100;
            if (cTemp & 1) s_Sound.ucFreq += 20;
            s_Sound.wDuration = 2000;   // 2000 * 100 us = 200 ms
 
            // Отправляем сообщение задаче вывода звука
            OS_Msg_Send(msg_Sound, (OST_MSG)&s_Sound);
        }
    }
}

Task_Sound

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

void Task_Sound (void)
{
    TSound *pSound;
 
    for (;;)
    {
        CCPR1L = 0;
        OS_Msg_Wait(msg_Sound, (OST_MSG) pSound);        // Ждем сообщение
 
        // Формируем параметры ШИМ из тела сообщения
        PR2 = pSound->ucFreq;                           // Частота тона
        CCPR1L = PR2 >> 1;                              // Скважность = 2
 
        OS_Delay(pSound->wDuration);                    // Выдерживаем паузу
        CCPR1L = 0;
 
        OS_Delay(1000);                                 // Ждем паузу 1000*100us = 100ms,
                                                        // чтобы звук не сливался, когда
                                                        // принимаются два сообщения подряд
    }
}

Task_Indicate

Здесь все просто: ждем установки двоичного семафора, а затем зажигаем сегменты индикатора в соответствие со значением m_ucMode.

const char SEGMENTS[10] = {
    //abcdefgh
    0b11111110,     // 0
    0b01100000,     // 1
    0b11011010,     // 2
    0b11110010,     // 3
    0b01100110,     // 4
    0b10110110,     // 5
    0b10111110,     // 6
    0b11100000,     // 7
    0b11111110,     // 8
    0b11110110,     // 9
}
 
void Task_Indicator (void)
{
    for (;;)
    {
        OS_Bsem_Wait(BS_INDICATE);
        if (m_ucMode >= MAX_MODE) m_ucMode = 0;
        PORTB = SEGMNTS[m_ucMode];
    }
}

Проект

Теперь создадим проект в MPLab, из которого уже получим рабочий HEX-фалй для прошивки в контроллер. Следуя указаниям из параграфа "Описание/Проект", создадим проект.

В MPLab через меню Project/New создаем новый проект с именем "regulator" и выбираем рабочую

папку для него.

В рабочей папке создаем пустой файл OSAcfg.h
В начало нашего файла "regulator.c" добавляем включение файла "osa.h"
Через меню "Project/Build options…/Progect" открываем параметры проекта и на закладке

"Directories" указываем пути "Include Search Path":

путь к файлам самого проекта;
путь к файлу osa.h.

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

main()

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

void interrupt isr (void)
{
    if (T0IF)
    {
        T0IF = 0;
        OS_Timer();
    }
    wdt_work();             // (описание см. ниже)
}
 
 
void main (void)
{
    init();                 // Для начала инициализируем все настройки периферии ПИКа
                            // (описание см. ниже)
 
    OS_Init();
 
    OS_Task_Create(2, Task_User);
    OS_Task_Create(0, Task_Regulator);
    OS_Task_Create(2, Task_Buttons);
    OS_Task_Create(2, Task_Indicator);
    OS_Task_Create(1, Task_Sound);
 
    OS_Run();
}

OSAcfg.h

Ну, и напоследок - конфигурация ОС. В каждом проекте, написанным с использованием OSA, должен быть конфигурационный файл OSAcfg.h.

#ifndef _OSA_CFG_H
#define _OSA_CFG_H
 
#define OS_TASKS                5       // Резервируем память под 5 дескрипторов задач
#define OS_ENABLE_TIMER                 // Говорим системе, что будем использовать задержки
#define OS_USE_INLINE_TIMER             // Для ускорения вызова OS_Timer делаем его in-line
                                        // функцией
 
#define OS_BSEMS                1       // Резервируем память под 1 бинарный семафор
 
enum ENUM_BSEMS {                       // Задаем иденфикационные намера бинарным семафорам
    BS_INDICATE
};
 
 
#endif

Остальные функции

У нас осталось две неописанных функции: init() - инициализация периферии, и wdt_work() - сброс WDT при условии нормальной работы. Здесь мы не будем останавливаться на подробностях этих функций, а текст этих функций с комментариями см. в исходниках программы.

Резюме

Что мы получили

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

Если в дальнейшем будут какие-то глобальные схематические изменения (например, вместо 7-сегментного индикатора будет использоваться ЖК-индикатор; или вместо простых кнопок будет использоваться матричная клавиатура; или будет использован пьезодинамик со встроенным генератором), то все, что потребуется - это изменение одной отдельной задачи. При этом нам не нужно будет думать о том, как поведут себя остальные задачи. Мы определились с форматом связи между задачами и все, о чем нам нужно помнить при переписывании какой-либо задачи, - это соблюдение формата и типа входных и выходных данных.