8.5. Требования, предъявляемые к системе отладки

Все требования, предъявляемые к системе отладки, можно разделить на две группы:

• требования невидимости самой системы отладки – с точки зрения отлаживаемого МПУ;

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

8.5.1. Требования невидимости

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

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

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

Требования невидимости возникают из-за того, что средство отладки так или иначе занимает часть ресурсов отлаживаемого МПУ. Это может произойти из-за неполной адекватности эмуляции (например - ограничения в скорости работы эмулируемого МП или ОЭВМ), или из-за того, что часть ресурсов оказывается занятой ресурсами средства отладки.

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

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

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

Разработчик обязан учитывать эти ограничения, освобождая данные ресурсы на нужды средств отладки. Таким образом, разработчику приходится работать с «урезанным» вариантом МПУ, что, естественно, не может улучшить тактико–технических данных разработки.

Если, например, средство отладки требует для своих нужд запрос прерывания, а у данного МП он является единственным (так очень часто и бывает), то разработчик вынужден строить МПУ, рассчитанное на работу без прерываний.

Если средство отладки требует отрезка адресного пространства, то разработчик вынужден ограничить размеры программы для МПУ – исключительно для совместимости со средством отладки.

Если средство отладки использует какой-нибудь ресурс совместно с отлаживаемым МПУ, то тут возможны коллизии совсем иного рода.

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

Гораздо более неприятным случаем оказываются системы отладки, которые требуют проводить какие-либо аппаратные доработки отлаживаемого МПУ. Признаком такого случая являются фразы в эксплуатационной документации на средство отладки типа следующей: «разрежьте связь, подходящую к DD9/3 и подключите оба конца к проводам … средства отладки».

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

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

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

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

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