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


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


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


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


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


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

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

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

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

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

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

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

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

И как смотреть? Побайтово?
Операционка абстрагирована от задач и не знает "структуры" которые пользуются задачами.


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

Как угодно.

Читаем внимательно... Вообще-то о многих знает, знает о стеках, знает о используемых задачами областями памяти и их назначении.
Знает о порожденых задачами очередях и соответственно об очередях и их состоянии тоже информация от операционки есть.

А мысль, том, что мне тоже довелось с 1984 года и по сей день неоднократно сравнивать, Вы допустить ну никак не можете?

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

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

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

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

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

Мне угодоно смотреть структуры данных с учетом всех описаных в программе типов, к примеру написать (TYPE.MY_STRUCT)0x0400 и чтобы данные по адресу 0x400 были представлены в виде MY_STRUCT. Это у Вас делается?


Я немного не об этом. Допустим есть некий описатель чего-либо, если не против, пусть это будет описатель некоего канала связи, оформленный в виде структуры:


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

Покажет ли в консоли переменные x, y, z, и имена, ладно фиг с именами, покажет хотя бы адреса присвоенных функций? Или их надо будет искать среди дампа представленного побайтово?

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

Важных структуроподобных СИСТЕМООБРАЗУЮЩИХ вещей крайне немного. Средства для работы с ними встраиваются при написании приложения.

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

И текущий, и перед текущим и вообще где-то с начала 90x... тенденция, однако

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

Ой как-то пропустил
Ессно, end-user'у никто не будет рекомендовать пользовать отладчик. Да собсно и исходники никто ему не даст.
Пусть высылает трассы и дамп если есть проблема.


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


Ладно забудем про 'xy' ;>
Что насчет функций? Без точного представления по какому "пути" бегают сейчас данные замахаемся все верхние уровни перелопачивать.

Как писатель "контроллеров светодиодов" хочу задать Вам один вопрос,
у меня мой "контроллеров светодиодов" легко переживает остановку отладчиком и дальнейший пуск проги,
ни где ничего не рушиться и можно легко походить и пошагово по коду(в определенных пределах конечно...)
TTX моего "контроллера светодиодов":
- 2-3 UART на 115200
- иногда 1 UART на 230400
- иногда 1 I2C на 150000 - 250000
- SPI обмен на 16Мгц (реальный поток примерно 1Мбайт/сек)
- 2 CAN на 500000
- USB на 921600

Что я делаю не так ?

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

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



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

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

А кто сказал что он один ? все что я описал в ТТХ(кроме SPI) это каналы обмена с другими контроллерами,
более того, часть этих каналов может переключаться в разные режимы работы на ходу,
и вот сейчас стою на одном из промежуточных девайсов и легко отлаживаюсь.

Я уже вижу недостаток такого подхода - размер отладочного кода.
Смею предположить, что код консоли в такой форме занимает приличный % от всего проекта. Для МК с небольшим количеством флеш <=256K, консоль может и не влезть, либо влезть только "за счет урезания функционала".


В общем секрет прост:
1. В консоли замечаем проблему.
2. в коде ставим ловушку:



3. сопоставляем конкретные данные с кодом
4. устраняем проблему.

И не важно что после "2" произойдет снаружи. Как правило, одной остановки в "правильном" месте достаточно чтобы пофиксить проблему.

PS: Насчет того что "2" можно опустить, "3" заменить на просто "изучаем исходники", спорить не буду - можно и так, но не факт что так получится быстрее.

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



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

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

Хи-Хи ну и что? Либо это элемент просто построенной системы, пусть и мегагерцами и прочим, и сисмтема "не заметит потери бойца", либо
система более сложно организована и ..... и обломитесь .

Рад за Ваш большой и интерфейсно-мегагерцово-понтовый (ой у меня на текущей железке через контроллер в основном гонят информацию только два SPI, стыдно признаться на 7,5MHz....) "контроллер многих светодиодов". Только во множестве случаев и множестве протоколов принятых, например, даже на самых обычных и банальных телефонных сетях "стою и отлаживаюсь" заканчиается максимум через считанные секунды. После чего дальше уже не продолжите а пойдете медленнои печально через процедуры поднятия линков, установки каналов в исходные состочния и даллее с нуля.... Угадали с точкой останова отладчика? Нет? Тогда сидите и долбитесь. А я лучше головой подумаю, по ходу дела, возможно и еще какие потенциально скользкие моменты в исходнике замечу. Вы можете позволить себе постоять и ммееедленно пойти дальше - рад. Я в очень большом количестве случаев - не могу. При этом владея методикой отладки и без "стою отлаживаюсь" мне совершенно не хочется зачем-то ее менять и для простых логических систем, где "стою отлаживаюсь" вполне себе допустимы.

Занимает, конечно, но единицы процентов - иногда предусматриваеется сборка системы без возможности включить параноидальные уровни отладки (ну типа все на нижних уровнях уже отлажено, а возможноть запаса по загрузке системы не помешает ) так уменьшение размера кода именно единицы процентов. То, что остается, и того меньще - отладчные распечатки стоят в узких узловых местах системы.
Тут реальная проблем только одна - нужно крепко думать об отладке до и во время написания, а не после, как уже ранее писал, не в стиле а не поставить-ли сюда fprintf( "a=%i", a ) является основным методом.

Да.

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

А почему Вы считаете, что на консоль coredump получить нельзя? Очень даже можно, чем я и пользуюсь. Реально правда применял два раза всего...
По поводу пошаговой отладки. Общеизвестно, что самый выгодный метод поиска ошибок - вычитывание кода. Это вполне заменяет пошаговую отладку, надежнее, часто быстрее. Не забывайте, кроме того, про разработку-через-тестирование (согласен, что не везде можно использовать, конечно).
В итоге весь Ваш Священный Набор "кордамп + трассы + пошаговая отладка" с заменой пошаговой отладки на мозг чудесно работает в поле без всяких лишних девайсов.

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


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


Зря.


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

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

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

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

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

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

Разве я что-то другое утверждал? Видимо, Вы меня не совсем верно поняли. Конечно, ошибка внесена человеком. Как на это повлиял отладчик? Неужели Вы никогда не видели кода, который пестрит костылями типа "if (a>(b+2))"? Костыль - это именно "+2", это явно сделано по результатам шагания в отладчике.



И не уговаривайте. Я сторонник подхода господина zltigo - вдумчивое чтение кода и результатов kprintf - куда более правильное занятие.

Я так не считаю потому как и сам через консоль дампы вывожу (и полные и сокращенные).
Написал же - "Device Dead" ситуация - все заткнулось ничего не работает в том числе аварийная консоль, что делать?
Вот здесь два варианта:
1. Подключиться отладчиком и посмотреть в чем дело.
2. Отснять дамп бутлоадером после резета.



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

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

Я не уговариваю. Кроме того вдумчивое чтение исходников никто не отменял.

Для примера скажу, что последний перенос проекта, а он достаточно значительный (под AVR занимал 60к). Было много ковыряний с переферией, разборок с аппаратурой ARM. Одна ошибка переноса. Из-за небрежности при переносе констант из внутренней EEPROM AVR в спец блок 24c512, с соответствующими процедурами на ARM. Плюс в двух местах выравнивание. В одном просто изменил объявление, а в другом (упакованная структура шла с внешнего источника) пришлось изменить объявление, и при приёме вставить нули (распаковать). И всё заработало. И это при полной оптимизации под 8-ми битовик со множеством указателей.
Конечно - главное спасибо IAR, но в тоже время я удовлетворён, так как считаю, что и я корректно прогу написал. Иначе вылизываний было бы много (я этого и ожидал, если честно).
Теперь я перепишу RS232. Потом затестирую рост производительности за счёт производительности проца (именно по этому сохранил 8-ми битовую направленность проекта) потом буду переписывать на 32 битную платформу. Чтобы оценить рост производительности за счёт архитектуры.
Люблю переписывать проекты. Так как в конце, на проект смотришь несколько по-другому.

Так что зависимость от JTAG у меня "на лицо", но пока не считаю это "вредной зависимостью". Думаю от человека зависит.
С другой стороны у Вас "зависимость от мониторов".

Хе-хе, отладчиком Вы тоже ничего не добьетесь в такой ситуации...

Вот вы тут спорите про отладчики... А у меня есть вопрос гораздо интересней - какой язык (из человеческих) на планете самый лучший? Может русский? Может английский? Вот куда надо силы-то тратить

Вашу бы энергию да в полезное русло.

Повторяю, "вредной зависимостью", это является, когда человек слабо представляет как оно без отладчика, "вредной зависимостью" это является, когда дойдя отладчиком куда-то радостно пишут те самые "+2" (о господи! сколько раз я такое наблюдал!) и ждут пока где-то вылезет боком, дабы доковыляв отладчиком в другом месте написать "-2". Во многих случаях речь идет просто о привычках, даже без приставки "вредных" . И с этими привычками можно прекрасно жить долго и счастливо, если вдруг условия не изменятся. Я уже ноеднократно писал, что для меня отладчик есть своеобразный "последний шанс", Для кого-то отладчие один, пусть и любимый, но "один из шансов". Нешуточные проблемы это когда у многих и очень многих этот "последний шанс" становится "первым" и единственым шансом.

Оба.