Отладка в реальном времени - это отдельная тема. До нее еще нужно дойти при разработке устройства. Подчинять ей отладку с захватом ошибки и остановом - плохая идея. Тем более, что строгая отладка в реальном времени вообще невозможна, ибо любой отладчик "реального времени" таковым не является ибо задерживает вывод переменных относительно событий.
Опять же, если немного отвлечься от AVR , то тот же самый SWD/JTAG отладчик в других платформах, работая на частоте порядка 4...5 МГц, способен выводить и модифицировать переменные без останова исполнения. Просто в AVR слишком медленное сканирование.

Вообще то отладка через компорт является наиболее распространенной среди профессионалов. Нет принципиальной разницы в величине задержки при выводе переменных, даже если их выводить через SPI. Это все разные сорта г...вна, а не реальное время. Но это г...вно неизбежно в финишной отладке определенных устройств. В конце концов, на выходе отладчика сидит человек, скорость считывания информации у которого крайне низкая. Поэтому эта информация должна быть обработана, прежде чем сможет быть воспринята адекватно. И это тоже причина невозможности true real-time дебага.

Расчет "функции" делают не в симуляторе МК, а в математическом ПО. Делать это в симуляторе - верх перректальности, извините. Все что можно увидеть в симуляторе при расчете функции - детские ошибки. Что в Си, что в АСМе.

Еще раз. Работа с флешем и ЕЕПРОМом не симулируется. А если и симулируется, то как макрос - фиктивно. С такой работой можно лишь замылить реальный баг, а не найти его. И что вы называете "хорошим симулятором"? У меня выбран чип на основании технических резонов, а не по признаку наличия у него хорошей модели в хорошем симуляторе.
[/uquote]

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

shonty, Забейте. И не кормите тролля. Нравится человеку сидеть на своих двух проводках и считать это верхом совершенства.
Просто у него нет ничего, кроме этих двух проводков.
Еще Миша Жванецкий сказал 35 лет назад - "Давайте спорить о вкусе устриц и кокосовых орехов.... С теми, кто их ел".
На народные АВРки типа восьмой меги или тринадцатой тини у 99% радиолюбителей железных отладок нет.
Поэтому и существуют "два проводочка" имитации отладки, которые по сути есть просто способ вывода лога из МК. При этом посмотреть или потрогать память или регистры такая отладка не позволяет.
А услышать, что кроме двух проводков есть и другие инструменты и способы отладки, и что для разных случаев есть разные методы - человек не хочет.

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

Неуж то так и "не позоляет"?

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

Особенности хранения литиевых аккумуляторов и батареек

Потеря емкости аккумулятора напрямую зависит от условий хранения и эксплуатации. При неправильном хранении даже самый лучший литиевый источник тока с превосходными характеристиками может не оправдать ожиданий. Технология, основанная на рекомендациях таких известных производителей литиевых источников тока, как компании FANSO и EVE Energy, поможет организовать правильный процесс хранения батареек и аккумуляторов.

Подробнее>>

BOB51, ну да, аппаратный модуль, занимающий 0 байт программы и имеющий в идеале доступ ко всем ресурсам МК и программная закладка, где для вывода любой переменной нужно дописывать вызов подпрограммы вывода. А если переменных много и их надо быстро выплюнуть, то еще и буфер организовывать... И на время выплевывания данных наружу МК только этим и занимается. Т.е. тоже не true real-time (ц) КРАМ
Повторюсь. Оба способа отладки имеют место. У обоих есть свои плюсы и минусы. Но нельзя хвалить один, как панацею. Ибо способов отладки больше. Еще есть внешние логгеры, логические анализаторы, стенды для настройки управляющего модуля, что б не получить в рожу струю ядовитого газа...
Об этом уже несколько страниц оффтопа, но не все хотят слышать других. dixi.

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

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

Для меня неясно, как при использовании JTAG проводится привязка выводимых переменных к точкам программы.


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

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


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


Я не говорю о полной симуляции работы с флешем.
Запись во флеш – ассемблерная команда SPM, вполне «симулируемая».
После прохождения симулятора участка программы с записью во флеш должен появиться файл с текстом записанной программы. Вначале каждой строки должен быть адрес строки.
Это не полная симуляция, но обнаружить вашу ошибку можно было.
Насколько это реально, не знаю, но не вижу каких-то ограничений для такой организацией симулятора.
В симуляторе не создаётся модель МК, а «симулируются» ассемблерные команды, поэтому можно применять любой МК АВР, у них одинаковые команды.



Не знаю, что такое «стендик на dupont-ах» и причём тут ZIF.
А на компьютерном столе отлаживать удобней, чем на радиомонтажном.

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


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

Очень много букоф...
Однако:

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

А кто говорил, что такая привязка имеет отношение к JTAG?
JTAG просто сканирует заданные участки памяти с целью вывода на экран среды разработки. Есть желание наблюдать сечение - создавайте буфер в точке сечения и наблюдайте за ним.
Кроме того, штатная отладка ДВУХСТОРОНЯЯ. То есть можно и наблюдать и модифицировать переменные и регистры периферии на лету.
И все это не требует специальной модификации кода и перекомпиляции с прошивкой.
Скажем, при написании бутлоадера в окне программной памяти сразу видно как заполняется флеш. А это огромные объемы для вывода. Никакая куцая отладка через пин не дает таких возможностей.
Сегодня ловил ошибку связанную с хаотичным нештатным поведением данных в массиве. 99,9% времени в массиве все ОК. И лишь иногда проскакивают нештатные данные. Их отлично видно в окне Watch при наблюдении за массивом.

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

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

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

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

КРАМ, лично я использую протеус для симуляции РЕАЛЬНЫХ СХЕМ устройств на МК, причем в РЕАЛЬНОМ ВРЕМЕНИ. достоинства этого метода в том, что симулируемое "реальное время" можно остановить в любой момент, чего, безусловно, невозможно сделать с аппаратным отладчиком и реальной схемой. точность и достоверность симуляции процессов достаточно высокая, а уж если говорить о любительстве, то однозначно качественная. а потоки данных, с которыми вы так любите бороться, тоже симулируются путем чтения/записи из/в файл. реальность времени тут заключается в том, что относительное время между происходящими процессами в схеме и программе всегда "правильное" в соответствии с законами физики. ну, вы понимаете, я имею ввиду, что одной секунде настоящего процесса может соответствовать десяток минут симуляции, но внутри этой секунды все процессы мне доступны по микро- и нано-секундным интервалам с возможностью посмотреть в любой момент, что и как меняется.

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

но не смотря на эту проблему, примерно в 95% случаев я прекрасно обхожусь при разработке без паяльника вообще, т.е. мне не нужна реальная плата для отладки ПО (и схемы тоже).

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

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

???
Очень убедительно.
Давайте, на ATmega8 или ATmega328 продемонстрируйте это.
С Вами всё ясно.

Я уже это демонстрировал. Правда на ATmega165, но какое это имеет значение...
Меги дебажатся через PICkit4 - JTAG.
Даже если нужна Мега с небольшим количеством выводов, то легко сделать шилд из многовыводной версии в качестве эмулирующей системы. И потом тупо перенести код на рабочий таргет. Примерно так же используются отладочные чипы в малоногих ПИКах, где вообще нет блока отладки на кристалле.

Из чего очевидно следует, что 95% ваших схем, Роман, являются простой композицией чисто цифровых кубиков из более-менее рабочих моделей Протеуса.
Это все лишь подтверждает мою мысль, что Протеус - это инструмент совсем начинающего радиолюбителя. Я уже не говорю о выборе МК. Это отдельная "песня".
Ситуация примерно такая же, как с приснопамятным PIC16F84. Народ так и сидит на нескольких Мегах, модели которых есть в Протеусе.
Кроме того, симулировать устройство типа ридера HF RFID совершенно невозможно. Процесс завязан на физику приема магнитного поля модулированного меткой.
И таких устройств чуть более, чем все, если речь идет о встраивании МК в чисто радиотехническое устройство или устройств, где есть физика внешних процессов - например холодильник или двигатель коптера.

Нефертити, если вы пытаетесь взять меня на "слабо", то не выйдет. Доказывать или показывать вам что то я не собираюсь.
Купите дракона и пользуйтесь debugWIRE хоть на Tiny2313.
Ну и не одной восьмой мегой живо семейство АВР. Я ранее писала, что на Атмега128 я занималась отладкой на одной из старых работ.

КРАМ, восьмая мега - один из "народных" контроллеров.
Он недорогой*, имеет 22 GPIO и флеш на 4096 команд.
Для 90% домашних простых поделий этого хватает с головой. Равно как и протеза для отладки.
____
* Был не дорогой, сама покупала на али по 45 центов 50 штук. Как сейчас - не знаю, давно не покупала АВРки.

Первый нюанс - не все АВРки поддерживают внутрисхемную отладку.
Второе - краткое знакомство на одном проекте с АВРками это не то же самое, что и профессиональное знание ПИКовых.
Да и условия работы профессионала (технические и финансовые возможности предприятия, база которого используется для самообучения сотрудника) не то же самое, что и у "простолюбителя".
Третье - концепция разработки по принципу "все в одном супербольшом МК" во многих прикладных ситуациях ремонта не совсем оправдана.
На сегодня достаточно актуальный вопрос замещения отсутствующих в наличии компонентов самодельными аналогами на основе "малолапых" МК (бытовая автоматика, ремонты старой техники).
Дополнительное применение - конструкции на основе нескольких (часто "разносемейственных") МК.
Так что ВСЕ ПРИЕМЫ ХОРОШИ в конкретном приложении.
Как ранее в своей "винной" уже говорил - хотим сравнивать - возьмем единый (общедоступный) проект и на конкретной схемотехнике и конкретных программах будем это делать, выкладывая результаты работы для всеобщего обсуждения. Едственно - то уже отдельная тема потребуется.

А причем тут ремонт? Разговор идет об отладке. А значит про разработку.

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

Так я ж не заставляю ))) Это были женские советы Нефертити ))) Я ж не знаю, может у египетской царицы денежка на дракона и найдется )))))))))

У меня самой дома есть только MKII от Grott-а да кучка USBAsp-ов. Поэтому полноценной отладки на АВР нету, приходится извращаться с отладочным выводом куда-то, если есть в чем то затык.
Но вкусив нормальной внутрисхемной отладки на других МК (АВР и не только), я считаю способ отладки "по двум проводкам" - как бы это мякго сказать.... несколько несовершенным. Хотя как один из вариантов - они имеет место быть.
Но мне зачастую гораздо больше помогает логический анализатор и осциллограф, нежели отладка. Поскольку в основном нужно смотреть взаимодействие МК с внешней периферией. А в части случаев - действительно в реальном времени, ибо тайминги.
Ну либо, если периферия позволяет, то перекинуть проект на более толстый МК (или даже на другое семейство МК) и там уже смотреть всю логику под нормальной отладкой, нежели извращаться с двумя проводками.
Никто не мешает взять вместо Меги8 ту же Мегу32 с жтагом и спокойно работать. И дракон не нужен.

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

а, если есть атмега32, зачем "взять вместо Меги8 ту же Мегу32"?
Они что, по пинам совместимы?
Нет, не совместимы.
Зачем вместо меги8 брать мега32?
Я правильно понимаю, что мы говорим о внутрисхемной отладке?

PS Конечно, это не мое дело, только глубина Вашего вылизывания заставила меня рефлексировать.

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

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