Да ничем. Особенно если можно в дешёвом свистке заменить чип на тот же gd32f103cbt6 за ещё сто рублей, вывести пару ножек наружу взамен ненужных пинов питания и программирования стм8 и получится та же отладка для стм и внешний ресет.

А я где то это утверждал?
Я всего лишь привел пример инструмента. которым пользуюсь сам. Ваш вариант инструмента лишь доказывает, что использовать встроенную отладку экономически безразлично с пробросом УАРТ на терминал мостом УАРТ-ЮСВ.
Сиречь за чуть менее, чем зв 200 рублей получаем очень удобный терминал и брейкпойнты.

а разве вас банили хоть раз за ваши манеры?!

какой жестокий секс! Возмите готовый DAP-Link с али, он официально Keil поддерживается наряду с JLink. И стоит как STLink.

Вот я и пытаюсь понять, приобретение "вашего инструмента" мне дополнительно даст, что даст?

15 минут работы это для вас сложно? )
Тем кто не способен сделать элементарные вещи пусть покупает готовое, которое хуже. Купите готовое! Да и вообще тогда зачем заниматься электроникой? Покупайте всё готовое.
А тем кто хоть на что то способен, переделка даст много плюсов: прошивка и отладка + прошивка путём закидывания файла в него + полноценный ком порт.
И всё это в виде мелкого, аккуратного и удобного свистка, плюс поддержка от ст, ведь это по сути их новый ст-линк.

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

Банят не за манеры, а за нарушение правил.
А манеры - дело хозяйское. Мне, например, ваши манеры не нравятся. Я об этом так и говорю. Но правил не нарушаю.


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

Зачем? Достаточно просто привести в соответствие среду, платформу и отладчик. Железо отладчика никто и не предлагает курочить, а прошивку можно и восстановить.

наверно о разных вещах говорим:

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

Не курочить, а сделать удобный инструмент. Лично мне отрезанный от нуклео стлинк неудобен. Свисток удобней.

Перерезать три дорожки и припаять 3 провода? Это серьёзная переделка? Вы форумом не ошиблись?
А если при этом перепаять чип чтобы получить полный функционал как бы тоже не проблема.
А если вы инженер электроник, так и вовсе с удовольствием провести 15 минут времени, для души.

- прошивка и отладка - как будто обычный st-link за 170 рупь. не может и прошивку и отладку выполнить.
- прошивка путём закидывания файла в него - это что? типа сменного диска определяется что ли?
- полноценный ком порт - это еще как сказать, 115200 хоть вытягивает, да в добавок вместе с отладкой?

Я думал услышать типа такого:
- увеличится количество точек останова, желательно указать сколько
- увеличится скорость работы МК во время отладки, а то во время отладки скорость работы МК заметно снижается
- увеличится скорость работы внутреннего терминального, не знаю как назвать, в IAR называется Terminal I/O
- и еще много ++++++, чего не знаю

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

jcxz, если подходить с точки зрения цивилизации, то для дикаря живущего лет так 10 с протеусом ST-Link V2 это уже много.
Что такое обратная трассировка программы?

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

Возможность, после остановки CPU (на бряке например), прошагать программу в обратном направлении. Чтобы выяснить - "как это мы сюда попали?"
Прочитайте про: https://wiki.segger.com/ETB

Добавлено after 3 minutes 1 second:
У меня закрадывается подозрение, что отрицатели внутрисхемной отладки и адепты плоскоземельщики - это одна и та же секта!

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

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

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

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

Добавлено after 5 minutes 23 seconds:
Да даже без разрушений стека: Поставили бряк после некоей метки, на которую есть переходы из разных точек программы - как узнать по какой ветке программа дошла до этой точки? Здесь обратная трассировка тоже полезна.

Добавлено after 8 minutes 52 seconds:
А если происходит какой-то трудновоспроизводимый баг (попадаем в ISR при определённых состояниях переменных), которого не должно вроде быть.
А потом просматриваем последовательность выполненных команд и обнаруживаем, что такое происходит только когда сразу вслед за данным прерыванием, не выходя в фон, по tail-chaining-у вдруг влетаем в этот ISR.

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

PS: Вобщем - очень многие вещи гораздо легче находятся с помощью обратной трассировки.

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

А что - бы не гадать, нужно внешнее устройство отлаживать напрямую через x86/x64 машину с помощью моста, тем самым "вылизывать" управление им до блеска, правда необходимо уметь программировать под Win32. Ведь GUI винды гораздо удобнее, какого-то там UART, JTAG ... от слабенького MCU типа ARM или Atmega