Операционная система реального времени OS_MBB

Операционная система
реального времени OS_MBB
Руководство программиста
Содержание
1. Аппаратное обеспечение с точки зрения программиста
2. Состав и функции программного обеспечения
2.1. Системное программное обеспечение
2.1.1. Запуск программного обеспечения
2.1.2. Операционная система OS_MBB
2.1.4. Системная задача RAC
2.2. Прикладное программное обеспечение
3. Операционная система реального времени OS_MBB
3.1. Введение
3.2. Отсчет реального времени. Интервалы и таймауты
3.3. Аппаратные прерывания
3.4. Управление памятью
3.5. Задачи в системе OS_MBB
3.5.1. Основные свойства задач
3.5.2. Состояния задач
3.5.3. Приоритеты задач
3.5.4. Создание задач. Начальный дескриптор задачи (ITD)
3.5.5. Текущий и функциональный идентификаторы задачи
3.5.6. Начальный дескриптор данных (IDD)
3.5.7. Требования, предъявляемые к прикладной задаче
3.6. Сообщения
3.6.1. Прием и передача сообщений
3.6.2. Внешняя программная среда
3.6.3. Структура сообщения
3.7. Системные переменные
3.7.1. Текущий идентификатор работающей задачи TASK_ID
3.7.2. Приоритет работающей задачи TASK_PRIORITY
3.7.3. Единица системного времени CLOCK_UNIT
3.7.4. Размер системного буфера BUF_SIZE
3.8. Системные ресурсы
3.8.1. Память, доступная прикладным задачам
3.8.2. Другие ресурсы, доступные прикладным задачам
3.8.3. Реактивность системы. Время переключения задач
3.9. Системные вызовы
3.9.1. Соглашения по использованию регистров
3.9.2. Ожидание событий WAIT
3.9.3. Передача сообщения SEND_MESSAGE
3.9.4. Определение события "интервал" SET_INTERVAL
3.9.5. Запрещение и разрешение прерываний DISABLE_INT и
ENABLE_INT
3.9.6. Динамическое создание и удаление задач CREATE_TASK и
3.9.7. Получение и возврат системного буфера ALLOCATE и
DEALLOCATE
3.9.8. Получение и возврат блока памяти GET_MEM и
RELEASE_MEM
3.9.9. Соответствие TID и FID задач GET_FUNCTION_IDS
3.9.10. Получение информации о системе SYS_INFO
4. Задача дистанционного доступа и управления RAC
4.1. Введение
4.2. Локальная сеть Bitbus
4.2.1. Логическая модель Bitbus
4.2.2. Протокол транспортного уровня
4.2.3. Состояния устройств сети. Работа канала данных
4.3. Среда функционирования задачи RAC
DELETE_TASK
4.4. Описание работы задачи RAC
4.4.1. Функции (команды) задачи RAC
4.4.2. Обработка сообщений
4.5. Обращение к задаче RAC. Формат сообщения Bitbus
4.6. Команды (функции) задачи RAC
4.6.1. Программный перезапуск RESET_STATION
4.6.2. Создание задачи CREATE_TASK
4.6.3. Удаление задачи DELETE_TASK
4.6.4. Запрос таблицы FID задач GET_FUNCTION_IDS
4.6.5. Запрет/разрешение функций доступа RAC_PROTECT
4.6.6. Чтение внешней памяти данных EXT_UPLOAD
4.6.7. Запись во внешнюю память данных EXT_DNLOAD
4.6.8. Запись во внутреннюю память данных INT_WRITE
4.6.9. Чтение внутренней памяти данных INT_READ
4.6.10.Чтение системной информации о станции NODE_INFO
4.6.11.Исключении из таблицы полинга подчиненного узла
SET_NODE_OFFLINE
4.6.12.Чтение памяти программ UPLOAD_CODE
4.6.13.Запись в память программ DNLOAD_CODE
4.6.14.Обращение к подпрограмме GO_SUB
4.7. Установка адреса станции и скорости обмена в канале Bitbus
5. Управление внешними устройствами
5.1. Ввод-вывод дискретных сигналов
5.1.1. Инициализация дискретного ввода-вывода D_MODE
5.1.2. Ввод дискретных сигналов D_INP
5.1.3. Вывод дискретных сигналов D_OUT
5.2. Ввод-вывод сигналов через порты 4,5,6
5.3. Сторожевой таймер (watch-dog)
5.2.1. Контроль времени выполнения программ
5.2.2. Системные вызовы WATCHDOG_RST, WATCHDOG_OS,
WATCHDOG_USER
1. Аппаратное обеспечение с точки зрения программиста
Центральным процессором контроллера MBB (далее - MBB или просто контроллер) является
однокристальная микроЭВМ DS80C320 фирмы Dallas. Эта микроЭВМ имеет систему команд
микроконтроллеров семейства MCS-51, имеет внутреннее ОЗУ объемом 256 байт и адресует 64K
байт внешней памяти данных и 64K байт внешней программной памяти. МикроЭВМ имеет четыре
8-ми битных порта ввода/вывода, два последовательных порта, три 16-ти битных счетчика/таймера,
программируемый watchdog-таймер.
Контроллер MBB реализует высокоскоростной последовательный канал, поддерживающий
протоколы SDLC и CSMA/CD и называемый GSC (Global Serial Channel - глобальный
последовательный канал).
В контроллере MBB часть адресного пространства и отображенной на него памяти используют
системные программы, оставшуюся часть могут использовать прикладные программы. Прикладные
программы размещаются в совмещенном сегменте внешних данных и программ в пользовательской
области (адреса 8000h...0FFFFh).
2. Состав и функции программного обеспечения
Программное обеспечение (далее - ПО) делится на системное и прикладное. Системное ПО
реализует многозадачный режим исполнения прикладных программ и поддерживает протокол
Bitbus.
Прикладные программы обеспечивают выполнение конкретных функций в системе
управления.
2.1. Системное программное обеспечение
Системное программное обеспечение состоит из следующих компонент:
- операционной системы реального времени OS_MBB;
- задачи дистанционного доступа и управления RAC.
Системное программное обеспечение занимает первые 8К байт памяти программ (адреса 0...1FFFh)
и размещается во FLASH-памяти. Системное программное обеспечение использует внешнюю
память данных в диапазоне адресов 0...3FFh. Адреса 1000h...2FFFh используются аппаратурой
контроллера.
2.1.1. Запуск программного обеспечения
После включения питания, а также программного или аппаратного перезапуска, выполняется
запуск операционной системы. При успешном запуске операционной системы зажигается сначала
красный светодиод, затем через 250 мсек красный светодиод гаснет и зажигается зеленый
светодиод.
2.1.2. Операционная система OS_MBB
Операционная система OS_MBB реализует многозадачный режим исполнения прикладных
программ с системой приоритетов (до 8 одновременно исполняемых задач, включая системную
задачу RAC), межзадачное взаимодействие на уровне обмена сообщениями, обработку прерываний
и временных интервалов, динамическое создание и удаление задач, управление внутренней памятью
процессора.
2.1.3. Системная задача RAC
Системная задача дистанционного доступа и управления RAC
(Remote Access and Control) поддерживает протокол Bitbus на уровне
обмена сообщениями между задачами, исполняемыми в разных узлах сети,
осуществляет обмен сообщениями с устройством расширения.
2.2. Прикладное программное обеспечение
Прикладное ПО разрабатывается пользователем с учетом возможностей системного ПО.
Прикладная программа размещается в диапазоне адресов 8010h...0FFFFh в совмещенном
сегменте внешней памяти данных и программ. Начальные 16 байтов этого сегмента в диапазоне
адресов 8000h...800Fh используются под системные нужды. Начальный дескриптор первой
прикладной задачи может быть размещен, начиная с адреса 8010h. Если начальный дескриптор
размещен по этому адресу, то задачи будут создаваться автоматически при каждом перезапуске ПО.
3. Операционная система реального времени OS_MBB
3.1. Введение
Операционная система реального времени OS_MBB - это комплекс системных программ,
образующих проблемно-ориентированную среду выполнения прикладных программ в режиме
реального времени. Использование OS_MBB позволяет строить прикладные программы в виде
нескольких отдельных, выполняемых параллельно процессов, называемых задачами. Операционная
система обеспечивает диспетчеризацию задач, т.е. их квазиодновременное выполнение с
переключением процессора в соответствии с приоритетами задач. Кроме диспетчеризации задач
операционная система ведет отсчет реального времени, организует обработку аппаратных
прерываний процессора, поддерживает межзадачный обмен сообщениями, управляет внутренней
памятью процессора. Совместно с системной задачей дистанционного доступа и управления RAC
OS_MBB поддерживает прием и передачу внешних сообщений, т.е. общение задач с внешней
программной средой через последовательный канал Bitbus и канал связи с устройством расширения
(если таковое имеется). Операционная система располагаются в области системной памяти
программ. Часть программ операционной системы активизируется аппаратными прерываниями. Эти
программы отсчитывают реальное время и обрабатывают аппаратные прерывания процессора.
Остальные программы называются системными вызовами. Задачи обращаются к ним при помощи
команды LCALL с указанием абсолютного адреса точки входа в конкретную программу. Обращаясь
к системным вызовам, прикладные задачи могут динамически создавать и удалять другие задачи,
запрещать и разрешать аппаратные прерывания, приостанавливать свое выполнение процессором в
ожидании некоторых событий, посылать и принимать сообщения, получать и возвращать блоки
внутренней памяти данных.
3.2. Отсчет реального времени. Интервалы и таймауты
Отсчет реального времени в OS_MBB ведется в системных единицах времени - тиках.
Величина одного тика при инициализации по умолчанию устанавливается равной 1 миллисекунде.
Эта величина может быть изменена в прикладной программе путем указания нового значения в
начальном дескрипторе данных или прикладной задачей путем присвоения соответствующего
значения системной переменной CLOCK_UNIT. Использование функции отсчета реального
времени прикладной задачей возможно двумя способами:
a) Путем обращения к системному вызову SET_INTERVAL и определения события типа "интервал".
После этого указанное событие будет происходить регулярно с заданным периодом в виде "меток
времени". Задача может ожидать это событие, обращаясь к системному вызову WAIT;
b) Путем обращения к системному вызову WAIT и ожидания в течении заданного времени (таймаута)
одного или нескольких событий любого типа. Если ни одно из ожидаемых событий в течении
указанного времени не наступает, то ожидание прекращается.
Для отсчета реального времени используется один из таймеров процессора - таймер 0.
Запрещение прерываний от таймера 0 приостанавливает отсчет реального времени и до момента
разрешения этих прерываний отменяет событие "интервал", а также исчисление времени ожидания
других событий.
3.3. Аппаратные прерывания
Аппаратурой процессора DS80C320 предусматривается возможность прерывания его работы
от следующих источников: трех таймеровсчетчиков, пяти внешних сигналов запроса, двух
последовательных каналов, таймера Watchdog.
Прерывания от таймера 0 используются для отсчета реального времени. Внешние прерывания
INT2, INT3 и INT4 используются для организации обмена по каналу Bitbus. Все остальные
прерывания рассматривается как событие типа "прерывание". Использование прерываний задачами
осуществляется посредством ожидания события этого типа с помощью системного вызова WAIT.
Конкретные источники используемых задачей прерываний должны быть связаны с этой задачей при
ее создании. С каждым источником может быть связано не более одной задачи; это связывание
осуществляется путем указания в начальном дескрипторе задачи всех связываемых с задачей
источников прерываний.
Если прерывания от того или иного источника необходимо на время блокировать, запрещение
и разрешение прерываний производится системными вызовами DISABLE_INT и ENABLE_INT
соответственно.
Для быстрой реакции на прерывания введена возможность вне системной обработки
прерываний. Для этого в области векторов прерывания пользователя по адресам 8000h...800Fh
пользователь должен разместить команды перехода LJMP на соответствующие подпрограммы
обработки прерываний. Формат области векторов прерываний пользователя:
8000h
- прерывания
от INT0;
8003h
- прерывания
от TM2;
8006h
- прерывания
от INT1
8009h
- прерывания
от TM1;
800Ch
- прерывания
от UART.
3.4. Управление памятью
Операционная система обеспечивает управление внутренней памятью процессора, что
позволяют оптимально ее использовать. В функции управления внутренней памятью входит:
- выделение блока свободной внутренней памяти заданной длины - системный вызов GET_MEM;
- возвращение блока внутренней памяти заданной длины обратно в систему - системный вызов
RELEASE_MEM.
Управление памятью доступно как на этапе начальной инициализации, так и во время работы задач.
И системные, и прикладные программы используют внутреннюю память:
a) в виде регистров общего назначения R0...R7 какого-либо банка;
b) для размещения переменных с малым временем доступа;
c) для формирования, передачи и приема сообщений Bitbus;
d) для размещения стеков системных и прикладных задач.
Часть внутренней памяти используется операционной системой и недоступна для прикладных
задач. Оставшаяся часть внутренней памяти организована в виде "кучи" (memory heap).
Пространство под стеки задач, создаваемых во время начальной инициализации, отводится блоками
соответствующей длины, начиная со старших адресов. Прикладная программа может
зарезервировать блок памяти, размещенный по фиксированному адресу, используя начальный
дескриптор данных. После запуска задач внутренняя память может отводиться и освобождаться
блоками как фиксированной длины (системные вызовы ALLOCATE и DEALLOCATE), так и
произвольной длины (системные вызовы GET_MEM и RELEASE_MEM). При удалении задач
(системным вызовом DELETE_TASK) внутренняя память, в которой размещался стек задачи,
возвращается в "кучу"; при динамическом создании задачи (системным вызовом CREATE_TASK)
пространство под стек задачи отводится также из "кучи".
Операционная система осуществляет назначение банков рабочих регистров R0...R7 при
создании задач в соответствии с их начальными дескрипторами освобождение банков при удалении
задач.
3.5. Задачи в системе OS_MBB
3.5.1. Основные свойства задач
Прикладные задачи - это программы с некоторыми специфическими свойствами,
отличающими их от обычных программ.
Прикладная программа в машинных командах процессора, размещенная в памяти программ,
считается задачей, существующей в среде OS_MBB, начиная c момента создания задачи до момента
ее удаления. Задача может быть создана либо изначально, при инициализации системы, либо
динамически (другой задачей) с помощью системного вызова CREATE_TASK. Удаление задачи
происходит либо при разрушении системы, либо при обращении задачи к системному вызову
DELETE_TASK.
Хотя количество запрограммированных задач ограничивается только объемом памяти
программ, в каждый момент времени в системе допустимо существование не более 8 задач.
Системная задача RAC входит в это число.
Каждая задача должна представлять собой циклическую программу.
Все задачи выполняются квазиодновременно, занимая процессорное время по очереди в
соответствии со своими приоритетами. Переключение процессора от одной задачи к другой может
происходить в моменты появления соответствующих событий, истечении времени ожидания
событий (таймаута), а также при динамическом создании или удалении задачи. Ни одна из задач не
должна занимать все процессорное время. Это означает, что все задачи хотя бы в одной точке
своего цикла должны обращаться к системному вызову WAIT, и в результате этого ожидать какоелибо событие. Исключением может быть лишь одна задача, а именно задача с самым низшим
приоритетом.
Задачи выполняются асинхронно, однако, при необходимости, они могут за счет ожидания
событий в некоторых своих точках быть синхронизированы с отсчетом реального времени, c
другими задачами или с внешней программной средой. Кроме того, в случае привязки к аппаратным
прерываниям, задачи могут быть синхронизированы с внешней аппаратной средой.
3.5.2. Состояния задач
Задача, выполняемая в среде OS_MBB, в каждый момент времени находится в одном из трех
состояний: "работа", "ожидание" или "готовность". Эти состояния определяют, в каком отношении к
возможным событиям находится задача.
В состоянии "работа" в каждый момент времени находится либо только одна задача, либо не
находится никакая задача. В последнем случае процессор "простаивает", выполняя пустой цикл.
Задача остается в состоянии "работа" до тех пор, пока не выполнится какоелибо из следующих
условий:
a) Работающая задача обращается к системному вызову WAIT c ненулевым значением таймаута,
причем ни одно из ожидаемых событий к данному моменту еще не наступило. В результате
работающая задача переходит в состояние "ожидание", а в состояние "работа" переходит задача с
наивысшим приоритетом из числа готовых. Если готовых задач нет, процессор выполняет пустой
цикл;
b) Работающая задача обращается к системному вызову CREATE_TASK и создает задачу с
приоритетом выше своего. В результате работающая задача переходит в состояние "готовность", а в
состояние "работа" переходит созданная задача;
c) Работающая задача обращается к системному вызову SEND_MESSAGE и посылает сообщение
задаче, ожидающей его и имеющей приоритет выше, чем у работающей. В результате работающая
задача переходит в состояние "готовность", а в состояние "работа" переходит задача, ожидавшая
сообщение;
d) Работающая задача обращается к системному вызову DELETE_TASК и удаляет себя. В результате
эта задача перестает существовать, а в состояние "работа" переходит задача с наивысшим
приоритетом из числа готовых;
e) Возникает аппаратное прерывание процессора и имеется задача, ожидающая событие "прерывание" с
приоритетом выше, чем у работающей. В результате работающая задача переходит в состояние
"готовность", а в состояние "работа" переходит задача, ожидавшая прерывание;
f) Появляется событие типа "интервал", ожидаемое задачей с приоритетом, выше, чем у работающей. В
результате работающая задача переходит в состояние "готовность", а в состояние "работа"
переходит задача, ожидавшая событие;
i) Истекает таймаут, назначенный системным вызовом WAIT в задаче, ожидающей какого-либо
события (или нескольких событий) и имеющей приоритет выше, чем у работающей задачи. В
результате работающая задача переходит в состояние "готовность", а в состояние "работа"
переходит задача, ожидавшая событие.
Задача находится в состоянии "ожидание", когда она ждет появления события, обратившись к
системному вызову WAIT. В состоянии "ожидание" задача процессором не выполняется и остается
в нем до тех пор, пока либо не наступит ожидаемое событие, либо не истечет максимальное время
ожидания (таймаут), либо пока другая задача, обратившись к системному вызову DELETE_TASK,
не удалит данную задачу.
Все не работающие и не ожидающие задачи находятся в состоянии "готовность". В этом
состоянии задачи не выполняются процессором. Задача переходит в это состояние по одной из
следующих причин:
a) Изначально - когда задача создается при инициализации системы или в результате обращения другой
задачи к системному вызову CREATE_TASK;
b) Из состояния "работа" - при наступлении события, ожидаемого задачей более высокого приоритета.
В состояние "работа" переходит эта высокоприоритетная задача. Переход из состояния "работа" в
состояние "готовность" происходит также в результате создания работающей задачей
высокоприоритетной задачи при обращении к системному вызову CREATE_TASK;
c) Из состояния "ожидание" - при наступлении любого из ожидаемых событий, если ожидающая задача
имеет приоритет ниже, чем у работающей.
Попав в состояние "готовность", задача остается в нем до тех пор, пока система не переведет ее
в состояние "работа" или пока она не будет удалена из системы.
П_р_и_м_е_ч_а_н_и_е. При переводе задачи из состояния "работа" в состояние "готовность"
система сохраняет содержимое регистров процессора A, B, DPTR, R0...R7 и PSW этой задачи, а при
возврате задачи в состояние "работа" восстанавливает содержимое этих регистров. Корректное
совместное использование различными задачами остальных регистров должно обеспечиваться
алгоритмами этих задач.
3.5.3. Приоритеты задач
Приоритет задачи - это статическая характеристика задачи, определяющая степень
предпочтения задачи по отношению к другим задачам в случаях их конкуренции за процессорное
время. Приоритет представляется целым числом из диапазона 1...7. Высшему приоритету
соответствует значение 7. Операционная система использует приоритеты задач при решении двух
вопросов:
a) При назначении банка регистров общего назначения R0...R7 создаваемой задаче: две задачи или
более могут разделять банк регистров, только если они имеют одинаковые приоритеты.
b) При решении вопроса о том, какую из готовых задач перевести в состояние "работа". Из числа
готовых задач выбираются те, которые имеют наивысший приоритет. Из этих задач с равными
приоритетами выбирается задача, которая стоит первой во внутренних таблицах системы.
При возникновении прерывания система переводит работающую задачу в состояние
"готовность", а затем выбирает из числа готовых задачу наивысшего приоритета и переводит ее в
состояние "работа". Таким образом, работающая задача может быть прервана при возникновении
только такого аппаратного прерывания, которое связано с задачей высшего приоритета.
3.5.4. Создание задач. Начальный дескриптор задачи (ITD)
Создание прикладной задачи предполагает наличие в памяти программ специальной структуры
данных - начального дескриптора задачи (ITD - Initial Task Descriptor). В ITD указываются все
статические характеристики создаваемой задачи.
Все ITD задач, создаваемых при инициализации системы, должны быть заранее размещены в
памяти программ в виде цепочечной структуры, образуемой последовательными ссылками каждого
ITD (кроме последнего) на следующий. ITD прикладной задачи, которая должна быть создана
первой после системной задачи RAC, должен располагаться по адресу 8010h. ITD остальных
прикладных задач могут располагаться по произвольным адресам, большим 8010h.
Порядок создания задач при инициализации определяется порядком следования их ITD в
цепочке последовательных ссылок.
ITD имеет следующую структуру:
Номер байта
Назначение
0...1
Ключ
2...3
Стартовый адрес
4
Размер стека
5
Функциональный идентификатор
6
Банк регистров, приоритет
7...8
Прерывания
9...10
Ссылка на следующий ITD
Рассмотрим смысл и назначение элементов ITD (двухбайтовые величины располагаются
старшим байтом по младшему адресу):
Ключ - двухбайтовый код, равный 0AA55h и являющийся признаком структуры ITD. При запуске
системы прекращает начальное создание задач, если элемент "ссылка на следующий ITD" указывает
на поле, содержимое которого отлично от 0AA55h.
Стартовый адрес - двухбайтовая величина отрицательного смещения первой исполняемой команды
задачи относительно начала данного ITD. Если поле "стартовый адрес" содержит ноль, данный
начальный дескриптор считается начальным дескриптором данных (IDD).
Размер стека - значение, указывающее количество байт внутренней памяти данных, которое
необходимо выделить под стек задачи.
Следует указывать как минимум четыре байта. Для задач, создаваемых при инициализации, под
стек указанного размера последовательно (в порядке создания задач по цепочке ITD) выделяются
смежные области внутренней памяти данных (сегмент IDATA), начиная с верхних адресов (с адреса
0FFh и вниз). В случае динамического создания задач под стек также выделяется указанное
количество байт, но предсказать адрес начала стека невозможно.
Если в поле "размер стека" указано нечетное число байт, система округлит его до ближайшего
большего четного числа.
FID - функциональный идентификатор задачи.
Банк регистров - полубайтовая величина (тетрада), определяющая, с каким банком регистров
общего назначения из четырех имеющихся в процессоре будет работать задача сразу после
создания. Допустимы следующие значения этого элемента ITD (в двоичном формате):
00xx - запрашивается любой банк, xx - произвольное значение;
01yy - запрашивается банк "yy", где "yy" = 0...3.
При выделении банка регистров система следит за тем, чтобы с одним банком не работали задачи,
имеющие разные приоритеты.
Приоритет - полубайтовая величина (тетрада) из диапазона 1...7, определяющая приоритет задачи.
Прерывания - двухбайтовая величина, описывающая, какие аппаратные источники прерываний
связываются с задачей. Этот элемент ITD должен задаваться в следующем виде (двоичный формат):
xxIxHxGF xxEDCBxA
где x - произвольное значение.
A,B,C,D,E,F,G,H,I - разряды, соответствующие отдельным источникам аппаратных прерываний.
Значение "1" в разряде означает, что источник связывается с задачей. Ниже приводится
соответствие разрядов этого элемента ITD источникам прерываний.
A
B
C
D
E
F
G
H
I
-
внешний запрос прерывания 0
внешний запрос прерывания 1
таймер-счетчик 1
контроллер локального последовательниго канала (UART)
таймер-счетчик 2
контроллер канала Bitbus - успешный прием
контроллер канала Bitbus - ошибка приема
контроллер канала Bitbus - успешная передача
контроллер канала Bitbus - ошибка передачи
Система позволяет связать с одним источником прерывания не
более одной задачи. Если в поле "прерывания" ITD двух или
более задач указан один и тот же источник, с прерыванием
будет связана та задача, которая создавалась позднее.
В частности, при динамическом создании задачи (системным вызовом CREATE_TASK) с
прерыванием будет связана вновь созданная задача. При удалении такой задачи (системным
вызовом DELETE_TASK) прерывание не связывается с задачей, с которой оно было связано ранее, а
запрещается.
Ссылка на следующий ITD - двухбайтовая величина отрицательного смещения начала следующего
начального дескриптора (ITD или IDD) в цепочке относительно начала данного ITD. При начальном
создании задач этот элемент используется для перехода к следующему ITD. Если элемент "ссылка
на следующий ITD" указывает на двухбайтовое поле, содержимое которого отлично от 0AA55h,
начальное создание задач завершается. При динамическом создании задачи с помощью системного
вызова CREATE_TASK значение этого поля игнорируется.
3.5.5. Текущий и функциональный идентификаторы задачи
Каждой задаче от момента ее создания до момента удаления ставится в соответствие текущий
идентификатор TID - целое число из диапазона 0...7, идентифицирующее эту задачу при передаче ей
сообщений. Все существующие в данный момент задачи имеют различные текущие
идентификаторы. В процессе начального создания задач при инициализации системы
присваиваемые им значения TID возрастают от 0 в порядке расположения в цепочке ITD этих задач.
Значение TID=0 всегда имеет системная задача RAC. При удалении и динамическом создании задач
значения их TID изменяются. При сложной логике динамического создания и удаления задач эти
изменения трудно предсказуемы, по крайней мере из внешней программной среды.
Для идентификации задачи при ее взаимодействии с внешней программной средой
используется функциональный идентификатор (FID - Function IDentifer), определяющий функцию
(прикладное назначение) задачи и выражаемый целым числом из диапазона 1...255. FID задается в
ITD задачи и не меняется при ее удалении и последующем динамическом создании. Значение FID=1
зарезервировано для системной задачи RAC. При создании задач система следит за тем, чтобы
разные задачи имели несовпадающие FID: если задача с некоторым FID уже существует, новая
задача с таким же FID не создается.
Соответствие TID и FID задач, существующих в данный момент времени, прикладные задачи
могут выяснить с помощью системного вызова GET_FUNCTION_IDS.
3.5.6. Начальный дескриптор данных (IDD)
Конфигурирование системы возможно только при ее начальной инициализации и предполагает
наличие в памяти программ специальной структуры данных - начального дескриптора (описателя)
данных (IDD - Initial Data Descriptor). Структура IDD в целом соответствует структуре начального
дескриптора задач ITD. Все IDD должны быть встроены в цепь начальных дескрипторов, которая
просматривается во время начальной инициализации, т.е. заранее размещены в памяти программ в
виде цепочечной структуры, образуемой последовательными ссылками каждого ITD/IDD (кроме
последнего) на следующий. Первый дескриптор в цепи должен располагаться по адресу 8010h, а
остальные могут располагаться по произвольным адресам, большим, чем 8010h. Порядок просмотра
IDD определяется порядком их следования в цепочке последовательных ссылок. IDD имеет
следующую структуру:
Номер байта
Назначение
0...1
Ключ
2...3
0
4...5
Единица системного времени
6
Резерв
7
Длина системного буфера
8
Размер резервируемой памяти
9...10
Ссылка на следующий ITD/IDD
Рассмотрим смысл и назначение элементов IDD.
Ключ - двухбайтовый код, равный 0AA55h и являющийся признаком структуры ITD/IDD.
Назначение этого поля аналогично одноименному полю в ITD.
0 - Ноль в этом поле структуры позволяет системе отличить ее от
ITD и идентифицировать как IDD.
Единица системного времени - двухбайтовая величина, которая задает новое значение системной
переменной CLOCK_UNIT.
Резерв - байт, зарезервированный для совместимости с iDCX51. Должен всегда содержать 0.
Длина системного буфера - байтовая величина, которая задает новое значение системной
переменной BUF_SIZE. BUF_SIZE определяет длину блока внутренней памяти данных,
выделяемого и освобождаемого системными вызовами ALLOCATE и DEALLOCATE.
Размер резервируемой памяти - байтовая величина, задающая длину блока во внутренней памяти
данных, которое резервируется для использования в прикладных задачах. Резервируется блок
памяти, начиная с адреса 40h.
Ссылка на следующий ITD/IDD - двухбайтовая величина смещения начала следующего начального
дескриптора (ITD или IDD) в цепочке. Назначение этого поля аналогично одноименному полю в
ITD.
3.5.7. Требования, предъявляемые к прикладной задаче
Аппаратура контроллера не обеспечивает защиты ресурсов системы от некорректного
использования, поэтому алгоритм работы прикладных задач должен удовлетворять определенным
требованиям. Несоблюдение этих требований влечет за собой ухудшение характеристик системы
или нарушение ее правильной работы вплоть до полного отказа. Прикладная задача должна
разрабатываться так, чтобы выполнялись следующие условия:
Разрешается использовать только те области памяти данных
(внутренней и внешней) и памяти программ, которые описаны
в настоящем документе как предназначенные для прикладных задач.
Не следует модифицировать системные переменные, предназначенные только для чтения.
Прикладные задачи не должны производить запись или чтение
в области ввода-вывода (адреса 1000h...3FFFh в пространстве внешней памяти данных);
Для работы с устройствами ввода-вывода следует использовать соответствующие системные
вызовы.
Не следует модифицировать значения регистров специального назначения P0, TL0, TH0, IP, IPN1,
PCON. Нельзя изменять значения следующих битов в регистрах специального назначения: P1.0-2,
TCON.4-5, TMOD.0-3 и битов выбора банка рабочих регистров RS0 и RS1 в PSW.
Когда прикладной задаче требуется обеспечить целостность данных, доступных другим задачам,
проще всего запретить все прерывания путем обнуления бита EA (бит IE.7, битовый адрес 0AFh).
Однако не следует держать прерывания запрещенными дольше, чем это минимально необходимо,
т.к. во-первых, ухудшается время реакции системы на события "прерывание" на то время, пока
прерывания запрещены, а во-вторых, запрещение прерываний более чем на величину системного
тика (по умолчанию 1 мс) может привести к сбою в отсчете системного времени и/или привести к
потере кадров в сети Bitbus. Аппаратные прерывания индивидуально от какого-либо источника
следует запрещать и разрешать только путем обращения к системным вызовам DISABLE_INT и
ENABLE_INT.
3.6. Сообщения
3.6.1. Прием и передача сообщений
Выполняемые в системе прикладные задачи могут обмениваться информацией между собой.
Кроме того, используя в качестве посредника системную задачу RAC, прикладные задачи могут
обмениваться информацией с внешней программной средой через последовательный канал Bitbus и
канал связи с устройством расширения (если таковое имеется). Обмен информацией происходит
путем передачи и приема сообщений. Передача сообщения любой прикладной задачей, а также
завершение приема сообщения по последовательному каналу или от устройства расширения задачей
RAC, рассматриваются как событие типа "сообщение". Прием сообщения прикладными задачами
производится при ожидании этого события с помощью системного вызова WAIT.
Передача любого сообщения прикладной задачей производится путем обращения к
системному вызову SEND_MESSAGE. Перед этим обращением сообщение должно быть
сформировано во внутренней или внешней памяти данных.
Структура сообщения ориентирована на использование дисциплины обмена "запрос-ответ".
Эта дисциплина предусматривает наличие двух участников обмена (широковещания нет). Эти два
участника обмена (задачи и/или внешние программы) называются "источником" и "приемником".
Единичный акт обмена складывается из двух этапов: передачи сообщения-запроса от источника к
приемнику и последующей передачи сообщения-ответа от приемника к источнику. Таким образом,
каждый акт обмена начинается по инициативе источника. Сообщениезапрос может иметь смысл
запроса данных, содержать инициативно передаваемые данные или команду. Сообщение-ответ при
этом может, соответственно, содержать запрошенные данные, иметь смысл подтверждения
получения переданных данных или приема (исполнения) команды.
Перед формированием сообщения-запроса во внутренней памяти данных прикладная задача
должна, обратившись к системному вызову ALLOCATE, получить свободный блок этой памяти
(длина выделяемого блока определяется системной переменной BUF_SIZE из расчета сообщения
максимально допустимой длины). Возврат блока памяти производится после приема и
использования сообщения любой задачей с помощью системного вызова DEALLOCATE. При
обмене сообщениями с внешней программной средой получение и возврат блоков памяти
осуществляется системной задачей RAC. Для формирования сообщенийответов рекомендуется
использовать область памяти, в которой размещается соответствующее сообщение-запрос.
3.6.2. Внешняя программная среда
Аппаратура, на которой функционирует описываемое системное программное обеспечение,
позволяет использовать ее как элемент распределенной системы управления, информационно
объединенной локальной сетью, построенной на основе интерфейса Bitbus. Интерфейс Bitbus
базируется на иерархическом принципе взаимодействия и предполагает наличие в сети одного
ведущего устройства и до 250 ведомых устройств, объединенных последовательным каналом связи.
И ведущее, и все ведомые устройства называются узлами сети. Каждому узлу соответствует
уникальное число в диапазоне 1...250, называемое адресом узла. В каждом узле сети предполагается
наличие программной среды. Эта программная среда при рассмотрении взаимодействия узлов
локальной сети называется локальной средой данного узла.
Любой узел сети может иметь устройство расширения, связанное с этим узлом произвольным
интерфейсом, обеспечивающим, однако, обмен сообщениями между задачами, выполняющимися в
локальной среде данного узла, и участниками обмена со стороны устройства расширения.
Обмен сообщениями по сети Bitbus соответствует дисциплине обмена "запрос-ответ", причем
источником сообщений-запросов, передаваемых по сети, всегда является задача, выполняющаяся в
локальной среде ведущего устройства, или программа, выполняемая на устройстве его расширения,
а приемником - задача, выполняющаяся в локальной среде ведомого устройства или на его
устройстве расширения.
3.6.3. Структура сообщения
Сообщение включает 7 байтов служебной информации (заголовок) плюс информационные
данные, объем и смысл которых определяется прикладной задачей. Суммарная длина сообщения не
должна превосходить 254 байта. Ниже приводится структура сообщения.
Номер байта
Назначение
0...1
Связь
2
Длина сообщения
3
Флаги
4
Адрес узла
5
Источник / приемник
6
Команда / ответ
7...
Информационные байты
Отдельные поля сообщения имеют следующее назначение:
Связь - двухбайтовое поле, используемое системой.
Длина сообщения - число, равное суммарному количеству байтов в сообщении, включая заголовок.
Флаги - управляющие биты:
7-й бит (TY) - тип сообщения (TYpe). Этот разряд определяет,
запросом или ответом
является передаваемое
сообщение. Если TY=0, сообщение считается
запросом и адресат сообщения определяется
полем "приемник", если TY=1, сообщение
считается ответом и адресат сообщения
определяется полем "источник".
6-й бит (SE) - признак источника-расширения. При SE=1
считается, что источник
сообщения находится
на устройстве расширения. При SE=0 источником
считается задача локальной среды какого-либо
узла сети.
5-й бит (DE) - признак приемника-расширения. При DE=1
считается, что приемник
сообщения находится
на устройстве расширения. При DE=0 приемником
считается задача локальной среды какого-либо
узла сети.
4-й бит (TR) - след. Этот разряд используется системными
программами и должен быть
установлен прикладной
задачей в ноль перед передачей сообщения-запроса.
Адрес узла - параметр, который должен иметь различные значения в зависимости от того, откуда
передается и где принимается сообщение. При обмене в рамках локальной среды этот параметр
должен быть равен нулю. Для сообщений, передаваемых только через интерфейс устройства
расширения, этот параметр должен быть равен 255 (0FFh). Для сообщения, передаваемого по
локальной сети (и, быть может, через интерфейсы устройств расширения узлов), этот параметр
должен быть равен адресу узла ведомого устройства.
Источник (7-4 биты) - текущий идентификатор (TID) источника, если источник - задача системы.
При передаче сообщения-ответа определяет адресата. Если источник находится на устройстве
расширения, этот параметр не используется системными программами, но передается без
изменения, благодаря чему может использоваться для идентификации программ на устройстве
расширения.
Приемник (3-0 биты)- текущий идентификатор (TID) приемника. При передаче сообщения-запроса
определяет адресата. Если приемник находится на устройстве расширения, этот параметр не
используется системными программами, но передается без изменения, благодаря чему может
использоваться для идентификации программ на устройстве расширения.
Команда/ответ - поле, которое может использоваться для размещения кодов, функционально
идентифицирующих сообщения, т.е. определяющих их прикладное назначение (обычно кода
запроса и статуса ответа). Для сообщений системной задачи RAC этот параметр уже определен. При
системных ошибках пересылки сообщения это поле сообщения-ответа содержит код ошибки.
Информационные данные - поле, используемое прикладной задачей для размещения передаваемых
данных.
3.7. Системные переменные
Системные переменные - это переменные, доступные прикладным задачам для получения
системной информации, и, в отдельных случаях, для модификации. Все системные переменные
размещены во внутренней прямоадресуемой памяти данных. К их числу относятся: текущий
идентификатор работающей задачи - TASK_ID, приоритет работающей задачи - TASK_PRIORITY,
единица системного времени (тик) - CLOCK_UNIT и размер системного буфера - BUF_SIZE.
3.7.1. Текущий идентификатор работающей задачи TASK_ID
TASK_ID - это байтовая системная переменная, значение которой равно текущему
идентификатору (TID) работающей в данный момент задачи (от 0 до 7). Эта переменная
размещается во внутренней памяти данных процессора по адресу 30h (сегмент DATA). Чтение ее
значения может потребоваться при заполнении поля "источник" в передаваемом сообщении.
3.7.2. Приоритет работающей задачи TASK_PRIORITY
TASK_PRIORITY - это байтовая системная переменная, значение которой равно приоритету
работающей в данный момент задачи (от 0 до 7). Эта переменная размещается во внутренней
памяти данных процессора по адресу 31h (сегмент DATA). Прикладной задаче, как правило, свой
приоритет известен, и читать значение этой системной переменной нет необходимости.
3.7.3. Единица системного времени CLOCK_UNIT
CLOCK_UNIT - это двухбайтовая системная переменная, значение которой определяет
единицу времени системных часов (тик). Величина, дополняющая значение CLOCK_UNIT до нуля,
равна количеству циклов таймера/счетчика 0, которое соответствует одному тику. Цикл таймера/
счетчика 0 при тактовой частоте 24 МГц составляет 0,5 мкс. Например, значение CLOCK_UNIT=2000 (07D0h) соответствует тику, равному 1 миллисекундe. Во время инициализации этой
переменной по умолчанию присваивается значение, соответствующее тику в 1 миллисекунду.
Используя начальный дескриптор данных (IDD) ей можно присвоить другое начальное значение.
Переменная CLOCK_UNIT размещается во внутренней памяти данных процессора: старший байт по адресу 32h, младший - по адресу 33h (сегмент DATA).
Прикладная программа может изменять величину тика путем записи нового значения
CLOCK_UNIT. При этом надо иметь в виду, что переменная CLOCK_UNIT - разделяемый ресурс, и
запрещать прерывания на время ее модификации.
3.7.4. Размер системного буфера BUF_SIZE
BUF_SIZE - это байтовая системная переменная, значение которой равно длине блока
внутренней памяти, выделяемого и освобождаемого системными вызовами ALLOCATE и
DEALLOCATE. Значение BUF_SIZE может находится в пределах от 8 до 254 и должно быть
четным числом. При инициализации этой переменной по умолчанию присваивается значение 20,
соответствующее максимальной длине стандартного сообщения Bitbus. Используя начальный
дескриптор данных (IDD), ей можно присвоить другое начальное значение.
Переменная BUF_SIZE размещается во внутренней памяти данных процессора по адресу 34h
(сегмент DATA). Чтение ее значения может потребоваться при заполнении передаваемого
сообщения.
3.8. Системные ресурсы
3.8.1. Память, доступная прикладным задачам
Во внутренней памяти данных прикладные задачи могут использовать:
- Назначенный им банк рабочих регистров R0...R7. Следует учитывать, что системные вызовы
изменяют содержимое регистров A, B, DPTR, R0, R1, R6, R7 и всех битов PSW, кроме RS0 и RS1, а
регистры R2, R3, R4 и R5 могут использоваться совместно несколькими задачами, имеющими
одинаковый приоритет.
- Пространство, выделенное под стек во время создания задачи.
- Блоки памяти, выделенные путем обращения к системным вызовам
ALLOCATE и GET_MEM.
- Пространство, зарезервированное с помощью начального дескриптора данных (IDD) во время
начальной инициализации.
- Один байт во внутренней памяти с битовой адресацией: адрес байта 20h, адреса битов 00h...07h.
Прикладные задачи, их начальные дескрипторы (ITD) и начальные дескрипторы данных (IDD)
могут располагаться в памяти программ по произвольным адресам внутри диапазона
8010h...0FFFFh.
В пространстве внешней памяти данных прикладным задачам доступна память в диапазоне
адресов 400h...7FFh.
3.8.2. Другие ресурсы, доступные прикладным задачам
Прикладные задачи могут использовать таймер-счетчик 1, таймер-счетчик 2, локальный
последовательный канал (UART), а также обрабатывать события, связанные с внешними запросами
прерываний 0 и 1.
3.8.3. Реактивность системы. Время переключения задач
Ниже приводятся времена, которые система затрачивает на выполнения некоторых операций.
Время обработки прерывания от таймера
0 (системных часов).
72...861 мксек
Переключение задач. Прерывание не от
таймера 0 (приоритет ожидающей его
задачи выше, чем у работающей).
140...300 мксек
Переключение задач. Работающая задача
создает с помощью CREATE_TASK задачу с
приоритетом выше, чем свой.
973... мксек
Переключение задач. Работающая задача
обращается к DELETE_TASK и удаляет
себя.
815... мксек
Выделение буфера системным вызовом
ALLOCATE.
31...51 мксек
Освобождение буфера системным вызовом
DEALLOCATE.
14...29 мксек
Выделение блока памяти системным
вызовом GET_MEM.
15...51 мксек
Освобождение блока памяти системным
вызовом RELEASE_MEM.
18...32 мксек
Выполнение системного вызова WAIT.
Ожидаемые события уже наступили.
45...132 мксек
3.9. Системные вызовы
Обращение к системным вызовам осуществляется с помощью команды LCALL языка
Ассемблер-51 с указанием абсолютного адреса конкретного системного вызова. Необходимо, чтобы
перед обращением к системным вызовам (перед выполнением LCALL) в СТЕКЕ было свободно НЕ
МЕНЕЕ 4 байт. Большинство системных вызовов предполагает задание перед обращением к ним
входных параметров и возвращает выходные параметры. Входные и выходные параметры
передаются в регистрах процессора. Ниже приведен перечень системных вызовов.
CREATE_TASK Адрес
DELETE_TASK
GET_FUNCTION_IDS
DISABLE_INT
ENABLE_INT
SEND_MESSAGE
SET_INTERVAL
WAIT
ALLOCATE
DEALLOCATE
GET_MEM
RELEASE_MEM
SYS_INFO
WATCHDOG_RST
0083h
0086h
0089h
008Ch
008Fh
0092h
0095h
0098h
009Bh
009Eh
00A1h
00A4h
00ADh
00B0h
WATCHDOG_OS
WATCHDOG_USER
D_MODE
D_INP
D_OUT
00B3h
00B6h
00C0h
00C3h
00C6h
3.9.1. Соглашения по использованию регистров
Системные вызовы изменяют содержимое регистров A, B,
DPTR, R0, R1, R6, R7 и всех битов слова состояния PSW, кроме битов RS0 и RS1 выбора банка
рабочих регистров.
Регистры R2, R3, R4 и R5 системными вызовами не используются, однако эти регистры могут
использоваться совместно несколькими задачами, имеющими одинаковый приоритет.
Регистры A, B и DPTR используются некоторыми системными вызовами для передачи
параметров, а регистры A, DPTR, R6 и R7 - для возврата результата. Все системные вызовы могут
устанавливать в 1 бит разрешения прерываний EA (бит IE.7, битовый адрес 0AFh) перед возвратом
управления в вызвавшую их задачу.
3.9.2. Ожидание событий WAIT
Системный вызов WAIT переводит обратившуюся к нему задачу в состояние ожидания
события из числа указываемых: "интервал", "прерывание" или "сообщение". Ожидание длится до
наступления любого из указанных событий или до истечения заданного времени ожидания
(таймаута). Если к моменту обращения к WAIT хотя бы одно из указанных событий уже произошло,
то WAIT немедленно возвращает управление вызвавшей его задаче.
Входные параметры:
EVENT_VECTOR - байтовая величина, указывающая события, которые ожидает задача. Параметр
передается в регистре A и имеет следующий формат:
xxxxxABC
ABC - разряды, в которых указываются типы ожидаемых событий. Значение "1" указывает на то,
что ожидается соответствующее событие. В состоянии ожидания могут находиться следующие
события: A - интервал; B - прерывание; C - сообщение.
TIMEOUT - однобайтовое значение из диапазона 0...255, определяющее количество единиц
системного времени (тиков), в течении которого задача будет ожидать указанные события. Этот
параметр передается через регистр B. При значении TIMEOUT=0 задача не переходит в состояние
ожидания, и системный вызов WAIT предполагает, что задача "дождалась" события, только если это
событие произошло до момента обращения к WAIT. Значение TIMEOUT=255 (0FFh) определяет
бесконечное время ожидания.
Выходные параметры:
STATUS - байтовая величина, указывающая причину окончания ожидания. Параметр возвращается
в регистре A, он имеет нулевое значение в случае таймаута (ни одно из событий не произошло) или
значение в формате:
YYYYxABC
где - ABC - разряды, в которых указываются типы произошедших событий. YYYY - полубайтовое
значение, определяющее номер источника прерывания, которое произошло последним, если
наступило событие типа "прерывание". Ниже приводятся номера источников прерывания.
0
1
2
3
внешний запрос прерывания 0
таймер 0 - отсчет реального времени
внешний запрос прерывания 1
таймер-счетчик 1
4
5
6
8
9
10
контроллер локального последовательного канала (UART)
контроллер канала Bitbus - успешный прием
контроллер канала Bitbus - ошибка приема
контроллер канала Bitbus - успешная передача
контроллер канала Bitbus - ошибка передачи
таймер-счетчик 2
MESSAGE_PTR - двухбайтовый адрес принятого сообщения.
Этот параметр определен, если в параметре STATUS указано,
что произошло событие типа "сообщение". Параметр возвращается
в регистрах R6 и R7: старший байт - в R6, младший - в R7.
Если значение параметра меньше 256 (R6 = 0), сообщение располагается во внутренней памяти
данных (сегмент IDATA).
Если значение параметра равно или больше 256 (R6 > 0),
сообщение располагается во внешней памяти данных (сегмент XDATA).
3.9.3. Передача сообщения SEND_MESSAGE
Системный вызов SEND_MESSAGE передает сообщение от вызывающей его задачи. Адресат
и другие характеристики сообщения указываются в заголовке сообщения.
Задача-адресат определяется следующим образом. Если к системному вызову
SEND_MESSAGE обратилась задача с TID, равным 0, или если сообщение (запрос или ответ)
посылается в пределах локальной среды ("адрес узла" = 0), то TID задачи-адресата берется из поля
"источник" или "приемник" в соответствии с тем, является сообщение запросом или ответом. В
противном случае TID задачи-адресата принимается равным 0.
Если TID задачи-адресата больше максимального допустимого в системе, сообщение теряется.
Если задачи с указанным TID в данный момент в системе нет, то сообщение все равно ставится в
очередь и может быть получено, если какая-либо вновь созданная задача будет иметь
соответствующий TID. Если задача-адресат ожидает событие "сообщение", она переводится в
состояние "готовность". Если при этом приоритет задачи-адресата выше приоритета задачи,
обратившейся к SEND_MESSAGE, то последняя переводится в состояние "готовность", а задачаадресат становится работающей.
Входной параметр: MESSAGE_PTR - начальный адрес передаваемого сообщения (адрес
первого байта поля "связь"). Параметр передается в регистре DPTR. Если значение адреса меньше
256 (DPH = 0), то предполагается, что сообщение размещено во внутренней памяти данных (сегмент
IDATA). Если значение адреса равно или больше 256 (DPH > 0), то предполагается, что сообщение
размещено во внешней памяти данных (сегмент XDATA).
3.9.4. Определение события "интервал" SET_INTERVAL
Системный вызов SET_INTERVAL определяет для обращающейся к нему задачи событие типа
"интервал". Если для данной задачи уже было определено событие этого типа, старое событие
отменяется.
Входной параметр: INTERVAL - однобайтовое значение, определяющее период (в единицах
системного времени - тиках), с которым будет происходить событие типа "интервал". Значение
INTERVAL=0 отменяет ранее определенное событие для данной задачи. Параметр передается через
регистр A.
3.9.5. Запрещение и разрешение прерываний
Системный вызов DISABLE_INT запрещает аппаратное прерывание от указанного источника
до тех пор, пока системный вызов ENABLE_INT снова не разрешит его. Прерывание запрещается в
момент возврата из этого системного вызова одновременно для всех задач, существующих в
системе.
Входной параметр: INT_NUMBER - однобайтовое значение из диапазона 0...10, указывающае
источник того прерывания, которое необходимо запретить. Параметр передается через регистр A.
Номера прерываний и соответствующие им источники прерываний описаны выше.
Системный вызов ENABLE_INT разрешает прерывание, которое
было до этого запрещено при помощи системного вызова DISABLE_INT.
В прикладной задаче не следует пытаться разрешить прерывание, которое не было ранее запрещено
системным вызовом DISABLE_INT.
Входной параметр: INT_NUMBER - однобайтовое значение из диапазона 0...10, указывающее
источник того прерывания, которое необходимо разрешить. Параметр передается через регистр A.
3.9.6. Динамическое создание и удаление задач CREATE_TASK и
DELETE_TASK.
Системный вызов CREATE_TASK создает новую прикладную задачу с характеристиками,
указанными в ее начальном дескрипторе (ITD). Создается одна задача независимо от значения поля
"ссылка на следующий ITD" в начальном дескрипторе. Если приоритет новой задачи выше
приоритета работающей, то последняя переводится в состояние "готовность", а новая становится
работающей. В противном случае новая задача попадает в состояние "готовность".
Входной параметр: ITD_PTR - адрес начального дескриптора создаваемой задачи. Параметр
передается в регистре DPTR.
Выходной параметр: STATUS_TID - текущий идентификатор (TID) созданной задачи или код
неудачного завершения системного вызова. Параметр возвращается в регистре A. Ниже приведены
возможные значения выходного параметра.
0...7 - текущий идентификатор (TID) созданной
E_MAX_TASKS
E_REGS
E_FID
E_STACK
E_ITD
задачи
81h - задача не создана, т.к. уже существует
8 задач
82h - задача не создана, т.к. запрошенный
банк регистров уже занят
83h - задача не создана, т.к. задан FID=0
или задача с указанным FID < 255 уже
существует
84h - задача не создана, т.к. нет блока
внутренней памяти данных для стека
86h - задача не создана, т.к. не опознан
ключ ITD или дескриптор является IDD
Системный вызов DELETE_TASK удаляет указанную задачу и запрещает все прерывания,
связанные с этой задачей.
Входной параметр: TASK_ID - текущий идентификатор (TID) задачи, которую нужно удалить.
Допустимые значения 0...7 (включительно). Параметр передается в регистре A.
Выходной параметр: STATUS - однобайтовое значение, определяющее результат завершения
системного вызова. Возвращается в регистре A. Ниже приведены возможные значения выходного
параметра.
E_OK
0
- задача удалена
E_EXIST
80h - задача не удалена, т.к. задачи
с указанным TID не существует
3.9.7. Получение и возврат системного буфера
ALLOCATE и DEALLOCATE
Системный вызов ALLOCATE выделяет один блок внутренней памяти данных (сегмент
IDATA) для обращающейся к нему задачи. Размер выделяемого блока определяется системной
переменной BUF_SIZE и по умолчанию равен 20 байтам.
Выходной параметр: BUFFER_LOCATION - однобайтовое значение, равное адресу первого
байта выделенного блока памяти. Параметр передается в регистре A. Если свободного блока памяти
достаточного размера в данный момент нет, то возвращается значение "0".
Системный вызов DEALLOCATE возвращает один блок внутренней памяти данных, ранее
выделенный системным вызовом ALLOCATE, обратно в систему, т.е. делает его доступным для
нового использования другими задачами.
Входной параметр: BUFFER_LOCATION - однобайтовое значение, равное адресу первого
байта возвращаемого блока памяти. Параметр передается в регистре A.
3.9.8. Получение и возврат блока памяти
GET_MEM и RELEASE_MEM
Системный вызов GET_MEM выделяет один блок внутренней памяти данных (сегмент
IDATA) для обращающейся к нему задачи.
Входной параметр: BUFFER_LENGTH - однобайтовое значение, равное длине запрашиваемого
блока. Параметр передается в регистре A.
Выходной параметр: BUFFER_LOCATION - однобайтовое значение, равное адресу первого
байта выделенного блока памяти. Параметр передается в регистре A. Если свободного блока памяти
достаточного размера в данный момент нет, или если входной параметр равен 0, то возвращается
значение 0.
Системный вызов RELEASE_MEM возвращает один блок внутренней памяти данных, ранее
выделенный системным вызовом GET_MEM или зарезервированный во время начальной
инициализации, обратно в систему, т.е. делает его доступным для нового использования другими
задачами.
Входные параметры:
BUFFER_LOCATION - однобайтовое значение, равное адресу первого байта возвращаемого блока
памяти. Параметр передается в регистре A. Если этот параметр равен 0, не делается ничего.
BUFFER_LENGTH - однобайтовое значение, равное длине возвращаемого блока. Параметр
передается в регистре B.
3.9.9. Соответствие TID и FID задач GET_FUNCTION_IDS
Системный вызов GET_FUNCTION_IDS заполняет таблицу, определяющую соответствие
функциональных (FID) и текущих (TID) идентификаторов задач, существующих в данный момент
системе.
Входной параметр: FID_TBL_PTR - указатель на 8-байтовую область внутренней или внешней
памяти данных, где будет размещена таблица функциональных идентификаторов. Параметр
передается в регистре DPTR. Если указывается значение, меньшее 256 (DPH = 0), таблица
размещается во внутренней памяти данных (сегмент IDATA). При указании значения, равного или
большего 256 (DPH > 0), таблица размещается во внешней памяти данных (сегмент XDATA).
3.9.10. Получение информации о системе SYS_INFO
Системный вызов SYS_INFO позволяет задаче получить информацию о той среде, в которой
эта задача выполняется. Прикладная задача может обратиться к этому системному вызову, чтобы
удостовериться, что она запущена именно в среде OS_MBB.
Выходные параметры:
VERSION_ID - однобайтовое значение, содержащее идентификатор системы и номер версии ее
системного ПО. Параметр передается в регистре A в следующем формате:
SSSSVVVV
где SSSS - полубайтовое значение, определяющее тип системы; VVVV - полубайтовое значение,
определяющее номер версии
системного ПО;
SYS_NAME - двухбайтовый адрес массива из 8 байт,
размещенного в памяти программ
(сегмент CODE).
Этот массив содержит в виде символов ASCII
название системы и номер версии ее ПО.
Параметр
передается в регистре DPTR.
4. Задача дистанционного доступа и управления RAC
4.1. Введение
Задача дистанционного доступа и управления RAC (Remote Access and Control) осуществляет
информационный обмен в системах, объединенных в локальную сеть Bitbus, а также выполняет
функции дистанционного управления аппаратнопрограммными средствами узлов (станций) в этой
сети.
Система, построенная на основе локальной сети Bitbus, должна включать одну ведущую
станцию, связанную через высокоскоростную последовательную магистраль с одной или
несколькими (до 250) подчиненными (ведомыми) станциями.
4.2. Локальная сеть Bitbus
4.2.1. Логическая модель Bitbus
Интерфейс Bitbus представляет собой быстродействующую последовательную магистраль,
предназначенную для построения иерархических систем. Назначением промышленной сети Bitbus
является обеспечение обмена сообщениями между задачами в ведущем узле и задачами в
нескольких подчиненных узлах. Задачи в ведущем узле передают команды (сообщения-запросы)
задачам в подчиненных узлах, а те, в свою очередь, возвращают сообщения-ответы. Этот уровень
программно-аппаратного обеспечения обмена скрывает от прикладных программ последовательный
принцип передачи информации по сети.
Ведущее устройство управляет всеми операциями сети Bitbus. Оно инициирует операцию
обмена посылкой ведомому устройству сообщения-запроса, содержащего команду. Затем оно
опрашивает ведомое устройство до тех пор, пока не получит ответное сообщение. При нормальной
работе сети каждая посылка от ведущего устройства подтверждается адресуемым подчиненным
устройством. Если в данный момент времени ответ не готов, подчиненным устройством передается
только сообщение-квиток, подтверждающее связь. Это освобождает ведущее устройство для
выполнения других операций, например, посылки другого сообщения или опроса другого
подчиненного устройства.
Ведомое устройство в сети Bitbus является отвечающим. В одной системе может быть до 250
ведомых устройств с адресами из диапазона
1...250. Ведомое устройство само не может инициировать передачу,
оно может только реагировать ответами на команды ведущего устройства.
Устройство расширения (расширитель) является дополнительным процессором узла.
Использование расширителей позволяет реализовать мосты между несколькими системами с
интерфейсом Bitbus или шлюзы с другими системами.
4.2.2. Протокол транспортного уровня
Несмотря на то, что от прикладного программиста не требуется управление сетью Bitbus на
транспортном уровне, приводимые сведения по работе канала данных способствуют пониманию
логики работы сети и построению эффективных прикладных систем. Данная глава не является
полным описанием сети Bitbus, а призвана дать общее представление о работе сети.
Основанный на протоколе SDLC (Synchronous Data Link Control,
IBM), протокол канала данных сети Bitbus объединяет одно ведущее устройство с несколькими
ведомыми в общей магистральной структуре. Задача протокола канала данных заключается в
представлении сообщений в виде кадров и управлении передачей кадров по каналу данных.
4.2.3. Состояния устройств сети. Работа канала данных
Управление работой сети Bitbus осуществляет ведущее устройство сети. Ведущее устройство
хранит сведения о состоянии каждого ведомого после последнего акта обмена кадрами. Они
используется и контролируется ведущим устройством при каждой передаче. Состояние ведомого
может измениться в результате локального перезапуска, отключения питания и т.п. В случае
некорректного состояния предпринимаются соответствующие восстановительные действия.
Понятие состояния ведомого устройства включает его режим и значения счетчиков кадров.
Ведомое устройство всегда находится в одном из двух режимов: в нормально разъединенном
режиме (НРР) или в нормально ответном режиме (НОР). Ведомое устройство переходит в НРР
после включения питания, локального перезапуска, или когда обнаруживается неисправимая
ошибка протокола. Ведомое устройство переходит в НОР после специальной команды от ведущего
устройства. После входа в НОР все счетчики кадров обнуляются и ведомое устройство считается
синхронизированным с ведущим. В этом режиме ведомое устройство может обмениваться
сообщениями с ведущим до тех пор, пока поддерживается синхронизация, т.е. поддерживается
корректное соотношение счетчиков принятых и посланных кадров.
Счетчики кадров используются ведущим и каждым из ведомых устройств для гарантии того,
что кадры не теряются и не дублируются. Ведущее устройство поддерживает счетчик принятых
кадров (NR) и счетчик переданных кадров (NS) для каждого ведомого устройства, с которым
осуществляется связь. При каждой передаче эти числа включаются в кадр и проверяются. В случае
невосстановимого рассогласования ведущее устройство проводит повторную синхронизацию
ведомого путем перевода его в состояние НРР с последующим переводом в НОР.
Различаются ненумерованные, супервизорные и информационные кадры.
Ненумерованные кадры используются в сети Bitbus для синхронизации ведомых устройств с
ведущим.
Супервизорные кадры используются для обмена информацией между ведущим и ведомым
устройствами в состоянии НОР в отсутствии информационных кадров. Имеется два супервизорных
кадра: приемник готов RR и приемник не готов RNR. Ведущее устройство использует кадр RR для
опроса ведомого устройства о наличии информационного кадра. Ведомое устройство использует
супервизорный кадр RR для подтверждения успешного приема (совпадение адреса, правильная
контрольная сумма, наличие свободного буфера) предыдущего кадра, если информационное
сообщение не готово. Если сообщение готово, то в качестве подтверждения посылается
информационный кадр.
Супервизорный кадр RNR используется, когда для приема очередного кадра (адрес и
контрольная сумма которого правильны) в передающем устройстве нет свободного буфера. При
получении RNR ведущее устройство должно повторить посылку кадра, а ведомое - не отвечать
информационным.
Информационные кадры являются обобщением супервизорных кадров; они содержат данные
сообщения сети Bitbus в информационном поле.
Типичная последовательность обмена кадрами, обеспечивающая передачу сообщения-запроса
от ведущего устройства и сообщенияответа от ведомого, находящегося в НОР, выглядит
следующим образом:
a) Передается от ведущего устройства к подчиненному супервизорный кадр (RR), опрашивающий
готовность подчиненного устройства.
b) Передается от подчиненного устройства к ведущему супервизорный кадр (RR/RNR),
подтверждающий или не подтверждающий готовность подчиненного утройства к приему
информационного кадра. Если подчиненное устройство не готово к приему информационного
кадра, оно передает кадр RNR. Ведущее устройство начинает периодически в течении
определенного времени опрашивать подчиненное устройство и делает это до тех пор, пока
подчиненное устройство не будет готово к приему сообщения.
c) Передается от ведущего устройства к подчиненному информационный кадр.
d) Передается от подчиненного устройства к ведущему супервизорный кадр(RR/RNR),
подтверждающий прием информационного кадра и сообщающий о готовности или неготовности
ответных данных. Если информационный кадр принят подчиненным устройством, на ведущем
устройстве данные сообщения-запроса теряются (уничтожаются).
e) После того как сообщение-запрос передано подчиненному устройству, ведущее начинает опрос
подчиненного, посылая ему супервизорные кадры RR. Ведущее устройство хранит номера всех
подчиненных устройств, для которых количество отправленных информационных кадров больше
количества принятых, в специальном списке, называемом таблицей полинга.
f) Если на подчиненном устройстве сообщение-ответ не готово,
оно посылает супервизорный кадр (RNR) в ответ на запрос ведущего.
Когда сообщение-ответ будет готово, подчиненное устройство в ответ на очередной запрос передает
информационный кадр.
i) На этом процедура передачи сообщения-запроса и приема сообщенияответа заканчиваются. Если
количество отправленных данному подчиненному устройству информационных кадров равно
количеству принятых, ведущее устройство исключает его из таблицы полинга.
Можно легко подсчитать, что для передачи единичного сообщениязапроса и получения
сообщения-ответа по линии связи передается не менее 4 кадров (две пары кадров).
При передаче кадров по линии связи возможна их потеря (например, из-за значительного
уровня помех). В этом случае ведущее устройство осуществляет повторную передачу того кадра, на
который в течении 20 мс не получен ответный кадр от подчиненного устройства. Два потерянных
кадра подряд считаются ошибкой протокола Bitbus, после которой подчиненное устройство
переводится в НРР.
Протокол Bitbus допускает случай, при котором на сообщениезапрос будет вообще не
получено сообщение-ответ. Это достаточно маловероятно и происходит тогда, когда после
успешной передачи информационного кадра с сообщением-запросом ведущим устройством и
получения от починенного подтверждения приема этого кадра, ведущее уничтожает данные
сообщения-запроса, после чего связь с подчиненным теряется (например, в результате выключения
питания), или оно переходит в НРР (например, в результате локального перезапуска). Ведущее
устройство обнаруживает разрыв связи, но не может сформировать сообщение-ответ со статусом
доставки PROTOCOL_ERROR, т.к. неизвестно, куда его отправить, ибо данные сообщения-запроса
уже потеряны. Чтобы предотвратить блокирование прикладной задачи из-за описанного выше
исчезновения сообщения, ожидать сообщение-ответ следует с конечным таймаутом, по истечении
которого можно считать, что была обнаружена ошибка PROTOCOL_ERROR.
4.3. Среда функционирования задачи RAC
Задача RAC функционирует в среде операционной системы реального времени OS_MBB.
Начальный дескриптор ITD задачи RAC размещается в памяти программ. Задача RAC всегда имеет
текущий идентификатор TID=0. Элементы ITD задачи RAC имеют следующие значения:
- размер стека - 16 байт;
- функциональный идентификатор - 1;
- банк регистров - 0;
- приоритет - 4;
- адрес следующего ITD/IDD - 8010h.
4.4. Описание работы задачи RAC
4.4.1. Функции (команды) задачи RAC
Задача RAC принимает запросы от сети BITBUS или от прикладных задач, выполняющихся в
системе, и формирует соответствующие ответы.
4.4.2. Обработка сообщений
Обмен сообщениями между различными задачами распределенной системы, построенной с
использованием операционной системы и задач RAC, должен осуществляться в соответствии с
дисциплиной запрос-ответ. Это означает, что на каждое сообщение-запрос, выданное одной из задач
ведущего узла, должно быть получено одно и только одно сообщение-ответ. При этом может быть
выдано несколько сообщений-запросов раньше, чем поступят все сообщения-ответы на ранее
выданные запросы. Важно лишь, чтобы на каждое сообщениезапрос при отсутствии отказов
аппаратуры и перезапусков станции обязательно было получено сообщение-ответ.
В процессе работы задача RAC выполняет сервисные функции по запросам прикладных задач.
RAC может работать как в режиме ведущей, так и в режиме подчиненной станции. Это
обеспечивает возможность резервирования ведущей станции. Первоначально после создания задача
RAC устанавливается в режим подчиненной станции: она готова принимать сообщения-запросы от
программ удаленной ведущей станции. В режим ведущей станции задача RAC переводится после
получения от прикладной задачи сообщения-запроса для удаленной станции и остается в этом
режиме до отключения питания или перезапуска контроллера. В обоих режимах задача RAC
обеспечивает пересылку сообщений-запросов и сообщений-ответов между устройством расширения
и локальными прикладными задачами в произвольном направлении, определяемом в заголовках
сообщений. Локальные прикладные задачи и прикладные программы устройства расширения
ведущей станции могут посылать сообщения-запросы задаче RAC подчиненной станции. Задача
RAC подчиненной станции выполняет эти запросы и передает сообщения-ответы на данные
запросы.
Если задача RAC исполняется в ведомой станции, она принимает сообщения-запросы,
предназначенные данной станции. При этом задача RAC анализирует текущий идентификатор (TID)
задачи-приемника. Если он равен 0, задача RAC выполняет указанную в запросе команду и
возвращает в канал сети сообщение-ответ для передачи на ведущую станцию. Если TID задачиприемника не равен 0, сообщение-запрос пересылается указанной задаче. Впоследствии от этой
задачи должно быть получено сообщение-ответ, которое будет передано в ведущую станцию.
4.5. Обращение к задаче RAC. Формат сообщения Bitbus
K задаче RAC могут поступать сообщения от задач, работающих вместе с ней в системе, и от
сети Bitbus. Сообщения должны соответствовать общему формату сообщений.
4.6. Команды (функции) задачи RAC
Ниже приведен перечень команд, включающий их условные наименования, краткое описание и
коды, передаваемые в поле "команда/ответ" сообщений-запросов.
Команда
RESET_STATION
CREATE_TASK
DELETE_TASK
GET_FUNCTION_IDS
RAC_PROTECT
EXT_UPLOAD
EXT_DNLOAD
INT_WRITE
INT_READ
NODE_INFO
SET_NODE_OFFLINE
UPLOAD_CODE
DNLOAD_CODE
GO_SUB
Код
00h
01h
02h
03h
04h
08h
09h
0Dh
0Eh
0Fh
10h
11h
12h
C0h
Назначение
-
перезапуск, ответного сообщения нет
создание задачи OS152
удаление задачи OS152
запрос таблицы FID
запрет/разрешение команд доступа RAC
чтение данных из внешнего ОЗУ
запись данных во внешнее ОЗУ
запись данных во внутренне ОЗУ
чтение данных из внутреннего ОЗУ
чтение системной информации о станции
исключение узла из таблицы полинга
чтение данных из памяти программ
запись данных в память программ
выполнить подпрограмму
Тип
У
У
У
У
У
Д
Д
Д
Д
У
У
Д
Д
У
Ниже приведены коды статуса завершения операций обмена, возвращаемые в поле "команда/ответ".
Статус ответа
E_SERVICE_OK
E_PROTOCOL_ERROR
E_NO_DESTINATION_DEVICE
Код
Значение
00h - запрос выполнен
91h - ошибка канального протокола
93h - нет устройства-адресата
E_RAC_PROTECTED
E_UNKNOWN_RAC_COMMAND
E_BAD_COMMAND_LENGTH
E_NOT_MASTER_DEVICE
95h
96h
97h
99h
-
удаленный доступ запрещен
нераспознанный код команды
неверная длина команды
адресат - не мастер сети
З_а_м_е_ч_а_н_и_е. Если в сообщении-ответе в поле
"команда/ответ" возвращается статус доставки E_PROTOCOL_ERROR,
то невозможно сказать, выполнилась или нет на адресованном
устройстве команда RAC, код которой содержался в сообщениикоманде. Это объясняется тем, что
ошибка канального протокола может возникнуть как при передаче сообщения-команды (т.е. до
выполнения функции RAC на удаленной станции), так и при получении сообщения-ответа (т.е. уже
после выполнения функции RAC на удаленном устройстве).
4.6.1. Программный перезапуск RESET_STATION
Выполняется перезапуск системы. Ответ не формируется. Получение сообщения-ответа
возможно только при ошибке передачи, тогда поле "команда/ответ" будет содержать статус
доставки сообщения.
4.6.2. Создание задачи CREATE_TASK
Создается новая задача на адресованном устройстве.
В сообщении-команде поле "команда/ответ" содержит код команды (01h), байты 7 и 8 соответственно старший и младший байты адреса начального дескриптора (ITD) создаваемой
задачи. ITD должен быть занесен в программную память перед выполнением этой функции RAC.
В сообщении-ответе байты 7 и 8 не изменяются, а поле "команда/ ответ" содержит статус
завершения. Это или статус для CREATE_TASK, или статус доставки сообщения.
4.6.3. Удаление задачи DELETE_TASK
Удаляется задача на адресованном устройстве.
В сообщении-команде поле "команда/ответ" содержит код команды (02h), байт 7 - текущий
идентификатор удаляемой задачи (TID).
В сообщении-ответе байт 7 остается тем же, что и в команде, а поле "команда/ответ" содержит
статус завершения. Это или статус для DELETE_TASK, или статус доставки сообщения.
4.6.4. Запрос таблицы FID задач GET_FUNCTION_IDS
В сообщении-команде поле "команда/ответ" (байт 6) содержит код команды (03h), байты 7...14
- поле для приема таблицы функциональных идентификаторов задач 0...7, работающих в системе.
В сообщении-ответе поле "команда/ответ" содержит статус доставки сообщения. Байты 7...14
содержат таблицу функциональных идентификаторов.
4.6.5. Запрет/разрешение функций доступа RAC_PROTECT
Выполняется запрет или разрешение любого типа обращений к памяти через задачу RAC.
Команды RAC, выполнение которых можно заблокировать таким образом, помечены буквой 'д' в
последнем столбце таблицы 4.1.
В сообщении-команде поле "команда/ответ" (байт 6) содержит код команды (04h), байт 7 флаг запрета/разрешения: 0 - функции доступа к памяти разрешаются, 1 - запрещаются.
В сообщении-ответе поле "команда/ответ" содержит статус доставки сообщения. Байт 7 не
изменяется.
4.6.6. Чтение внешней памяти данных EXT_UPLOAD
Читается содержимое блока внешней памяти данных (сегмент XDATA). Размер блока
определяется длиной сообщения.
В сообщении-команде поле "команда/ответ" (байт 6) содержит код команды (08h), байты 7 и 8
- соответственно старший и младший байты адреса блока памяти, байты 9... резервируются для
прочитанных данных.
В сообщении-ответе байты 9... содержат прочитанную информацию, байты 7 и 8 не
изменяются, а поле "команда/ответ" содержит статус доставки сообщения.
4.6.7. Запись во внешнюю память данных EXT_DNLOAD
Записываются данные во внешнюю память данных (сегмент XDATA). Размер блока
определяется длиной сообщения.
В сообщении-команде поле "команда/ответ" (байт 6) содержит код команды (09h), байты 7 и 8
- соответственно старший и младший байты адреса блока памяти, байты 9... - записываемую
информацию.
В сообщении-ответе байты 7... не изменяются, а байт поле "команда/ответ" содержит статус
доставки сообщения.
4.6.8. Запись во внутреннюю память данных INT_WRITE
Записываются данные по указанным адресам во внутренней памяти данных (сегмент IDATA).
В сообщении-команде поле "команда/ответ" (байт 6) содержит
код команды (0Dh), байты 7... последовательно сгруппированы попарно.
Первый байт пары - адрес, второй содержит информацию для записи по данному адресу.
Количество пар байт определяется длиной сообщения.
В сообщении-ответе поле "команда/ответ" содержит статус доставки сообщения. Байты 7... не
изменяются.
4.6.9. Чтение внутренней памяти данных INT_READ
Считываются данные по указанным адресам во внутренней памяти данных (сегмент IDATA).
В сообщении-команде поле "команда/ответ" (байт 6) содержит
код команды (0Eh), байты 7... последовательно сгруппированы попарно.
Первый байт пары - адрес, второй резервируется для прочитанного по этому адресу значения.
Количество пар байт определяется длиной сообщения.
В сообщении-ответе поле "команда/ответ" содержит статус доставки сообщения. Байты
адресов не изменяются, байты данных содержат прочитанную информацию.
4.6.10. Чтение системной информации о станции NODE_INFO
Считывается системная информация о станции.
В сообщении-команде поле "команда/ответ" (байт 6) содержит код команды (0Fh), байты 7...19
резервируются для системной информации (длина сообщения всегда равна 20 байтам).
В сообщении-ответе байты 7...12 содержат идентификатор типа станции в ASCII кодах, байты
13...14 содержат ASCII коды версии системного программного обеспечения данной станции, байт 15
содержит тип контроллера, байт 16 содержит длину системного буфера (значение системной
переменной BUF_SIZE), байты 17...19 зарезервированы для будущего развития. Поле
"команда/ответ" содержит статус доставки сообщения.
4.6.11. Исключении из таблицы полинга подчиненного узла
SET_NODE_OFFLINE.
Команда предназначена исключительно для ведущего узла.
По этой команде задача RAC ведущего узла исключает из таблицы полинга подчиненную станцию,
адрес которой указан в поле данных, и считает, что эта станция находится в нормально
разъединенном режиме. Обычно эта команда выполняется после перезапуска подчиненного
устройства.
В сообщении-команде поле "команда/ответ" (байт 6) содержит код команды (10h), байт 7
содержит адрес удаляемого узла.
В сообщении-ответе байт 7 не изменяется. Поле "команда/ответ" содержит статус доставки
сообщения.
4.6.12. Чтение памяти программ UPLOAD_CODE
Считываются данные из памяти программ (сегмент CODE).
В сообщении-команде поле "команда/ответ" (байт 6) содержит код команды (11h), байты 7 и 8
- соответственно старший и младший байты адреса блока памяти, байты 9... резервируются для
прочитанной информации. Количество считываемых байт определяется длиной сообщения.
В сообщении-ответе байты 9... содержат прочитанную информацию, байты 7 и 8 не
изменяются, а поле "команда/ответ" содержит статус доставки сообщения.
4.6.13. Запись в память программ DNLOAD_CODE
По этой команде, задача RAC записывает данные в память программ по указанному адресу.
Проверка правильности записи не производится.
В сообщении-команде поле "команда/ответ" (байт 6) содержит код команды (12h), байты 7 и 8
- соответственно старший и младший байты адреса памяти, а байты 9... - записываемые значения.
Количество записанных байт определяется длиной сообщения.
В сообщении-ответе байты 7... не изменяются, а поле "команда/ответ" содержит статус
доставки сообщения.
4.6.14. Обращение к подпрограмме GO_SUB
Получив сообщение-запрос с кодом этой команды, задача RAC на адресованном устройстве по
указанному адресу обращается к подпрограмме, заранее занесенной в память программ.
В сообщении-команде поле "команда/ответ" (байт 6) содержит код команды (0C0h), байты 7 и
8 соответственно содержат старший и младший байты адреса подпрограммы. Байты 9... могут
содержать входные параметры для подпрограммы.
В сообщении-ответе байты 7... не меняются (но могут быть изменены подпрограммой), а поле
"команда/ответ" содержит статус доставки сообщения.
5. Управление внешними устройствами
5.1. Ввод-вывод дискретных сигналов
Контроллер имеет 8 каналов дискретного ввода-вывода, каждый из которых может быть
независимо от других запрограммирован либо на ввод, либо на вывод. "Направление работы"
каналов (ввод или вывод) может быть изменено в любой момент системным вызовом D_MODE.
Функции управления вводом-выводом дискретных сигналов реализованы в виде системных
вызовов.
5.1.1. Инициализация дискретного ввода-вывода D_MODE
Вызывается командой LCALL по адресу C0h. Задает режимы работы всех восьми каналов
дискретного ввода-вывода.
Входной параметр: MODE_BITS - байт, в котором нулевые биты определяют
соответствующий канал как вход, а единичные биты - как выход. Параметр передается в регистре A.
5.1.2. Ввод дискретных сигналов D_INP
Вызывается командой LCALL по адресу C3h. Системный вызов D_INP считывает состояние
каналов дискретного ввода.
Выходной параметр: INP_BITS - состояние входных каналов. Разряды, соответствующие
выходам, не определены. Параметр возвращается в регистре A.
5.1.3. Вывод дискретных сигналов D_OUT
Вызывается командой LCALL по адресу C6h. Системный вызов D_OUT устанавливает
состояние каналов дискретного вывода.
Входной параметр: OUT_BITS - байт, соответствующие биты которого содержат выводимые
значения. Разряды, соответствующие входам, должны обнуляться перед обращением к D_OUT.
Параметр передается в регистре A.
5.2. Ввод-вывод сигналов через порты 4,5,6
Доступ к 4-му, 5-му и 6-му портам в контроллере MBB организован в виде соответствующих
системных вызовов:
P4_INP - ввод содержимого порта P4 на регистр A.
Вызывается командой LCALL по адресу C9h.
P4_OUT - вывод содержимого регистра A в порт P4.
Вызывается командой LCALL по адресу CCh.
B4_SET - установка отдельного бита порта P4. Номер
бита указывается в регистре A.
Вызывается командой LCALL по адресу CFh.
B4_CLR - сброс отдельного бита порта P4. Номер
бита указывается в регистре A.
Вызывается командой LCALL по адресу D2h.
P5_INP - ввод содержимого порта P5 на регистр A.
Вызывается командой LCALL по адресу D5h.
P5_OUT - вывод содержимого регистра A в порт P5.
Вызывается командой LCALL по адресу D8h.
P6_INP - ввод содержимого порта P6 на регистр A.
Вызывается командой LCALL по адресу DBh.
P6_OUT - вывод содержимого регистра A в порт P6.
Вызывается командой LCALL по адресу E0h.
5.3. "Сторожевой таймер" (watch-dog)
5.3.1. Контроль времени выполнения программ
В состав аппаратуры контроллера входит устройство контроля времени выполнения программ
- сторожевой таймер (watch-dog). Если он включен, то одновременно с работой процессора
сторожевой таймер отсчитывает периоды реального времени, равные примерно 2,5 секунды. Если в
течении одного такого периода к сторожевому таймеру поступает сигнал сброса от выполняемой
процессором программы, таймер начинает отсчет нового периода. Если до истечения периода
сигнал сброса не поступает, таймер инициирует аппаратный перезапуск всего контроллера.
Включение сторожевого таймера производится установкой соответствующей перемычки на плате
контроллера.
Для реализации контроля времени выполнения прикладных задач в их алгоритмах должны
быть предусмотрены контрольные точки, в которых выдается сигнал сброса сторожевого таймера
путем обращения к системному вызову WATCHDOG_RST. Прикладная задача, обратившись к
системному вызову WATCHDOG_OS, может "отключить" от себя сторожевой таймер и переложить
заботу по его сбросу на операционную систему. Однако, в результате этого сторожевой таймер
будет контролировать лишь время выполнения программ системы, а не прикладных задач. Обратное
отключение сторожевого таймера от системы и переключение его на прикладные задачи
производится путем обращения к системному вызову WATCHDOG_USER.
После включения питания контроллера, а также после аппаратного или программного
перезапуска сторожевой таймер отключен от прикладных задач и его сбросом занимается
операционная система.
5.3.2. Системные вызовы WATCHDOG_RST, WATCHDOG_OS,
WATCHDOG_USER
Системный вызовы управления сторожевым таймером не имеют параметров.
Системный вызов WATCHDOG_OS переключает сброс сторожевого таймера на программы
операционной системы (включает автосброс). Вызывается командой LCALL по адресу B3h.
Системный вызов WATCHDOG_RST однократно сбрасывает сторожевой таймер. Вызывается
командой LCALL по адресу B0h.
Системный вызов WATCHDOG_USER переключает сброс сторожевого таймера на
прикладную программу (выключает автосброс). Вызывается командой LCALL по адресу B6h.