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

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

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