Привязанность к отладчикам Опции

[GetSmart]

А чего было то?

[zltigo]

А чего было то?

Можно предположу?
Не смотря на несомненную многоопытность имеет место быть болезненная привязанность к отладчику . В результате вместо просмотра глазами куска исходника с опиской, или обдумывания алгоритма были получены обильные листинги (да еще и с непонятным ARM ASM) да окошечки c цифирками в которых все проблемы прекрасно замаскировались. То, что было привычным для исходников на ASM для AVR положило свинью.

[Rst7]

Был у меня в практике случай весьма мрачной отладки. Софтина на PIC16, писанная врукопашную (причем не мной) имела баг - происходила ошибка обмена раз в N часов. Если бы она просто происходила и все, вопросов бы не было (ну переповторило бы пакет и окей). Однако, случались такие фазы Луны, что на переповторе ошибка опять повторялась ну и т.д. вплоть до досчета до победного конца счетчика ошибок (собственно, из-за чего внимание и обратили). Попытки вставки различных отладочных фичей не привели к результату - ошибка пропадала. Стало понятно, что проблема кроется где-то в синхронизации потоков (или какой-то подобной фигне). Неделю копались в коде, ничего не нашли. Потом решили, что раз скорость обмена всего 300 бод, запишем через звуковую карту весь обмен на шине до ошибки и посмотрим, что же именно происходит. После того, как записали трехчасовой wav и увидели дупу, ошибку нашли за 5 минут. Судя по коду и каментам, внесена была эта ошибка в результате вбивания костыля по результатам даже не работы с отладчиком, а трассировки в симуляторе (что в общем-то почти один хрен). Вот так. В общей сложности пляски заняли пару недель.

[SasaVitebsk]

Был у меня в практике случай весьма мрачной отладки. Софтина на PIC16, писанная врукопашную (причем не мной) имела баг - происходила ошибка обмена раз в N часов. Если бы она просто происходила и все, вопросов бы не было (ну переповторило бы пакет и окей). Однако, случались такие фазы Луны, что на переповторе ошибка опять повторялась ну и т.д. вплоть до досчета до победного конца счетчика ошибок (собственно, из-за чего внимание и обратили). Попытки вставки различных отладочных фичей не привели к результату - ошибка пропадала. Стало понятно, что проблема кроется где-то в синхронизации потоков (или какой-то подобной фигне). Неделю копались в коде, ничего не нашли. Потом решили, что раз скорость обмена всего 300 бод, запишем через звуковую карту весь обмен на шине до ошибки и посмотрим, что же именно происходит. После того, как записали трехчасовой wav и увидели дупу, ошибку нашли за 5 минут. Судя по коду и каментам, внесена была эта ошибка в результате вбивания костыля по результатам даже не работы с отладчиком, а трассировки в симуляторе (что в общем-то почти один хрен). Вот так. В общей сложности пляски заняли пару недель.

Будьте добры. Приведите пример ошибки привнесённой по результатам работы с отладчиком.

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

zltigo, если бы все придерживались Ваших взглядов, то тогдабы не выпускались в мире килобаксовые и более дорогие отладочные средства. И покупают их, по определению, отнюдь не "моргальщики светодиодами". Они себе не могут позволить дармовой JTAG ICE MK2. Уже не говоря про ONE, к примеру. А это, заметьте, для ширпотребовской AVR. А для TI вообще всё по взрослому.

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

1) Много на форуме человек способных создать монитор-отладчик с возможностями Вашего?
2) Сколько ориентировочно времени они его будут отлаживать?
3) Где взять готовый? Вы готовы поделится своим?
4) Скажите честно (в продолжение предыдущего вопроса), если бы Вы отдали бы свой отладчик сколько % смогло бы им эффективно воспользоваться? Ваша оценка.

[Rst7]

Будьте добры. Приведите пример ошибки привнесённой по результатам работы с отладчиком.

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

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

Дада. Запоминающий осциллограф, в который войдет несколько часов с семплрейтом 96к/с. У меня и сейчас такого нет

А внутрисхемными эмуляторами - не пользуюсь. Есть осциллограф (уже цифровой, но не брезговал и C1-64, главное - сделать правильный ногодрыг на отдельной ножке для синхронизации) для разбора узких мест на периферии, и есть отладочная печать в разных формах - например, когда делал TCP-стек, банально отправлял raw-пакеты с отладочной инфой. В сниффере отлично все видно - пакеты TCP-сессии и между ними - мои пакеты с состоянием. Оказалось очень удобно.

[SasaVitebsk]

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

Да не имеет это отношение к принципу отладки. Симулятор, эмулятор, монитор... Он впёр бы эту ошибку всё равно. Это ошибка человека писавшего программу, а не отладчика.

Дада. Запоминающий осциллограф, в который войдет несколько часов с семплрейтом 96к/с. У меня и сейчас такого нет

Да знаю я всё это. Проходил.
Я, к примеру сделал железяку к компу, на которой делал предварительную обработку, сжатие данных и передачу на комп. Правда ч/з LPT. Ну тогда с процами работал - 1/2 мипса. Реальный сигнал помедленней - успевал. Ну и прога (громко названная осциллограф ). Ей просматривал до 8 лучей с поиском. Сохранилась как раритет. Последнее время не работаю. Отладчика достаточно. В том числе и с синхронизацией и с прочими хренями. Конечно при работе более 2 устройств в системе сложновато, но, как правило система работает по принципу от 2. Иными словами достаточно связки мастер-ведомый. При полной отладке этой системы - далее масштабируется как угодно. А связка мастер-слэйв прекрасно разруливается ч/з отладчик. На уровне транзакций единичных. Если останавливать и то и то. Но даже если не останавливать мастер к примеру, то всё равно любой протокол вылизывается - только дольше.
Кроме того, никто не мешает использовать сам монитор встроенный. Или отладочный вывод. Зато нет необходимости городить сложные прибамбасы для вывода этой отладочной инфы. Есть возможность просмотреть её и так.

А внутрисхемными эмуляторами - не пользуюсь.

Зря.

Есть осциллограф (уже цифровой, но не брезговал и C1-64, главное - сделать правильный ногодрыг на отдельной ножке для синхронизации) для разбора узких мест на периферии, и есть отладочная печать в разных формах - например, когда делал TCP-стек, банально отправлял raw-пакеты с отладочной инфой. В сниффере отлично все видно - пакеты TCP-сессии и между ними - мои пакеты с состоянием. Оказалось очень удобно.

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

А Ваша отладочная печать "в разных формах", как раз и отталкивает. Это как раз то, о чём я и говорю. Наработки - незначительны. Каждый раз приходится править эти самые формы. Для TCP-стека так, для CAN-open по другому. Это я к примеру. Ну хорошо, вы обошлись готовым снифером. А не было бы его - пришлось бы городить.

А я CAN SAE J1939 отладил без снифера и без командировки на МАЗ. Упёрся и не поехал. Они мне блок управления двигателем купили. А себе купили и снифер и прочую хрень. Прямо со снифера тестируют теперьготовые изделия. А я прекрасно всё отладчиком вижу.

Понятно, что совсем без мониторов и трассировщиков никуда.
Последний раз когда я их применял - модем. Там была мной обнаружена ошибка Гипертерминала win. В том числе в XP. Не помню, но по-моему одна на 20Мбайт передаваемых данных. Я помню эти безразмерные портянки. Волосы шевелятся на голове. Если можно от этого уйти, то я постораюсь.

Ну а при однотипных проектах, использование своего монитора очень толково. Однотипных, не значит с однотипным железом. Например есть ОС с кучей отлаженного софта и мы прикручиваем к нему новое железо. Обработка этого железа занимает 2% времени проекта. Конечно, в этом случае JTAG будет проигрывать отлаженному монитору с отлаженным аппаратным выводом дебажной инфы в удобоваримую форму. Особенно если я этим 10 лет пользуюсь.

Только это выход не для всех.