Разработка и отладка программы реализации логического уравнения для выбранного микроконтроллера

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

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

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

Если МК имеет гарвардскую архитектуру, то память программ и данных физически и логически разделены. Память данных обычно имеет ограниченный объем. Это обстоятельство нужно учитывать при разработке программ для МК. Так, при программировании МК константы лучше хранить не как переменные, а заносить в ПЗУ программ. Прикладные программы должны ориентироваться на работу без использования больших массивов данных.

В памяти данных МК также находится стек. Стековая память обычно имеет ограниченный объем. Разработчик микроконтроллерных систем должен следить за тем, чтобы стек не переполнялся. При разработке программ для компьютеров наполняемость стека контролируется интегрированной средой программирования.

Также следует следить за правильностью указания типов переменных. Если тип переменной указан некорректно, то можно испортить хранимые в памяти данные. Желательно избегать вычислений с плавающей запятой, упрощать задачи деления, умножения и вычитания. Выражения с условиями лучше записывать с указанием равенства или неравенства нулю, поскольку условные переходы, которые получаются при компилировании условных конструкций языка С, выполняются по нулевому или ненулевому результату в аккумуляторе микроконтроллера. Все это позволяет при компилировании получать максимально «быстрый» код.

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

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

Следует заметить, что алгоритмы программ для МК отличаются от алгоритмов программ для универсальных компьютеров. При выполнении программы на универсальном компьютере ее запуск, взаимодействие с внешними и внутренними устройствами, и с человеком выполняет операционная система. Программа, написанная для МК, решает эти задачи самостоятельно. В компьютере программа в определенный момент времени запускается и завершается. Программа, управляющая МК, запускается при включении устройства и не завершает свою работу, пока не будет выключено питание. Она как бы «наблюдает» за использованием ресурсов микроконтроллерной системы, поэтому ее иногда называют «монитором». Схема алгоритма программы-монитора приведена на рис.2.

Рис. 2. Схема работа программы–монитора

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

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

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

Использование временных слотов позволяет реализовать устройства, имеющих различное время реакции или опроса. Однако при этом возникают сложности. Часто сигнал на входе МК длится всего несколько микросекунд. В то же время временной интервал между приходами сигналов может быть достаточно большой. Для решения возникших трудностей в МК предусмотрен механизм прерываний основной программы.

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

Рис. 3. Схема реализации параллельных программных потоков

В настоящее время самым мощным средством разработки программного обеспечения для МК являются интегрированные среды разработки, имеющие в своем составе менеджер проектов, текстовый редактор и симулятор, а также допускающие подключение компиляторов языков высокого уровня типа Паскаль или Си. При этом необходимо иметь в виду, что архитектура многих 8-разрядных микроконтроллеров вследствие малого количества ресурсов, страничного распределения памяти, неудобной индексной адресации и некоторых других архитектурных ограничений не обеспечивает компилятору возможности генерировать эффективный код. Для обхода этих ограничений разработчики ряда компиляторов вынуждены были переложить на пользователя заботу об оптимизации кода программы.

Для проверки и отладки программного обеспечения используются так называемые программные симуляторы, предоставляющие пользователю возможность выполнять разработанную программу на программно-логической модели МК. Программные симуляторы распространяются, как правило, бесплатно и сконфигурированы сразу на несколько микроконтроллеров одного семейства. Выбор конкретного типа МК среди моделей семейства обеспечивает соответствующая опция меню конфигурации симулятора. При этом моделируется работа ЦП, всех портов ввода/вывода, прерываний и другой периферии. Карта памяти моделируемого МК загружается в симулятор автоматически, отладка ведется в символьных обозначениях регистров.

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

Так, например, при работе с семейством iMCS-51 (ВЕ51), ARM удобно использовать интегрированную среду Keil uVision. Keil uVision позволяет работать с проектами любой степени сложности, начиная с введения и правки исходных текстов и заканчивая внутрисхемной отладкой кода и программированием ПЗУ микроконтроллера. От разработчика скрыта большая часть второстепенных функций, что сильно разгружает интерфейс и делает управление интуитивно понятным. Однако при возрастании сложности реализуемых задач, всегда можно задействовать весь потенциал модулей, функционирующих под управлением единой оболочки. Среди основных программных средств Keil uVision можно отметить приведенные ниже.

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

2. Менеджер проектов, служащий для объединения отдельных текстов программных модулей и файлов в группы, обрабатываемые по единым правилам. Подобная группировка позволяет намного лучше ориентироваться среди множества файлов.

3. Встроенный редактор, облегчающий работу с исходным текстом за счет использования многооконного интерфейса, выделения синтаксических элементов шрифтом и цветом. Существует опция настройки в соответствии со вкусами разработчика. Редактирование остается доступным и во время отладки программы, что позволяет сразу исправлять ошибки или отмечать проблемные участки кода.

4. Средства автоматической компиляции, ассемблирования и компоновки проекта, которые предназначены для создания исполняемого (загрузочного) модуля программы. При этом между файлами автоматически генерируются новые ассемблерные и компиляторные связи, которые в дальнейшем позволяют обрабатывать только те файлы, в которых произошли изменения, или файлы, находящиеся в зависимости от изменённых. Функция глобальной оптимизации проекта позволяет достичь наилучшего использования регистров микроконтроллера путем неоднократной компиляции исходного кода. Компиляторы uVision работают с текстами, написанными на Си или ассемблере для контроллеров семейств ARM, MSC51, C166 и многих других. Кроме того возможно использование компиляторов других производителей.

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

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

Среда программирования разработана компанией Keil, которая была основана в Мюнхене в 1982 году братьями Гюнтером и Рейнхардом. В октябре 2005 года Keil вошла в состав американской корпорации ARM.

Программа Keil uVision является платной и очень дорогой. По ссылке ниже, после заполнения анкеты, можно скачать демонстрационную версию, в которой присутствует ряд ограничений и основное из них – 32 КБ на размер программы.

Среда разработки Keil uVision представлена на английском языке и работает на персональных компьютерах под управлением только операционной системы Windows версий 2000, XP, Vista и 7.

Распространение программы: Shareware (платная). Есть демоверсия с рядом ограничений, в т.ч. на размер кода — не более 32 КБ.

Видео:Логические выражения, таблицы истинности ,структурная логическая схемаСкачать

Электроника для всех

Видео:Основы программирования микроконтроллеров. Лекция в МИРЭАСкачать

Блог о электронике

Видео:Введение в AVR микроконтроллерыСкачать

AVR. Учебный Курс. Отладка программ. Часть 1

У каждого случалась такая ситуация — программа вроде бы написана, даже компилится, но не работает. Почему не работает? Дак все же просто — в ней есть лажа!

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

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

Метод 0. Тупление в код (Аналитический)
К моему великому удивлению, данный метод является наиболее популярным в народе и, а у начинающих порой единственным.
Видимо сказывается засилье всяких высокоуровневых языков вроде ПОХАПЭ или Си, где такое вполне может и проканать. Там да, можно пофтыкать несколько минут в исходник, глядишь да найдешь где накосячил.

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

И вот тут мозг срывает напрочь. С непривычки голова пухнет от попытки удержать в памяти состояние регистров, флагов, попыток просчитать куда пойдет ядро на следующем шаге.

Из этого же лезет народ убежденность в том, что ассемблерные программы сложны в написании и отладке.

Хотя я, в свое время, изучал ассемблер вообще без компа — не было его у меня. Тетрадка в клеточку, команды i8008 в столбик. А потом и Z80 с его божественным ассемблером. И опять без отладчиков, аналитически. Ляпота! Но вот когда я сел за ассемблер 80С51, в первую же очередь я нашел нормальную IDE с эмуляцией — Keil uVision. А эра х86 прошла под знаменем Borland Turbo Debugger и TASM. Когда моя первая 128 байтная интруха полыхнула по экрану пиксельным пламенем клеточного автомата… да ощущения были еще те. Где то ее сорцы валяются, надо поискать.

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

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

Под каждый стиль написания кода свои инструменты отладки. Поэтому переходим к другому методу.

Метод 1. Лопата — бери и копай (Трассировка)
Не можешь понять как будет вести код? Как сработают условия? Как пойдет ветвление? Что будет в регистрах?

Что тут думать? Выполни в эмуляторе и все! Какая-нибудь AVR Studio идеально для этого сгодится.

Компилируй программу и запускай на выполнение, а дальше выполняй ее пошагово, наблюдая за регистрами, флагами, переменными. Да за чем угодно, все в твоей власти.

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

Трассировка
Активно используй не только пошаговую трассировку (F11), но и такие удобные фичи как трассировка до курсора (Ctrl+F10), позволяющая сразу же выполнить весь код до курсора. Правда может застрять в каком нибудь цикле по пути. Но можно нажать на паузу и вытащить трассировщик из цикла вручную (выставив флаги так, чтобы произошел нужный нам переход).

Обход ненужных условий
Условия, встречающиеся на пути, довольно легко обходятся путем установки вручную нужных флагов. А если логика отлаживаемого участка от этого не пострадает, то можно и временно закомментить мешающий код. Если до нужного участка кода предстоит продраться через несколько десятков условий, то можно облегчить себе задачу, воткнув сразу же после всех нужных инициализаций секцию DEBUG

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

Генерация прерываний
Если нужно отлаживать прерывание, то необязательно этого прерывания дожидаться. Помни, что вызов прерывания делается установкой флага в соответствующем регистре. Т.е. хочешь ты сэмулировать прием байта по UART — тыкай на бит RXC регистра UCSRA и вот у тебя на следующем же шаге произошло прерывание. Разумеется если оно разрешено локально и глобально.

Если хочешь запустить прерывание в случайный момент. То нет ничего проще — запусти программу на исполнение (F5) через пару секунд тупления в монитор нажми паузу (Ctrl+F5), тычком по нужному биту сгенерь прерывание, а дальше пошагово влезь в обработчик и позырь что там происходит. После чего проверь, что выход из прерывания произошел корректно и пусти прогу пастись дальше.

Ускоряй процессы
Многие процессы на трассировке идут весьма длительно. Например, в режиме скоростного прогона (F5) эмуляция секунды на моем компе (AThlonXP 1300+/512DDRPC3200) идет около минуты, если не больше. Разумеется ждать столько западло.

Но зачем ждать? если алгоритм задержки верен, то что нам мешает взять и уменьшить время с секунд до десятков миллисекунд?
Если задержка сделана на таймере, то можно временно уменьшить предделители таймеров в 1. Или даже выставить другие значения уставок. Главное, не забыть вернуть все как было.

Остановка по требованию
Это в маршрутках остановок «Здеся» и «тута» не существует. В нашей же симуляции мы можем выгрузиться в пошаговый режим где угодно, хоть посреди МКАД в час пик. Достаточно применить волшебный щелчок по почкам.

Используй брейкпоинты или точки останова. Их можно ставить на произвольные участки кода и в режиме запуска на автомате (F5) симулятор сам воткнется в ближайший брейкпоинт. А дальше вручную, пошагово, проходим трудный участок. Выясняя почему он работает не так.

Причем брейкпоинты можно ставить не только на участки кода, но и на события происходящие в регистрах. Это, так называемые, Data Breakpoint. Ставятся они из Debug-NewBreakPoint-DataBreakPoint

А там на выбор событий тьма:

Например, хочешь ты поймать событие когда кто то стукнулся в ОЗУ и нагадил, запоров значение. Кто такой поганец? Стек? Где то в коде опечатался и не заметил? Индексный регистр не туда залез?

Чем гадать и тупить в код лучше поставить бряк. Например, загадилась переменная CCNT объявленная в RAM:

Выбираешь тип события, Location is Acessed (доступ к обьекту) в поле location выбираешь объект за которым будем следить В выпавшем списке будут ВСЕ твои символические имена используемые в программе. В том числе и наши CCNT и TCNT. Надо только внимательно поискать — они там не в алфавитном порядке, а черт знает в каком.

Дальше выбираешь тип доступа к переменной (Access Type) — чтение или запись, а может и то и другое. Также можно указать тип данной переменной или ее байтовый размер.

А еще можно в памяти разметить колышками Start Addr — End Addr (в графе Custom Scope) делянку, где наша конопля растет. И как только туда кто сунется — алярм, ловить и пинать по почкам.

А через контекстное меню, можно по быстрому, на любой регистр, ячейку ОЗУ/ПЗУ/EEPROM повесить Data breakpoint. При этом он сразу же появляется в окошке Breakpoints&TracePoints и там уже можно подправить ему конфигурацию как нужно.

Осталось только заполнить графу хитов Break Execution after… Т.е. после скольких событий останавливать трассировку. По умолчанию стоит 1. Но если, например, нам надо пропустить несколько сотен итераций цикла, а на сто первом посмотреть что происходит, то указываем число хитов в 100 и жмем запуск, не страдая фигней на промотке этих итераций.

Есть там еще одна интересная галочка — Continue executions after views have been updated. Она превращает бряк в информер. Думаю ты уже замечал, что когда студия гонит код в режиме выполнения (F5), то данные в окошках периферии и регистрах в реальном времени не меняются. Чтобы увидеть изменения надо поставить программу на паузу.
Так вот, брейкпоинт-информер нужен для принудительного обновления этих значений. Т.е. программа на нем не останавливается, а только лишь обвновляет данные в окошках. Что позволяет динамически наблюдать как данные ползают по памяти, как щелкают таймеры, как тикают регистры.

Своего рода автоматическое пошаговое выполнение (Alt+F5), но обновление не по каждой команде, а по условию. Да, превратить обычный путевой бряк в информер можно, но для этого надо открыть окно управления брейкпоинтами View-Toolbars-Breakpoint&TracePoint. И там уже, найдя наш путевой брейк, даблкликом по нему залезть в свойства.

Там же бряки можно оперативно включать-выключать, что очень удобно. Выключать и включать их также можно по F9.

Пускай на самотек
Если программа в железе ведет себя как то не так, то может у ней крышу сорвало? Когда пишешь на ассемблере (да и на Си тоже, но там поймать сложней) легко ошибиться со стеком или индексным переходом. А сразу не поймаешь. Далеко не факт, что срыв найдется при первом или втором пошаговом прогоне. В этом случае я просто жму запуск симуляции и ухожу нарезать колбаски и чаю налить. Прихожу — жму паузу. Если прога идет по своему циклу, значит все в порядке. Если же произошел срыв, то это будет сразу же видно — трассировщик сойдет с ума и выбросит тебя из исходного кода в дизассемблер, где будет видно, что происходит что то явно не из нашей оперы. Например, выполнение кода там где его нет — за пределами программы. Если такое случилось надо внимательно проверить возможные пути срыва. Наставив брейков на входы-выходы из прерываний, перед и после индексных переходов и так далее.

Еще тут может помочь режим автошага (Alt+F5) нажал его и студия сама начала шустро тикать тактами, сразу же показывая что происходит. Тебе же остается сидеть и тупить в этот телевизор, глядишь найдешь глюк. Пару раз я таким способом отлавливал ошибки атомарного доступа, вылезавшие только в полнолуние и исключительно по спец мантре.

Глядим внимательно
Несмотря на то, что можно тупить в регистры, порты или напрямую в память, делать это все равно неудобно — глаз замыливается разглядывать в этой каше наши значения. Даже несмотря на то, что при изменении они подкрашиваются красным. Тут нам поможет очередной инструмент студии Watch (вызывается по Alt+1). Ватч это гляделка. С ее помощю можно наши выделенные переменные пихать в отдельные окошки, где за ними удобно наблюдать.

Навести гляделку можно на что угодно — на регистр, на ячейку памяти, на порт. При этом мы можем выбирать тип отображения (DEC,HEX,ASCII), что бывает очень удобно.

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

Эмуляция периферии
Внутреннюю периферию отлаживать проще простого — все прерывания вот они, свисают в IO регистрах, дергай не хочу. Регистры там же. А вот внешняя…

Тут все плохо. Дело все в том, что Студия не имеет понятия о том, что есть за ее пределами. Поэтому либо отлаживать периферию ручным тыком по битам в портах (что ужасно муторно), либо юзать примочки вроде HAPSIM или StiGen от ARV. Да, пользуясь моментом, рекомендую прошуршать по сайту arv.radioliga.com — много интересных штуковин. Проблем они всех не решают, но лучше чем ничего.

Трассировка по Сишному коду
А тут все весело. Дело в том, что оптимизатор может так залихватски перелопатить код, что на исходный код он будет походить весьма и весьма отдаленно. Т.е. ты грузишь переменную в одном месте, а компилятор решил это сделать в самом начале программы. Работать то будет так как ты сказал, но вот отлаживать это… Некоторые участки кода вообще будут перепрыгиваться.

Т.к. оптимизатор все заоптимизировал за счет других строк, а промежуточные варианты тебе в виде отчета забыл предоставить.

В общем, я понимаю почему трассировка среди тех кто пытается писать на Си не прижилась. В том виде в каком ее видишь в первый раз пользоваться ей не хочется совершенно. В самом деле, кому охота связываться с дебильным симулятором? Проще уж в код тупить, там хоть какая то логика есть.
Но не стоить хоронить трассировку по высоким языкам раньше времени. Если отбросить приколы с выполнением некоторых участков кода, то все еще вполне ничего. А если выключить на время оптимизацию (параметр -O0), то вообще самое то. Правда отлаживать совсем без оптимизации я бы не советовал.

Т.к. с оптимизатором там есть свои приколы и грабли. И при несоблюдении ряда правил (volatile, пустые циклы и прочие фишечки), код который прекрасно работает без оптимизации на -Os с треском разваливается на куски.

Но общую логику работы программы отследить можно. А учитывая умные гляделки, бряки, информеры… так вообще сказка!

Но это далеко не все методы отладки. А так, самая малость. Однако трассировкой можно выловить 90% проблем связанных с внутренней периферией и алгоритмом работы кода на уровне ядра.

Впереди же будут описаны еще реалтаймовые способы на реальном железе — дебаг выводы, развлекухи с осциллографом, облизывание на логический анализатор и JTAG мониторы.
Не обойду вниманием и симуляторы вроде PROTEUSа, хотя я с недавних пор предпочитаю ими не пользоваться — мне своих глюков хватает.

Спасибо. Вы потрясающие! Всего за месяц мы собрали нужную сумму в 500000 на хоккейную коробку для детского дома Аистенок. Из которых 125000+ было от вас, читателей EasyElectronics. Были даже переводы на 25000+ и просто поток платежей на 251 рубль. Это невероятно круто. Сейчас идет заключение договора и подготовка к строительству!

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

Видео:Программирование микроконтроллеров avr для начинающихСкачать

32 thoughts on “AVR. Учебный Курс. Отладка программ. Часть 1”

а еще навешивание контрольных светодиодов, подмена функций на врапперы с системой логгирования, например, или счетчиком входа/выхода и пр.

Видео:ЯЗЫК АССЕМБЛЕРА за 3 МИНУТЫСкачать

Средства разработки и отладки для однокристальных микроконтроллеров

К числу основных инструментальных средств отладки относятся:

• внутрисхемные эмуляторы.
• программные симуляторы.
• платы развития (оценочные платы).
• мониторы отладки.
• эмуляторы ПЗУ.

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

Внутрисхемные эмуляторы.

Внутрисхемный эмулятор — программно аппаратное средство, способное замещать собой эмулируемый процессор в реальной схеме. Внутрисхемный эмулятор — это наиболее мощное и универсальное отладочное средство.

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

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

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

Как минимум, эмулятор содержит следующие функциональные блоки:

• отладчик.
• узел эмуляции микроконтроллера;
• эмуляционная память;
• подсистема точек останова;

Более продвинутые модели могут содержать дополнительно:

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

Отладчик

Отладчик является своеобразным мостом между разработчиком и отладочным средством. Состав и объем информации, проходящей через средства ввода-вывода, доступность ее для восприятия, контроля, и, при необходимости, для коррекции и модификации — напрямую зависят от свойств и качества отладчика.

Хороший отладчик позволяет осуществлять:

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

Более мощные отладчики, обычно их называют высокоуровневыми (High-Level Debuggers), помимо этого, позволяют:

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

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

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

Эмуляционная память

Наличие эмуляционной памяти дает возможность использовать ее в процессе отладки вместо ПЗУ в отлаживаемой системе, и более того, отлаживать программу без использования реальной системы или ее макета. При необходимости внесения изменений в отлаживаемую программу, достаточно загрузить новую или модифицированную программу в память эмулятора, вместо того чтобы заниматься перепрограммированием ПЗУ. Существуют модели эмуляторов, которые позволяют пользователю «подставлять» вместо ПЗУ эмуляционную память не только целиком, но и поблочно (в некоторых моделях минимальный размер блока может достигать одного байта), в порядке, определенном пользователем. Для этого пользователю достаточно задать распределение памяти данных и памяти программ, в соответствии с которым процессор будет получать доступ и к содержимому ПЗУ в отлаживаемой системе, и к содержимому эмуляционной памяти внутрисхемного эмулятора. Такая память обычно называется памятью с возможностью мэппинга.

Трассировщик

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

Процессор точек останова

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

Профилировщик

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

• количество обращений к различным участкам программы;
• время, затраченное на выполнение различных участков программы.

Анализ статистической информации, поставляемой профилировщиком, позволяет легко выявлять «мертвые» или перенапряженные участки программ, и в результате оптимизировать структуру отлаживаемой программы.

Интегрированная среда разработки

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

Наличие в программной оболочке эмулятора встроенного редактора, встроенного менеджера проектов и системы управления, позволяют существенно облегчить работу разработчика, избавив его от множества рутинных действий. Для разработчика стирается грань между написанием программы, ее редактированием и отладкой. Переход от редактирования исходного текста к отладке и обратно происходит «прозрачно» и синхронно с активизацией соответствующих окон, менеджер проектов автоматически запускает компиляцию по мере необходимости и активизирует соответствующие окна программного интерфейса.

Столь же просто осуществляется и переход к отладке проекта с помощью имеющегося отладчика-симулятора, или приступить к «прошивке» ПЗУ отлаженной программой.

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

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

Возможности «реального» внутрисхемного эмулятора мы проиллюстрируем на примере модели PICE-51.

PICE-51

Внутрисхемный эмулятор 8-разрядных микроконтроллеров семейства 8051

PICE-51 — эмулятор нового поколения, созданный с применением новых технологий разработки аппаратуры и программного обеспечения.

Применение программируемых матриц большой емкости позволило резко сократить размеры эмулятора без какого-либо ущерба его функциональным возможностям, минимизировать отклонения электрических и частотных характеристик эмулятора от характеристик эмулируемого процессора и, тем самым, добиться максимальной точности эмуляции на частотах до 30 Мгц при напряжениях питания от 3.3В до 5В.

Перезагружаемая аппаратная структура эмулятора обеспечивает эмуляцию практически всех микроконтроллеров семейства 8051 как отечественного производства, так и фирм: Intel, Philips, Siemens, Atmel, Dallas, Temic, OKI, AMD, MHS и других.

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

Эмулятор состоит из основной платы размером 80х76мм, сменного адаптера под конкретный процессор и сменной эмуляционной головки под конкретный тип корпуса. На основной плате реализованы: трассировщик, процессор точек останова. Плата сменного адаптера содержит эмулирующий процессор под конкретный тип микроконтроллера. Эмуляционные головки обеспечивают установку эмулятора в колодки DIP и PLCC на плате пользователя. Питание эмулятора осуществляется от блока питания +5В, 0,5А или непосредственно от отлаживаемого устройства. Связь с компьютером — по гальванически развязанному каналу RS-232C на скорости 115 КБод..

ХАРАКТЕРИСТИКИ АППАРАТУРЫ

• Точная эмуляция — отсутствие каких-либо ограничений на использование программой пользователя ресурсов микроконтроллера.
• До 256K эмулируемой памяти программ и данных. Поддержка банкированной модели памяти. Распределение памяти между эмулятором и устройством пользователя с точностью до 1-го байта.
• До 512K аппаратных точек останова по доступу к памяти программ и данных.
• Аппаратная поддержка для отладки программ на языках высокого уровня.
• Трассировка 8 произвольных внешних сигналов.
• 4 выхода синхронизации аппаратуры пользователя.
• Трассировщик реального времени с буфером объемом от 16К до 64K фреймов по 64 бита с доступом «на лету». Трассировка адреса, данных, сигналов управления, таймера реального времени и 8-ми внешних сигналов пользователя.
• Программируемый фильтр трассировки.
• Аппаратный процессор точек останова с возможностью задания сложного условия останова эмуляции по комбинации сигналов адреса, данных, управления, 8-ми внешних сигналов, таймера реального времени, счетчиков событий и таймера задержки.
• Четыре комплексных точки останова, которые могут быть использованы независимо или в комбинациях по условиям AND/OR/IF-THEN.
• 48-разрядный таймер реального времени.
• Прозрачная эмуляция — доступ «на лету» к эмулируемой памяти, точкам останова, процессору точек останова, буферу трассировки, таймеру реального времени.
• Управляемый генератор тактовой частоты для эмулируемого процессора. Возможность плавного изменения тактовой частоты от 500 кГц до 40 МГц.
• Гальванически развязанный от компьютера канал связи RS-232C со скоростью обмена 115 КБод.
• Встроенная система самодиагностики аппаратуры эмулятора.

ХАРАКТЕРИСТИКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

• Программное обеспечение ориентировано на работу в среде Windowsв на IBM-соместимых компьютерах с процессорами типа 386/486/Pentium;
• Встроенный многооконный редактор предназначен для написания исходных текстов программ. Редактор поддерживает операции с блоками текста, поиск/замену, цветовое выделение синтаксических конструкций языка ассемблера и Си;
• Встроенный менеджер проектов обеспечивает автоматическую компиляцию программ. Все опции задаются в диалоговой форме. Переход от редактирования исходного текста к отладке и обратно происходит «прозрачно», т.е. менеджер проектов автоматически запускает компиляцию проекта при необходимости;
• PICE-51 обеспечивает символьную отладку и отладку по исходному тексту для программ, созданных с помощью следующих компиляторов:
  • ассемблер ASM51 фирмы Intel;
  • ассемблер MCA-51 фирмы Фитон/МикроКосм;
  • компилятор PL/M фирмы Intel;
  • ассемблер и компилятор Си фирмы IAR Systems;
  • ассемблер и компилятор Си фирмы Avocet Systems Inc./HiTech;
  • ассемблер и компилятор Си фирмы Keil Software Inc.;
• Автоматическое сохранение и загрузка файлов конфигурации аппаратуры, интерфейса и опций отладки. Обеспечивается совместимость файлов конфигурации с симулятором PDS-51. Обеспечена переносимость проектов между эмулятором PICE-51 и симулятором PDS-51;
• Возможность настройки цветов, шрифтов и других параметров для всех окон одновременно и для каждого окна в отдельности;

Эмулятор снабжен печатным руководством по эксплуатации и контекстным электронным руководством, в которых детально описаны его принципы работы, команды, меню, горячие клавиши.

Структурная схема эмулятора PICE-51

Варианты комплектации эмулятора PICE-51

Сравнительные характеристики некоторых эмуляторов для микроконтроллеров семейства 8051

Более полная информация, а так же демо-версия эмулятора, представлена на Website: http://www.phyton.ru

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

Симуляторы

Симулятор — программное средство, способное имитировать работу микроконтроллера и его памяти. Как правило, симулятор содержит в своем составе:

• отладчик;
• модель ЦПУ и памяти.

Более продвинутые симуляторы содержат в своем составе модели встроенных периферийных устройств, таких, как таймеры, порты, АЦП, и системы прерываний.

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

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

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

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

В реальной системе микроконтроллер обычно занимается считыванием информации с подключенных внешних устройств (датчиков), обработкой этой информации и выдачей управляющих воздействий на исполнительные устройства. Чтобы в симуляторе не обладающем интерфейсом внешней среды смоделировать работу датчика, нужно вручную изменять текущее состояние модели периферийного устройства, к которому в реальной системе подключен датчик. Если, например, при приеме байта через последовательный порт взводится некоторый флажок, а сам байт попадает в определенный регистр, то оба эти действия нужно производить в таком симуляторе вручную. Наличие же интерфейса внешней среды позволяет пользователю создавать и гибко использовать модель внешней среды микроконтроллера, функционирующую и взаимодействующую с отлаживаемой программой по заданному алгоритму. Возможности «реального» отладчика-симулятора проиллюстрируем на примере модели PDS-PIC.

PDS-PIC

Отладчик-симулятор для разработки и отладки программ на базе микроконтроллеров PIC16/PIC17.

PDS-PIC — удобное и гибкое средство для написания и отладки программ, ориентированных на микроконтроллеры PICmicro фирмы Microchip.

Симулятор имеет:

• Встроенный многооконный редактор для написания исходных текстов программ. Редактор поддерживает операции с блоками текста, поиск/замену, цветовое выделение синтаксических конструкций языка ассемблера;
• Встроенный менеджер проектов, поддерживающий автоматическую компиляцию программ, написанных для макроассемблера PASM-PIC фирмы Фитон и для макроассемблера MPASM фирмы Microchip.
• Все опции ассемблера задаются в виде удобных диалогов. Переход от редактирования исходного текста к отладке и обратно происходит «прозрачно», т.е. менеджер проектов автоматически запускает ассемблер при необходимости;
• Широкие возможности по отладке программ: отслеживание выполнения программы по ее исходному тексту, просмотр и изменение значений любых переменных, встроенный анализатор эффективности программного кода, точки останова по условию и доступу к ячейкам памяти, просмотр стека вызовов подпрограмм, встроенный ассемблер, точный подсчет интервалов времени и многое другое;
• Возможность выполнения программы «назад» на большое количество шагов, а также в непрерывном режиме. При этом состояние модели микроконтроллера полностью восстанавливается;
• Точную модель поведения микроконтроллеров. Симулируется работа всех встроенных в микроконтроллер периферийных устройств: таймеров, АЦП, системы прерываний, портов и т.д.;
• Развитые средства моделирования «внешней среды», т.е. устройств, подключенных к микроконтроллеру. Можно легко задавать различные периодические и непериодические внешние сигналы на ножках микроконтроллера, моделировать работу внешней логики. С помощью встроенных средств графического отображения можно наглядно отображать различные индикаторы, строить графики, моделировать клавиатуру;
• Систему сохранения конфигурации окон и параметров настройки. Возможно сохранение и восстановление неограниченного количества файлов конфигурации;
• Возможность настройки цветов и шрифтов и других параметров для всех окон одновременно и для каждого окна в отдельности;
• Систему контекстной помощи. Находясь в любом меню, окне или диалоге, Вы можете получить справку, относящуюся к этому меню, окну или диалогу;
• PDS-PIC работает в среде Windowsв.

Более подробно особенности симулятора представлены в таблице, составленной по результатам сравнительного анализа двух симуляторов: MPlabSIM -фирмы Microchip и PDS-PIC — фирмы Фитон. Основные особенности и различия MPlabSIM и PDS-PIC обусловлены тем, что при их проектировании были использованы концептуально разные интерфейсы пользователя и среды для симуляции.

* MPlabSIM использует меню как надстройку над строчным вводом команд управления процессом симуляции с возможностью запоминания и выполнения линейных последовательностей команд. Например, для изменения содержимого регистра нужно произвести следующие действия:

— выбрать в меню раздел «WINDOWS» — выбрать в подменю опцию «MODIFY» — выбрать «что» (STACK,DATA or CODE)(в данном случае «DATA») собираетесь менять — указать адрес — ввести новое значение — подтвердить ввод При этом в окне дампа регистрового фала Вы увидите результат изменения, но в самом окне ничего не сможете изменить (только через меню — аналог командной строки).

Используя PDS-PIC, модифицировать значение рагистра можно нажатием двух клавиш. Так же просто можно выполнять все другие действия по отладке программы.

** На примере из пакета MPLAB-sim для 16c54, при выполнении на рекомендованной MICROCHIP конфигурации P90/16RAM.

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

Отладочные мониторы

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

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

Программа монитора обязательно должна работать в связке с внешним компьютером или пассивным терминалом, на которых и происходит визуализация и управление процессом отладки. Повторим, что отладочные мониторы используют тот процессор, который уже стоит на плате пользователя. Достоинством этого подхода являются очень малые затраты при сохранении возможности вести отладку в реальном времени. Главным недостатком является отвлечение ресурсов микроконтроллера на отладочные и связные процедуры, например: монитор занимает некоторый объем памяти, прерывания, последовательный канал. Объем отвлекаемых ресурсов зависит от искусства разработчика монитора. В последнее время появились изделия, которые практически не занимают аппаратных ресурсов процессора, о них будет рассказано ниже, в разделе «Эмуляторы ПЗУ».

Платы Развития

Платы развития, или как принято их называть в зарубежной литературе — оценочные платы (Evaluation Boards), являются своеобразными конструкторами для макетирования прикладных систем. В последнее время, при выпуске новой модели кристалла микроконтроллера, фирма-производитель обязательно выпускает и соответствующую плату развития. Обычно это печатная плата с установленным на ней микроконтроллером, плюс вся необходимая ему стандартная обвязка. На этой плате также устанавливают схемы связи с внешним компьютером. Как правило, там же имеется свободное поле для монтажа прикладных схем пользователя. Иногда, имеется уже готовая разводка для установки дополнительных устройств, рекомендуемых фирмой. Например, ПЗУ, ОЗУ, ЖКИ-дисплей, клавиатура, АЦП и др. Кроме учебных или макетных целей, такие доработанные пользователем платы стало выгодно (экономия времени) использовать в качестве одноплатных контроллеров, встраиваемых в мало серийную продукцию (5..20 шт.).

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

В первом случае отладочный монитор поставляется фирмой в виде микросхемы ПЗУ, которая вставляется в специальную розетку на плате развития. Плата также имеет ОЗУ для программ пользователя и канал связи с внешним компьютером или терминалом. Примером здесь может служить плата развития фирмы Intel для микроконтроллера 8051.

Во втором случае, плата развития имеет встроенные схемы программирования внутреннего ПЗУ микроконтроллера, которые управляются от внешнего компьютера. В этом случае, программа монитора просто заносится в ПЗУ микроконтроллера совместно с прикладными кодами пользователя. Прикладная программа при этом специально должна быть подготовлена: в нужные ее места вставляют вызовы отладочных подпрограмм монитора. Затем осуществляется пробный прогон. Чтобы внести в программу исправления пользователю надо стереть ПЗУ и произвести повторную запись. Готовую прикладную программу получают из отлаженной путем удаления всех вызовов мониторных функций и самого монитора отладки. Примерами могут служить платы развития фирмы Microchip для своих PIC контроллеров. Такой же принцип и у плат для отладки микроконтроллеров 80С750 Philips или 89C2051 Atmel.

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

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

Эмуляторы ПЗУ.

Эмулятор ПЗУ — программно-аппаратное средство позволяющее, замещать ПЗУ на отлаживаемой плате, и подставляющее вместо него ОЗУ, в которое может быть загружена программа с компьютера через один из стандартных каналов связи. Это устройство позволяет пользователю избежать многократных циклов перепрограммирования ПЗУ. Эмулятор ПЗУ имеет смысл только для микроконтроллеров, которые в состоянии обращаться к внешней памяти программ. Это устройство сравнимо по сложности и по стоимости с платами развития. Оно имеет одно большое достоинство: универсальность. Эмулятор ПЗУ может работать с любыми типами микроконтроллеров.

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

Однако появились модели интеллектуальных эмуляторов ПЗУ, которые позволяют «заглядывать» внутрь микроконтроллера на плате пользователя и вообще, по управлению отладкой, стали похожими на внутрисхемный эмулятор. Фирма Cactus даже представляет свой фактически интеллектуальный эмулятор ПЗУ, как внутрисхемный эмулятор ряда микропроцессоров, настолько невозможно отличить работу с тем и другим. В действительности, процессор здесь не замещается, а используется тот, что стоит на плате пользователя.

Интеллектуальные эмуляторы ПЗУ представляют собой гибрид из обычного эмулятора ПЗУ, монитора отладки и схем быстрого переключения шины с одного на другой. Этим создается эффект, как если бы монитор отладки был установлен на плате пользователя и при этом он не занимает у микроконтроллера никаких аппаратных ресурсов, кроме небольшой зоны программных шагов, примерно 4К. Например, такое устройство разработала фирма «Фитон» для всех существующих и будущих микроконтроллеров, которые имеют ядро от 8051 но дополнительно насыщенны различными устройствами вводавывода. Это устройство поддерживает множество самых разных микроконтроллеров фирм Philips, Siemens, OKI.

Интегрированные среды разработки.

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

При традиционном подходе, начальный этап написания программы строится следующим образом:

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

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

Избежать большого объема рутины и существенно повысить эффективность процесса разработки и отладки, позволяют появившиеся и быстро завоевывающие популярность т.н. интегрированные среды (оболочки) разработки (Integrated Development Environment, IDE).

Как правило, «хорошая» интегрированная среда позволяет объединить под одним крылом имеющиеся средства отладки (внутрисхемный эмулятор, программный симулятор, программатор), и при этом обеспечивает работу программиста с текстами программ в стиле «турбо».

Работа в интегрированной среде дает программисту:

• Возможность использования встроенного много файлового текстового редактора, специально ориентированного на работу с исходными текстами программ.
• Диагностика выявленных при компиляции ошибок, и исходный текст программы, доступный редактированию, выводятся одновременно в многооконном режиме.
• Возможность организации и ведения параллельной работы над несколькими проектами. Менеджер проектов позволяет использовать любой проект в качестве шаблона для вновь создаваемого проекта. Опции используемых компиляторов и список исходных файлов проекта, устанавливаются в диалоговых меню и сохраняются в рамках проекта, устраняя необходимость работы с неудобными batch-файлами.
• Перекомпиляции подвергаются только редактировавшиеся модули.
• Возможность загрузки отлаживаемой программы в имеющиеся средства отладки, и работы с ними без выхода из оболочки.
• Возможность подключения к оболочке практически любых программных средств.

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

🎥 Видео

Как прошить микроконтроллер / Как правильно понимать микроконтроллер / Обзор среды программированияСкачать

Разработка программ для микроконтроллеров с компилятором O7Скачать

Proteus | AVRDUDE | Отладка и прошивка микроконтроллеров AVR | Микроконтроллеры с нуля #5Скачать

5 урок. Начальные сведения о микроконтроллере attiny2313Скачать

Микропроцессоры и "умные" вещи / Встроенные системы, IoT и язык С / Интервью с Design EngineerСкачать

Изучаем STM32. Как изучить микроконтроллеры за несколько недель. Набор для изучения STM32 до 1000 р.Скачать

Внешние прерывания микроконтроллера | Микроконтроллеры с нуля #14Скачать

23 задание Информатика ЕГЭ Система логических уравнений Часть 13Скачать

Топ 3 худших программиста на YouTube! #код #айти #программистСкачать

Лекция 2.2. Отладка ПО в электроприводе. Курс "Разработка цифровых систем управления на К1921ВК01Т"Скачать

КАК РЕШАТЬ СИСТЕМЫ ЛОГИЧЕСКИХ УРАВНЕНИЙ. ЕГЭ по информатике. Задание 23Скачать

23 задание Информатика ЕГЭ Система логических уравнений Часть 1Скачать

23 задание Информатика ЕГЭ Система логических уравнений Часть 11Скачать

1. Знакомство с микроконтроллером PIC16F84A (Урок 1. Теория)Скачать

C++ Siberia 2019: Игнат Ворошилов, Возможности С++ для программирования микроконтроллеровСкачать