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

А кто сказал что он один ? все что я описал в ТТХ(кроме 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". Во многих случаях речь идет просто о привычках, даже без приставки "вредных" . И с этими привычками можно прекрасно жить долго и счастливо, если вдруг условия не изменятся. Я уже ноеднократно писал, что для меня отладчик есть своеобразный "последний шанс", Для кого-то отладчие один, пусть и любимый, но "один из шансов". Нешуточные проблемы это когда у многих и очень многих этот "последний шанс" становится "первым" и единственым шансом.

Оба.