Да разные были... От ST6265, у корого даже сдвига вправо не было - какой уж тут в.с.о. - до ATmega128, объём нетрудно прикинуть.
Для справки: я был не свободен в выборе МК, работал по договору - с тем, что дадут.

Ну вот Вам и ответ! МК - простейшие, с простой периферией. Попробуйте как-нить поработать скажем на XMC4700 без эмулятора или на чём-то подобном. У кого мануал весит несколько тысяч страниц. И errata - под сотню страниц. И размер исходников - несколько мегабайт.
Хотя в этой теме речь, идёт конечно и мелких МК, но даже на STM8 - можно конечно что-то разрабатывать без эмулятора, но зачем??? Если стоит он - копейки, а времени позволяет сэкономить несравнимо больше своей стоимости.
Ну вы же не будете копать котлован лопатой, если у вас рядом стоит почти бесплатный заправленный экскаватор? (бесплатный если сравнить со стоимостью своего времени, которое потратите на этот сизифоф труд)

Добавлено after 3 minutes 6 seconds:
Я в таких случаях говорю заказчику просто: "Ок, я не против работать без эмулятора, если уж так надо, но времени для реализации оговоренного функционала мне понадобится на N месяцев больше. Вы согласны мне заплатить за дополнительные месяцы работы по оговоренной ставке?" После этого вопрос с эмулятором сразу решается.
Так как даже дорогой эмулятор стоит намного меньше месяца моей работы.

Спойлер

Это было лихое безработное безвременье, и 200$ в месяц, предлагаемые заказчиком, были сказочной мечтой. Не до выпендрёжа было.

Но всё же тема - про маааленькие МК.

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

наблюдение и изменение переменных на лету в быстроменяющемся процессе?! серьезно?!

я бы хотел конкретной инфы о том, как вы это делаете и какие плюсы получаете.

Добавлено after 5 minutes 34 seconds:
и я сильно поражен, что заказчик готов платить некомпетентному специалисту вообще, тем более слушать от него ультиматумы. или неготовность работать с МК уже не считается некомпетентностью?

Добавлено after 6 minutes 8 seconds:
P.S. может быть я просто отстал от жизни и современные отладчики уже работают поверх основного процесса, не вмешиваясь в него, а отсылая на комп содержимое контролируемых объектов?

Тебе о твоей отсталости уже давно было сказано. Если бы потрудился почитать об отладочной макроячейке ARM, то давно бы знал, что именно так она и работает. И переменные можно смотреть без остановки ядра, вживую.

ну ок, вживую. что видно вживую с АЦП, работающего на мегагерце, например? ну и остальные вещи тоже меняются десятки тысяч раз в секунду - какая польза от этого?

ну, ок. допустим у меня прошивка перестала работать. что мне делать? Как мне поможет осцилограф?

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

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

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

для каких целей нужно пошаговку применять внутрисхемно?

КРАМ, а что будет, если МК, управляющий приводом, вы брякните сложным способом, как можно? останов == смерть, хоть по сложному, хоть по простому бряку. и это верно не только для привода: пока вы рассмотрите переменные, у вас и ПИД печки спалить все успеет.

Добавлено after 2 minutes 28 seconds:
кстати, если говорить об исключениях, куда можно улететь, то и с УАРТОм можно оттуда стек раскрутить и т.п. диагностику проделать, ноль преимуществ.

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

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

Добавлено after 50 seconds:
и чем это отличается от вывода в консоль? и в чем преимущества этого?

Добавлено after 2 minutes 36 seconds:
кстати, в предложенном мной примере привода понижать частоту АУП недопустимо, т.к. система завязана на реальное время, и замедлив этот реализм вы рискуете или все спалить, или лишиться смысла отладки, т.к. процессы будут не те

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

Добавлено after 1 minute 46 seconds:

В том, что терминал не требуется. От слова совсем.

Добавлено after 2 minutes 47 seconds:

Эти "редкие случаи" для моего класса задач составляют 100%. Впрочем, для трех моих коллег по работе - тоже.

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

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

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

вы же наверняка не собираете макеты аналоговых схем, а моделируете их, а отладка схемы на макете по смыслу эквивалентна внутрисхемной отладке кода!

Добавлено after 2 minutes 16 seconds:
да, вывод в терминал к реальному времени не пришьешь, т.е. оба подхода тут неприемлемы. и чо?

Добавлено after 1 minute 23 seconds:
пы.сы. ну, допустим, я заявляю, что для семидесяти моих коллег аппаратная отладка не нужна. и чо? разве я вас убедил, КРАМ?

и они пишут неотлаженный бажный код.

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

А что, в терминале что-то будет видно с АЦП работающего на мегагерце?

Я уже такой пример приводил. Могу подробнее.
Я занимаюсь обнаружителями сигналов. При цифровой фильтрации иногда могут возникать исключения типа деления на ноль, или ошибка адреса/стека, или ошибка DMA, или .... 100500 вариантов.
Возникает спорадично. То есть понять точку в коде очень сложно и затратно по времени. Ставим бряки в обработчики исключений и получаем искомое за несколько секунд.
Терминал тут вообще не поможет. Ибо МК уходит в сброс.
ЗЫ. Кстати, даже при работе с силовыми цепями в реальном времени можно создать внешнюю схему работающую при малых токах и симулирующую реальное железо. Это когда очень нужно.

а разве обработчик исключений не позволяет выполнять код обработки исключения?

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

так речь о том, что считать стандартом и насколько этот стандарт необходим!

КРАМ, появились новые вопросы. вы отлаживаете свои штучки на моделях сигналов? что мешает отладить код на компе без кристалла вообще? это же вроде как задача для тестировщика... и уж к реальному времени вот вообще отношения не имеет. или в чем подвох?