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

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

Чтобы широко обозревать в удобном редакторе нужен кордамп с реальными цифрами указывающими на проблему.
Иначе, что обозревать?


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

Если же скорость обновления фирмвари через JTAG быстрее или сравнима с заливкой через бут (UART Boot например), то на мой взгляд глупо говорить, что компиляция и обновление прошивки сразу из IDE отладчика, пустая трата времени... В этом случае, как раз заливка прошивки через бут будет пустой тратой времени.

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


Отладчик - это инструмент. Один из инструментов. Если им пользуешься, даже редко, то надо научиться им пользоваться. Как и любым инструментом, им можно пользоваться по разному. Можно более эффективно, можно менее. Можно "в лоб", а можно "с вывертом".

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

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

Есть ещё и собственная предрасположенность. Один любит ловить рыбу на спиннинг, - другой на удочку. С точки зрения "удочника" - спиннинг - совершенно бесполезная снасть, абсолютно "неуловистая" и вредная для удочников.

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

На данный момент, однозначно, он мне помогает лучше узнать новое железо. Ознакомится с камнем. Выявить особенности построения. Это как минимум. Правда пока я ещё им слабо владею (MT-Link), а камнем - совсем не владею.

Например: Один из моментов, о чём я писал как о "не совсем коректном поведении отладчика" - я выяснил. У меня после 1-2 остановов наблюдался эфект, как будто прерывания больше не вызываются. Причина оказалась проста. При останове, таймер "пролетал" некоторое время (что понятно и наблюдается также и в AVR). Прерывания вызывались по "сравнению". В связи с этим, при пролёте нужного значения, таймер выходил на счёт до переполнения. А таймер 32 бита и результирующая задержка оказывалась крайне большой, что и приводило к созданию соответствующего эфекта. Интересно что сброс таймера после останова, не приводил к желаемому результату. Видимо пролёт появляется и при старте.
Короче всё это не хомут, а неумение пользоваться инструментом. И надо не плакать, а сжать зубы, изучить, выяснить причину, и устранить её.
Пока я написал банальную фразу в голове:

Есть ещё много белых пятен. Разбираюсь.

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

Я всегда благосклонно отношусь и рассматриваю идеи вне зависимости со стороны они или нет.





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

Просто для меня этот орудие уровня "Ultima ratio regum". Вот и все.




Это, естественно, делает make в едином процессе компиляции - без каких либо ручных манипуляций.

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

Пустая трата времени подключать отладчик к системе в которой неудобно постоянно висеть на USB-JTAG.

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

Не, эти не помогут. У них свои разборки


Не понял что то. Чем не нравится апаратный MATCH ?

Сообщение отредактировал GetSmart - May 27 2009, 23:58

Так аппаратный MATCH и стоит!

Ещё раз попытаюсь пояснить.
1) При останове с помощью MT-LINK, проц останавливается, а таймер продолжает молотить некоторое время.
2) При определённой ситуации, таймер проскакивает MR0.
3) При следующем запуске, из-за п.2. не выполняется прерывание, до тех пор, пока таймер не пройдёт полный круг. А он 32 бита. Время занимает - минуты.

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

С этими строками - всё прекрасно работает. И первоначальная отладка уже завершена. Осталось только ввод/вывод сделать, написать обработчик RS485 и переработать ядро на 32 бита.

Не пытайтесь переворачивайть с ног на голову. Нет никакой особой зависимости - я много более системо и железо независим - как минимум нет требований в отношении наличия JTAG или подобного интерфейса (тем не менее в моем железе он за редчайшими исключениями присутствует), адаптера, доступа к девайсу и ограничений на длинну USB. Можно чем-то не пользоваться по незнанию, можно не пользоваться по причине знания, можно чем-то пользоваться по незнанию - не надо сваливать эти разные причины в одну кучу.

Я не переворачиваю, просто прочитайте безотносительно к себе.
Неужели будете отрицать зависимость от системы? Чтобы "фантазировать" было проще - представим, нет у нас ни CAN, ни ETH, есть только RS485 с медленной опторазвязкой наружу. Будем грузить отладочную прошивку через бут при имеющемся JTAG'е? Проц неважно какой, пусть ARM за десятку с 256K флеш (на 9600 это... хм... 256 * 1024 * 10 / 9600 == 273c, ни много ни мало почти 5 минут, - чертовски эффективно).

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


четвертая кобинация - можно пользоваться по причине знания

Поделился наболевшим, и сразу настучали
Я не техническую сторону имел ввиду, а скорее психологическую.
Вместо того, чтобы сесть и заново четко поставить задачу, нарисовать на бумажке алгоритм, и реализовать его, вчера пол-дня все что-то правил, отлаживал... Зачем, почему? Лох какой-то И я уверен, что не я один такой.
Если Вы, defunt, всегда делаете все максимально эффективно, то я рад за Вас. Научите.

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

Ступеньки д.б. следующие:
1. Составление документации.
2. Составление тестовых сценариев.
3. Реализация кода по п.1
4. Реализация тестовых сценариев по п.2
5. Отладка.
6. Релиз.
7. Тест на регрессию.

п.5 - делайте как Вам удобно. Мне удобно комбинировать трассы (для real time) + отладчик (для анализа кордампа, полная картина всей машины состояний в определенный момент времени + статистика).

Хех ... Дык а я о чем?

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

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

Хочу выразить солидарность с коллегой zltigo: как минимум нужно уметь работать без отладчика, и не чувствовать при таком раскладе дискомфорта. С отладчиком "умеет" работать каждый первый.

Насчет 100% зависимости я совершенно не утверждаю, но, к сожалению, по моим вполне репрезентативным многолетним наблюдением вероятность именно такой зависимости не менее 75%. Что, как минимум, настораживает .

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

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

Вывод. Вдумчивое (неторопливое) написание программы существенно эффективнее поэтапному написанию с использованием железки.

Сообщение отредактировал DpInRock - May 29 2009, 13:05