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

[zltigo]

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

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

[SasaVitebsk]

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

Код переносился с ATMega640. Ядро использовалось в разных вариантах с разными контроллерами и разными схемами. В Mege640 11 портов. В связи с этим аппаратного дешифратора не было. Программно дешифрированное значение адреса строки выводилось прямо в порт. В LPC мне не хватило ног. В связи с этим был поставлен дешифратор. 2 переменные назывались похоже, и в общем-то имели один и тот же смысл: Str_Ekr, Str_Dec. Вместо кода строки (действующие 3 бита) в порт выводилось дешифрированное значение (8 бит). Соответственно портились те биты порта, которые не должны были портится.
Проблем с прерываниями не было. Были проблемы с отладочным выводом.

...болезненная привязанность к отладчику...

Всё никак не мог понять Вашей нелюбви к отладчикам...

Теперь несколько начинаю въезжать в причину. Имею J-Link. Вижу, на сегодня некоторые проблемы с его использованием. Дело в том, аппаратный отладчик - это прибор. Прибору надо доверять абсолютно. Иными словами, если вольтметр показывает 3V, а на самом деле 5V, то единожды обнаружив несоответствие, не будешь им пользоваться, пока не починишь. Даже если на другом пределе он даёт верные показания. Это вопросы доверия. Пока несколько раз сталкивался с непонятным поведением кристалла под отладчиком. Но для полной убедительности надо время и знания самого кристалла. Постепенно въезжаю.
Второй момент - это навороченный ассемблер. Система команд, мягко говоря сложновата для быстрого чтения листинга. Широкое применение косвенной адресации при обращении к переферии, не позволяет чётко определять куда именно обращаемся. Условное исполнение, не даёт "влёт" следить за текстом ну и так далее.
Третий момент - оптимизация. Похоже - неплохой оптимизатор. Поскольку я сразу работаю и отлаживаю под максимальной оптимизацией, то есть некоторые "нюансы".
Ну и некоторые мелочи. Например возникают сложности с установкой нескольких точек останова, появляются каки-то жуткие тормоза и прочее.
Всё это, конечно не способствует..... Но...

Под AVR JTAG ICE MK2 ни одной из перечисленных проблем просто нет. Никаких ассемблерных листингов я практически не просматриваю. Шпарю сразу по сишной проге. Если нет необходимости просматривать нижний уровень, то и не надо. Почему вы думаете, что я по шагам хожу? Принял пакет (к примеру), посмотрел корректность его прямо в буфере. Прекрасно работает всё и со структурами и с указателями. Отлично с кучей. Запускаю на исполнение - приостановил в нужный момент - посмотрел "что творится". Очень удобно. Кроме того - ничуть не мешает Вашему подходу с отладкой. Введите отлаживаемые переменные - останавливайте и просматривайте. Кто мешает?

При работе с однотипными изделиями - отладочный монитор - хорошее дело. Сам не раз пользовался. Делал и на 232 и на I2C и спец приблуды для скоростного мониторинга. Но при разноплановых изделиях - каждый раз приходится вносить изменения. Каждый раз править. В том числе аппаратные вещи. Это отнимает кучу времени. В этом смысле - применение хардварного отладчика - неплохой выход. Другое дело что дорогой! Я думаю, что если бы я применил какой-нибудь дорогой отладчик, например от IAR или от NXP, то проблем было бы меньше.

[zltigo]

Всё никак не мог понять Вашей нелюбви к отладчикам...

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

Кроме того - ничуть не мешает Вашему подходу с отладкой. Введите отлаживаемые переменные - останавливайте и просматривайте. Кто мешает?

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

Я думаю, что если бы я применил какой-нибудь дорогой отладчик, например от IAR или от NXP, то проблем было бы меньше.

У IAR J-Link с наклейкой IAR. У NXP нет вообще.

[defunct]

"Переменные" это слишком мелко - так, трава в лесу. Типичная поблема при комплексной отладке И ОБЪЕКТОВОЙ это ну, например, рассмотрение пакетов нетривиальных протоколов - я убьюсь их битовые поля и варианты форматов-размеров полей в отладчике ввиде байтов рассматривать.

Может это от лени? Никто не мешает объявить соответвующие типы для нетривиальных протоколов, и смотреть в удобочитаемом виде, перемещая указатель на соответвующую структуру по телу пакета.

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

Никуда реальное время не идет. Просто не надо ходить по шагам там где не надо.
Выделяете наиболее подходящее место, (если проблема с приемом точку останова после приема всего фрейма, если с отправкой - точку останова перед отправкой всего фрейма и смотрите что не так).

По исходнику однозначно дольше получится.

Пример из жизни: MEK870-5-101 по синхронному каналу. Имеются два типа фреймов Fixed / variable. После портирования с одного проца на другой перестали работать variable frames. Неизвестно, что не работает прием или отправка.
Отладчиком поставил точку останова на парсер variable фрейма, и буквально за 5 минут нашел, что проблема совершенно в левом месте, в функции системной библиотеки и константе накладывающей ограничения на размер сообщений.

По исходникам я бы и не догадался туда смотреть.

[zltigo]

Никто не мешает объявить соответвующие типы для нетривиальных протоколов...

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

Никуда реальное время не идет. Просто не надо ходить по шагам там где не надо.

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

Выделяете наиболее подходящее место....

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

По исходнику однозначно дольше получится.

Для того, кто привык смотреть в отладчик а не в исходник и проверять каждый 2+2= действительно-ли 4 (утрирую) - несомненно .

[defunct]

Да и на простейшие фиксированные пакетики но, например в кольцевом буфере, структуру не наложишь.

А что мешает?
Заводите volatile some_packet_type *pSomePacketType;
В отладчике просто присваиваете этому pSomePacketType требуемый адрес и смотрите.

То же самое работает и с переменной длиной фрейма, только типов придется описать больше.

Типа ходи там, где можно , а не там, где нужно.

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

А то, что в системе жеские таймауты на обмен и после притормаживания встречная сторона пошлет в меня совсем
другим пакетом и далее по другой ветке это совсем "мелочи".

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

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

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

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

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

Для того, кто привык смотреть в отладчик а не в исходник и проверять каждый 2+2= действительно-ли 4 (утрирую) - несомненно .

Да не надо смотреть каждые 2+2, часто хватает глянуть только на статистику, и уже ясно где искать проблему. Вот тогда в исходники можно смотреть.
Отладочную статистику ведь также проще и быстрее посмотреть отладчиком, чем в консоли описывать каждое поле. Кстати вернемся к эффективности использования памяти - а надо ли в "Release" держать параноическую статистику (по каждой ошибке)? На мой взгляд - нет. Вот и пишем

Код

... struct ....
{
....
#ifndef NDEBUG
    U32 err...lalala;
    U32 err...blablabla;
#endif

и смотрим в DEBUG build статистику отладчиком. А в релизе - нафиг ее, только память и производительность жрет.

[zltigo]

В отладчике просто присваиваете этому pSomePacketType требуемый адрес и смотрите.

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

То же самое работает и с переменной длиной фрейма, только типов придется описать больше.

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

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

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

Можно писать эффективный код пригодный для работы с отладчиком.

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

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

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

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

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

[defunct]

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

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

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

Я предпочитаю пакеты парсить последовательно и соблюдать иерархию протоколов. У каждого протокола свой обработчик, у каждого типа пакета - свой парсер. И каждый парсер начинается с преобразования к структуре того типа с которым он должен работать (если возможно конечно), на примере ethernet'a:

Код

Handle_EthFrame( PFRAME_BUF pFrame)
{
     PETHERNET_HEADER pEthHdr = (PETHERNET_HEADER)(pFrame->payload + pFrame->Offset);
      
     pFrame->Offset  += ETHERNET_HDR_SIZE;
     .....

     switch( pEthHdr->FrameType)
     {
          FT_ARP:
               Handle_Arp_Frame( pFrame );
               break;
          FT_IPv4:
               Handle_IPv4_Frame( pFrame );
               break;
          ...
}


Handle_IPv4_Frame( PFRAME_BUF pFrame )
{
      PIPv4_HDR  pIpHdr = (PIPv4_HDR)(pFrame->payload + pFrame->Offset);

      pFrame->Offset += IP_HDR_SIZE;
      // действия специфичные для IP аля проверка IP адреса, FCS, склейка фрагментированных фреймов и т.п.
      // дальше также как и с Eth фреймом:

      swtich (pIpHdr->ProtoType)
      {
            PT_ICMP:
                  Handle_ICMP_Frame( pFrame, pIpHdr );
                  break;
            ....
      }
}

и т.д.

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

Резонно - никаких гарантий.

то полезность такой работы по титаничесому описанию просто нулевая.

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

При определенном уровне писательства полезность отладчика падает,

Согласен.

как и полезность третьего колеса у велосипеда.

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

Можно предложу свой вариант ответа, что мешает мне - "определенный уровень писательства" той части проекта которую я не делал.

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

Какие-то две крайности ;>
Среди тех кто обходится без отладчика - Вами любимые писатели на ASM под mega8.

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

В разумных пределах статистика нужна, но под отладкой у меня порой в каждом if'е счетчик. Обычно 1 запуск/останов просмотр для выявления и устранения ошибки достаточно. В релиз такое непотянешь, да и незачем.

[zltigo]

Кольцевой буфер это как правило элемент библиотеки, отлаженный вдоль и поперек.

Только эта отлаженность никак не относится к содержимому туда попадающему и которое собственно и подлежит отладке.

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

Ну-ну "не убудет" . Вот этим примером Вы сами и хорошо проиллюстировали стиль главенства отладки перед функционалом.

Я предпочитаю пакеты парсить последовательно и соблюдать иерархию протоколов....

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

У каждого протокола свой обработчик, у каждого типа пакета - свой парсер....

годящемся для банальной инкапсуляции простых фиксированных заголовков/протоколов там и не пахнет.

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

Все именно такие. Ничего из исходных текстов (которых зачастую и бывает до 75%, но которые пишутся, так сказать, в заданных рамках и под моим наблюдением ) со стороны не используется и перед употреблением обязательно изучается и доводится до состояния "свое". От некоторых, правда, после этого камня на камне не остается

Попытайтесь ответить на вопрос, что в других проектах Вам мешает также эффективно пользовать отладчик?

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

среди тех кто обходится без отладчика - Вами любимые писатели на ASM под mega8

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

[rezident]

Сообщение модератора.
С подачи SasaVitebsk в сообщении #35 тема ушла в другую сторону: программная отладка vs аппаратные эмуляторы. Может активно участвующий в полемике СуперМодератор zltigo сам сообразит как безболезненно разделить темы?

[zltigo]

С подачи SasaVitebsk ...

Подача была моя . Темы разделил.

[defunct]

Ну-ну "не убудет" . Вот этим примером Вы сами и хорошо проиллюстировали стиль главенства отладки перед функционалом.

Главенство читаемости и сопровождаемости кода над мизерным приростом производительности.
"premature optimization is the root of all evil." (С) Donald Knuth

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

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

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

Все именно такие.

Или я не так что-то запомнил, мне казалось Вы где-то пользовали порт FreeRTOS.

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

Все то же самое можно сказать и для не слепоглухих мелочей на контроллерах "за десятку". ;>
Всмысле просто перечисляю перечиленное Вами:
1. Минимум затрат времени на дополнительный отладочный код.
2. Минимум затрат на доп железо (в плане interoperability проблем).
3. Исходники __обозревать__ в окошке отладчика никто не заставляет - удобнее и рациональнее их обозревать в том же любимом редакторе к котором писали проект, в отладчике смотреть только имя файла, строку и watch.

[DpInRock]

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

[Dog Pawlowa]

...Посему аппаратный отладчик уже не имеет особенного смысла.

Одна моя знакомая очень иронично реагирует на слово "смысл", особенно в обобщениях

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

[zltigo]

Главенство читаемости и сопровождаемости кода над мизерным приростом производительности.

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

Или я не так что-то запомнил, мне казалось Вы где-то пользовали порт FreeRTOS.

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

3. Исходники __обозревать__ в окошке отладчика никто не заставляет - удобнее и рациональнее их обозревать в том же любимом редакторе к котором писали проект, в отладчике смотреть только имя файла, строку и watch.

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

[Legotron]

zltigo прав в том, что использование аппаратного отладчика это противопоставление системному подходу в программировании.

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

[defunct]

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

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

Если я их действительно внимательно широко "обозрю" в удобном редакторе, а не с какой-то одной точки через амбразуру отладчика,

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

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

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

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

[SasaVitebsk]

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


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

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

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

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

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

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

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

Код

  // ===+++=== Отладка ===+++===
  __disable_fiq();
  if(T0TC>T0MR0)T0TC=0;
  __enable_fiq();

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

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

[zltigo]

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

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

Вычитывание листинга, не всегда помогает....

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

Отладчик - это инструмент. Один из инструментов.....

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

Не тратой времени для Вас я так понимаю является упаковка отладочной фирмфари в формат поддерживаемый Вашим бутлоадером

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

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

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

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

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

[defunct]

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

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

[GetSmart]

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

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

Код

  // ===+++=== Отладка ===+++===
  __disable_fiq();
  if(T0TC>T0MR0)T0TC=0;
  __enable_fiq();

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

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

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

[SasaVitebsk]

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

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

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

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

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

[zltigo]

О, через N постов начинает просматриваться истина.. - зависимость от системы...

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

[defunct]

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

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

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

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

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

[Dog Pawlowa]

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

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

[defunct]

Вместо того, чтобы сесть и заново четко поставить задачу, нарисовать на бумажке алгоритм, и реализовать его, вчера пол-дня все что-то правил, отлаживал... Зачем, почему? Лох какой-то И я уверен, что не я один такой.

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

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

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

[Dog Pawlowa]

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

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

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

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

[aaarrr]

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

[zltigo]

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

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

[DpInRock]

С отладчиком "умеет" работать каждый первый.

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

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

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

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

[defunct]

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

Нет, это сильно жестко. Не надо навязывать диету когда с весом все ОК.

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

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

Увеличивается Time-to-market.
Тем более если задача бьется, а как правило большая задача разбивается на этапы очень хорошо, разумнее делать поэтапно. Только не забывать о тестировании на регрессию.

[zltigo]

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

[defunct]

А вот, например, тут

Пример наглядный. Без чтения документации будет - "Мартышка и очки".

после ПЕРВОГО моего прикосновения к LPC2114 и ARM вообще. Без всяких отладчиков. Случилось это на плате от Olimex,

Аналогично, только и железо я делал сам (LPC2105, проц питал опером LM358).
Тем не менее я считаю, что с отладчиком и с готовой отладочной платой было бы удобнее и быстрее.

[aaarrr]

Аналогично, только и железо я делал сам (LPC2105, проц питал опером LM358).

Изучение ARM'ов я начинал на AT91M40800. Пока писал свой загрузчик, приходилось прошивать панелечную флеш stand-alone программатором. Очень способствует вдумчивому прочтению документации и внимательному написанию программы - лишний раз возиться с программатором (а он довольно кривой был) ой как не хочется.

А с отладчиком и готовой платой так и остался бы дураком

[sergeeff]

Первый мой опыт программирования 580ик80 - 80-й год прошлого столетия. Не было не только отладчика, но вообще ничего, кроме блокнота, ручки, кодов команд и возможности записать PФ1 у друзей. Я не ратую за возврат в прошлое, но, как говорил мой приятель "поиграть в компьютер", т.е. самому повыполнять ту программу, которую пишешь, очень полезно и сегодня. Независимо от языка программирования.

[MrYuran]

А с отладчиком и готовой платой так и остался бы дураком

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

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

[Rst7]

И что каждый шаг выполняется отдельной программой, которой можно задать параметры в командной строке (а не только галочками в ИАРе)

Дык ИАР точно такой же. Отдельно компилятор, отдельно линкер. Все с командной строкой. Препроцессор, правда, в комплекте с компилятором.

[MrYuran]

Дык ИАР точно такой же. Отдельно компилятор, отдельно линкер. Все с командной строкой. Препроцессор, правда, в комплекте с компилятором.

Да, только об этом не подозреваешь, пока умеешь пользоваться только двумя кнопками - "молоток" (build) и "жук" (debug).

Разве что нечаянно занесёт документацию почитать

[zltigo]

И что каждый шаг выполняется отдельной программой, которой можно задать параметры в командной строке (а не только галочками в ИАРе)

Действтельно? А документацию на компилятор, линкер, библиотекаль, ассемблер, утилиты... совсем не читали. Всего-то "F1" нажать и сразу даже просто по меню! хелпа видно из чего пакет состоит, ибо по каждому компоненту свой PDF приложен. А уж в каждом из докуменов все подробненько.

Препроцессор, правда, в комплекте с компилятором.

Но можно и стороннй использовать .

[Rst7]

Но можно и стороннй использовать

А смысл?

[zltigo]

А смысл?

Никакого, поскольку ключик прогона препроцессора у компилятора, естественно, имеется, но если хочется, то можно.

[singlskv]

Никакого, поскольку ключик прогона препроцессора у компилятора, естественно, имеется, но если хочется, то можно.

А я вот "люблю" пользовать отладчик на чужом коде...
и это всегда дает некоторое преимущество....

[SasaVitebsk]

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

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

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

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

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

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

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

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

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

[galjoen]

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

[Rst7]

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

[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 для Союза была крутизны немерянной.

[defunct]

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

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

Это Ваша колоколенка. Бывает .

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

[zltigo]

И как смотреть? Побайтово?

Как угодно.

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

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

Так что мне есть с чем сравнивать.

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

[SasaVitebsk]

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

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

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

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

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

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

[defunct]

Как угодно.

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

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

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

Код

typedef struct tagSOME_DATA_LINK
{
    ...
    
    U32 x;
    U8   y;
    U8   z;

    TSOME_LINK_RX_STAT    RxStats;
    TSOME_LINK_TX_STAT    TxStats;

    ...

    ... (* send_frame_cb)(...);
    ... (* get_frame_cb)(...);

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

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

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

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

[zltigo]

Что предоставляет Ваша ОС на этот случай? (без специального вмешательства в код программы).

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

..среди дампа представленного побайтово?

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

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

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

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

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

[defunct]

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

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

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

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

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

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

[singlskv]

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

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

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

[zltigo]

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

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

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

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

у меня мой "контроллеров светодиодов" легко переживает остановку отладчиком и дальнейший пуск проги,

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

Все так, просто не мегагерцы, ни количество UART, ни количество понтов, во многих случаях совершенно не меняют сути устройства

[singlskv]

Это когда Вы комануете "светодиодами" и "самый главный", ибо "светодиоды" сугубо беспрекословные твари.

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

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

Реальное время это сколько ?

Каналов тоже будет далеко не один. Ну а Вы постоите и поотлаживаетесь....

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

[defunct]

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

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

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

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

...
if ( <проблема> )
TrapIt(); <-- сюда ставим точку останова.

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

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

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

[Rst7]

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

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

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

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

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

[zltigo]

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

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

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

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

Я уже вижу недостаток такого подхода - размер отладочного кода.
Смею предположить, что код консоли в такой форме занимает приличный % от всего проекта.

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

1. В консоли замечаем проблему.

Да.

2. в коде ставим ловушку:

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

[HARMHARM]

2. Использовать только консоль (трассы) - не все ошибки можно так отловить, банальная ситуация "Device Dead" и приплыли

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

[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 лет пользуюсь.

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

[Rst7]

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

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

Зря.

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

[defunct]

А почему Вы считаете, что на консоль coredump получить нельзя? Очень даже можно, чем я и пользуюсь. Реально правда применял два раза всего...

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

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

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

[SasaVitebsk]

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

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

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

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

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

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

[HARMHARM]

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

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

[GetSmart]

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

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

[zltigo]

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

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

[defunct]

на планете самый лучший? Может русский? Может английский? Вот куда надо силы-то тратить

Оба.