5.3. Система команд микроконтроллеров подгруппы PIC16F8X
5.3.1. Перечень и форматы команд
Микроконтроллеры подгруппы PIC16F8X имеют простую и эффективную систему команд, состоящую всего из 35 команд.
Каждая команда МК подгруппы PIC16F8X представляет собой 14-битовое слово, разделенное на код операции (OPCODE), и поле для одного и более операндов, которые могут участвовать или не участвовать в этой команде. Система команд PIC16F8X является ортогональной и включает в себя команды работы с байтами, команды работы с битами и операции с константами и команды управления. В таблице 5.10 приведены описания полей команд.
Для команд работы с байтами f обозначает регистр, с которым производится действие; d — бит, определяющий, куда положить результат. Если d =0, то результат будет помещен в регистр w, при d=1 результат будет помещен в регистр «f», упомянутый в команде.
Для команд работы с битами b обозначает номер бита, участвующего в команде, а f — это регистр, в котором данный бит расположен.
Для команд передачи управления и операций с константами, k обозначает восьми или одиннадцатибитную константу.
Почти все команды выполняются в течение одного командного цикла. В двух случаях исполнение команды занимает два командных цикла:
• проверка условия и переход;
• изменение программного счетчика как результат выполнения команды.
Один командный цикл состоит из четырех периодов генератора. Таким образом, для генератора с частотой 4 МГц время исполнения командного цикла будет 1 мкс.
Основные форматы команд МК изображены на рис. 5.15.
Система команд МК подгруппы PIC16F8X приведена в табл. 5.11.
5.3.2. Команды работы с байтами
Команды работы с байтами используются в PIC М К для пересылки данных между регистрами и выполнения математических операций над их содержимым. Несмотря на относительно небольшой набор команд, они позволяют реализовать целый ряд операций. Это связано, в частности, с возможностью указать в команде адрес размещения результата операции.
Преимуществом системы команд является также возможность использования различных способов обращения к регистрам. Адрес регистра может быть указан непосредственно в команде соответствующим 7-битовым полем f. При этом доступ возможен только к данным, расположенным в пределах текущего банка данных. Адресация данных может осуществляться и с помощью индексного регистра FSR, путем обращения к регистру косвенной адресации INDF, расположенному по нулевому адресу.
Пересылка данных выполняется с помощью двух команд: MOVF и MOVWF, назначение которых существенно различается. Команда MOVF используется для установки бита нулевого результата в зависимости от содержимого определенного регистра и может применяться для его загрузки в регистр w. Команда MOVWF используется для записи содержимого рабочего регистра w в указанный регистр МК. Если в качестве этого регистра указывается INDF, то адрес регистра назначения выбирается из регистра FSR. При выполнении данной команды биты состояния не изменяются.
Специальные команды CLRF f и CLRW применяются для очистки регистров МК. Команда CLRF f записывает ноль в указанный регистр, а команда CLRW — в рабочий регистр. При этом необходимо помнить, что они также устанавливают соответствующее значение бита нуля.
Наиболее часто используемой арифметической операцией является сложение, которое выполняется командой ADDWF f, d. Эта операция может изменять все биты состояния. Бит нуля устанавливается в 1, если при выполнении логической операции «И» над полученным результатом и числом 0x0FF (255) получается ноль. Бит переноса устанавливается в 1, если результат превышает число 0x0FF. Бит десятичного переноса устанавливается в 1, если сумма четырех младших битов результата превышает 0x0F (15).
При использовании операции вычитания SUBWF f, 4 следует иметь в виду, что в PIC МК она выполняет операцию сложения с отрицательным числом. То есть вместо операции d = f — w в действительности выполняется d = f + (-w). Отрицательное значение содержимого в вычисляется по формуле Negw = (Posw ^ 0x0FF) + 1.
Команды логических операций ANDWF f, d, IORWF f, d и X0RWF f, 4 позволяют выполнять основные логические операции над соответствующими битами содержимого указанного регистра и регистра w. Бит нуля в регистре STATUS устанавливается в 1 или сбрасывается в 0 в зависимости от значения полученного результата. Команду XORWF f, d удобно использовать для проверки содержимого некоторого регистра. Для этого необходимо загрузить заданное число в регистр w и выполнить операцию XORWF f, d над содержимым проверяемого регистра и w. Если содержимое регистра равно содержимому w, то результат операции будет равен нулю, и бит нуля установится в 1.
Команда СОМР f, d используется для инвертирования значений всех битов в регистре источника. Следует отметить, что эта команда не делает число отрицательным, то есть не переводит его в дополнительный код.
Отрицательное число Neg может быть получено из положительного Pos следующим образом: Neg = (Pos^ 0x0FF) + 1.
Команда SWAPF f, d меняет местами тетради в регистре. Как и в остальных командах данной группы, результат выполнения может быть записан как в регистре W так и в регистре-источнике. Данная команда не меняет значения какого либо из битов состояния, что может использоваться для восстановления содержимого контекстных регистров перед возвратом из прерывания. Команду SWAPF f, d можно применять, в частности, для хранения двух цифр в одном регистре, переставляя их в зависимости от того, какую из них вы хотите использовать. С помощью команды SWAPF Г, д удобно разделить байт на две тетради для их последующего отображения на дисплее.
Основной функцией команд циклического сдвига RLF f, d и RRF f, d является сдвиг содержимого регистра влево или вправо на один бит с записью на место младшего значащего бита значения бита переноса или, соответственно, установления бита переноса в соответствии со значением старшего значащего бита. Команды циклического сдвига могут использоваться для умножения и деления на число 2 в степени n. Они также служат для реализации последовательного ввода или вывода данных и позиционирования байта для того, чтобы можно было тестировать значение отдельных битов.
Команды инкремента INCF f, d и декремента DECF f, d используются для изменения содержимого регистра на 1. После выполнения команд инкремента и декремента может измениться только бит нуля. Изменения бита переноса, если результат превысит значение 0x0FF при инкременте или окажется меньше 0 при декременте, не происходит.
Для реализации условных переходов в программе существуют команды инкремента и декремента с пропуском команды при нулевом результате: INCFSZ f, д и DECFSZ f, d. С точки зрения обработки данных они работают аналогично командам INCF f, d и DECF f, d. Основное отличие от этих команд заключается в том, что при нулевом результате выполнения команды INCFSZ f, d или DECFSZ f, d пропускается следующая за ней команда. Это означает, что команды INCFSZ f, d и DECFSZ f, d могут использоваться для организации программных циклов. Другая особенность этих команд состоит в том, что они не влияют на содержимое битов состояния регистра STATUS.
Команда NOP означает отсутствие операции. Традиционно она используется для двух целей. Первая — обеспечение синхронизации программы с временными характеристиками различных устройств системы. Вторым возможным вариантом является использование команды N0P для удаления части программного кода. Вследствие того, что код команды
NOP состоит из одних нулей, его легко ввести в память программ вместо любой другой команды, не прибегая к стиранию и репрограммированию всей памяти программ.
5.3.3. Команды работы с битами
Отличительной особенностью данной группы команд является то, что они оперируют с однобитными операндами, в качестве которых используются отдельные биты регистров МК.
Установка и сброс отдельных битов производится командами BSF f, Ь и BCF f, Ь. Любой доступный для записи бит в регистровой памяти может быть модифицирован таким способом. При этом гарантируется, что ни один из остальных битов регистра не будет изменен.
Однако при работе с портами ввода/вывода последнее утверждение не всегда справедливо. Связано это с тем, что значение числа, считываемого из регистра порта, зависит от конфигурации его выводов в качестве входов или выходов данных.
В системе команд, рассматриваемых PIC МК, отсутствуют команды условного перехода. Вместо них имеются такие, которые позволяют пропустить выполнение следующей команды. В частности, рассмотренные выше команды INCFSZ f, д и DECFSZ f, d удобны для организации циклов в программе.
Для управления процессом выполнения программы используются команды работы с битами BTFSC f, Ь и BTFSS f, Ь, позволяющие пропустить выполнение следующей команды программы в зависимости от состояния определенного бита в заданном регистре.
Если в качестве заданного регистра используется регистр STATUS, то можно организовать управление переходами программы в зависимости от состояния битов признаков результата операции, как предусмотрено в микропроцессорах стандартной архитектуры.
5.3.4. Команды управления и работы с константами
Команды работы с константами используют при выполнении операции явно заданные операнды, которые являются частью команды.
Команда MOVLW k используется для записи константы k в рабочий регистр w. Содержимое регистра STATUS при этом не изменяется.
Команда ADDLW k прибавляет непосредственно заданную величину к содержимому регистра и Эта команда изменяет значения битов нуля, переноса и десятичного переноса таким же образом, как и команда ADDWF f, d.
Команда SUBLW k вычитает содержимое регистра w из заданного значения константы k. В отличие от SUBWF f, d, результат выполнения команды SUBLW k можно представить в следующем виде: w = k+ (w^ 0x0FF)+ 1. С помощью этой команды удобно изменять знак содержимого регистра w, используя ее следующим образом: SUBLW 0.
Команды логических операций ANDLW 1с, IORLW k и XORLW k выполняют побитно соответствующие операции над содержимым регистра w и непосредственно заданной константой k. Эти команды, как и команды работы с байтами, устанавливают только бит нуля в регистре STATUS в соответствии с результатом операции. Полученный результат сохраняется в регистре w.
С помощью команды IORLW 0 удобно определять равенство нулю содержимого регистра w. В зависимости от результата этой операции бит нуля будет установлен в 1 или сброшен в 0.
Команда RETLW k используется для возврата из подпрограммы с установкой начальных условий в регистр w, а также для реализации табличных преобразований, что будет описано ниже. Перед возвращением из подпрограммы эта команда осуществляет загрузку непосредственно заданной величины в рабочий регистр w.
Команды GOTO k, CALL k, RETURN и RETFIE используются для управления программой.
Команды GOTO k и САLL k могут явно задавать адрес перехода в пределах определенной страницы, размер которой зависит от типа МК: 256/ 512 адресов для младших моделей, 2К адресов для PIC МК среднего уровня (включая PIC16F8X) и 8К адресов для старших моделей МК. Если адрес перехода выходит за пределы страницы, то регистр PCLATH должен содержать правильную информацию о новой странице.
Команда САLL k выполняется практически так же, как и СОТО k, за исключением того, что указатель на следующую страницу сохраняется в стеке счетчика команд.
Для PIC МК средней группы существует три различных способа возврата из подпрограммы, определяемые командами RETLW k, RETURN и RETFIE. При каждом из этих способов значение адреса извлекается из вершины стека и загружается в счетчик команд. Эти адреса используются для возврата из подпрограмм или прерываний.
Обычное использование команды RETURN приводит к восстановлению адреса команды, следующей за командой вызова подпрограммы. При этом содержимое каких-либо регистров не изменяется, как и значения отдельных битов.
Команда RETFIE используется для возврата из прерывания. Она реализуется аналогично команде RETURN за исключением того, что при ее выполнении устанавливается в 1 бит GIE в регистре управления прерываниями INTCON. Это позволяет после выполнения данной команды немедленно перейти к обработке прерываний, ожидающих своей очереди.
В противном случае перед окончанием обработки потребовалась бы проверка наличия запросов других прерываний, и, в случае их поступления, переход к их обработке.
Существует всего две команды, служащие для непосредственного управления функционированием МК. Первая из них — CLRWDT — используется для сброса сторожевого таймера. Вторая — SLEEP — обеспечивает сохранение текущего состояния МК в режиме ожидания, пока не произойдет какое-либо внешнее событие, которое позволит PIC МК продолжить выполнение программы.
Команда CLRWDT сбрасывает в 0 содержимое сторожевого таймера WDT и определителя (если он используется для установки интервала времени срабатывания WDT), запуская сначала отсчет времени сторожевого таймера. Целью введения команды CLRWDT является предотвращение перезапуска МК при нормальном выполнении программы.
Команда SLEEP служит для двух целей. Первой из них является отключение МК после того, как он закончит выполнение программы. Такое использование МК предполагает, что он необходим только для решения определенной задачи, например, инициализации других устройств в системе, а затем его функционирование не требуется.
Второй целью использования команды SLEEP является реализация в МК режима ожидания какого-либо события. Существует три события, способные вывести МК из режима ожидания. Первым из них является подача сигнала запуска на вход сброса МК, что приведет к перезапуску процессора и началу выполнения программы с нулевого адреса. Второй способ— поступление сигнала «пробуждения» МК от сторожевого таймера. Третьим способом «пробуждения» является прерывание от какого-либо внешнего источника. При любом способе «пробуждения» использование команды SLEEP позволяет избежать необходимости организации циклов ожидания, а также снизить потребляемую системой мощность.
При этом необходимо иметь в виду, что выход МК из режима ожидания занимает, по меньшей мере, 1024 такта. Поэтому команду SLEEP нельзя использовать в тех случаях, когда требуется быстрая реакция на внешнее событие.
5.3.5. Особенности программирования и отладки
Анализ архитектуры микроконтроллеров PIC с точки зрения их программирования и отладки систем позволяет сделать следующие выводы:
• RISC-система команд обеспечивает высокую скорость выполнения инструкций, но вызывает затруднения и снижение производительности при программировании нетривиальных алгоритмов. Поскольку все инструкции в системе команд являются одноадресными, загрузка константы в любой из регистров требует двух инструкций. Вначале нужно загрузить константу в рабочий регистр w, а затем переслать его содержимое в нужную ячейку памяти данных:
MOVLW k
MOVWF f
Аналогично, все бинарные арифметико-логические операции приходится выполнять с привлечением рабочего регистра w;
• высокое быстродействие достигается в значительной степени за счет применения конвейера команд. Инструкции ветвления, изменяющие счетчик команд (безусловный переход, вычисляемый переход), не используют инструкцию из очереди, поэтому выполняются за два машинных цикла и снижают темп выполнения программы. Кроме того, сам анализ условий в архитектуре PIC требует выполнения «лишних» команд;
• наличие одного вектора прерываний, отсутствие развитого механизма обработки запросов по приоритетам и вложенных прерываний затрудняют решение сколько-нибудь сложных задач управления. При приходе запроса от любого из источников выполняется переход на процедуру обработки по единственному вектору. В процедуре приходится по битам признаков определять источник, причем условия ветвления, как указывалось выше, анализируются сложно, и все это увеличивает время реакции. После обработки прерывания нужно самостоятельно очистить бит запроса. Из-за отсутствия вложенных прерываний возможно длительное ожидание обработки запросом от источника с более высоким приоритетом;
• аппаратный стек глубиной 8 слов не имеет признака переполнения и ограничивает вложенность процедур. За тем, чтобы он не переполнялся, программист должен следить самостоятельно;
• память данных состоит из банков, для определения текущего банка используются биты регистров STATUS (для PIC16) или BSR (для PIC17). На этапе трансляции принадлежность указанного регистра текущему активному банку проверить невозможно, для этого требуется моделирование хода выполнения программы;
• память программ разбита на страницы размером 2К слов. Для перехода на нужный адрес по командам CALL и GOTO должны быть правильно установлены биты выбора текущей страницы в регистре PCLATH. На этапе трансляции невозможно проверить корректность передачи управления во время выполнения, для этого также требуется моделирование выполнения программы;
• ограниченность ресурсов МК серии PIC делает проблематичным их программирование на языках высокого уровня.
Указанные особенности архитектуры микроконтроллеров PIC компенсируются чрезвычайно низкой ценой, поэтому такие изделия (особенно семейства Р1С16) весьма популярны. В настоящее время их используют даже вместо логических ИС средней степени интеграции. Но реализовать все преимущества этих МК можно только при наличии средств программирования и отладки, адекватных по цене и функциональным возможностям решаемым задачам. Важнейшие требования к инструментальным средствам для МК, ориентированным на выполнение функций ввода-вывода, можно сформулировать следующим образом:
• основным назначением этих средств является поддержка программирования на языке ассемблер и перенос программы на плату системы управления;
• мощные драйверы портов ввода/вывода, состояние которых однозначно описывается значениями в регистрах управления, упрощают функцию замещения электрофизических параметров прототипной БИС, поэтому такие порты можно имитировать с помощью БИС программируемой логики;
• стоимость инструментальных средств должна соответствовать невысокой стоимости одноплатного контроллера.
Глава 6. Проектирование устройств на микроконтроллерах
Лекция 11. Особенности разработки цифровых устройств на основе микроконтроллеров
В этой лекции рассказывается об основных этапах проектирования и разработки цифровых устройств и систем на основе микроконтроллеров, а также приводится обзор методов совместной отладки аппаратных и программных средств.
Ключевые слова: разработка, аппаратные средства, программные средства, отладка.
6.1. Разработка микропроцессорной системы на основе микроконтроллера
6.1.1. Основные этапы разработки
МПС на основе МК используются чаще всего в качестве встроенных систем для решения задач управления некоторым объектом. Важной особенностью данного применения является работа в реальном времени, т.е. обеспечение реакции на внешние события в течение определенного временного интервала. Такие устройства получили название контроллеров.
Технология проектирования контроллеров на базе МК полностью соответствует принципу неразрывного проектирования и отладки аппаратных и программных средств, принятому в микропроцессорной технике. Это означает, что перед разработчиком такого рода МПС стоит задача реализации полного цикла проектирования, начиная от разработки алгоритма функционирования и заканчивая комплексными испытаниями в составе изделия, а, возможно, и сопровождением при производстве. Сложившаяся к настоящему времени методология проектирования контроллеров может быть представлена так, как показано на рис. 6.1.
В техническом задании формулируются требования к контроллеру с точки зрения реализации определенной функции управления. Техническое задание включает в себя набор требований, который определяет, что пользователь хочет от контроллера и что разрабатываемый прибор должен делать. Техническое задание может иметь вид текстового описания, не свободного в общем случае от внутренних противоречий.
На основании требований пользователя составляется функциональная спецификация, которая определяет функции, выполняемые контроллером для пользователя после завершения проектирования, уточняя тем самым, насколько устройство соответствует предъявляемым требованиям. Она включает в себя описания форматов данных, как на входе, так и на выходе, а также внешние условия, управляющие действиями контроллера.
Функциональная спецификация и требования пользователя являются критериями оценки функционирования контролера после завершения проектирования. Может потребоваться проведение нескольких итераций, включающих обсуждение требований и функциональной спецификации с потенциальными пользователями контроллера, и соответствующую коррекцию требований и спецификации. Требования к типу используемого МК формулируются на данном этапе чаще всего в неявном виде.
Этап разработки алгоритма управления является наиболее ответственным, поскольку ошибки данного этапа обычно обнаруживаются только при испытаниях законченного изделия и приводят к необходимости дорогостоящей переработки всего устройства. Разработка алгоритма обычно сводится к выбору одного из нескольких возможных вариантов алгоритмов, отличающихся соотношением объема программного обеспечения и аппаратных средств.
При этом необходимо исходить из того, что максимальное использование аппаратных средств упрощает разработку и обеспечивает высокое быстродействие контроллера в целом, но сопровождается, как правило, увеличением стоимости и потребляемой мощности. Связано это с тем, что увеличение доли аппаратных средств достигается либо путем выбора более сложного МК, либо путем использования специализированных интерфейсных схем. И то, и другое приводит к росту стоимости и энергопотребления. Увеличение удельного веса программного обеспечения позволяет сократить число элементов контроллера и стоимость аппаратных средств, но это приводит к снижению быстродействия, увеличению не обходимого объема внутренней памяти МК, увеличению сроков разработки и отладки программного обеспечения. Критерием выбора здесь и далее является возможность максимальной реализации заданных функций программными средствами при минимальных аппаратных затратах и при условии обеспечения заданных показателей быстродействия и надежности в полном диапазоне условий эксплуатации. Часто определяющими требованиями являются возможность защиты информации (программного кода) контроллера, необходимость обеспечения максимальной продолжительности работы в автономном режиме и другие. В результате выполнения этого этапа окончательно, формулируются требования к параметрам используемого МК.
При выборе типа МК учитываются следующие основные характеристики:
• разрядность;
• быстродействие;
• набор команд и способов адресации;
• требования к источнику питания и потребляемая мощность в различных режимах;
• объем ПЗУ программ и ОЗУ данных;
• возможности расширения памяти программ и данных;
• наличие и возможности периферийных устройств, включая средства поддержки работы в реальном времени (таймеры, процессоры событий и т.п.);
• возможность перепрограммирования в составе устройства;
• наличие и надежность средств защиты внутренней информации;
• возможность поставки в различных вариантах конструктивного исполнения;
• стоимость в различных вариантах исполнения;
• наличие полной документации;
• наличие и доступность эффективных средств программирования и отладки МК;
• количество и доступность каналов поставки, возможность замены изделиями других фирм.
Список этот не является исчерпывающим, поскольку специфика проектируемого устройства может перенести акцент требований на другие параметры МК. Определяющими могут оказаться, например, требования к точности внутреннего компаратора напряжений или наличие большого числа выходных каналов Ш ИМ.
Номенклатура выпускаемых в настоящее время МК исчисляется тысячами типов изделий различных фирм. Современная стратегия модульного проектирования обеспечивает потребителя разнообразием моделей МК с одним и тем же процессорным ядром. Такое структурное разнообразие открывает перед разработчиком возможность выбора оптимального МК, не имеющего функциональной избыточности, что минимизирует стоимость комплектующих элементов.
Однако для реализации на практике возможности выбора оптимального МК необходима достаточно глубокая проработка алгоритма управления, оценка объема исполняемой программы и числа линий сопряжения с объектом на этапе выбора МК. Допущенные на данном этапе просчеты могут впоследствии привести к необходимости смены модели МК и повторной разводки печатной платы макета контроллера. В таких условиях целесообразно выполнять предварительное моделирование основных элементов прикладной программы с использованием программно-логической модели выбранного МК.
При отсутствии МК, обеспечивающего требуемые по ТЗ характеристики проектируемого контроллера, необходим возврат к этапу разработки алгоритма управления и пересмотр выбранного соотношения между объемом программного обеспечения и аппаратных средств. Отсутствие подходящего МК чаще всего означает, что для реализации необходимого объема вычислений (алгоритмов управления) за отведенное время нужна дополнительная аппаратная поддержка. Отрицательный результат поиска МК с требуемыми характеристиками может быть связан также с необходимостью обслуживания большого числа объектов управления. В этом случае возможно использование внешних схем обрамления МК.
На этапе разработки структуры контроллера окончательно определяется состав имеющихся и подлежащих разработке аппаратных модулей, протоколы обмена между модулями, типы разъемов. Выполняется предварительная проработка конструкции контроллера. В части программного обеспечения определяются состав и связи программных модулей, язык программирования. На этом же этапе осуществляется выбор средств проектирования и отладки.
Возможность перераспределения функций между аппаратными и программными средствами на данном этапе существует, но она ограничена характеристиками уже выбранного МК. При этом необходимо иметь в виду, что современные МК выпускаются, как правило, сериями (семействами) контроллеров, совместимых программно и конструктивно, но различающихся по своим возможностям (объем памяти, набор периферийных устройств и т.д.). Это дает возможность выбора структуры контроллера с целью поиска наиболее оптимального варианта реализации.
Нельзя не упомянуть здесь о новой идеологии разработки устройств на базе МК, предложенной фирмой «Scenix». Она основана на использовании высокоскоростных RISC-микроконтроллеров серии SX с тактовой частотой до 100 МГц. Эти МК имеют минимальный набор встроенной периферии, а все более сложные. периферийные модули эмулируются программными средствами. Такие модули программного обеспечения называются «виртуальными периферийными устройствами», они обеспечивают уменьшение числа элементов контроллера, времени разработки, увеличивают гибкость исполнения. К настоящему времени разработаны целые библиотеки виртуальных устройств, содержащие отлаженные программные модули таких устройств как модули ШИМ и ФАПЧ, последовательные интерфейсы, генераторы и измерители частоты, контроллеры прерываний и многие другие.
6.1.2. Разработка и отладка аппаратных средств
После разработки структуры аппаратных и программных средств дальнейшая работа над контроллером может быть распараллелена. Разработка аппаратных средств включает в себя разработку общей принципиальной схемы, разводку топологии плат, монтаж макета и его автономную отладку. Время выполнения этих этапов зависит от имеющегося набора апробированных функционально-топологических модулей, опыта и квалификации разработчика. На этапе ввода принципиальной схемы и разработки топологии используются, как правило, распространенные системы проектирования типа «ACCEL EDA» или «OrCad».
Автономная отладка аппаратуры на основе МК с открытой архитектурой предполагает контроль состояния много разрядных магистралей адреса и данных с целью проверки правильности обращения к внешним ресурсам памяти и периферийным устройствам. Закрытая архитектура МК предполагает реализацию большинства функций разрабатываемого устройства внутренними средствами микроконтроллера. Поэтому разрабатываемый контроллер будет иметь малое число периферийных ИС, а обмен с ними будет идти преимущественно по последовательным интерфейсам. Здесь на первый план выйдут вопросы согласования по нагрузочной способности параллельных портов МК и отладка алгоритмов обмена по последовательным каналам.
6.1.3. Разработка и отладка программного обеспечения
Содержание этапов разработки программного обеспечения, его трансляции и отладки на моделях существенно зависит от используемых системных средств. В настоящее время ресурсы 8-разрядных МК достаточны для поддержки программирования на языках высокого уровня. Это позволяет использовать все преимущества структурного программирования, разрабатывать программное обеспечение с использованием раздельно транслируемых модулей. Одновременно продолжают широко использоваться языки низкого уровня типа ассемблера, особенно при необходимости обеспечения контролируемых интервалов времени. Задачи предварительной обработки данных часто требуют использования вычислений с 1 плавающей точкой, трансцендентных функций.
В настоящее время самым мощным средством разработки программного обеспечения для МК являются интегрированные среды разработки, имеющие в своем составе менеджер проектов, текстовый редактор и симулятор, а также допускающие подключение компиляторов языков высокого уровня типа Паскаль или Си. При этом необходимо иметь в виду, что архитектура многих 8-разрядных МК вследствие малого количества ресурсов, страничного распределения памяти, неудобной индексной адресации и некоторых других архитектурных ограничений не обеспечивает компилятору возможности генерировать эффективный код. Для обхода этих ограничений разработчики ряда компиляторов вынуждены были перекладывать на пользователя заботу об оптимизации кода программы.
Для проверки и отладки программного обеспечения используются так называемые программные симуляторы, предоставляющие пользователю возможность выполнять разработанную программу на программно-логической модели МК. Программные симуляторы распространяются, как правило, бесплатно и сконфигурированы сразу на несколько МК одного семейства. Выбор конкретного типа МК среди моделей семейства обеспечивает соответствующая опция меню конфигурации симулятора. При этом моделируется работа ЦП, всех портов ввода/вывода, прерываний и другой периферии. Карта памяти моделируемого МК загружается в симулятор автоматически, отладка ведется в символьных обозначениях регистров.
Загрузив программу в симулятор, пользователь имеет возможность запускать ее в пошаговом или непрерывном режимах, задавать условные или безусловные точки останова, контролировать и свободно модифицировать содержимое ячеек памяти и регистров симулируемого МК.
6.1.4. Методы и средства совместной отладки аппаратных и программных средств
Этап совместной отладки аппаратных и программных средств в реальном масштабе времени является самым трудоемким и требует использования инструментальных средств отладки. К числу основных инструментальных средств отладки относятся:
• внутрисхемные эмуляторы;
• платы развития (оценочные платы);
• мониторы отладки;
• эмуляторы ПЗУ.
Внутрисхемный эмулятор — программно-аппаратное средство, способное заменить эмулируемый МК в реальной схеме. Стыковка внутрисхемного эмулятора с отлаживаемой системой производится при помощи кабеля со специальной эмуляционной головкой, которая вставляется вместо МК в отлаживаемую систему. Если МК нельзя удалить из отлаживаемой системы, то использование эмулятора возможно, только если этот микроконтроллер имеет отладочный режим, при котором все его выводы находятся в третьем состоянии. В этом случае для подключения эмулятора используют специальный адаптер клипсу, который подключается непосредственно к выводам эмулируемого МК.
Внутрисхемный эмулятор — это наиболее мощное и универсальное отладочное средство, которое делает процесс функционирования отлаживаемого контроллера прозрачным, т.е. легко контролируемым, произвольно управляемым и модифицируемым.
Платы развития, или, как принято их называть в зарубежной литературе, оценочные платы (Evaluation Воаrds), являются своего рода конструкторами для макетирования электронных устройств. Обычно это печатная плата с установленным на ней МК и всей необходимой ему стандартной периферией. На этой плате также устанавливают схемы связи с внешним компьютером. Как правило, там же имеется свободное поле для монтажа прикладных схем пользователя. Иногда предусмотрена уже готовая разводка для установки дополнительных устройств, рекомендуемых фирмой. Например, ПЗУ, ОЗУ, ЖКИ-дисплей, клавиатура, АЦП и др. Кроме учебных или макетных целей, такие доработанные пользователем платы можно использовать в качестве одноплатных контроллеров, встраиваемых в мало серийную продукцию.
Для большего удобства платы развития комплектуются еще и простейшим средством отладки на базе монитора отладки. Используются два типа мониторов отладки: один для МК, имеющих внешнюю шину, а второй для МК, не имеющих внешней шины.
В первом случае отладочный монитор поставляется в виде микросхемы ПЗУ, которая вставляется в специальную розетку на плате развития. Плата также имеет ОЗУ для программ пользователя и канал связи с внешним компьютером или терминалом. Во втором случае плата развития имеет встроенные схемы программирования внутреннего ПЗУ МК, которые управляются от внешнего компьютера. При этом программа монитора просто заносится в ПЗУ МК совместно с прикладными кодами пользователя. Прикладная программа должна быть специально подготовлена: в нужные места необходимо вставить вызовы отладочных подпрограмм монитора. Затем осуществляется пробный прогон. Чтобы внести в программу исправления, пользователю надо стереть ПЗУ и произвести повторную запись. Готовую прикладную программу получают из отлаженной путем удаления всех вызовов мониторных функций и самого монитора отладки.
Возможности отладки, предоставляемые комплектом «плата развития плюс монитор», не столь универсальны, как возможности внутрисхемного эмулятора, да и некоторая часть ресурсов МК в процессе отладки отбирается для работы монитора. Тем не менее, наличие набора готовых программно-аппаратных средств, позволяющих без потери времени приступить к монтажу и отладке проектируемой системы, во многих случаях является решающим фактором. Особенно если учесть, что стоимость такого комплекта несколько меньше, чем стоимость более универсального эмулятора.
Эмулятор ПЗУ — программно-аппаратное средство, позволяющее замешать ПЗУ на отлаживаемой плате, и подставляющее вместо него ОЗУ, в которое может быть загружена программа с компьютера через один из стандартных каналов связи. Это устройство позволяет пользователю избежать многократных циклов перепрограммирования ПЗУ. Эмулятор ПЗУ нужен только для МК, которые могут обращаться к внешней памяти программ. Это устройство сравнимо по сложности и по стоимости с платами развития и имеет одно большое достоинство: универсальность. Эмулятор ПЗУ может работать с любыми типами МК.
Эмулируемая память доступна для просмотра и модификации, но контроль над внутренними управляющими регистрами МК был до недавнего времени невозможен.
В последнее время появились модели интеллектуальных эмуляторов ПЗУ, которые позволяют «заглядывать» внутрь МК на плате пользователя. Интеллектуальные эмуляторы представляют собой гибрид из обычного эмулятора ПЗУ, монитора отладки и схем быстрого переключения шины с одного на другой. Это создает эффект, как если бы монитор отладки был установлен на плате пользователя и при этом он не занимает у МК никаких аппаратных ресурсов, кроме небольшой зоны программных шагов, примерно 4К.
Этап совместной отладки аппаратных и программных средств в реальном масштабе времени завершается, когда аппаратура и программное обеспечение совместно обеспечивают выполнение всех шагов алгоритма работы системы. В конце этапа отлаженная программа заносится с помощью программатора в энергонезависимую память МК, и проверяется работа контроллера без эмулятора. При этом используются лабораторные источники питания. Часть внешних источников сигналов может моделироваться.
Этап интеграции разработанного контроллера в изделие заключается в повторении работ по совместной отладке аппаратуры и управляющей программы, но при работе в составе изделия, питании от штатного источника и с информацией от штатных источников сигналов и датчиков.
Состав и объем испытаний разработанного и изготовленного контроллера зависит от условий его эксплуатации и определяется соответствующими нормативными документами. Проведение испытаний таких функционально сложных изделий, как современные контроллеры, может потребовать разработки специализированных средств контроля состояния изделия во время испытаний.
Лекция 12. Разработка программного обеспечения для PIC-микроконтроллеров
В этой лекции рассматриваются основные этапы разработки программного обеспечения микроконтроллеров, а также приводится обзор основных программ для разработки и отладки программного обеспечения PIC-микроконтроллеров.
Ключевые слова: разработка, программное обеспечение, ассемблер, симулятор.
6.2. Разработка программного обеспечения для PIG-микроконтроллеров
Разработка программного обеспечения является центральным моментом общего процесса проектирования. Центр тяжести функциональных свойств современных цифровых систем находится именно в программных средствах.
Основным инструментом для профессиональной разработки программ является ассемблер, предполагающий детализацию на уровне команд МК. Только ассемблер позволяет максимально использовать ресурсы кристалла.
Для микроконтроллеров PIC выпущено большое количество различных средств разработки. В данной главе речь пойдет о средствах, предоставляемых фирмой Microchip, которые весьма эффективны и широко используются на практике.
Ассемблер MPASM представляет собой интегрированную программную среду для разработки программных кодов PIC микроконтроллеров всех семейств. Выпускается фирмой Microchip в двух вариантах: для работы под DOS и для работы под Windows 95/98/NT. Ассемблер MPASM может использоваться как самостоятельно, так и в составе интегрированной среды разработки MPLAB. Он включает несколько программ: собственно MPASM, MPLINK и MPLIB, причем каждая из них обладает собственным интерфейсом.
Программа MPASM может использоваться для двух целей:
• генерации исполняемого (абсолютного) кода, предназначенного для записи в МК с помощью программатора;
• генерации перемещаемого объектного кода, который затем будет связан с другими ассемблированными или компилированными модулями.
Исполняемый код является для MPASM выходным кодом по умолчанию. При этом все переменные источника должны быть явно описаны в тексте программы или в файле, подключаемом с помощью директивы INCLUDE <filename>. Если при ассемблировании не выявляется ошибок, то генерируется выходной .hex-файл, который может быть загружен в МК с помощью программатора.
При использовании ассемблера MPASM в режиме генерации перемещаемого объектного кода формируются объектные модули, которые могут быть впоследствии объединены с другими модулями при помощи компоновщика MPLINK. Программа-компоновщик MPLINK преобразует перемещаемые объектные коды в исполняемый бинарный код, привязанный к абсолютным адресам МК. Библиотечная утилита MPLIB позволяет для удобства работы сгруппировать перемещаемые объекты в один файл или библиотеку. Эти библиотеки могут быть связаны компоновщиком MPLINK в файл выходного объектного кода ассемблера MPASM.
Программы MPASM и MPLINK доступны через оболочку MPASM, тогда как MPLIB доступна только со своей командной строки.
Исходным файлом для ассемблера MPASM по умолчанию является файл с расширением .ASМ. Текст исходного файла должен соответствовать требованиям синтаксиса, приведенным далее.
Ассемблер MPASM может быть вызван командной строкой
MPASM [/<Option>[ /<Option>...]] <file_name>
где /<Option> означает выбор режима работы ассемблера в командной строке; <file_name> — имя файла на ассемблирование.
Режимы работы ассемблера, выбранные по умолчанию, приведены в табл. 6.1.
Здесь и далее используются следующие соглашения по использованию символов:
[ ] — для аргументов по выбору;
< > — для выделения специальных ключей <ТАВ>, <ESC) или дополнительного выбора;
| — для взаимоисключающих аргументов (выбор ИЛИ);
строчные символы — для обозначения типа данных.
Выбор по умолчанию, приведенный в табл. 6.1, может быть изменен командной строкой:
/<option> разрешает выбор;
/<option>+ разрешает выбор;
/<option> — запрещает выбор.
Исходный ассемблерный файл создается с использованием любого ASCII текстового редактора. Каждая линия исходного файла может содержать до четырех типов информации:
• метки (labels)
• мнемоника (mnemonics)
• операнды (operands)
• комментарий (comments)
Порядок и положение каждого типа имеет значение. Метка должна начинаться в колонке номер один. Мнемоника может начинаться в колонке два или далее. Операнды идут за мнемоникой. Комментарий может следовать за операндом, мнемоникой или меткой или может начинаться в любом столбце, если в качестве первого не пустого символа используется * или;.
Максимальная длина строки 255 символов.
Один или несколько пробелов должны отделять метку и мнемонику или мнемонику и операнд(ы). Операнды могут отделяться запятой. Например:
Метки
В поле метки размещается символическое имя ячейки памяти, в которой хранится отмеченный операнд. Все метки должны начинаться в колонке 1. За ними может следовать двоеточие (:), пробел, табуляция или конец строки. Комментарий может также начинаться в колонке 1, если используется одно из обозначений комментария.
Метка может начинаться с символа или нижнего тире (_) и содержать буквенные символы, числа, нижние тире и знак вопроса. Длина метки может быть до 32 символов.
Мнемоники представляют собой мнемонические обозначения команды, которые непосредственно транслируются в машинный код. Мнемоники ассемблерных инструкций, директивы ассемблера и макровызовы должны начинаться, по крайней мере, в колонке 2. Если есть метка на той же линии, она должна быть отделена от 'этой метки двоеточием или одним или более пробелами или табуляцией.
В этом поле определяются операнды (или операнд), участвующие в операции. Операнды должны быть отделены от мнемоники одним или более пробелами или табуляцией. Операнды отделяются друг от друга запятыми. Если операция требует фиксированного номера (числа) или операндов, то все на линии после операндов игнорируется. Комментарии разрешаются в конце линии. Если мнемоники позволяют использовать различное число операндов, конец списка операндов определяется концом строки или комментарием.
Выражения используются в поле операнда и могут содержать константы, символы или любые комбинации констант и символов, разделенных арифметическими операторами. Перед каждой константой или символом может стоять + или -, что указывает на положительное или отрицательное выражение.
В ассемблере MPASM используются следующие форматы выражений:
• текстовая строка;
• числовые константы и Radix;
• арифметические операторы и приоритеты;
• High / Low операторы.
Текстовая строка — это последовательность любых допустимых АЯСII символов (в десятичном диапазоне от 0 до 127), заключенная в двойные кавычки. Строка может иметь любую длину в пределах 132 колонок. При отсутствии ограничения строки она считается до конца линии. Если строка используется как буквенный операнд, она должна иметь длину в один символ, иначе будет ошибка.
Числовая константа представляет собой число, выраженное в некоторой системе счисления. Перед константой может стоять + или -. Промежуточные величины в константах рассматриваются как 32-разрядные целые без знака.
MPASM поддерживает следующие системы счисления (представления значений или Radix): шестнадцатеричную, десятичную, восьмиричную, двоичную и символьную. По умолчанию принимается шестнадцатеричная система. Табл. 6.2 представляет различные системы счисления.
Операторы — это арифметические символы, подобные + и —, которые используются при формировании выражений. Каждый оператор имеет свой приоритет. В общем случае приоритет устанавливается слева направо, а выражения в скобках оцениваются первыми. В табл. 6.3 приведены обозначения, описания и примеры применения основных операторов MPASM.
Операторы high, low и upper используются для получения одного байта из многобайтного значения, соответствующего метке. Применяются для управления расчетом точек динамического перехода при чтении таблиц и записи программ.
Операторы инкремента и декремента могут применяться к переменной только в качестве единственного оператора в строке. Они не могут быть встроенным фрагментом более сложного выражения.
Поле комментария может использоваться программистом для текстового или символьного пояснения логической организации программы. Поле комментария полностью игнорируется ассемблером, поэтому в нем можно применять любые символы. Комментарии, которые используются в строке сами по себе, должны начинаться с символа комментария (* или ;). Комментарии в конце строки должны быть отделены от остатка строки одним или более пробелами или табуляцией.
Расширения файлов, используемые MPASM и утилитами
Существует ряд расширений файлов, применяемых по умолчанию MPASM и связанными утилитами. Назначения таких расширений приведены в табл. 6.4.
Листинг представляет собой текстовый файл в формате ASCII, который содержит машинные коды, сгенерированные в соответствии с каждой ассемблерной командой, директивой ассемблера или макрокомандой исходного файла. Файл листинга содержит: имя продукта и версии, дату и время, номер страницы вверху каждой страницы.
В состав листинга входят также таблица символов и карта использования памяти. В таблице символов перечисляются все символы, которые есть в программе, и где они определены. Карта использования памяти дает графическое представление о расходовании памяти МК.
Директивы языка — это ассемблерные команды, которые встречаются в исходном коде, но не транслируются прямо в исполняемые коды. Они используются ассемблером при трактовке мнемоники входного файла, размещении данных и формировании файла листинга.
Существует четыре основных типа директив в MPASM:
• директивы данных;
• директивы листинга;
• управляющие директивы;
• макро-директивы.
Директивы данных управляют распределением памяти и обеспечивают доступ к символическим обозначениям данных.
Директивы листинга управляют листингом файла MPASM и форматом. Они определяют спецификацию заголовков, генерацию страниц и другие функции управления листингом.
Директивы управления позволяют произвести секционирование обычного ассемблерного кода.
Макро-директивы управляют исполнением и распределением данных в пределах определений макротела.
Ниже приводится описание некоторых директив ассемблера MPASM, используемых в данном учебном пособии.
СОDЕ — начало секции объектного кода
Синтаксис:
[<label>] code [ROM address>]
Используется при генерации объектных модулей. Объявляет начало секции программного кода. Если <label> не указана, секция будет названа .code Стартовый адрес устанавливается равным указанному значению или нулю, если адрес не был указан.
Пример:
ВЕЗЕТ code Н'01FF'
goto START
#DEFINE — определить метку замены текста
Синтаксис:
#define <name> [<string>]
Директива задает строку <string>, замещающую метку <name> всякий раз, когда та будет встречаться в исходном тексте.
Символы, которые определены директивой #DEFINE, не могут быть просмотрены симулятором. Используйте вместо этой директивы EQU.
Пример:
#define length 20
#define control 0х19,7
#define position (Х,Y,Z) (у-(2 * Z+X)).
test_label dw position(1, length, 512)
bsf control ;установить в 1 бит 7 в 119
END — конец программного блока
Синтаксис:
end
Определяет конец программы. После остановки программы таблица символов сбрасывается в файл листинга.
Пример:
start
;исполняемый код
end ;конец программы
EQU — определить ассемблерную константу
Синтаксис:
<label> equ <expr>
Здесь <ехрг> — это правильное MPASM выражение. Значение выражения присваивается метке <label>.
Пример:
four equ 4 ; присваивает численное значение метке four
INCLUDE — включить дополнительный файл источника
Синтаксис:
include « include file»
include "<include file>"
Определяемый файл считывается как источник кода. По окончании включаемого файла будет продолжаться ассемблирование исходника. Допускается до шести уровней вложенности. <include_file> может быть заключен в кавычки или угловые скобки. Если указан полный путь к файлу, то поиск будет происходить только по этому пути. В противном случае порядок поиска следующий: текущий рабочий каталог, каталог, в котором находится исходник, каталог MPASM.
Пример:
include "с:\sys\sysdefs. ins"; system defs
include <addmain.asm>; register defs
LIST — установить параметры листинга
Синтаксис:
list [<list option>,, <list option>]
Директива <list> разрешает вывод листинга, если он до этого был запрещен. Кроме того, один из параметров листинга может быть изменен для управления процессом ассемблирования в соответствии с табл. 6.5.
NOLIST — выключить выход листинга
Синтаксис:
NOLIST
ORG — установить начальный адрес программы
Синтаксис:
<label> org <expr>
Устанавливает начальный адрес программы для последующего кода в соответствии с адресом в <expr>. MPASM выводит перемещаемый объектный код, а MPLIN K разместит код по определенному адресу. Если метка <label> определена, то ей будет присвоена величина <expr>. По умолчанию начальный адрес имеет нулевое значение. Директива может не использоваться, если создается объектный модуль.
Пример:
Int_1 org 0х20; Переход по вектору 20
Int_2 org int 1+0x10; Переход по вектору 30
PROCESSOR — установить тип процессора
Синтаксис:
processor <processor_tуре>
Устанавливает тип используемого процессора <processor_tуре>:
[16C54 | 16С55 | 16С56 |16С57 | 16С71 | 16С84 | 16F84 | 17C42]. Общие
процессорные семейства могут быть выбраны как: [16С5Х | 16СХХ | 17CXX] Для поддержания совместимости с новыми изделиями выбирается максимум доступной памяти.
SET — определить ассемблерную переменную
Синтаксис:
<label> set <expr>
Директива SET функционально эквивалентна директиве EQU, за исключением того, что величина, определяемая SET, может быть изменена директивой SET.
Пример:
area set 0
widthset 0x12
length set 0х14
area set length * width
length set length+ 1
TITLE — Определить программный заголовок
Синтаксис:
title "<title_text>"
Эта директива устанавливает текст, который используется в верхней линии страницы листинга. <title_text> — это печатная ASCII последовательность, заключенная в двойные скобки. Она может быть до 60 символов длиной.
Пример
title "operational code, rev 5.0"
Абсолютный (неперемещаемый) код программы генерируется непосредственно при ассемблировании и располагается в программной памяти в порядке следования операторов программы. Операторы перехода на метку сразу же заменяются соответствующим кодом перехода на адрес метки.
При генерации перемещаемого кода каждая секция программного кода должна предваряться директивой СОDЕ. Окончательное размещение программных кодов, расстановку физических адресов переходов выполняет компоновщик MPLINK.
Компоновщик MPLINK выполняет следующие задачи:
• распределяет коды и данные, т.е. определяет, в какой части программной памяти будут размещены коды и в какую область ОЗУ будут помещены переменные;
• распределяет адреса, т.е. присваивает ссылкам на внешние объекты в объектном файле конкретные физические адреса;
• генерирует исполняемый код, т.е. выдает файл в формате .hex, который может быть записан в память МК;
• отслеживает конфликты адресов, т.е. гарантирует, что программа или данные не будут размещаться в пространстве адресов, которое уже занято;
• предоставляет символьную информацию для отладки.
Для более подробного изучения работы компоновщика следует обратиться к специальной литературе.
6.2.3. Менеджер библиотек MPLIB
Менеджер библиотек позволяет создавать и модифицировать файлы библиотек. Библиотечный файл является, коллекцией объектных модулей, которые размещены в одном файле. MPLIB использует объектные модули с именем типа «filename.o» формата COFF (Common Object File Format).
Использование библиотечных файлов упрощает компоновку программы, делает ее более структурированной и облегчает ее модификацию.
Симулятор MPSIM представляет собой симулятор событий, предназначенный для отладки программного обеспечения PIC-контроллеров. MPSIM моделирует все функции контроллера, включая все режимы сброса, функции таймера/счетчика, работу сторожевого таймера, режимы SLEEP и Power-down, работу портов ввода/вывода.
MPSIM запускается из командной строки DOS, конфигурируется пользователем и непосредственно применяет выходные данные ассемблера MPASM.
Перед использованием симулятора необходимо отассемблировать исходный файл <file_name>.asm и получить файл объектного кода в формате INHX8M, создаваемый MPASM по умолчанию:
MPASM <file_name>.asm <RETURN>
Чтобы запустить симулятор, необходимо набрать в командной строке
MPSIM < RETURN >.
Вид экрана, получаемого при запуске МРSIМ, показан на рис. 6.2. Экран
разделен на три части, или окна. В верхнем окне показано текущее состояние моделирования, включая моделируемую программу, тип МК, число выполненных командных циклов и затраченное на них время. Среднее окно используется для вывода содержимого регистров пользователя. Набор регистров и формат выводимых на экран данных определяются файлом MPSIM.INI, который далее будет описан подробнее. Нижнее окно содержит приглашение на ввод команд, а также текущие операции и результат их выполнения.
При запуске симулятор MPSIM начинает искать командный файл MPSIM. INI. Этот текстовой файл создается пользователем и используется для задания всех задействованных в программе параметров.
В представленном файле указаны: тип микроконтроллера, система счисления данных по умолчанию, регистры, содержимое которых выводится на экран, способ представления данных, рабочие параметры. Любая команда, которая исполняется MPSIM, может быть задана в файле МРSIМ.INI, который определяет начальное состояние программы. При работе MPSIM создает файл МРSIM.JRN, в котором сохраняются все сведения о нажатии клавиш в процессе работы.
В файле MPSIM.INI допускается вводить комментарии, которые даются после знака «;», но не допускается использование пустых строк.
Основные команды, применяемые в симуляторе MPSIM, приведены в табл. 6.6. Когда эти команды вводятся в сеансе работы с MPSIM, они заносятся в файл MPSIM.JRN, который используется при создании расширенного файла MPSIM.INI. Данный файл можно задействовать для выявления ошибок и обеспечения нормального выполнения программы после исправления кода.
Для моделирования внешних тестовых событий (воздействий) на моделируемый МК используются файлы стимуляции с расширением .STI. Эти файлы используются MPSIM для того, чтобы обеспечить подачу однократных и повторяющихся входных сигналов в процессе выполнения программы. При этом можно наблюдать на экране, как МК реагирует на сигналы.
В качестве примера ниже приведен файл для тестирования программы, выполняющей опрос состояния линии 1 порта А.
Файл воздействия состоит из множества состояний, для которых задается параметр STEP, определяющий число циклов, в течение которых поддерживается указанное состояние. Он позволяет одновременно подавать сигналы на различные выводы МК. В файле воздействия можно указать любой вывод МК, в том числе и вывод сброса ( _MCLR). Для обозначения комментариев используется знак !.