Вопросы по отладке

[Just_Fluffy]

Нефертити
Я к тому, что если хочется полноценной отладки на семействе AVR, то мною предложено несколько вариантов.
1. Взять debugWIRE программатор и отлаживать мегу 8
2. Взять что то с ЖТАГом и отлаживать недорогими аппаратными средствами. Но для этого МК должен уметь ЖТАГ.
Потом перенести код в целевой МК.
Ближайший к меге 8 МК с ЖТАГом - это 32 мега. В ней есть абсолютно все, что есть в восьмерке и даже чуть больше. Поэтому любой код, работающий на восьмерке - можно отлаживать на 32 меге, подкорректировав область описания периферии.

Есть 10 типов людей - которые работали с внутрисхемной отладкой на АВР и которые только слышали про нее.
dixi.

ПС. не судите других по себе.

[Нефертити]

Just_Fluffy писал(а):

Нефертити
Я к тому, что если хочется полноценной отладки на семействе AVR, то мною предложено несколько вариантов.
1. Взять debugWIRE программатор и отлаживать мегу 8

Вы это в глаза когда-нибудь видели?
Прежде чем советовать, ...

PS Конечно, барышня ни о чём, только апломб.

[Just_Fluffy]

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

[Нефертити]

А при чём здесь тобой так называемый "дракон"? Что это такое?
Не отклоняйся от темы.

Добавлено after 4 minutes 58 seconds:
Слюни выползали в коридор?

Добавлено after 5 minutes 9 seconds:
Martian, это не "она".

Добавлено after 45 minutes 42 seconds:
Just_Fluffy, Давай, покажи своего своего AVR Dragon? Или, хотя-бы, что ты видела?
Или, я что-то видела, но только один раз?

Добавлено after 7 minutes 55 seconds:
Пустомеля.

[Martian]

Нефертити, ты сомневаешься в субъективности моих оценок? Я видел её работы. Читал сообщения. Посмотрел Дракона (раньше не знал о нём). Мой стиль работы примерно выражен как "нажать паузу в IDE и смотреть все, что творится в МК". Что-то не так? Может, мне и за другие оценки перед тобой отчитаться?

[Нефертити]

Я не сомневаюсь в субъективности твоих оценок.
Как, вообще, можно сомневаться в субъективности чьих-либо оценок?
Я ведь их не делал.
Ну, этих субъектов.

[Martian]

Тогда с какой целью это было сказано:

Нефертити писал(а):

Martian, это не "она".

?
и причём тут

Я ведь их не делал.
Ну, этих субъектов.

?

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

[КРАМ]

Нефертити писал(а):

КРАМ писал(а):

Стандартная практика при использовании эмулятора - применение ...

А причём здесь эмуляторы?
Мы говорим о внутрисхемной отладке.

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

[AQ29]

КРАМ писал(а):

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

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

КРАМ писал(а):

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

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

КРАМ писал(а):

Скорость вывода не имеет никакого значения, поскольку сам интерфейс при выводе работает автономно. Поэтому, что УАРТ, что SPI - без разницы. Любой интерфейс будет занят и будет требовать кусок кода.

В моей отладке USART и SPI не используются. При отладке лучше всего не использовать никакие периферийные устройства, поскольку они могут быть заняты основной программой.
Вывод байтов в отладчик делается программно, при этом МК останавливается. Чем меньше время остановки, тем лучше, меньше вероятность искажения работы программы.

КРАМ писал(а):

AQ29 писал(а):

Обычно для расчёта функции используется линейная аппроксимация, а при этом используется массив чисел.

Это чушь. Но дело даже не в этом. Один раз написав функцию, далее ее можно просто копипастить из проекта в проект.

Аппроксимация функции отрезками линий – это не чушь. Похоже, вы никогда не делали этого.

КРАМ писал(а):

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

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

В симуляторе, которыми пользовался, нет моделей конкретного МК. Симулируются команды ассемблера. Симулятор просто идёт по командам ассемблера, поэтому можно смотреть любой МК.

Just_Fluffy писал(а):

Потому что на любой чих вам нужно писать хоть и небольшой, но код.
А для двусторонней "отладки" - еще больше кода. Который тоже надо отлаживать.
А для того, что бы остановить программу в любом месте без перекомпиляции проекта и вдумчиво просмотреть все регистры МК, область ОЗУ... еще код писать?
А сможете?
....
а КРАМу не надо ничего писать. Ему достаточно нажать паузу в IDE и смотреть все, что творится в МК. И даже поменять.

Написать строчку вывода переменной в отладчик – несколько секунд, представлять это проблемой несерьёзно.
Я не останавливаю МК, остановка – прощай реальный режим, всерьёз это не рассматриваю.
Я не смотрю, даже вдумчиво, на все регистры МК, зачем на них смотреть.
Точнее, когда начинал изучать МК, с интересом смотрел в симуляторе, как меняются регистры РОН, но это было в далёком прошлом.
Да и в программе почти отсутствуют в явном виде регистры РОН, есть переменные, вот их и смотрю, этого достаточно для быстрой отладки.

Ваше мнение об отладке «по двум проводкам» было бы объективным, если бы вы поработали с такой отладкой. Вспомнилось про мангустины…

[Just_Fluffy]

AQ29, Вы начинаете повторяться.
Если сильно хочется поговорить за отладку, то создавайте отдельный топик, как правильно отметил БОБ.
Выкладывайте примеры схем, алгоритмы, идеи... И будем обсуждать.

Ваше мнение об отладке «по двум проводкам» было бы объективным, если бы вы поработали с такой отладкой.

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

Я не смотрю, даже вдумчиво, на все регистры МК, зачем на них смотреть.

Под регистрами МК подразумеваются не только РОН. Регистры периферии - тоже регистры МК.

ВКстати, ваш сценарий - заполнить в ОЗУ 100 байт и потом их смотреть - не требует двух проводов. Отладчиком точно так же можно посмотреть эту область ОЗУ.
А влажные истории про отладку в цеху простых поделий на АВРках (тема ж про ассемблер АВР) - это высосано из пальца.
А на стенде можно и останов смотреть.

[AQ29]

Just_Fluffy писал(а):

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

Поверю. Что вы давно занимаетесь МК, я давно понял.
Написал, что вы плохо представляете мою отладку «по двум проводкам», по следующей причине.
Ранее вы писали, что мне для просмотра регистров, ОЗУ, надо писать код, да ещё смогу ли я это сделать.
Всё гораздо проще. Вообще-то у меня в программе нет регистров, ОЗУ, есть только переменные. Посмотреть любую переменную очень просто, это одна команда, написать которую займёт 10 секунд. А переменная может быть объявлена в разных местах, и в РОН, и в РВВ, и в SRAM, и в EEPROM.
В старом варианте была ещё команда просмотра массива, в новом пока не сделана.
Не может быть для меня проблемой написать простую команду, которая ненамного сложнее команды NOP.

У логического анализатора своё назначение. Использовать его для отладки «внутренней» части программы - это что-то школьно-любительское, всерьёз этот вариант не рассматриваю.

У JTAG используется 4 вывода, народ пользуется и доволен, у меня, на практике, один.

Just_Fluffy писал(а):

Просто при наличии нормальных средств это не нужно.

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

Just_Fluffy писал(а):

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

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

[КРАМ]

AQ29 писал(а):

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

Вы гордитесь тем, что у вас не приспособленное для работы место?
Если вас устраивает симулятор, значит проекты крайне примитивны.

[Just_Fluffy]

Вот это заявление для меня сильно сомнительно. Насколько помню, у вас производится остановка МК, т.е. анализ только в одной точке. Это сильно ограничивает область применения.

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

[BOB51]

Платы "прототипы" для ISA шины...
НОСТАЛЬЖИ !...

(как и книга для их изучения/разработки).
Правда тогда ПК мало чем по ресурсам от современного МК отличался. Зато полезных навыков давало.

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

[AQ29]

КРАМ писал(а):

Вы гордитесь тем, что у вас не приспособленное для работы место?
Если вас устраивает симулятор, значит проекты крайне примитивны.

В КБ – работа с документацией, разработка схем и программ, обсуждение с коллегами и руководством вопросов. В КБ чистые компьютерные столы, чистый воздух, паяльная вонь ни к чему. Отладка – в лаборатории, где есть вытяжка, приборы и прочее.
Для таких разработок это хорошее решение.
Когда-то у нас стояли пульты в КБ, но это было в далёком прошлом.
Насчёт симулятора – это несерьёзно. Симулятор – один из инструментов отладки, может использоваться и в простых, и в сложных проектах.

Just_Fluffy писал(а):

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

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

Just_Fluffy писал(а):

И я так и не поняла, кстати, вы свои мегапроекты на атмеге отлаживаете в цеху или в симуляторе? Вы как то определитесь....

Применение предлога «или» в вопросе некорректно. При отладке в зависимости от ситуации использую разные инструменты: и отладчик, и симулятор, и осциллограф, и логический анализатор, и логический пробник.
С симулятором можно работать в КБ, остальное – в цеху.

[КРАМ]

AQ29 писал(а):

В КБ – работа с документацией
Отладка – в лаборатории

Бегать что ли? Зачем?
Отладка если и требует пайки, то очень редко. Отладка на 99,9(9)% - это работа с кодом на реальном оборудовании.

AQ29 писал(а):

Симулятор – один из инструментов отладки, может использоваться и в простых, и в сложных проектах.

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

AQ29 писал(а):

Про количество точек. Говорилось о количестве точек при реальной работе.

Количество ОДНОВРЕМЕННЫХ точек контроля в JTAG ограничено только скоростью сканера JTAG и возможностью глаза различить каждый захват данных. Но возможность глаза ограничивает ЛЮБОЙ инструмент отладки в реальном времени.
Например сейчас я контролирую в реальном времени порядка 20...25 переменных одновременно.
Проблемы со слайд-шоу начинаются примерно с 50...100 переменными.

[BOB51]

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

[КРАМ]

BOB51 писал(а):

В каждом конкретном случае

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

[BOB51]

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

[КРАМ]

BOB51 писал(а):

Разница только в уровне задачи и материальных возможностях исполнителя.

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