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

[GetSmart]

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

[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 и надо - зачастую это единственная ниточка при поиске ошибок в реальных условиях, а не на столе с подключенным отладчиком.