 |
| |
|
Отладчики микроконтроллеров и их применение в разработке микроконтроллерных приложений
А. Калядин (ЗАО "РТСофт") |
|
| | В статье описывается эволюция и современное состояние отладочных средств, используемых для разработки прикладных систем на базе микроконтроллеров (базовые и новые методы отладки, ПЗУ-мониторы, симуляторы, внутрисхемные эмуляторы, логические анализаторы). Особое внимание уделяется N-проводным отладчикам EJTAG и NEXUS. | | | |
|
| |
Введение |
|
|
Вы не забыли те кошмарные дни, когда программы для микропроцессоров (типа 2708, 2716) разрабатывались на ассемблере и прожигались в СППЗУ? Определить, что делает программа в случае ошибки, было невозможно; чтобы узнать, в каком месте она исполняется, изобретались всевозможные хитрости, например, применение "избыточных" выводов устройства. Для создания работоспособной программы требовалось огромное упорство и немалая квалификация. Лишь у немногих счастливчиков были программы-мониторы (зашитые в ПЗУ), при помощи которых, а также семисегментных светодиодных дисплеев и шестнадцатиричной клавиатуры разработчики могли по шагам исполнять ассемблерные команды и вставлять простейшие точки останова. В некоторых случаях отлаживаемые устройства связывались с компьютером или терминалом последовательной линией связи. Существовало также несколько программных эмуляторов с рудиментарными возможностями. И лишь элитные и богатейшие компании могли себе позволить "инструмент инструментов" внутрисхемный эмулятор (In-Circuit Emulator). Однако из-за высокой начальной стоимости и ненадежности первых подобных устройств от них часто отказывались в пользу старых добрых мониторов. Единственное, что было общего у эмуляторов с мониторами их строгая ориентация на язык ассемблера.
|
Базовые методы |
|
|
В те времена, когда никакого тестового оборудования не было, написанные программы компилировались и сразу же прожигались в СППЗУ. Никакого тестирования методом прозрачного ящика (white box testing) или вне целевого устройства не проводилось. Работа велась по принципу "прожигай и молись", то есть предполагалось, что если при тестировании программа выдает ожидаемые результаты, то она, должно быть, работает правильно. Поскольку между программой на ассемблере и содержимым ПЗУ существует строгое соответствие, можно говорить, что разработчики знали, что записано в ПЗУ (по крайней мере, думали, что знали...)
|
Появление макросов и оптимизирующих трансляторов с языка ассемблера изменило соответствие между написанной программой и конечным результатом в ПЗУ. Текст программы на языке Си (да и на любом другом языке высокого уровня) абсолютно не похож на содержимое ПЗУ (в том смысле, как были похожи ассемблерные тексты и исполняемые программы). Теперь программист, не пользуясь внутрисхемным эмулятором (ВСЭ) или ПЗУ-монитором, не может утверждать, что он точно знает, что записано в ПЗУ.
|
Однако действия оптимизирующих компиляторов иногда приводят к интересным результатам. Например, известен следующий случай такой компиляции. Программа писала определенное значение в регистр, затем в ячейку памяти, тут же считывала содержимое этой ячейки памяти и сравнивала считанное значение с величиной, ранее записанной в регистр. Поскольку компилятор определил, что программа пишет и тут же читает из ячейки с тем же адресом, он счел эти операции ненужными и удалил. Таким образом был оптимизирован и код, и время работы программы. Ускорение работы программы было весьма значительным. Это был тест памяти, который никогда не выявлял сбоев, поскольку на практике никогда к памяти и не обращался!
|
Как ни странно, но практика "прожигай и молись" по-прежнему в ходу. Остаётся лишь надеяться, что программы сначала тестируются хотя бы программными симуляторами. И очень хочется, чтобы метод "прожигай и молись" остался в прошлом веке.
|
Применение светодиодов и наблюдение за переключением выходных сигналов анализируемого порта сродни оператору printf("Привет! Я на строке номер xxx \n"), который; возможно, и сообщает вам о точке, в которой работает в данный момент ваша программа. Этот метод предполагает, что программа успешно дошла до того места, где переключается сигнал на контакте анализируемого порта. Однако гарантии, что целевое устройство находится в том состоянии, какое предполагается, нет. Одно дело тестировать с помощью этого метода аппаратуру, и совсем другое дело отлаживаемую программу.
|
Этим методом пользуются и сегодня, но в основном для сигнализации о возникновении сбоев в уже готовом изделии. Примером его применения могут служить звуковые сигналы динамика компьютера в случае неисправностей в момент начальной загрузки или свечение светодиодов, индицирующих состояния внутрисхемного эмулятора. Однако все это лишь средство индикации конкретных известных (как правило, аппаратных) отказов в полностью протестированной и работоспособной системе. Обычно для этого метода требуется работающего программное обеспечение. Как основной способ тестирования разрабатываемых программ этот метод используется сегодня крайне редко, хотя семисегментные сведодиодные индикаторы способны дать некоторую дополнительную информацию. Скорее всего, подобные методы применяются для тестирования новых аппаратных средств, а не для отладки программного обеспечения.
|
ПЗУ-мониторы |
|
|
Тем временем инженерам-разработчикам простой индикации состояний портовых выводов стало недостаточно. Им хотелось знать, что происходит внутри микропроцессорных устройств. В результате были разработаны резидентные мониторы отладки, или ПЗУ-мониторы (ROM-monitors). ПЗУ-монитор это очень простая и по возможности небольшая программа, дающая пользователю возможность в определенной степени контролировать выполнение тестируемой программы, одновременно работающей в целевом устройстве (рис.1). Среди недостатков первых ПЗУ-мониторов были такие, как малое число команд и очень примитивный (а зачастую трудный в освоении) интерфейс. Кроме того, для их работы в целевом устройстве требовался рабочий последовательный порт, плюс к этому ПЗУ-мониторы изменяли карту памяти целевого устройства. Даже для самых скромных мониторов требовалось несколько килобайт дополнительной памяти. Набор команд был довольно ограничен: пошаговое исполнение (но только машинных команд), точки останова (но никаких точек просмотра watchpoint), отображение содержимого регистров и ячеек памяти, чтение ячеек памяти. Интерфейс пользователя был очень примитивен и ограничивался выводом на экран требуемой информации после ввода какой-либо команды (обычно в виде буквы). Содержимое памяти выводилось однократно и в последующем динамично не обновлялось. Подключение к хост-системе выполнялось по медленной последовательной линии связи.
|
Главный недостаток ПЗУ-мониторов, помимо того, что они не работали в режиме реального времени, заключался в том, что они требовали работоспособности отлаживаемого устройства в целом и изменяли карту памяти в результате их подключения. Кроме того, их применение приводило к лишним затратам, поскольку каждая отлаживаемая с их помощью плата должна была оснащаться дополнительным последовательным портом. Помимо всего прочего это означает, что аппаратный состав изделия, тестируемого с помощью ПЗУ-монитора, был не идентичен аппаратному составу производимого изделия.
|
Однако при всех своих недостатках ПЗУ-мониторы действительно позволяли "увидеть", что происходит внутри целевого устройства, и контролировать исполнение программ. В принципе, их можно назвать "дешевым внутрисхемным эмулятором ", поскольку были сравнительно недорогими. Многие программисты умели писать собственные мониторы. Хотя, как уже говорилось, все это приводило к удорожанию аппаратных средств.
|
 Рис.1 Система с ПЗУ-монитором |
| |
Симулятор ЦП |
|
|
Совсем недавно появился еще один вид отладчиков, попадающий по функциональным возможностям, стоимости и эффективности между эмуляторами и обычными мониторами. Это симуляторы центрального процессора (ЦП), которые иногда еще называют симуляторами наборов инструкций. Первоначально они выпускались производителями компиляторов. Некоторые поставщики интегральных схем тоже создавали свои симуляторы и продавали их по пониженной цене, прежде чем на рынке появится достаточное для начала разработок новых изделий количество микросхем.
|
Подобные симуляторы осуществляют абсолютное моделирование процессора целевого устройства чисто программным способом. Быстродействие первых симуляторов достигалось за счет ограничения их возможностей и упрощения интерфейса. Как правило, они работали с шестнадцатиричным кодом, а не с текстом на языке высокого уровня. Подобные симуляторы вполне позволяли контролировать ход выполнения программы и выявлять в ней ошибки. Поскольку моделирование осуществлялось чисто программным способом, исполнение программы шло, естественно, не в режиме реального времени, а все сигналы ввода/вывода необходимо было моделировать специальными подпрограммами, имитирующими работу периферийных устройств и иных ресурсов процессора.
|
Симуляторы начали появляться тогда, когда вычислительной мощности персональных компьютеров и рабочих станций стало хватать для обеспечения приемлемого быстродействия моделирующих программ. Однако "приемлемое быстродействие" понятие субъективное, и то, что было приемлемо раньше, сегодня считается медленным. Интерфейсы первых симуляторов многофункциональностью тоже не отличались.
|
Сказав о том, что первоначально симуляторы поставлялись производителями микросхем и представляли собой превосходный инструмент для тестирования нового кристалла, следует призвать к осторожности при выборе инструментальных средств, поставляемых поставщиками интегральных схем.
|
Причин подобной осторожности несколько. Во-первых, вполне может случиться, что поставщики компиляторов и внутрисхемных эмуляторов рыночного будущего у этого устройства не увидят. Поэтому такой микропроцессор может либо существовать очень недолго, либо использоваться в какой-либо очень специализированной области, либо значительно отличаться от других имеющихся устройств. Конечно, если эта специализированная область ваша, проблемы никакой нет.
|
Во-вторых, если на рынке уже есть инструментарий от поставщика микросхем (как правило, по очень низкой цене), то какой резон создавать аналогичный инструментарий третьим фирмам? В результате прикладной разработчик оказывается привязанным к единственному источнику средств разработки, которые вполне могут исчезнуть, как только поставщик этих интегральных схем решит прекратить их производство. К тому же он может выпустить очередную модификацию своего устройства и призвать пользователей "обновить" свои средства, прекратив поддерживать предыдущие версии своих инструментальных средств.
|
Кроме того, необходимо убедиться, что предлагаемый инструментарий действительно только программный. Создание аппаратных средств отладки пока еще требует больше времени и денег, чем производство программного инструментария. Копии программных средств отладки легко распространяются и модифицируются, что весьма удобно, особенно если интегральная схема еще не совсем отработана. Аппаратные средства отладки обычно появляются тогда, когда новые микросхемы уже в значительной степени отлажены.
|
Первые внутрисхемные эмуляторы |
|
|
Даже в начале разработок встраиваемых микроконтроллеров внутрисхемные эмуляторы были самым совершенным инструментом. В 1975 году компания Intel создала свой первый настоящий внутрисхемный эмулятор MDS-800, предназначенный для микропроцессоров 8080. Правда, это были довольно дорогие (в 1975 году MDS-800 стоил 20 тыс. долл.) и громоздкие системы (MDS-800 имел экран, клавиатуру и два дисковода для гибких дисков диаметром 20 см).
|
В то время подобные эмуляторы были не всегда надежны и во многих ситуациях все-таки вмешивались в работу моделируемого устройства. Таким образом, они работали "в не совсем реальном времени" (хотя и в гораздо более реальном по сравнению с другими методами). Их буферы были небольшими из-за, смешно сказать, высокой стоимости оперативной памяти. Кроме того, они не могли эмулировать более быстродействующие процессоры. В те времена процессор, который можно было бы использовать во встроенной системе, был идентичен процессору, используемому в эмуляторе.
|
Эмуляторы отличают от мониторов два следующих момента. Во-первых, когда эмулятор останавливается в контрольной точке, останавливается и вся система, при этом разработчик видит перед собой действительно текущее состояние микропроцессорного устройства. В случае же с монитором рабочая система и программа монитора продолжают исполняться, при этом монитор на деле информации о внутреннем состоянии микропроцессора не дает. Точки останова в эмуляторе могут размещаться в любом месте программы, в то время как мониторам и симуляторам свойственны определенные ограничения. В частности, в программах для семейства 8051 контрольные точки, как правило, могут устанавливаться только на месте трехбайтного кода операции.
|
В чем эмуляторы были похожи на мониторы так это в ориентации на язык ассемблера. Так было в 70-х годах прошлого столетия, когда ни один язык высокого уровня не мог сравниться с нынешней распространенностью в индустрии встраиваемых компьютеров языка Си. Да и код, создаваемый первыми компиляторами языков высокого уровня, не был достаточно компактен, чтобы уместить его во встраиваемых системах.
|
Из-за высокой стоимости и сравнительной ненадежности некоторых первых эмуляторов многие пользователи отказывались от них в пользу ПЗУ-мониторов. Это может показаться шагом назад, однако разработчики предпочитают двигаться вперед в решении своей задачи, а не тратить время на борьбу с ненадежным оборудованием. Симуляторы были недоступны, и мониторы были единственным выходом в этой ситуации.
|
Кроме того, иногда вместо эмуляторов использовались логические анализаторы, поскольку они имели гораздо лучшие средства синхронизации доступа к информации. По крайней мере, они позволяли видеть, что творится на шине, не нарушая при этом ее работы.
|
Также одним из недостатков первых эмуляторов было низкое быстродействие последовательных линий связи. Хотя 9600 бод довольно высокая скорость, на загрузку программы могло уходить значительное время. Кроме того, требовалось время и на генерацию таблицы символов.
|
Логические анализаторы |
|
|
Логические анализаторы это, в общем-то, не программные средства отладки, однако отсутствие на первых порах хороших эмуляторов способствовало их выдвижению на передний план. Логические анализаторы позволяли оперативно считывать состояние шин адреса и данных, не мешая при этом их нормальной работе. С течением времени они улучшились настолько, что практически превратились в надежное, менее дорогое подобие того, чем ранее были внутрисхемные эмуляторы. Некоторые из лучших логических анализаторов могут даже реассемблировать данные на шине. В настоящее время их иногда используют для отладки на аппаратном уровне. Стоимость логических анализаторов по-прежнему очень высока.
|
Новая эра |
|
|
Однако прошлое прошло, мир меняется, причём с пугающей быстротой. Все стало одновременно и меньше, и больше. Быстродействие возросло, цена упала, появились новые возможности, улучшенные интерфейсы и мультимедийные функции (все теперь мультимедийное)... К нашим услугам справочные файлы с красивыми цветными картинками, гипертекст, более образные иконки, программы с надоедливым пиканьем в соответствующие моменты ну чего уж кажется больше?
|
Такое бурное развитие встроенного инструментария произошло главным образом благодаря самой полупроводниковой промышленности. Эти перемены результат значительного увеличения числа транзисторов на кристалле и внедрения технологий массового производства, позволивших существенно снизить стоимость микросхем. Это означает, что в менее дорогие кристаллы теперь можно упаковать больше функций, включая средства отладки.
|
Другое следствие полупроводниковой революции появление очень мощных и при этом недорогих хост-систем. Персональные компьютеры с более мощными процессорами, весьма емкими жесткими дисками, десятками мегабайт (а не килобайт!) оперативной памяти, многооконными графическими интерфейсами (а не экраном с несколькими строками текста) и в десятки раз более высоким быстродействием сейчас применяются везде. Соответственно, и пользовательский интерфейс программного инструментария, и вычислительные возможности хост-системы по обработке данных эмулятора улучшились весьма значительно. Побочный эффект роста мощности хост-систем возможность интеграции инструментальных средств.
|
В итоге родилось такое понятие, как интегрированная среда разработки (Integrated Development Environment IDE). Теперь есть реальная возможность в одной и той же компьютерной системе работать одновременно и с компилятором (управляемым мышью посредством меню), и с отладчиком (симулятором, ПЗУ-монитором или эмулятором), с необыкновенной легкостью переключаясь между ними по мере необходимости. Циклы редактирования, компиляции, компоновки и отладки в эмуляторе поразительным образом укоротились.
|
Однако, несмотря на столь радужную картину, многие разработчики до сих пор пользуются программами с интерпретаторами командной строки и создают файлы для DOS. Не вызовет удивления, если где-то обнаружатся и поклонники операционной системы C/РМ.
|
Осовременивание ПЗУ-мониторов |
|
|
На фоне симуляторов и эмуляторов с отладкой на языках высокого уровня ПЗУ-мониторы, которые ориентированы на ассемблер, начали выглядеть устаревшими. Однако оказалось, что такие мониторы очень просто модернизировать: создав монитор целевого устройства, который "обманывает" отладчик высокого уровня (компонент эмулятора) и вынуждает его "поверить" в существование аппаратной части эмулятора, пользователь монитора мог обратиться к функциям, ранее доступным только пользователям эмуляторов. Теперь скомпилированную тестовую программу можно загружать в целевую систему для пошагового исполнения операторов на языке Си; устанавливая при этом контрольные точки по любым адресам с помощью исходного текста или таблицы символов.
|
Пользовательский интерфейс монитора теперь тоже стал многооконным, с управлением мышью и всплывающими меню. В некоторых случаях он стал полностью аналогичен интерфейсу эмулятора. Появилась возможность написания командных файлов для создания повторяющихся условий тестирования для разных секций пользовательских программ ранее прерогатива симуляторов. Некоторые отладчики высокого уровня на основе мониторов могут даже отражать на экране хост-системы изменение значений переменных в процессе исполнения программы, хотя и с некоторой потерей оперативности. Вместе с тем ПЗУ-мониторы до сих пор не являются программами реального времени и изменяют карту памяти. Правда, некоторые современные мониторы загружаются теперь в верхние адреса памяти. Это изменение в местоположении монитора означает, что пользовательская программа компилируется для размещения в тех же адресах, что и в окончательной целевой системе. Хотя это и значительный шаг вперед, карта памяти всё же искажается. В некоторых случаях такие мониторы требуют для отображения кода в память специальных аппаратных средств. В настоящее время мониторы в основном применяются в следующих двух областях.
|
Во-первых, в очень простых и недорогих проектах, где проблемы с аппаратными средствами или критичностью обработки во времени маловероятны. Предполагается, что для использования монитора доступна дополнительная память и имеется свободный последовательный порт. Однако, выбирая "дешевый" ПЗУ-монитор, следует помнить, что последовательные порты стоят денег и что стоимость проектирования дополнительного последовательного порта, электронных компонентов и организации производства может быть весьма значительной.
|
Во-вторых, на начальных этапах крупных проектов, когда испытания программного обеспечения осуществляется на полностью отлаженной плате, обычно предоставляемой производителем процессоров или другими поставщиками. Отказываются от ПЗУ-мониторов в пользу полнофункционального внутрисхемного эмулятора (ВСЭ) обычно на последующих стадиях проекта, когда доступны реальные целевые системы. Хотя ВСЭ может делать то же самое, что и ПЗУ-монитор, на начальных этапах разработки отлаживать целевой модуль с помощью ПЗУ-монитора дешевле. Кроме того, на первых этапах разработки нового микропроцессорного устройства найти эмулятор сразу не всегда возможно. Конечно, при этом остаётся проблема установки контрольных точек только в определенных местах программы, например, на трехбайтовых командах в случае отладки микроконтроллера на базе 8051.
|
Практически все современные эмуляторы имеют определенные возможности работы с языками высокого уровня, что говорит о широком использовании языка Си в проектах встраиваемых систем. Сегодня этот язык применяется даже в малобюджетных проектах, так что традиционные мониторы с ориентацией только на ассемблер остались практически не у дел.
|
| Пользовательские приложения со встроенными отладчиками |
В некоторых случаях пользователь может включить в число компонуемых прикладных модулей объектные файлы монитора и тем самым получить прикладную систему со встроенным отладчиком. Благодаря этому возможна отладка непосредственно на месте с использованием только переносного компьютера. Естественно, при этом в системе для поддержки монитора должно быть достаточно места в ОЗУ и ПЗУ и должен существовать запасной последовательный порт. К сожалению, большинство производителей предлагают исходные тексты монитора отнюдь не бесплатно, а в некоторых случаях еще и требуют дополнительную плату за каждую поставляемую с монитором систему.
|
Распространение микроконтроллеров с расположенной на кристалле флэш-памятью или однократно программируемым ПЗУ часто исключает возможность применения мониторов, поскольку ограниченные возможности внешней шины не способствуют подключению ОЗУ большого объема.
|
Современные симуляторы |
|
|
За несколько лет симуляторы прошли в своем развитии довольно большой путь, в значительной степени благодаря повышению мощности персональных компьютеров и операционных систем с графическими интерфейсами пользователя. Симуляторы это средство моделирования поведения процессора целевой системы чисто программным способом. Симуляторы позволяют "запустить" программу и полностью проследить ее исполнение. Поскольку моделирование осуществляется программным способом, программа, естественно, исполняется не в реальном масштабе времени, причем все сигналы ввода/вывода должны генерироваться специальными подпрограммами, разработанными для имитации периферийных устройств и других ресурсов процессора. Большинство коммерческих симуляторов в состоянии моделировать работу самых разных процессоров различных семейств.
|
В состав современных симуляторов входят также отладчики на языках высокого уровня, поскольку в комплект поставки, как правило, входит и соответствующий компилятор. Теперь симулятор может охватывать все фазы разработки проекта, однако его неспособность обрабатывать события и сигналы реального времени означает, что как средство отладки он может использоваться только для разработки самых простейших программ. К этому следует добавить, что если программа должна взаимодействовать с другими устройствами как внутрикристальными, так и внешними периферийными устройствами, сложность их моделирования практически сводит на нет все преимущества этого подхода. Сила симуляторов в их способности исполнять отлаживаемое программное обеспечение (целиком или частично) повторяемым образом с заранее определенными сигналами. С помощью симулятора можно проводить блочное тестирование исходного модуля или функции. Таким образом, тестирование новой функции перед включением ее в состав разрабатываемой системы позволяет заранее устранить многие потенциальные проблемы с серьезными последствиями в будущем.
|
Благодаря низкой стоимости симуляторов и отсутствию необходимости во внешнем оборудовании, симуляторы стали очень популярными. Ныне их поставляет множество производителей эмуляторов и компиляторов, в то время как традиционные поставщики производители интегральных схем предпочитают покидать этот рынок, заказывая разработку симуляторов, компиляторов и эмуляторов для новых устройств у сторонних поставщиков инструментальных средств.
|
Современные внутрисхемные эмуляторы |
|
|
Современный эмулятор, как и вся электронная техника, стал меньше в размерах, быстрее в операциях, приобрел множество функций и стал стоить намного дешевле. Все этим он обязан "потере" встроенного экрана, клавиатуры и флоппи-дисков (рис. 2), благодаря чему удалось повысить его надежность и удешевить производство. В то же время повысилась скорость вычислений эмулятора, что обеспечило не влияющую на основной режим работы эмуляцию операций в реальном масштабе времени со скоростью, о которой еще несколько лет назад приходилось только мечтать. Последнее объясняется тем, что, в целом, быстродействие встраиваемых целевых систем, по сравнению с эмуляторами, возросло не столь сильно. В них по-прежнему используется 8-Мгц микропроцессор семейства 8051, в то время как в хост-системе на месте 16-МГц процессора 80286 уже стоит Pentium4 с рабочей частотой 2000 МГц.
|
Наконец-то внутрисхемные эмуляторы (ВСЭ) освободились от ассемблера и могут работать с языками высокого уровня (как минимум с Си). Есть даже несколько эмуляторов, которые поддерживают другие языки, такие как PL/M, Pascal, ADA и, что удивительно, Modula 2! Эти языки постепенно вымирают, однако ADA будет жить, пока востребован государственными учреждениями США, да и своих сторонников у него в данный момент достаточно. Всё вышесказанное чисто коммерческий комментарий к существующему соотношению спроса и предложения, не имеющему никакого отношения к технической применимости этих языков.
|
 Рис. 2 Эмулятор Vision ICE II компании WindRiver |
| |
Благодаря поддержке расширенных средств управления объектами в формате OMF (Object Module Format) современные эмуляторы могут отображать текст на языке высокого уровня с полным описанием типов и символов. В некоторых недорогих эмуляторах поддержка расширенных OMF-средств все еще отсутствует. Кроме уже упоминавшихся дисплея и пользовательского интерфейса, в современных ВСЭ отсутствуют микропереключатели (больше не нужны). Конфигурирование и задание параметров теперь выполняется программным образом (с сохранением во флэш-памяти или ПЗУ). В число таких параметров входят тактовая частота целевой системы, тип процессора (и семейство), а также конфигурация периферийных устройств.
|
Такое общее улучшение характеристик в сочетании с еще более быстрым удешевлением технологии способствовало, к сожалению, тому, что некоторые производители вместо более разумного подхода к проектированию стали решать некоторые проблемы "грубой силой". Возьмем, к примеру, точки останова. Внутрисхемные эмуляторы первых поколений, как правило, сначала исполняли команду, на которую была поставлена контрольная точка, и лишь затем останавливались. Поэтому программисту приходилось ставить точку останова до интересуемого его оператора. Однако это не всегда так просто, как кажется. Рассмотрим следующий пример:
|
|
char Func(char b, y)
|
{
|
char x[max_count];
|
count = 0;
|
char a = 1;
|
char c = 2;
|
char z = 3;
|
while (max_count > count)
|
{
|
x[count] = y/((a*b)/(b+c));
|
a++;
|
y++;
|
c = a+(b/a);
|
z = z+x[count];
|
count++;
|
}
|
return(z);
|
}
|
Чтобы увидеть возвращаемое из функции значение переменной "z", надо поставить контрольную точку на оператор возврата, но чтобы он не исполнялся. Выполнение оператора возврата с последующим остановом означает возврат в вызывающий программный модуль, в результате чего внутренние переменные данной функции станут недоступными. Поставить контрольную точку перед оператором возврата значит поставить ее внутри цикла и придумывать какие-то переключатели. Ни один из этих методов не удовлетворителен, но многие эмуляторы по-прежнему действуют так же, как и раньше.
|
Реализация останова на операторе в месте контрольной точки, без его исполнения, требует трудоёмкой разработки схем предупредительной дешифрации кодов операций, не влияющих на исполнение программ. Это дало бы и побочный эффект очень хорошую, с точки зрения пользователей, пусковую систему и улучшенные характеристики трассировки. Для имитации такого действия некоторые эмуляторы, не имеющие схем предварительной дешифрации, вставляют в ассемблированную программу инструкции NOP перед каждым оператором языка Си.
|
Благодаря удешевлению памяти многие эмуляторы оснащены буферами трассировки значительных объемов, причем этот факт преподносится как одно из достоинств эмулятора. Некоторые производители все-таки проанализировали, что же на самом деле требуется для повышения эффективности, и пришли к выводу, что лучше тратить меньше времени на трассировку 1К байтов, чем долго ворошить 8К байтов в поисках возникшей проблемы. Всё это требует хорошего набора триггеров и хранения нужной информации в буфере. В состав нужной информации входят:
|
- адреса выполненных инструкций (а также не загруженных и проигнорированных),
|
- метки кодов и названия переменных,
|
- внешние сигналы, порты и т.д.
|
- состояния шины, результаты команд чтения/записи, подтверждения прерываний и т.д.
|
Хороший эмулятор должен также представлять данные несколькими способами. Например, в виде дисассемблированного кода, операторов языка высокого уровня, машинных циклов и, как делает большинство программ, в виде двоичного и шестнадцатиричного кода. Желательна также возможность генерации событий и организации буфера как кольцевого и линейного.
|
Должна также существовать возможность объединения этих режимов с целью, например, трассировки на основе абсолютных циклов с отображением ситуации до (или после) события в виде операторов языка высокого уровня.
|
Некоторые эмуляторы лишь регистрируют в буфере трассировки точки перехода в программе, а затем при анализе содержимого динамически воссоздают на его основе исходный текст. Вместе с механизмами определения моментов запуска и останова и выявления обращений к библиотекам это может дать весьма мощную систему трассировки, не требующую большого объёма буфера трассировки. Кроме того, должна существовать возможность доступа к содержимому буфера трассировки во время исполнения программы средствами эмулятора (а не позднее средствами текстового редактора).
|
Некоторым эмуляторам буферы трассировки большого объема нужны потому, что они записывают в него весь ассемблерный код, а не только операторы языка Си, и не умеют игнорировать обращения к библиотечным функциям. Кроме того, как уже ранее говорилось, они могут вставлять в начало каждого оператора языка Си инструкцию NOP.
|
Во многих случаях для создания внутрисхемного эмулятора требуются специализированные микросхемы, которые есть только у производителя кристаллов. Для решения этой проблемы полупроводниковая промышленность предлагает такое средство, как FPGA-матрицы. Они часто используются в составе недорогих эмуляторов, для того чтобы создать у будущего пользователя впечатление практически тех же возможностей, что и у более дорогих ВСЭ. Впечатление сохраняется до тех пор, пока вы не начнете этим ВСЭ пользоваться и не обнаружите, что по эффективности он не сравним с настоящим эмулятором, особенно там, где вам как раз и нужны его возможности как системы "жесткого" реального времени.
|
Эта новая дешёвая технология породила множество так называемых "универсальных" эмуляторов, которые могут работать с несколькими семействами микропроцессорных устройств. Однако если бы всё было так просто, применение FPGA-матриц для выпуска многоархитектурных эмуляторов привлекло бы многих ведущих производителей ВСЭ. И по стоимости было бы замечательно однако на практике так не произошло!
|
Вспоминается шуточное определение эрудита: "эрудит это тот, кто знает ничего обо всём". Стоит только сравнить фон-неймановскую архитектуру микропроцессорной серии 68К со всем её своеобразием и гарвардскую архитектуру процессора 8051, как сразу становится ясно, что, либо система состоит из компромиссов, либо в одном корпусе мы имеем две системы. Если это двойная система, то такой эмулятор должен стоить дороже, чем эмулятор, рассчитанный на одно семейство микропроцессоров. Однако эти "универсальные" системы предлагаются по цене, гораздо меньшей. Такие недорогие "универсалы", как правило, требуют дополнительных модификаций, чтобы только приблизиться к возможностям эмулятора одного единственного семейства микропроцессоров. Бесплатного сыра просто так не бывает.
|
Одной из "преходящих" проблем в истории внутрисхемных эмуляторов оказалась проблема последовательных соединений. В те времена, когда скорость передачи по параллельным линиям связи составляла 1200, 2400, 4800 и (при известном старании) 9600 бод, панацеей считалось соединение персонального компьютера и ВСЭ параллельными линиями связи. Некоторые производители даже встраивали эмулятор непосредственно в персональный компьютер! Современные же последовательные линии вполне нормально работают на скорости 115200 бод. Даже весьма крупные программы загружаются за секунды. Параллельные шины ушли со сцены, во многих системах уступив место линиям Ethernet.
|
Новые возможности внутрисхемных эмуляторов |
|
|
Кроме поддержки языков высокого уровня и улучшенных триггеров и трассировки, современные эмуляторы обладают множеством других достоинств. Среди них анализ использования кода и подсчет времени исполнения. Некоторые симуляторы тоже имеют подобные характеристики, однако не на реальном оборудовании и не в реальном времени, что превращает подсчет времени исполнения в чисто академический интерес.
|
| Анализ использования кода |
Анализ использования кода одна из важнейших составляющих процесса тестирования и аттестации программы, особенно в системах с повышенными требованиями к безопасности. Если говорить просто, то в процессе этого теста должно быть документально доказано, что при выполнении конкретной тестовой программы все инструкции исполняются, причём без сбоев. После прохождения этого теста конечному пользователю даётся практически абсолютная гарантия того, что скрытых ошибок в системе нет. Анализ использования данных определяет, к каким областям данных осуществлялся доступ в процессе тестирования, позволяя выявлять потенциально опасные операции чтения (READ), выполняемые до инициализации данных операцией записи (WRITE). Для аттестации встраиваемой программы она должна работать на целевом оборудовании в режиме реального времени. Такое возможно только с использованием ВСЭ. На симуляторе может быть выполнен и анализ использования кода, однако не в реальном аппаратном окружении, к тому же ПЗУ-монитор (если только не поставляется в составе продукта) меняет распределение памяти (и в любом случае не обеспечивает работу в реальном масштабе времени).
|
| Подсчет времени исполнения |
Подсчет времени исполнения прикладных программ требует от симуляторов работы в режиме настоящего, "жесткого", а не псевдореального времени. Симуляторы могут показывать длительность исполнения в циклах и процентах, но не в миллисекундах. Одно из достоинств современных эмуляторов, на которое часто не обращают внимания, их способность определять, по желанию пользователя, чистое время исполнения функций, то есть длительность их исполнения, как с учетом, так и без учета времени работы подпрограмм и вызываемых библиотечных функций. Предположим, надо узнать, сколько времени занимает выполнение функции, содержащей множество операторов IF. Глупо просчитывать напрямую все возможные варианты выполнения этой функции (хотя владеть карманным калькулятором вы научитесь мастерски). Эмулятор, удалив все вложенные подпрограммы, точно определит длительность исполнения основного тела функции.
|
Новые методы: N-проводные отладчики |
|
|
Одна из проблем, связанная с использованием новых эмуляторов, это компоновка целевого устройства. Микросхемы с двухрядным размещением выводов сейчас используются лишь в самых недорогих проектах. Наиболее распространенная ныне практика поверхностный монтаж микросхем с множеством близко расположенных выводов, что требует применения сложных, дорогих и "капризных", с механической и электрической точки зрения, адаптеров.
|
В стремлении к стандартизации методов отладки и избавления от многочисленных дополнительных кабелей, изобретались различные схемные приспособления. Как правило, эти схемы подключаются к весьма небольшому числу выводов (три-пять) процессора, установленного в стандартное гнездо. И хотя в большинстве случаев они способны отобразить происходящее внутри процессора, состязаться с полнофункциональным эмулятором в части полноты оперативной информации они не в состоянии. В некоторых случаях реализуемый такими схемами сервис крайне ограничен.
|
| JTAG |
Система JTAG это 5-проводная диагностическая система, являющаяся частью стандарта IEEE 1149. Она реализует метод периферийного сканирования, то есть получения последовательности состояний выводов исследуемого устройства. В системе есть порт TAP (Test Acces Port), посредством которого можно выполнять ограниченное число команд. Поскольку информация вводится в отлаживаемое устройство и выводится из него в последовательном виде, метод JTAG не может похвастаться оперативностью и служить заменой полнофункциональному эмулятору, так как не в состоянии отразить текущее состояние внутренних шин.
|
Вместе с тем JTAG широко используется для отладки реальных устройств, поскольку не требует никакой оперативной памяти и дополнительных портов. Тестируемая программа может быть той окончательной версией, которая будет поставляться. Другое достоинство JTAG заключается в том, что этот метод позволяет одновременно тестировать несколько устройств на плате, выступая в этом случае в роли псевдоэмулятора.
|
Учитывая то, что JATG сейчас является де-факто стандартным интерфейсом для отладки, разработчики новых стандартов стремились сделать их электрически совместимыми с существующим решением. В настоящее время предлагается две альтернативные реализации: так называемый улучшенный JTAG (EJTAG) от фирмы MIPS и интерфейс NEXUS.
|
| Отладочный интерфейс NEXUS |
Стандарт IEEE-ISTO 5001-1999, или Nexus 5001, ранее называвшийся GEPDISC (Global Embedded Processor Debug Interface Consortium), был задуман как стандартный отладочный интерфейс для встроенных применений. По начальной спецификации он должен обеспечивать:
|
- отладку в режиме реального времени;
|
- слежение в реальном времени за исполняемым кодом и данными;
|
- калибровку (изменение данных "на лету");
|
- анализ логики исполнения;
|
- быструю отладку опытных образцов.
|
Почему назрела необходимость в разработке нового стандарта?
|
Отладочные средства, встроенные в процессоры, нужны уже сегодня (и тем более в будущем), поскольку без такой поддержки невозможно либо технически, либо экономически разрабатывать и применять традиционные средства отладки, учитывая все увеличивающиеся скорости работы микросхем. Вот некоторые основные причины:
|
- хранение кода программы в памяти, расположенной в той же микросхеме, что и процессор, крайне затрудняет (или даже делает невозможным) применение традиционных внешних устройств, таких как логические анализаторы или эмуляторы для определения исполняемых инструкций, поскольку просто не существует доступа к шине снаружи;
|
- очень высокие скорости работы микропроцессоров означают, что отладчики не в состоянии корректно устанавливать точки останова, поскольку временные интервалы слишком малы для обеспечения режима работы "остановка-перед-исполнением";
|
- использование на кристаллах очередей команд, RISC-архитектур и кэш-памяти крайне затрудняет выявление выполняемых в данный момент инструкций;
|
- растущая популярность систем-на-кристалле (SOC), многие из которых включают более одного процессора и ориентируются на решение конкретных задач, означает что, для того чтобы избежать переделки отладочных средств для каждого нового SOC-кристалла, необходимо наличие встроенного единообразного отладочного интерфейса;
|
- поскольку сроки разработки новых продуктов стремительно сокращаются, для выхода продукта на рынок в установленные сроки, необходимо наличие надежного и эффективного механизма отладки.
|
Перечислим основные свойства интерфейса NEXUS.
|
- Управление процессором в режиме исполнения. Это базовое свойство всех отладочных средств является стандартом для всех внутрисхемных отладчиков. Оно позволяет запускать и останавливать процессор, модифицировать регистры и обеспечивать пошаговое исполнение инструкций.
|
- Интерфейс NEXUS обеспечивает доступ к памяти во время работы микропроцессора ("на лету"). Это свойство позволяет отладочным средствам читать и модифицировать содержимое ячеек памяти во время работы процессора без влияния на исполняемые инструкции. Доступ "на лету" очень привлекательное средство для отладки систем реального времени, где остановка системы при проведении тестов просто невозможна.
|
- Точки останова. В интерфейсе NEXUS используется техника "Переход-Запись" (Branch-trace) для компрессирования информации, необходимой для отслеживания процесса исполнения программы. Адрес исполняемого кода выдается в интерфейс NEXUS только для команд перехода или исключений, отладочные средства потом интерполируют (восстанавливают) ход исполнения программы путем добавления последовательных (не переходы) инструкций на основании образа программы на диске. Это позволяет полностью восстановить ход исполнения программы. Пример приведен на рис. 3:
|
 Рис.3 Стандартизация отладочной спецификации Nexus 5001 упрощает трассируемость кода программы, благодаря передаче сообщений о ветвлениях и ассемблированию кода во время его исполнения в реальном времени на встроенном процессоре целевого устройства. |
| |
- Трассировка данных. Это свойство позволяет записывать в реальном времени адреса, по которым производилось обращение к данным. Регистрация может производиться по специфическим адресам памяти (начальный и конечный адрес региона) и по типу доступа (запись чтение).
|
- Контроль владельца. Благодаря этому свойству операционные системы реального времени (ОСРВ) могут идентифицировать исполняемый процесс или поток. ОСВР просто производит запись в специально отведенный в стандарте IEEE-ISTO 5001 -1999 регистр, вызывая тем самым выдачу сообщения "Ownership Trace" в NEXUS-порт. Сообщение содержит параметр, который идентифицирует отлаживаемый процесс или поток.
|
- Замена портов ввода-вывода или области памяти. Это свойство позволяет отображать доступ к внутренней памяти или портам через дополнительный NEXUS-порт. Например, оно может использоваться для изменения ПЗУ, когда вместо чтения ПЗУ на кристалле, средство отладки просто обращается к нему через дополнительный NEXUS-порт. Замена портов, например, полезна, когда относительно медленные контакты имеют дополнительную функцию. Это позволяет отладочному средству эмулировать их основную функцию.
|
- Сбор данных. Это свойство было добавлено для поддержки быстрой отладки систем, оно позволяет осуществлять быстрый обмен произвольными массивами данных через дополнительный порт. Этот обмен использует более эффективный протокол, чем при трассировке данных.
|
- Программный Интерфейс. Это низкоуровневый интерфейс программирования (API) который скрывает специфику целевых систем, такую как механизм связи с хост-ЭВМ, и специфические регистры процессора. Такой интерфейс разрабатывается совместно производителем средств отладки и поставщиком микросхем.
|
Классы IEEE-ISTO 5001 -1999
|
Отладочный интерфейс NEXUS является масштабируемым стандартом; в настоящее время существует 4 класса, определяющих функциональность, от базового Класса 1 (JTAG) до Класса 4.
|
Класс 1 поддерживает управление процессором (останов, запуск, запись-чтение памяти при остановленном процессоре, чтение или запись в регистры), используя интерфейс JTAG. Режим обмена полудуплекс, полоса пропускания ограничена. Трассировка не поддерживается.
|
В классе 2 добавляются контроль владельца, трассировка программного кода и возможность использования дополнительного порта для ввода-вывода.
|
Класс 3 добавляет возможность трассировки записи данных и чтения/записи памяти "на лету", без остановки процессора. Трассировка чтения/записи данных, использование дополнительного порта для быстрого обмена данными и эмуляции шин данных/адреса являются опциональными.
|
Класс 4 добавляет эмуляцию памяти через дополнительный NEXUS-порт и возможность старта трассировки с помощью точки останова. Запуск эмуляции памяти по точке останова является опциональным свойством для Класса 4.
|
Примерами микропроцессоров, уже поддерживающих данный стандарт, являются процессоры M-CORE (M340) и MPC565 от компании Моторола.
|
Для поддержки функциональности, определенной в различных классах, используется концепция общедоступных сообщений (Public Messages). Они представляют собой набор пакетов для передачи информации, ассоциированной с каждой особенностью отладки, представленной в стандарте. Общедоступное сообщение (Public Message) включает в себя передачу классификатора или TCODE, идентификационного номера процессора и ассоциированных данных. Основное требование к реализации общедоступных сообщений их эффективность, вследствие этого пакеты могут иметь различную длину в зависимости от TCODE. Каждая конкретная функция NEXUS может требовать генерации нескольких сообщений для передачи необходимой информации. В таблице 1 приведены функции в соответствии с классами и типами используемых сообщений.
|
 Таблица 1 Функции в соответствии с классами и типами сообщений |
| |
| Интерфейс EJTAG |
Консорциум поставщиков средств отладки для RISC-процессоров MIPS (консорциум MIPS RISC) совместно с компанией MIPS Technologies Inc. разработали альтернативную реализацию интерфейса отладки на кристалле, называемую EJTAG (Enhanced JTAG). В настоящее время она воплощена в нескольких процессорах, включая TinyRISC от LSI Logic, семейство TX49 от Toshiba и 32-разрядный процессор JADE от MIPS Technologies, Inc. Для упрощения физической реализации, снижения стоимости и обеспечения совместимости в EJTAG используется интерфейс, аналогичный JTAG. Дополнительная логика, размещенная на кристалле, обеспечивает управление, установку точек останова в данных и коде, трассировку счетчика инструкций в реальном времени.
|
 Рис. 4 Внутренняя архитектура отладочного средства EJTAG |
| |
Для обмена данными со средствами отладки в EJTAG используются те же 5 контактов IEEE 1149.1. На рис.4 изображена внутренняя архитектура EJTAG:
|
Передача данных через TAP-порт происходит в последовательном виде с частотой до 40 Мгц и выше. Контроль работы EJTAG осуществляется с помощью набора внутренних 32-разрядных регистров, которые используются для определения ресурсов, необходимых для отладки и сбора статусной информации.
|
Работа EJTAG контролируется с помощью EJTAG-адаптера, служащего интерфейсом между хост-ЭВМ и целевым устройством, как показано на рис.5:
|
 Рис.5 Схема отладки микроконтроллера с помощью технологии EJTAG |
| |
Возможности отладки ЦП
|
Средства отладки EJTAG требуют высокой степени интеграции с процессором. Для обеспечения процесса отладки блок центрального процессора (ЦП) должен поддерживать специальный режим отладки, регистры и инструкции. Одна из наиболее важных особенностей наличие специального отладочного исключения, приоритет которого выше приоритетов всех других исключений. Оно возникает в том случае, когда установлена программная точка останова, выдана инструкция пошагового исполнения или зарегистрировано отладочное событие JtagBrk в EJTAG. Инструкция программной точки останова (SDBBP) определена в наборе команд архитектуры MIPS. Для простых точек останова отладчик может подменять инструкции приложения на программные точки останова для генерации отладочного исключения.
|
Когда исключение возникает, ЦП переходит в специальный отладочный режим, в котором нет ограничений на доступ к сопроцессорам и памяти, и обычные исключения, такие как ошибка адреса или прерывание, замаскированы.
|
Обработчик исключения обеспечивается отладочной системой и может запускаться через EJTAG-порт, используя интерфейс доступа к процессору, или включается в код приложения по выбору разработчика.
|
Специальные отладочные регистры DEBUG, DEPC и DESAVE содержат отладочную информацию. Регистр DEBUG показывает источник отладочного исключения и других стандартных исключений, которые могут возникать одновременно. Он также используется для установки пошагового режима. Регистр DEPC (Debug Exception Program Counter) содержит адрес точки возникновения исключения. Он используется для возврата в исполняемую программу после завершения режима отладки. Регистр DESAVE (Debug Exception Save Register) может хранить дополнительную информацию, освобождая 32-разрядные регистры процессора общего назначения от задачи сохранения обработчика исключения. В этом случае обработчик исключения не затрагивает содержимое регистров процессора общего назначения.
|
В спецификации EJTAG существуют несколько типов аппаратных точек останова. Они останавливают нормальную работу ЦП и переводят его в отладочный режим. Останов возникает в том случае, когда на шинах адреса, данных или управления ЦП происходят определенные операции. Отладочное исключение возникает до выполнения операции, сохраняя тем самым содержимое регистров или памяти. Аппаратные точки останова, в отличие от программных, могут ассоциироваться с определенным адресом на шине, так что могут использоваться для доступа к любой области памяти.
|
Всего определено три типа аппаратных точек останова: по команде, по данным и по шине процессора.
|
Одной из самых больших проблем в отладке с использованием высокопроизводительных ЦП, снабжённых кэш-памятью, является доступ в реальном времени к счетчику команд. Режим EJTAG RPCT (Real Time Counter Trace) позволяет отслеживать счетчик в реальном времени, но, тем не менее, требует дополнительных контактов в интерфейсе. Число контактов зависит от скорости процессора. В зависимости от числа контактов и тактовой частоты для вывода данных, процессор может работать на полной скорости, либо приостанавливаться для ожидания завершения передачи. Например, в ядрах JADE 32 от MIPS Technologies процессор может использовать от 4 до 11 контактов для передачи данных в реальном времени. При использовании 4 контактов до останова процессора может быть зарегистрировано около 40% данных, при использовании 11 контактов, достигается 100-процентная передача данных без остановки процессора.
|
Состояние счетчика передается лишь в некоторых случаях. Пока происходит последовательное исполнение команд, нет нужды в передаче содержимого счетчика. Только когда происходит переход, ветвление или исключение, новое значение должно быть зафиксировано. В случае исключения передается также информация о его типе. Такой подход позволяет значительно сокращать количество интерфейсных контактов.
|
| BDM (Motorola) |
Отладочное средство BDM (Background Debug Mode отладка в фоновом режиме) это 10-проводная система отладки, используемая в основном компанией Motorola. Система позволяет считывать и записывать данные в отдельные ячейки памяти и регистры, читать и записывать данные в непрерывные блоки памяти, а также останавливать и возобновлять исполнение программы с указанного адреса (который может быть исходным или модифицированным значением регистра счетчика команд). При своей активизации BDM полностью останавливает текущую работу микропроцессора. Заменить внутрисхемный эмулятор метод BDM не может, хотя всё же и дает разработчику динамически загружаемый ПЗУ-монитор (правда, с базовыми функциями). Основным достоинством этого метода является то, что отладка может осуществляться из программ, работающих на хост-ПК.
|
Хотя система BDM и не всесильна, её можно считать бесплатной в том смысле, что она вообще не требует никаких ресурсов и во всех случаях присутствует на кристалле. Современные BDM-адаптеры и программное обеспечение хост-ПК относительно недороги.
|
| AMDeBug |
Недавно компания AMD объявила о создании специальной, встроенной в кристалл диагностической системы для своих процессоров семейства Е86, в состав которой входит буфер трассировки и которая обеспечивает работу с буфером через последовательный (разъем JTAG) или параллельный порт. Вариант с параллельным портом требует применения диагностической версии микропроцессора.
|
| Концепция эмуляции Enhanced Hooks |
Некоторые производители микросхем воспользовались концепцией эмуляции Enhanced Hooks, разработанной компанией Metalink Corporation. В частности, Siemens применяет ее для контроля исполнения машинных команд и сбора сведений о внутренних операциях в микроконтроллерных устройствах семейства С500 и С166.
|
Концепцией предусмотрена также возможность использования программ, записанных в ПЗУ на кристалле. Внутри каждого производимого интегрального устройства есть встроенные логические схемы, обеспечивающие поддержку концепции Enhanced Hooks, вследствие чего в процессе эмуляции не нужны дорогостоящие диагностические варианты кристаллов. Кроме того, подобное решение гарантирует полную идентичность эмулируемой и производимой микросхем. Технология Enhanced Hooks, требующая наличия в С500 встроенной логики, обеспечивает работу этого процессора вместе с интегральной схемой Enhanced Hooks аналогично работе одной диагностической микросхемы. Благодаря этому упрощается конструкция и снижается стоимость всей системы эмуляции.
|
| Системы ICE-Connect |
Для отладки устройств типа 8051 и С166, которые не являются однокристальными и в которых порты 0 и 2 используются в качестве внешней шины, могут применяться системы ICE-Connect. Особенно они полезны для эмуляции систем с высокой степенью интеграции, где необходимо протестировать покрытие кода в окончательной версии программы и с окончательным составом технических средств.
|
Эмулятор подключается к отлаживаемой системе посредством 30- или 56-контактного переходника (в зависимости от разрядности восьми- или 16-разрядная система), однако вместо дорогостоящей диагностической модификации процессора используется его реальный рабочий вариант. Из дополнительного оборудования для целевой платы нужен лишь переходник ICE-Connect, который экономичен даже в серийном производстве плат. Этот недорогой разъем может быть установлен на любой плате, благодаря чему новые программы могут тестироваться на реальном оборудовании с применением тестов анализа использования кода и расчета времени исполнения, что делает системы ICE-Connect почти обязательными для отладки устройств высокой степени интеграции.
|
| Встроенные в кристалл средства отладки |
Устройства Tricore компании Siemens оснащены дополнительными отладочными средствами. Подключиться к ним можно через интерфейс JTAG по обычному соединительному кабелю. В архитектуре Tricore реализовано два уровня поддержки внутрикристальных средств отладки OCDS (On-Chip Debug Support), обеспечивающих реализацию чрезвычайно мощных инструментальных средств. Оба уровня отличаются гораздо более широкими возможностями, чем может предложить обычный JTAG-коннектор. Интегрированные схемы отладки не требуют выделения никаких ресурсов целевой системы (например, коммуникационных интерфейсов или памяти), а ошибки в прикладной программе на работу управляющего монитора никакого влияния не оказывают.
|
OCDS-средства уровня 1
|
При обнаружении ошибки программа может быть остановлена, хотя возможна всего лишь выдача соответствующих сигналов внешнему тестовому оборудованию с продолжением работы программы. Кроме того, присвоив отладочному прерыванию определенный уровень приоритета, можно организовывать постоянную обработку более приоритетных прерываний в критичных ко времени программных секциях, пока приостановлено исполнение отлаживаемых кодов более низкого приоритета. Другое достоинство OCDS-средств возможность операций чтения/записи по внутренним шинам Tricore с обращением в процессе исполнения программы к любому допустимому адресу (включая внутренние регистры) с крайне незначительным ухудшением оперативности. Таким образом, возможен доступ к любым переменным и параметрам программы "на лету".
|
OCDS-средства уровня 2
|
Этот уровень отличается дополнительной поддержкой в виде специализированной эмулирующей микросхемы, снабженной добавочными контактами, что значительно облегчает трассировку исполнения программы и поиск трудно выявляемых ошибок. Отладка на этом уровне требует прямого соединения с целевым контроллером и подключения дополнительного оборудования для регистрации сведений о ходе исполнения программы.
|
| Резюме |
Основная проблема, связанная с описанными N-проводными системами, их ориентация на микросхемы определенной архитектуры или определенного поставщика. Вместе с тем ориентация на разные архитектуры характерна и для эмуляторов, симуляторов и ПЗУ-мониторов, и большим недостатком обычно не выглядит. Да и вряд ли можно серьезно предполагать, что кто-нибудь будет пользоваться для отладки систем х86 средствами, рассчитанными на архитектуру 68К. Как правило, разработчики специализируются на одном-двух типах микропроцессорных устройств, и желание приобрести универсальный ВСЭ для всех типов архитектур так и останется розовой мечтой (по крайней мере, в обозримом будущем).
|
Пригодится все |
|
|
При разработке крупных проектов, как правило, нужны отладчики всех типов. Более того, они нужны для реализации вообще всех проектов (правда, в некоторых случаях дело упирается в цену). Что касается встраиваемых систем, на разработку которых влияют вопросы безопасности, время и наличие ресурсов (как в целевой системе, так и финансовых), то здесь наиболее полезным и экономичным является внутрисхемный эмулятор.
|
| Симуляторы |
Используются для тестирования новых программных секций в процессе проектирования, а также поиска и устранения несложных ошибок, для блочного тестирования функций или программных модулей в последовательности тестов. Одно из достоинств заключается в том, что, поскольку симуляторы не требуют наличия реальных аппаратных средств, разработка программного обеспечения может идти прежде, чем появятся технические средства, включая целевое микропроцессорное устройство. Кроме того, их стоимость обычно составляет порядка четверти стоимости ВСЭ, поэтому они могут применяться в больших коллективах для блочного тестирования компонентов программного обеспечения. Таким образом, тестирование системы или демонстрация опытных образцов может осуществляться везде, где есть возможность воспользоваться ноутбуком.
|
| ПЗУ-Мониторы |
Применяются для тестирования самых первых версий программы с выводом реальных сигналов, а также в качестве вспомогательного средства при использовании эмулятора. ПЗУ-мониторы обычно используются для контроля исполнения тестовой программы на оборудовании, о котором заранее известно, что оно хорошо разработано и надёжно функционирует. Как правило, поставляются производителями интегральных схем или их партнерами для испытаний периферийных устройств, тестовых алгоритмов на реальном кристалле (если не на окончательной целевой системе). ПЗУ-мониторы, как и симуляторы, используются для тестирования отдельных программных элементов, но чаще для тестирования ввода/вывода.
|
| Эмуляторы |
Применяются для интеграции реальных аппаратных и программных средств разрабатываемой системы, поиска и устранения ошибок, зависящих от времени исполнения и используемой аппаратуры, оценки эксплуатационных характеристик, а также тестирования программ в целевой среде. Кроме того, для доказательства 100-процентного покрытия кода при тестировании в реальной системе. Тестирование с использованием эмулятора, особенно важно, но это тема для отдельного разговора.
|
К вышесказанному следует добавить, что должна существовать возможность запуска эмулятора в автономном режиме, то есть без целевой системы, только с подключенной адаптерной приставкой. При этом эксплуатационная гибкость сравнима с универсальными возможностями симулятора (в том смысле, что, несмотря на обязательное присутствие в эмуляторе реального микропроцессора, наличие реальной целевой системы не обязательно).
|
| Сравнение |
Небольшие проекты можно, по всей видимости, разрабатывать только с помощью симулятора и ПЗУ-монитора, прибегая к помощи эмуляторов лишь в крайних случаях при решении сложных проблем. И в самом деле, в состав многих моделирующих пакетов сейчас входят версии симуляторов на базе мониторов. В проектах, где характеристики реального времени не являются главными, возможностей отладчика, входящего в состав симулятора, может быть вполне достаточно. Для более крупных проектов или проектов с жесткими требованиями реального времени лучшим вариантом, вероятно, будет отладчик их набора средств эмулятора.
|
| Супермонитор |
Свидетельством продолжающегося размывания границ между различными типа инструментария, применяемого для отладки микропроцессорных устройств, служит появление "супермонитора". Целый ряд компаний-производителей компиляторов предлагает программные средства моделирования ЦП, которые могут поставляться в виде симулятора, монитора или эмулятора. Благодаря сотрудничеству с поставщиками эмуляторов эти системы теперь расширены триггерами и аппаратными средствами трассировки, входящими в состав оборудования эмуляторов. Наблюдается также и обратный процесс: производители внутрисхемных эмуляторов меняют внешние интерфейсы эмуляторов на внешние интерфейсы мониторов и симуляторов. В некоторых случаях производители эмуляторов идут даже на такой шаг, как замена собственных отладчиков на готовые пакеты от поставщиков компиляторов.
|
Автономный эмулятор может выступать в роли симулятора, при этом обеспечивая такие преимущества, как режим реального времени с использованием реального интегрального устройства. Однако такой вариант гораздо дороже и требует наличия реальной микросхемы.
|
| Пожизненная поддержка |
Теоретически разработка может начинаться с использованием симулирующего отладчика, исполняющегося только в персональном компьютере. Когда возникает необходимость, приобретается целевая плата, где в реальном процессоре, с реальными внешними сигналами, с применением монитора запускается отлаживаемая программа. Когда готовы надлежащие аппаратные средства и относящиеся к режиму реального времени моменты игнорировать больше нельзя, комбинация "плата+монитор" заменяется полнофункциональным внутрисхемным эмулятором. И, наконец, в окончательной версии приложения монитор встраивается в прикладной код для отладки в условиях эксплуатации. Таким образом, один и тот же отладчик может использоваться в течение всего жизненного цикла микроконтроллера "от рождения до смерти".
|
| Этап эксплуатации микроконтроллера |
Один из методов поиска ошибок на этапе эксплуатации встраивание в продукт монитора, ICE-Connect, JTAG, BDM или других отладочных средств. Несмотря на то, что встраиваемые устройства очень не похожи друг на друга и на всё остальное, две-три общих черты у них есть. Обычно к ним сильно затруднен доступ; как правило, нет экрана и клавиатуры; и они не ориентированы на решение какой-либо конкретной задачи. Поэтому их нелегко тестировать в полевых условиях. Возьмем, к примеру, небольшую автоматическую станцию "где-нибудь на Гебридах", контролирующую состояние трансатлантического кабеля. Предположим, сетевая автоматика определила возникновение неисправности как ее устранить? Командировка из теплого европейского офиса на далекие острова дождливым вечером накануне выходных вряд ли кому-нибудь понравится. Другое дело, если в системе имеется встроенный ПЗУ-монитор или внутрисхемный эмулятор BDM. С ними можно связываться по модемной линии.
|
Если это оборудование находится в пределах физической досягаемости, то вариантов еще больше. Наиболее распространены простые семисегментные индикаторные табло, на которые выводится код ошибки. Еще больше возможностей дает инструментальный последовательный порт на плате, к которому можно подключить терминал, ноутбук со специализированным программным обеспечением или ПЗУ-монитор в составе знакомого ПО симуляторов, мониторов или эмуляторов.
|
Есть и другие варианты, зависящие от стоимости и сложности оборудования и, естественно, стоимости простоев. Такие простые интерфейсы, как JTAG и ICE-Connect, в состоянии обеспечить подключение к эмулятору любых серийно выпускаемых изделий с минимальными издержками. В случае ICE-Connect, например, на печатной плате необходимо предусмотреть место для выводов двухрядного переходного адаптера. Многие макетные платы сторонних разработчиков уже оснащены подобными переходниками, так что серийные устройства могут запросто подключаться к эмулятору без каких-либо дополнительных затрат или извлечения процессора. Благодаря уменьшению размеров современных внутрисхемных эмуляторов и дешевизне компьютеров, то, что ранее было дорогостоящим лабораторным оборудованием, сегодня стало обычным инструментальным средством. Если кто-то думает, что ВСЭ для "полевых" инженеров удовольствие дорогое, пусть ознакомится с их расходами!
|
ВСЭ будущего |
|
|
Длинный путь своего развития внутрисхемные эмуляторы преодолели очень быстро. Что дальше? Эмуляторы, встроенные в кристалл? Быстрые, многоканальные оптоволоконные линии связи от целевого микропроцессора до ВСЭ вместо JTAG, BDM, OCDS и ICE-Connect? Сам ВСЭ на плате PCMCIA?
|
С ростом быстродействия и сложности микропроцессорных устройств и специализацией внутрикристальных средств отладки мечта об "Универсальным эмуляторе" постепенно отомрёт. Возможно, благодаря встроенным в кристалл отладочным средствам, для каждого микропроцессорного семейства понадобится лишь ВСЭ и соответствующий переходной кабель.
|
Литература |
|
|
1. "Microcontroller Debuggers Their Place In The Microcontroller Application Development Process" by Chris Hills, C.Eng., MIEE and Mike Beach BSc (Hon s) AMIEE, Hitex (UK) Ltd.
|
2. "Non-intrusive On-chip Debug Hardware Accelerates Development for MIPS RISC Processors" EE Times - Morten Zilmer, MIPS Technologies, Inc.
|
3. "IEEE-ISTO 5001 -1999, the Nexus 5001 Forum Standard for a Global Embedded Processor Debug Interface". 15th Dec 1999.
|
4. "The NEXUS Standard: Providing the Gateway to the Embedded Systems of the Future" Hugh O Keeffe, Ashling Microsystems.
|
5. "Evaluation of a New Emulation Port Using an M-CORE Architecture System" David Ruimy Gonzales, Motorola Embedded Platform Solutions.
|
6. "Data trace format facilitates debugs" EETimes, Ron Stence, Semiconductor Products Sector, Motorola.
|
|
|
