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

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



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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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


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


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



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


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



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



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

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

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

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

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

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

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

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


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


и т.д.


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


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


Согласен.


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

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


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

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

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

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

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

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

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

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

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

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

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

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

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


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


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


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

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

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

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

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

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


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