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

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


В каком виде она рассказывает, да еще и "обо всем"?!
Винда к примеру много Вам рассказывает?


Что-то у Вас все кто не делает так как Вы - попадают в разряд еретиков отлаживателей "контроллера светодиода".


Ну дык, давайте без ля-ля-ля, у Вас оно делается? Или конкретно в этом случае - нет?


С чего бы это удобный инструмент предоставляющий достоверную информацию ставить на последнее место?
На последнее место я лично поставлю логи 3-rd party Host'a (абсолютно бесполезный хлам как правило), следом за ними - неполный / битый кордамп с объекта.


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

И по именно этой причине эти отладки не отличаются, но Остапа явно понесло и по этому "вывод" прямо противоположный

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

Как минимум никак не менее линукса, т.е. очень много.

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

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

По той простой причине, что он не такой уж и удобный (а в обьектовых условиях просто и невозможный) и предоставляет, хоть и достоверную, соверщенно сырую информацию на интерпретация которой стоит времени, да и то с верочтностью ошибок. Нормально продуманный системно на этапе проектирования лог, уровни отладки, распечатка ошибочных ситуаций позволяют локализовать проблему до порядка нескольких сот строк исходника, ну а уж их НАДО уметь читать глазами. Если лог делается по принципу а не впендюрить-ли мне сюда
printf( "a=%i", a ), то это вообще не лог, а просто тот самый случай, когда дальше носа и отладчика не видят . Спору нет - при такой "методе" отладчик мерещится волшебным ключиком, хотя на самом деле он обычный лом. И желательно, что-бы он был ржавым, а не отполированным до блеска неумеренным употреблением

Это Ваша колоколенка. Бывает .
P.S.
Не ожидал - нашел в интернете свой первый железный отладчик , aka внутрисхемный эмулятор http://oldcomputermuseum.com/mds_800.html
Вешь, даже в начале-середине 80-x для Союза была крутизны немерянной.

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


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

Как угодно.

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

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

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

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

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

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

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

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


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


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

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

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

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

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

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

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

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


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


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

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

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

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

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



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