AQ29 писал(а):Пишу на языке, близком к ассемблерному. Никаких «суперциклов и событийных моделей с диспетчером задач», на мой взгляд, для МК AVR это ни к чему. Писать проще и отладка получается простой.
И это говорит человек, который боится прерываний, хехе )))
[uquote="AQ29",url="/forum/viewtopic.php?p=4651430#p4651430"]Когда-то и у нас инженеры паяли в КБ. Но это из тёмного прошлого. Сейчас в КБ чистота и порядок.[/uquote]
У нас нет КБ. У нас есть два отдела разделенных перегородкой. В одном работают разработчики механики, а во втором разработчики электроники.
Чистота имеется и там, и там. Порядок рабочий.
За застекленной стеной производство.
Проблем от включения паяльника или фена на пять минут ни у кого не возникает.
[uquote="AQ29",url="/forum/viewtopic.php?p=4651430#p4651430"][uquote="КРАМ",url="/forum/viewtopic.php?p=4595617#p4595617"]Патамушта речь идет не о проверке арифметической функции типа извлечения корня, а о симуляции реального процесса работы. И там все очень тормозит.[/uquote]
Речь как раз идёт про «арифметические функции».
Я с самого начала писал, что использую симулятор только для отладки процессов внутри МК без взаимодействия с внешними устройствами, большей частью это математические функции. В этих случаях у симулятора существенные преимущества перед дебаггером.[/uquote]
Дебаггер от симулятора при статической проверке ничем не отличается. Поскольку "проверка арифметики" это крошечная часть работы, включать ради этого симулятор смешно.
Реальная проверка арифметики происходит в реальном времени и с реальными данными.
Просто "арифметика" у нас с вами сильно отличается.
Ничего про stlink v2 не знаю. Насколько представляю, там есть точки остановки, в которых можно анализировать МК.
Но это всего одна точка и нет контроля прохождения программы. Кроме того, не всегда можно останавливать МК.
У меня несколько точек и можно контролировать путь программы без остановки, в этом плане такая отладка представляется сильнее.
КРАМ, забейте, это переливание из пустого в порожнее уже по третьему кругу пошло. Если не по четвертому.
AQ29, точек останова может быть столько, сколько нужно. Плюс есть стандартный отладочный вывод через stlink в терминал любой нужной информации. Но вам это не нужно, у вас есть самый лучший инструмент - отладка по двум проводам.
КРАМ, я и спрашиваю, чтобы узнать. Серьёзно изучать stlink v2 мне не имеет смысла, я не работаю с такими МК.
Just_Fluffy, насколько представляю, в точке останова вы остановили МК и опрашиваете переменные.
Такая ситуация, есть центральный МК и несколько периферийных. Вы остановили периферийный МК. Центральный МК при очередном опросе не обнаружит этот МК и остановит аппарат, это авария. Соответственно, после первой точки останова последующие не имеют смысла.
А распределённая система удобна для серьёзных аппаратов.
Я вообще-то не против внутрисхемной отладки. В старых МК АВР её не было, в новых есть, как её организовать – вопрос.
Я уже предварительно сделал внутрисхемный опрос в новых МК, а вы пишите, что он мне не нужен - нелогично.
AQ29 писал(а): Сб июн 20, 2026 10:41:00
насколько представляю, в точке останова вы остановили МК и опрашиваете переменные.
Нет. JTAG сканирует память и периферию во время исполнения кода. Поэтому выбранные в окно Watch регистры и переменные отображаются на лету.
Можно вообще не применять точки останова. А можно применять. Вывод переменных никак от этого не зависит.
Можно на лету значения переменных изменять. Естественно с учетом асинхронности этих изменений по отношению к исполняемому коду.
