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

[GetSmart]

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

[zltigo]

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

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

[zltigo]

Еще об отладчиках Очень часто встречается вариант, когда отладчик-то есть, только вот отлаживать нечего - надо сначала подумать и НАПИСАТЬ хоть что-то. В случае голого софта с этим проще - пишется любая галиматья и в отладчике пороверяется действительно-ли 2+2=4? А вот, например, тут http://electronix.ru/forum/index.php?showtopic=63469&hl= фигово - он-бы и типа "отладил", но попасть туда сначала надо, а для этого надо просто уметь прочитать документацию и правильно написать десяток строк. Взять и написать и все оладчики мира тут не помогут.
Лет мамнадцать назад один в один задача была решена через полдня после ПЕРВОГО моего прикосновения к LPC2114 и ARM вообще. Без всяких отладчиков. Случилось это на плате от Olimex, которую до этого несколько месяцев терзали вполне, типа крутые пользователи AVR+JTAG Ice со словами - "да тут JTAG нужен, куды-ж без него, кто для AVR он у нас есть....".

[SasaVitebsk]

Лет мамнадцать назад один в один задача была решена через полдня после ПЕРВОГО моего прикосновения к LPC2114 и ARM вообще. Без всяких отладчиков. Случилось это на плате от Olimex, которую до этого несколько месяцев терзали вполне, типа крутые пользователи AVR+JTAG Ice со словами - "да тут JTAG нужен, куды-ж без него, кто для AVR он у нас есть....".

А причём здесь отладчик?

Честно говоря, не совсем понимаю о чём тема. Зависимость - сложное понятие.

Приведу пример.
Вот только что закончил проект (надо было) на STEP7 сименса.
Всё по вашему желанию и сценарию.

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

При начале отладки - выяснилась что она практически нулевая. Вопрос к спецу - он мне ответ - а я просто ошибок не делаю. (Правда он 19 лет пишет. Смею предположить, что когда-то он ошибки делал).

Сейчас всё работает естественно. Но, если честно, сейчас, я бы всё переписал заново. И времени не пожалел. Не дадут. Оборудование простаивать не может.

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

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

[galjoen]

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

[zltigo]

буквально за 15 минут отловил глюк в интерфейсной микросхеме (несоответствие описанию).

Ну вот прямо сейчас копаюсь с самой что ни на есть "интерфейсной микросхемой" - 699 листов не слишком подробного описания + errata + notes ... почти 1000 регистров. Всяка разна дополнительная информация типа библиотек от производителя еще не дошла - на CD конфидециально, типа, передают. Несоответствий опиманию уже пяток точно найден. Ума не приложу зачем мне внутрисхемный отладчик для этой работы. Запущена от состояния взяли в руки документацию до состояния дышит, интерфейсы подняты, обмен идет примерно за двое суток. При этом основное время ушло на борьбу с тем, что ее PLL (просто песня, 64 бита конфигурации) не мог на самом деле работать от опорной частоты 16.384MHz. Сегодня продолжил лабораторные работы - нашел пару багов (будем считать мои, покольку последовательность действий не описана, а интуиция не сработала что-то). Куда-бы мне этот отладчик вставить , дабы пользу получить . Сегодня после двух дней писательства и правок всухую системка зависла - на консоль не реагирует, ну думаю, не взять-ли отладчик из стола.... Но вовремя решил, что лучше релизик отладочный собрать в котором консоль максимальный приоритет имеет - минут 10 и все увидел. Отладчиком точно было-бы дольше. Ну начало было-бы быстрым - остановил-бы на ходу в одной из задач предположительно именно в той, которая время и жрет, но дальше шагать куда-то долго и упорно и при этом система-то уже того - стоит как неживая. Да, если там плагинчики под операциоку есть, то можно уже увидеть именно то, что надо, но плагины еще и писать надо, а в живой консоли все это у меня и так есть...

[defunct]

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

Это показывает уровень, насколько операционка "своя".

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

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

Кстати если МС на шине памяти, тогда отладчиком можно ее конфигурировать (все эти 1000 регистров), без единой строчки кода, и без пересборки проекта.

[zltigo]

Это показывает уровень, насколько операционка "своя".

Это Ваше выступление просто показавает насколько Вы "разбираетесь" в отладке операционки.

И нафига куда-то шагать? Остановили - смотрите.

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

Не знаете что смореть?

Разумеется знаю и по этой причине в своей операционке со своими штатными средствами отладки быстро все увидел в проблему возникающую в ДИНАМИКЕ.

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

Кто о чем, а вшивый о бане.

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

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

Естессно, если операционка НЕ своя, то это нереализуемо сложная задача...

Легко делается только то, о чем человек имеет очень отдаленное представление, что Вы сейчас и демонстрируете

Кстати если МС на шине памяти, тогда отладчиком можно ее конфигурировать (все эти 1000 регистров), без единой строчки кода, и без пересборки проекта.

Какая свежая мысль Положим, я доступ к этим регистрам и из консоли имею - десяток сторочек... (забудем пока о том, что не все произвольно на ходу менять можно, не все в произвольный момент времени читать можно, не все в произвольном темпе записывать можно, что чип на 24bit SPI интерфейсе,... ). Ну а дальше что? Полагаете, что оно дальше само светодиодом мигает и все? Оно еще имеет около 90 источников прерываний и регламент их обслуживания и совсем не будет стоять пока кто-то будет пялится отладчиком. А после очухивания славно пойдет не дальше "мигать" а на обработку офигеного количества ошибок возникших за время пока кто-то не разгребал ее 12 64килобитных потоков. При этом и встречная сторона не получая разумной реакции тоже пойдет совсем совсем другими путями начнет перезапросы, восстановления протоколов на самых разных уровнях. Вот так "отладились".
Ну не все пишут "контроллеры светодиодов".

[defunct]

Это Ваше выступление просто показавает насколько Вы "разбираетесь" в отладке операционки.

Я вообще-то об отладке проекта "на базе" операционки, а не самой оперционки (к слову ее тоже удобно отладчиком отлаживать).

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

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

Насчет когда-то потом не отдаст управление, моя ОС умеет отслеживать такие ситуации. В Debug Build'е в случае детекта "подвисшей" задачи - консоли автоматически назначается наивысший приоритет и выдается подробный отчет о "подвисшей" задаче и о состоянии ОС. В release - факт подвисания любой задачи, инициирует запуск дампа с последующим сбросом по WDT.

Разумеется знаю и по этой причине в своей операционке со своими штатными средствами отладки быстро все увидел в проблему возникающую в ДИНАМИКЕ.

напомню что

Сегодня после двух дней писательства и правок всухую системка зависла - на консоль не реагирует

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

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

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

Легко делается только то, о чем человек имеет очень отдаленное представление, что Вы сейчас и демонстрируете

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

Полагаете, что оно дальше само светодиодом мигает и все? Оно еще имеет около 90 источников прерываний и регламент их обслуживания и совсем не будет стоять пока кто-то будет пялится отладчиком. А после очухивания славно пойдет не дальше "мигать" а на обработку офигеного количества ошибок возникших за время пока кто-то не разгребал ее 12 64килобитных потоков. При этом и встречная сторона не получая разумной реакции тоже пойдет совсем совсем другими путями начнет перезапросы, восстановления протоколов на самых разных уровнях. Вот так "отладились".

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



Ладно все это фигня, разбирать конкретную одну ошибку - мелко...
Суть моих опусов вот в чем:
1. Использовать только отладчик (кордамп + пошаговая отладка) - до добра не доведет.
2. Использовать только консоль (трассы) - не все ошибки можно так отловить, банальная ситуация "Device Dead" и приплыли
3. Отладчик (кордамп + пошаговая отладка) + консоль (трассы) - наиболее полный вариант позволяющий найти и устранить любую проблему

[zltigo]

Я вообще-то об отладке проекта "на базе" операционки, а не самой оперционки (к слову ее тоже удобно отладчиком отлаживать).

В если операционки не уровня win/lin то оперционка от проекта с операционкой не отличеется ничем.

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

Именно обо всем этом рассказывает САМА операционка и Вы со своим отладчиком ни нафиг не нужны

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

Прелестные "советы" с колоколенки отлаживателя "контроллера светодиода"

Насчет когда-то потом не отдаст управление, моя ОС умеет отслеживать такие ситуации.

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

Ага, только перед тем как за 10 минут "увидеть" проблему, Вы умолчали сколько времени ушло на то чтобы догадаться,

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

и пересобрать проект,

Ну пресобирать весь незачем, а линкер быстро работает... минута где-то

обновить прошивку.

Еще секунд 30.

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

Это уже, как всегда, выши фантазии - смотрите описание первых 30 секунд "разборок".

ОС у меня заточена так, что я легко могу контроллировать задачи из под отладчика ...

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

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

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

Вам проблему найти или чтоб еще и пользователи не заметили, что Вы там проблему ищите?

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

Суть моих опусов вот в чем:
1. Использовать только отладчик (кордамп + пошаговая отладка) - до добра не доведет.
2. Использовать только консоль (трассы) - не все ошибки можно так отловить, банальная ситуация "Device Dead" и приплыли
3. Отладчик (кордамп + пошаговая отладка) + консоль (трассы) - наиболее полный вариант позволяющий найти и устранить любую проблему

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

[defunct]

если операционки не уровня win/lin то оперционка от проекта с операционкой не отличеется ничем.

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

Именно обо всем этом рассказывает САМА операционка и Вы со своим отладчиком ни нафиг не нужны

В каком виде она рассказывает, да еще и "обо всем"?!
Винда к примеру много Вам рассказывает?

Прелестные "советы" с колоколенки отлаживателя "контроллера светодиода"

Что-то у Вас все кто не делает так как Вы - попадают в разряд еретиков отлаживателей "контроллера светодиода".

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

Ну дык, давайте без ля-ля-ля, у Вас оно делается? Или конкретно в этом случае - нет?

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

С чего бы это удобный инструмент предоставляющий достоверную информацию ставить на последнее место?
На последнее место я лично поставлю логи 3-rd party Host'a (абсолютно бесполезный хлам как правило), следом за ними - неполный / битый кордамп с объекта.

И забыли зачем-то
4. Консоль и "Кордамп" - почти полный вариант, причем, работающий всегда и везде в том числе и на обьекте, а не только на макетном столе.

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

[zltigo]

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

И по именно этой причине эти отладки не отличаются, но Остапа явно понесло и по этому "вывод" прямо противоположный

В каком виде она рассказывает, да еще и "обо всем"?!

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

Винда к примеру много Вам рассказывает?

Как минимум никак не менее линукса, т.е. очень много.

Что-то у Вас все кто не делает так как Вы - попадают в разряд еретиков отлаживателей "контроллера светодиода".

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

Ну дык, давайте без ля-ля-ля, у Вас оно делается? Или конкретно в этом случае - нет?

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

С чего бы это удобный инструмент предоставляющий достоверную информацию ставить на последнее место?

По той простой причине, что он не такой уж и удобный (а в обьектовых условиях просто и невозможный) и предоставляет, хоть и достоверную, соверщенно сырую информацию на интерпретация которой стоит времени, да и то с верочтностью ошибок. Нормально продуманный системно на этапе проектирования лог, уровни отладки, распечатка ошибочных ситуаций позволяют локализовать проблему до порядка нескольких сот строк исходника, ну а уж их НАДО уметь читать глазами. Если лог делается по принципу а не впендюрить-ли мне сюда
printf( "a=%i", a ), то это вообще не лог, а просто тот самый случай, когда дальше носа и отладчика не видят . Спору нет - при такой "методе" отладчик мерещится волшебным ключиком, хотя на самом деле он обычный лом. И желательно, что-бы он был ржавым, а не отполированным до блеска неумеренным употреблением

На последнее место я лично....

Это Ваша колоколенка. Бывает .
P.S.
Не ожидал - нашел в интернете свой первый железный отладчик , aka внутрисхемный эмулятор http://oldcomputermuseum.com/mds_800.html
Вешь, даже в начале-середине 80-x для Союза была крутизны немерянной.