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


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

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

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

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


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

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

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


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

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

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

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

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

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

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

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

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

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





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

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




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

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

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

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

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


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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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


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

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

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

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

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

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

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

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

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

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



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

А смысл?

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

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

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

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

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

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

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

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

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

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

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

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

Ну вот прямо сейчас копаюсь с самой что ни на есть "интерфейсной микросхемой" - 699 листов не слишком подробного описания + errata + notes ... почти 1000 регистров. Всяка разна дополнительная информация типа библиотек от производителя еще не дошла - на CD конфидециально, типа, передают. Несоответствий опиманию уже пяток точно найден. Ума не приложу зачем мне внутрисхемный отладчик для этой работы. Запущена от состояния взяли в руки документацию до состояния дышит, интерфейсы подняты, обмен идет примерно за двое суток. При этом основное время ушло на борьбу с тем, что ее PLL (просто песня, 64 бита конфигурации) не мог на самом деле работать от опорной частоты 16.384MHz. Сегодня продолжил лабораторные работы - нашел пару багов (будем считать мои, покольку последовательность действий не описана, а интуиция не сработала что-то). Куда-бы мне этот отладчик вставить , дабы пользу получить . Сегодня после двух дней писательства и правок всухую системка зависла - на консоль не реагирует, ну думаю, не взять-ли отладчик из стола.... Но вовремя решил, что лучше релизик отладочный собрать в котором консоль максимальный приоритет имеет - минут 10 и все увидел. Отладчиком точно было-бы дольше. Ну начало было-бы быстрым - остановил-бы на ходу в одной из задач предположительно именно в той, которая время и жрет, но дальше шагать куда-то долго и упорно и при этом система-то уже того - стоит как неживая. Да, если там плагинчики под операциоку есть, то можно уже увидеть именно то, что надо, но плагины еще и писать надо, а в живой консоли все это у меня и так есть...

Это показывает уровень, насколько операционка "своя".

И нафига куда-то шагать? Остановили - смотрите. Не знаете что смореть? Дык значит не охватываете проект целиком, и тут ничего постыдного нет, абсолютно нормальная и понятная ситуация.

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

Кстати если МС на шине памяти, тогда отладчиком можно ее конфигурировать (все эти 1000 регистров), без единой строчки кода, и без пересборки проекта.

Это Ваше выступление просто показавает насколько Вы "разбираетесь" в отладке операционки.

Смотреть на остановленную операционку бессмысленно - ну находимся в некой задаче - это не криминал. Криминал это если задача не когда-то ПОТОМ не отдаст управление.

Разумеется знаю и по этой причине в своей операционке со своими штатными средствами отладки быстро все увидел в проблему возникающую в ДИНАМИКЕ.

Кто о чем, а вшивый о бане.

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

Легко делается только то, о чем человек имеет очень отдаленное представление, что Вы сейчас и демонстрируете

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

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

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

Насчет когда-то потом не отдаст управление, моя ОС умеет отслеживать такие ситуации. В Debug Build'е в случае детекта "подвисшей" задачи - консоли автоматически назначается наивысший приоритет и выдается подробный отчет о "подвисшей" задаче и о состоянии ОС. В release - факт подвисания любой задачи, инициирует запуск дампа с последующим сбросом по WDT.


напомню что

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



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


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


Понятно что сорвется все. Понятно, что возникнет масса ошибок и не только на нашей стороне.
Ну и пусть. Какая разница? Соединится все еще раз. Долго что ли?
Вам проблему найти или чтоб еще и пользователи не заметили, что Вы там проблему ищите?



Ладно все это фигня, разбирать конкретную одну ошибку - мелко...
Суть моих опусов вот в чем:
1. Использовать только отладчик (кордамп + пошаговая отладка) - до добра не доведет.
2. Использовать только консоль (трассы) - не все ошибки можно так отловить, банальная ситуация "Device Dead" и приплыли
3. Отладчик (кордамп + пошаговая отладка) + консоль (трассы) - наиболее полный вариант позволяющий найти и устранить любую проблему

В если операционки не уровня win/lin то оперционка от проекта с операционкой не отличеется ничем.

Именно обо всем этом рассказывает САМА операционка и Вы со своим отладчиком ни нафиг не нужны

Прелестные "советы" с колоколенки отлаживателя "контроллера светодиода"

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


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

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

Еще секунд 30.

Это уже, как всегда, выши фантазии - смотрите описание первых 30 секунд "разборок".

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

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

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

Несомненно, только отладчик здесь на самом последнем месте, и не за него надо хвататься в первую очередь (исключения, имеющие место быть я поминал).
И забыли зачем-то
4. Консоль и "Кордамп" - почти полный вариант, причем, работающий всегда и везде в том числе и на обьекте, а не только на макетном столе.