МЕТОДИКА РАЗРАБОТКИ ППО МКС
СИСТЕМА КОМАНД МИКРОКОНТРОЛЛЕРА ВЕ48
Система команд включает 96 основных команд, имеющих формат один или два байта (70% однобайтные команды), время выполнения команд составляет от 1 до 2 машинных циклов (2,5 или 5 мкс).
МК использует четыре вида адресации: прямая регистровая (Ri), косвенная регистровая (@Ri), непосредственная (#d) и неявная (A, T, Pp, BUS, PSW). Все команды можно разделить на пять групп по функциональному признаку:
* команды пересылки данных можно представить в виде графа:
PSW Û AC Ü #d
@A ППЗУ Þ AC Û @Ri ВПД
Порты Û AC Û Rn
Таймер Û AC Û @Ri ОЗУД
¨ арифметические операции (12 команд: ADD, INC, DEC, ADDC, DA - десятичная коррекция).
¨ логические операции (28 команд: ANL, ORL, XRL, инверсия, сброс, сдвиг: сброс и инверсия возможна над битами).
¨ команды передачи управления (19 команд, из них две команды БП, 14 команд - УП, CALL, RET, RETR):
а) команды ветвления и перехода с прямой адресацией, когда в команде указан 8- или 11-разрядный адрес перехода, т.е. переход внутри страницы или 2048-байтного банка, а номер банка определяется флагом МВ, который устанавливается командой SEL MB0 или 1 и копируется в РС[11] при выполнении команд JMP и CALL.
б) переход по косвенному адресу, хранимому в АС внутри текущей страницы JMPP @A.
* команды управления режимами работы МК (13 команд): это команды управления таймером/счетчиком, прерываниями, флагами переключения банков памяти программ и данных:
Þ запуск таймера в режиме таймера или счетчика событий и останов счета;
Þ разрешение/запрещение прерываний от таймера или внешнего источника прерываний;
Þ выбор нулевого или первого банков регистров данных или памяти программ.
Если определена цель разработки и критерии проектирования, то далее необходимо выполнить следующие действия:
1. Составление подробного описания задачи (спецификаций) и ТЗ на проектирование.
2. Анализ задачи, поиск и выбор прототипов, анализ технической литературы и патентный поиск.
3. Инженерную интерпретацию задачи с выбором математического аппарата для проектирования и выполнения этапа формализации задачи (на основе теории графов, автоматов, сетей Петри, матриц состояний и связности и т.п.).
4. Разработка общей блок-схемы алгоритма (БСА) контроллера.
5. Разработка детализированных БСА отдельных процедур в соответствие с модульным принципом составления и отладки программ.
6. Детальная проработка интерфейса контроллера и коррекция БСА.
7. Распределение рабочих регистров данных и памяти программ МК.
8. Подготовка текста исходной программы.
Результатом работы по первым трем пунктам является подробная спецификация на ППО МК, в которой основное внимание уделяется детализации способов формирования входной и выходной информации, получаемых от объекта управления и передаваемая из МК к объекту управления.
На последующих этапах разработчик описывает метод, выбранный для решения поставленной задачи, так как одна и та же задача может быть решена различными методами и средствами. Здесь основой выбора метода являются требуемые по ТЗ технические характеристики, анализ литературы по методикам проектирования и патентный поиск прототипов.
В основу разработки БСА положен принцип модульного проектирования программ. Разработка БСА требует предельной точности и однозначности используемой атрибутики:
¨ символических имен переменных, подпрограмм, адресов таблиц, портов ввода-вывода и т.д.
¨ описание аппаратуры сопряжения МК с объектом управления вплоть до электрических и временных характеристик каждого входного и выходного сигнала;
¨ однозначно определить действия по преобразованию входных данных в обработанные выходные.
Секрет успеха разработки ППО МК заключается в использовании метода декомпозиции, когда вся задача последовательно разделяется на меньшие функциональные модули, каждый из которых можно анализировать, разрабатывать и отлаживать отдельно от других, а схема связности этих модулей образует общую БСА прикладной программы.
Метод последовательной декомпозиции обладает достаточной гибкостью и позволяет привести степень детализации БСА в соответствие со сложностью алгоритма.
Структурное программированиеэто процесс построения ППО из строгого набора модулей, каждый из которых реализует определенную процедуру обработки данных. Программные модули должны иметь только одну точку входа и одну точку выхода. Типичной ошибкой программирования является использование модулей, имеющих один вход и несколько выходов.
Разработка БСА функциональных модулей имеет ярко выраженный итеративный характер, т.е. требует многократных проб, прежде чем ринять окончательное решение.
Поэтому методики разработки БСА включают такие промежуточные этапы как:
¨ возврат к постановке задачи для анализа полученного результата и его корректировки с целью сделать алгоритм (БСА) более простым, логичным и наглядным при графическом представлении;
¨ проверку работоспособности алгоритма на бумаге путем подстановки в него действительных данных (моделирование на бумаге);
¨ рассмотрение предельных случаев, например, диапазона изменения входных данных, изменение знака результата операции, деление на нуль и т.п.;
¨ проведение мысленного эксперимента по определению работоспособности алгоритма в реальном масштабе времени, особенно реакцию алгоритма на возможные прерывания, пропуск кратковременных событий в объекте управление и т.п.
Следующим этапом является разработка исходного текста программы. Предварительно необходимо специфицировать память и выбрать язык программирования. Спецификация памяти включает:
Þ определение адреса первой команды ППО;
Þ начальных адресов стека, таблиц данных, буферных зон передачи параметров между процедурами, подпрограмм обработки прерываний и т.д.
При выборе языка программирования необходимо помнить, что на языке ассемблера программировать труднее и дольше, чем на языках высокого уровня, но при этом требуется меньшая емкость памяти программ и программа выполняется быстрее.
Выбор языковых средств в каждом конкретном применении зависит от характеристик прикладной задачи, опыта программиста и допустимых затрат на разработку и сроков проектирования.
Однако для прикладных задач управления объектом, работающих в реальном времени, основным языковым средством написания ППО еще долгое время будет оставаться язык ассемблера (80%), т.к. такие программы критичны к длине ППО и быстродействию, а также необходимо учитывать стоимость АС и ППО и сроки проектирования.