– 1 –

Список литературы

1. Каган Б.М., Сташин В.В. Основы проектирования микропроцессорных устройств в автоматике. Москва, Энергоатомиздат, 1987г.

2. Сташин В.В. и др. Проектирование цифровых устройств на однокристальных микроконтроллерах. Москва, 1990г.

3. Хвощ и др. Микропроцессоры и микроЭВМ в системах автоматического управления. Справочник. Ленинград, 1987г.

4. http://www.keil.com – документация и демонстрационная версия пакета Keil uVision.

Список сокращений

МП – микропроцессор.

МПК – микропроцессорный контроллер.

МК – микроконтроллер.

ОМК – однокристальный микроконтроллер.

МПС – микропроцессорная система.

ПО – программное обеспечение.

АС – аппаратные средства.

ЯВУ – язык высокого уровня.

– 2 –

1. Этапы разработки МПС 1. Системный анализ.

1.1. Описание объекта автоматизации и формирование требований к МПС.

1.2. Анализ функций, выполняемых МПС. 1.3. Определение основных структур данных и требований к их

хранению. 2. Выбор типа МП.

2.1. Разбиение функций МПС на программно и аппаратно реализуемые. 2.2. Анализ определяющих функций, влияющих на быстродействие,

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

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

Выбор типа МП определяет структуру МПС, т.е. ее логическую организацию. После выполнения данного этапа имеем:

- тип МП; - распределение функций на программно и аппаратно

реализуемые.

В дальнейшем все программно реализуемые функции являются основой алгоритмов ПО МПС, а аппаратно реализуемые функции трансформируются в функциональную схему АС МПС.

3. Разработка АС (может выполняться параллельно с разработкой ПО). 3.1. Разработка функциональной схемы АС. 3.2. Разработка принципиальной схемы АС. Один из вариантов

разработки принципиальной схемы – выбор готового МПК. В этом случае разработка принципиальной схемы сводится к оценке возможности применения выбранного МПК и разработке требуемых устройств сопряжения (если это необходимо).

4. Разработка ПО МПС. Данный этап является наиболее трудоемким, однако, он имеет наибольшую поддержку средствами автоматизации проектирования.

– 3 – 4.1. Разработка алгоритмов функционирования ПО. При этом за основу

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

4.2. Распределение памяти и выбор форматов данных. 4.3. Кодирование алгоритмов на языке программирования

Все ПО МПС можно разделить на две части: системное ПО и прикладное ПО. Системное ПО используется для управления ресурсами МПС и может включать в себя следующие составные части:

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

- тестовые программы для проверки основных узлов МПС; - библиотеки арифметических функций; - интерпретаторы псевдокода.

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

Во многих случаях системное ПО может отсутствовать или состоять из простейших программ инициализации и элементарных тестов.

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

Для разработки ПО МПС используются специальные средства и специальное ПО. Специальными средствами являются инструментальные системы, представляющие собой микроЭВМ с необходимым набором периферийных устройств (дисплей, накопители большой емкости, принтер и т.п.). ПО инструментальной системы (ПО разработки) включает в себя следующий набор средств: кросс-ассемблеры и кросс-компиляторы с ЯВУ, программно-логические модели (симуляторы), позволяющие отладить значительную часть ПО в среде инструментальной системы.

5. Совместная (комплексная) отладка ПО и АС МПС. На данном этапе программа переносится в ПЗУ макетного образца МПС или в эмулятор ПЗУ прототипа МПС, после чего выполняется ее отладка совместно с

– 4 – реальными АС. На этапе комплексной отладки обычно используются кросс-отладчики или внутрисхемные эмуляторы МП.

6. Оценка характеристик разработанной МПС. На данном этапе МПС тестируется на соответствие ее характеристик техническому заданию.

– 5 –

2. Разработка ПО МПС

2.1. Программное обеспечение инструментальной системы.

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

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

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

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

• ускоренный ввод некоторых конструкций языка путем нажатия определенных комбинаций клавиш;

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

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

3. Редактор связей (компоновщик) – служит для объединения объектных модулей с целью получения загрузочного файла программы (т.е.

– 6 – файла, который затем может быть использован для загрузки в память разрабатываемой МПС).

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

2.2. Выбор языка программирования.

Выбор языка программирования для кодирования алгоритмов работы ПО МПС возможен из нескольких альтернатив.

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

• отсутствие автоматического распределения памяти – контроль за распределением и использованием памяти полностью ложится на программиста;

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

• отсутствие переносимости программ: программа, написанная для одного процессора, как правило, не может быть перекомпилирована для другого;

• низкая «читабельность» исходного текста: для понимания логики работы программы ее исходный текст необходимо тщательно комментировать.

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

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

Наиболее распространенным в настоящее время ЯВУ для программирования МП и МК является язык «С». Качественные компиляторы этого языка существуют практически для каждого МП, что позволяет во многих случаях переносить программные модули с одного МП на другой с минимальными доработками. Эффективному использованию этого языка способствует также наличие стандарта, принятого ANSI: ANSI C, которому должны следовать разработчики компиляторов. За счет этого диалект языка для конкретного МП содержит большую стандартную часть, общую для всех диалектов, и некоторые дополнения и расширения, позволяющие учесть особенности конкретного типа МП (например, наличие различных типов памяти).

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

char C; C=’A’+0x20; Это является потенциальным источником ошибок при написании программы.

Другим распространенным ЯВУ является Pascal. Этот язык, обладая практически всеми достоинствами «С», имеет еще и строгий контроль типов с возможностью явного преобразования. Однако, применение этого языка сдерживается отсутствием общепринятого стандарта, и, как следствие, отсутствием качественных компиляторов для большого количества МП.

Существует еще несколько ЯВУ, применяемых при программировании МП и МК. К ним относятся С++, Basic, Java и некоторые другие. Однако, компиляторы и интерпретаторы этих языков существуют лишь для некоторых типов МП, и поэтому широкого применения при программировании встроенных систем они не нашли.

При выборе языка программирования для кодирования алгоритмов работы ПО МПС необходимо учитывать следующие факторы:

1. Сложность алгоритмов ПО и предполагаемый объем программы. 2. Требования к быстродействию и объему программы. В том

случае, если от программы требуется максимальное быстродействие или к ней предъявляются жесткие требования по объему занимаемой памяти, целесообразно вести разработку ПО

– 8 – на языке Ассемблера. Однако, наличие таких требований нередко свидетельствует об ошибке на этапе выбора микропроцессора при проектировании МПС. Зачастую оказывается выгоднее использовать более мощный процессор и разрабатывать ПО на ЯВУ, чем применять язык Ассемблера для программирования недостаточно мощного процессора.

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

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

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

6. Предполагаемое время сопровождения ПО и необходимость его модернизации. Как правило, ПО, написанное на ЯВУ, значительно легче поддается модернизации, чем написанное на языке Ассемблера.

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

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

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

– 9 – 2.3. Создание загрузочного модуля программы.

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

Эмулятор

Программатор

Исходныетексты

Транслятор

Объектныефайлы

Другиеобъектныефайлы

Компоновщик

Абсол.объектный

файл

MAP-файл

Преобразовательв HEX-формат

HEX-файл

Отладчик

Листинг

– 10 – Прежде всего, создаются исходные тексты отдельных модулей ПО. Эти тексты могут быть созданы различными способами (в текстовом редакторе, с использованием CASE-средств и т.п.) и написаны на различных языках программирования.

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

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

Полученный загрузочный модуль обычно может быть размещен в памяти МПС для последующего исполнения. Если ПО будет функционировать в ПЗУ, то для размещения машинного кода в памяти может использоваться программатор или средства программирования ПЗУ, встроенные в МПС. Если ПО должно работать в ОЗУ, то МПС должна иметь в своем составе специальный загрузчик, позволяющий получить машинные коды ПО из какого-либо источника (дисковая подсистема, карта FLASH-памяти и тп) и разместить в памяти. Иногда в процессе загрузки код программы подвергается некоторой модификации (например, при загрузке EXE-файла в PC-совместимых компьютерах).

– 11 – 2.4. Разработка программ на языке ассемблера.

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

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

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

Поскольку языков ассемблера существует много, изучить «язык ассемблера вообще» нельзя. В данном курсе мы будем рассматривать язык ассемблера однокристальных микроконтроллеров семейства MCS-51 на примере пакета Keil uVision 2.

Программа на ассемблере содержит записи трех видов:

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

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

• символьные инструкции – записи, соответствующие каким-либо машинным кодам, которые могут быть выполнены микропроцессором;

Символьные инструкции имеют следующий формат:

[Метка:] мнемоника команды [операнд 1] [, операнд 2] [;комментарий]

– 12 – Метка – символьное имя, которому назначается адрес данной инструкции. Метка может быть определена только один раз и не может быть переопределена.

Мнемоника команды – текстовая строка, соответствующая машинной команде.

Операнд – аргумент, необходимый для соответствующей команды.

Комментарий – текст любого содержания.

Структура программы на языке ассемблера.

NAME <Имя модуля> ;необязательное имя модуля.

;Описание имен, импортируемых из других модулей.

EXTRN CODE (mmm1, mmm2), DATA (var1, var 2)

(BIT, CODE, DATA, IDATA, XDATA)

;Описание имен, доступных для других модулей

PUBLIC k1, var8, Cnt

; Описание локальных символьных имен

; <Имя> <тип> <Значение>

; SET – можно переопределить

k1 equ 20h

lkj1 data 8h

; Описание сегментов программы.

END

– 13 –

3. Средства отладки программного обеспечения Все средства отладки ПО можно разделить на три типа:

• встроенные (резидентные) – средства, реализованные на базе той МПС, для которой разрабатывается ПО;

• кросс-средства – средства, реализованные на базе МПС с типом процессора, отличающимся от процессора целевой МПС;

• комбинированные средства – представляют собой комбинацию двух предыдущих.

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

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

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

Недостатком кросс-средств отладки является то, что отладка ПО ведется не в реальных условиях, как в случае резидентных средств,

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

– 15 –

4. Средства комплексной отладки МПС. К числу основных инструментальных средств отладки относятся:

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

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

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

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

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

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

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

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

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

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

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

• Процессор точек останова. • Трассировщик. • Анализатор эффективности программного кода. • Таймер реального времени; • Программно-аппаратные средства, обеспечивающие возможность

чтения и модификации ресурсов эмулируемого процессора “на лету”, т.е. в процессе выполнения программы пользователя в реальном времени;

• Программно-аппаратные средства, обеспечивающие синхронное управление, необходимое для эмуляции в мультипроцессорных системах;

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

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

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

• Загрузку отлаживаемой программы в память системы;

• Вывод на монитор состояния и содержимого всех регистров и памяти, и при необходимости, их модификацию;

• Управление процессом эмуляции.

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

– 17 – • Вести символьную отладку, благодаря тому, что отладчик “знает”

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

– 19 – компиляцию по мере необходимости и активизирует соответствующие окна программного интерфейса.

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

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

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

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

4.2. Симуляторы.

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

• Отладчик; • Модель процессора и памяти.

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

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

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

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

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

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

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

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

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

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

• Загрузку прикладных кодов пользователя в свободную от монитора память.

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

регистров.

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

4.4. Оценочные платы.

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

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

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

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

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

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

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

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

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

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

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

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

– 24 – тем и другим. В действительности, процессор здесь не замещается, а используется тот, что стоит на плате пользователя.

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

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

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

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

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

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

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

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

– 25 – интегрированные среды (оболочки) разработки (Integrated Development Environment, IDE).

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

Работа в интегрированной среде дает программисту следующие преимущества.

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

• Отображение выявленных при компиляции ошибок, при этом исходный текст программы, доступный для редактирования, выводится одновременно в многооконном режиме;

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

• Перекомпиляции подвергаются только измененные с момента последней компиляции модули.

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

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

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

4.7. Логические анализаторы.

Логические анализаторы – это контрольно-измерительные приборы, предназначенные для сбора данных о поведении дискретных систем, для обработки этих данных и представления их человеку на различных уровнях абстракции. Они работают независимо и

– 26 – незаметно для испытуемых дискретных систем и применяются для их отладки и диагностирования.

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

Для определения значений сигналов ЛА используют компараторы, с помощью которых выясняется, выше или ниже входной сигнал заданного порогового уровня. Если сигнал превышает порог, его уровень определяется как высокий, если ниже порога, то низкий. Пороговое напряжение компараторов, как правило, может регули-роваться (в основном от -10 до +10 В).

Подключение ЛА требует доступа к участкам цифрового устройства (например, выводам микросхем или трассам платы). Анализаторы снабжаются специальными щупами и зажимами. Основное требование – минимизация влияния прибора на испытуемое уст-ройство. ЛА должны обладать высоким входным сопротивлением (примерно 1 МОм) и малой входной емкостью (порядка 10-25 пФ). Для обеспечения этих требований компараторы логических уровней делаются выносными.

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

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

– 27 – Основное разнообразие в семейство логических анализаторов вносят способы запуска и формы представления данных. Этим вопросам далее будет уделено особое внимание.

Традиционно ЛА выпускались такими фирмами, как Hewlett-Packard (HP), Tektronix, Philips.

4.7.1. Классификация ЛА по функциональному назначению.

Все ЛА можно разделить на несколько типов. Фирма Tektronix выде-ляет два основных типа: анализаторы микропроцессорных систем на программном уровне описания (embedded microprocessor software debug applications), называемые также анализаторами состояний (state analyser) и анализаторы цифровых систем на логическом и временном уровне (hardware debug applications), называемые анализаторами временных соотношений (timing analyser).

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

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

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

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

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

4.7.2. Способы запуска ЛА.

Большинство ЛА предоставляют различные возможности для задания способов запуска. Пользователю предлагается определить события, которые будут последовательно оцениваться ЛА и при возникновении которых осуществляется запуск. События могут комбинироваться, зависеть друг от друга, оцениваться одновременно. Такие события называются условиями запуска.

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

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

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

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

Так, например, ЛА фирмы Tektronix используют для задания запуска автомат состояний срабатываний. Этот автомат может содержать до шести состояний, где каждое состояние содержит от одного до четырех условных выражений типа «если-то-иначе». Каждое вы-ражение оценивает комбинации из событий, число которых может быть до восьми, а выполнение его условий может определять до восьми действий. С приходом сигнала синхронизации в текущем состоянии оцениваются все выражения «если-то-иначе». Первое вы-ражение в списке, условия которого выполняются, преобладает над остальными, и далее производятся действия, связанные с этим выражением. Если не выполняются условия ни одного выражения, автомат запуска остается в текущем состоянии, и действия не производятся.

ЛА фирмы HP предоставляют библиотеку макросов, определяющих параметры срабатывания. Каждый макрос имеет график измерения и структуру, похожую на предложение. Семейство макросов включает в себя основные макросы, последовательно определенные макросы, включая нахождение последовательности из N бит, макросы нахождения временных несоответствий, включая нахождение неко-торого события X, произошедшего вскоре после события Y.

Основу всех библиотек и состояний запуска составляют несколько основных условий.

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

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

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

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

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

Вторая группа условий – это запуск по помехе. ЛА может включать в себя встроенный детектор помех, который непрерывно ожидает помехи на каждом канале. Детектор помех отслеживает поток собираемых данных. Когда возникает помеха, ЛА срабатывает и помеха выводится на экран.

– 31 – Детектор помех используется в основном для исследования помех на линии синхронизации. В высокоскоростных логических устройствах параметры синхронизации наряду с качеством сигнала – один из важнейших показателей.

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

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

4.7.3. Визуализация собранной информации.

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

– 32 – настройку прибора и визуализацию информации, манипуляторы мышь, существенно упрощающие работу с прибором.

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

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

Профессиональные ЛА предоставляют возможность совмещать во времени анализ состояний и анализ временных соотношений и показывать это на экране.

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

Существует такой способ отображения, как карта состояния. В этом режиме вместо таблицы единиц и нулей на экране воспроизводится матрица 2^N точек. Каждая точка представляет одну возможную комбинацию значений N входных линий, так что любое исходное слово — точка. Слово, содержащее все нули, находится в верхнем левом углу экрана; слово, содержащее все единицы, — в нижнем правом углу. Точки взаимосвязаны таким образом, что можно наблюдать последовательность обработки данных. Отрезок линии становится более ярким по мере приближения к новой точке, указывая тем самым направление потока данных. Такой способ дает возможность весьма быстрого обнаружения искажений программы путем сравнения с «образцовой» картой состояния.

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

– 33 – повторяемости (абсолютное, процентное), сортировка шкалы данных, использование цвета, шрифтов и т.д.

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

4.8. Механизм граничного сканирования.

Механизм граничного сканирования (Boundary Scan) является промышленным стандартом, который был разработан группой специалистов по проблемам тестирования электронных компонент (JTAG) и зарегистрирован в IEEE 1149.1 – 1990 “Standard Test Access Port and Boundary Scan Architecture”.

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

Практически все проекты микропроцессорных систем предполагают решение ряда инструментальных задач, которые можно условно поделить на три группы:

• начальное тестирование, которое выявляет технологические дефекты изготовления;

• доставка необходимой конфигурации для программируемых компонент;

• поддержка различного рода отладочных механизмов (статических или динамических) и режима мониторинга;

Для решения этих задач МПС должна содержать в себе необходимый набор специализированных резидентных средств. Рассмотрим особенности применения в качестве таких средств механизм граничного сканирования IEEE 1149.1 – 1990 (JTAG).

Гибкость использования механизма граничного сканирования достигается рядом особенностей стандарта, основными из которых являются:

– 34 – • возможность параллельной согласованной работы нескольких

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

• возможность расширения самого механизма (введение дополнительных команд и форматов данных);

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

Одной из главных особенностей данного механизма является специализированный последовательный четырехпроводный интерфейс TAP (Test Access Port), функциональная схема аппаратных средств которого приведена на рисунке 1). Назначение сигналов интерфейса приведено в таблице.

Контакт Имя Описание TDI Test Data Input Последовательный вход сдвигового

регистра. Данные защелкиваются по переднему фронту импульса на TCK

TDO Test Data Output Последовательный выход сдвигового регистра. Данные выводятся по заднему фронту импульса на TCK

TMS Test Mode Select Вход управления машиной состояний TAP-контроллера. Данные защелкиваются по переднему фронту импульса на TCK

TCK Test Clock Input Вход синхронизации TRST Test Reset Input Асинхронный сброс всей BST-схемы с

инициализацией TAP-контроллера. (необязательный контакт)

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

– 35 –

Из диаграммы состояний автомата следует, что данный интерфейс работает в двух режимах: режим чтения/записи регистров команд (IR) и режим чтения/записи регистров данных (DR). При этом чтение и запись происходит одновременно по двум раздельным линиям, одна из которых (выходная) является тристабильной (TRI-State), что

Рис. 1) Функциональная схема аппаратных средств JTAG.

– 36 –

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

Стандарт на механизм граничного сканирования определяет требования на реализацию трех основных режимов работы интерфейса: BYPASS, EXTEST, SAMPLE/PRELOAD. Один из этих

Рис. 2) Граф состояний TAP-контроллера.

– 37 – режимов (BYPASS) позволяет эффективно использовать возможности последовательного интерфейса при организации длинных последовательно объединенных цепочек. Два других режима обеспечивают потенциальную возможность проведения тестов методом граничного сканирования.

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

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

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

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

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

Примером такого подхода является механизм отладки микропроцессов, который заложен в архитектуру процессорных ядер компании ARM (Advanced Risc Machines) – Embedded ICE [5]. В состав процессорного ядра ARM входит специализированный блок отладки (мониторинга), который с помощью механизма граничного сканирования программируется для работы в инструментальном режиме. Далее в этом режиме, через механизм граничного сканирования, осуществляется доступ к ресурсам отладочного механизма в режиме “запрос/ответ”. В таком режиме производительности последовательного интерфейса хватает для осуществления управляющих действий по отладке или мониторингу.

– 38 – Для описания ресурсов механизма граничного сканирования, существуют стандартные средства, такие как форматы и языки описания TDL (Test Description Language). Одним из первых форматов описания модели механизма граничного сканирования стал BSDL (Boundary Scan Description Language), который представляет собою подмножество языка описания аппаратуры VHDL (VHSIC Hardware Description Language). BSDL позволяет описывать структурные элементы механизма граничного сканирования на уровне разрядностей регистров управления и форматов регистров граничного сканирования (Boundary Scan Register). В настоящее время BSDL стал стандартом описания ресурсов механизма граничного сканирования и принят большинством фирм-производителей электронных компонент.

Другие группы языков – SVF (Serial Vector Format) и STAPL (Standard Test and Programming), ориентированы на описание поведенческой модели работы механизма граничного сканирования. Языки STAPL более развиты, чем SVF. В семантику STAPL добавлены средства алгоритмизации, такие как: процедурные вызовы, циклы, переменные, которые отсутствуют в SVF. Язык JAM (разработанный фирмой Altera) является представителем семейства STAPL. Он позволяют производить загрузку и чтение значений, переводить автомат в определенное состояние, анализировать и обрабатывать рабочие значения.

Наиболее часто механизм граничного сканирования используется для тестирования и программирования (конфигурирования) аппаратуры. Раскроем данные термины и определим круг реально решаемых задач.

Тестирование.

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

– 39 – системы, конкретными микросхемами и т.д. (хотя при составлении сценария эта информация была использована).

Программирование.

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

В ряде случаев микросхемы, нуждающиеся в конфигурировании, не имеют JTAG интерфейса (например, flash-память). Такие элементы можно программировать, используя JTAG-интерфейс связанных с ними микросхем (рисунок 3)).

Эффективность использования технологии граничного сканирования во многом зависит от решения двух вопросов: описания структуры цепочки JTAG и формулировки алгоритма работы с описанной цепочкой. Под JTAG-цепочкой понимается полная стандартная тест-шина, полученная последовательным соединением сигналов TDI и

Рис. 3) Граф состояний TAP-контроллера.

– 40 – TDO нескольких компонент. Это понятие используется при решении следующих задач:

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

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

• описания (выделения) цели работы конкретного алгоритма (программирование, тестирование).

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

Задача выделения цели не входит в число стандартных задач описания структуры JTAG-цепочки. Однако на практике приходится очень редко работать с регистром граничного сканирования BSR (Boundary Scan Register), равным объединению BSR всей цепочки. Обычно для конкретного теста или алгоритма требуется не более десятка ячеек в BSR или только одна микросхема в составе цепочки. Стандартного средства такого описания, по-видимому, не существует. Это объясняется, скорее всего, спецификой описания (по факту) JTAG-цепочки и кругом решаемых JTAG задач. Есть упоминания о средствах программирования, например flash-памяти, с помощью JTAG, что требует выделения линий адреса, данных и управления во всем BSR. Однако в известных реализациях это делается неформальным образом. Справедливости ради, необходимо отметить, что в стандарте HSDL имеется возможность “выделять” отдельные ячейки BSR, назначая им произвольные имена. Но это нельзя назвать выделением цели в чистом виде, поскольку алгоритм, составленный по такому описанию, по-прежнему будет оперировать полным BSR. Что касается разработчика, то ему при работе также придется рассматривать всю JTAG-цепочку (явным или неявным образом), даже если используется только несколько выводов одной из микросхем.