Система команд микроконтроллера ве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%), т.к. такие программы критичны к длине ППО и быстродействию, а также необходимо учитывать стоимость АС и ППО и сроки проектирования.