Начал изучение программирования STM32F103 с System Workbench + STM32CubeMX, и по обучающим материалам составил мнение - что каждый раз при экспериментах надо прошивать (читай - насиловать и изнашивать) микроконтроллер, что вообще не оправдано (кроме последнего случая). На предмет симуляции контроллера для данной системы (Eclipse) нашёл следующее: Программный симулятор микроконтроллеров ARM в Eclipse, с чего понятно - что по простачку симулировать можно из командной строки, если встраивать в систему - куча всего всякого, и в конце концов - получаем текст с содержимым регистров. - Так что-ли понимается симуляция у программистов? Я ожидал некое схематическое изображение светодиодов, аналоги вывода на дисплей, какие-то сообщения об частоте, выводе единиц на контакты, индикацию процессов в АЦП и т.п. Чёрт ногу сломит. Это обычное дело? Стоит остановиться на этом? Или есть нечто более удобное для новичка? Может в других системах?

Что там изнашивать? 10000 циклов перезаписи флеш гарантируется. Вы поседеете раньше

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

Сам не видел, люди говорят, есть Proteus, он лампочки в процессоре симулирует.

Купите себе плату NUCLEO-F103RB за 11 Евро, уже с встроенным программатором-дебаггером, и ни в чем себе не отказывайте в плане "насилия и изнашивания" микроконтроллера. Еще ни разу не встречал отказа флеша МК на отладочной плате из-за частой перепрошивки. Есть тестовые платы, которые я периодически "мучаю" по несколько раз в год оччень плотно, уже лет по десять, и ничего.


Тоже слышал про Протеус, но только как "для начинающих" и "для обучения". Сам не видел и вряд ли ...

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

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

Короче берите реальную плату и работайте с реальным железом. И да перепрошивается весь софт при изменении одной переменной.

Не стоит. Как Вам тут уже неоднократно сказали. Тем более что STM32F103 - один из самых дешёвых, если работаете с отладочной платой - купите их несколько раз так боитесь изнасиловать Если с реальным устройством - скорее новую плату переразведёте (для правки схемотехники) и всё равно там будет новый МК.
Ну или возьмите более мощный МК, где больше ОЗУ, и насилуйте его ОЗУ вашей программой сколько угодно.


Да время - самое главное. Скорее даже поэтому, а не из-за экономии ресурса флеша, я стараюсь отлаживать ПО по возможности в ОЗУ, ибо перепрошивка флеша - это в разы медленнее.

Эх молодежь пошла.. вот помню Z80 как центральный проц, ПЗУ с УФ стиранием.. прогу пишешь, потом стираешь ПЗУ под лампой ДРЛ 20 минут, потом шьешь его.. ресурс - 25 циклов. Новая стоит денег дохрена, брали в Автово.. вот это было программирование.. Пишешь конечно на ассемблере, а не на этих ваших новомодных Сях, на офигительном компе с 2.5 МГц тактовой и 48 кбайт ОЗУ с монитором из ЧБ телевизора.. А щас что.. чем ошибки в коде искать - проще залить и смотреть - пашет-не пашет ))) Всех на Колыму!! Потом at90s1200 появился и at89c2051 c флешем - такой оргазм был... !


Вы прикалываетесь? Сколько этот ваш проц шьется? У меня 60 кил в EFR32 заливаются секунды 4.. Я в день на курению трачу времени больше, чем yf 900 рперепрошивок

Вы прикалываетесь? Неужто так и стирали по 20 минут? А работали когда? Или просто надо было время на перекуры оправдать?
Сам когда-то давно отлаживал ПО в устройствах на i8080 и хранивших его штатно в РФ-ах. РФ шил только тогда, когда надо было на стенд ставить или заказчику отправлять.
А для отладки были статические ОЗУ, по пинам совместимые с РФ. Их и ставили в колодки. Никто 20 минут на перешивку не ждал.
Да и для прошивок в РФ у меня их не одна штука была, а пачка. И если нужно - брал следующую из пачки. А потом всю пачку стирал.


А я не курю.
Мой МК только один сектор и только стирает до 5.5сек + прошивка. И прошивка у меня гораздо больше 60 кил.
И сидеть ждать по 10 секунд (а то и больше) при каждом небольшом изменении ПО меня напрягает. И сбивает с рабочего ритма.
А в ОЗУ всё грузится за ~секунду.

20 минут. ДРЛ-250 со снятой колбой.
Ну раз 10 секунд напрягает то звиняйте.. я над кодом думаю дольше значительно обычно, 10 секнду никак не напрягают

Когда надо думать над кодом - это одно.
А когда разбираться с новым периферийным блоком МК, имеющим несколько десятков регистров да ещё очень плохо описанных - это совсем другое. И тогда приходится очень много раз перешивать МК.
Речь конечно не об STM32, где регистров в периферии - раз два и обчёлся....

"STM32, где регистров в периферии - раз два и обчёлся...." я бы так не сказал... а в каком не обчелся тогда?

Infineon XMC4xxx например.

По описанию их перифирии - тож самое. Странно тогда. Ну да ладно

Странно вы как-то описание читаете....
Например UART в STM32F4: 7 регистров, в каждом используется не более 16 бит.
Аналогичный последовательный порт (USIC) в XMC4700: регистров под 4 десятка, используются биты 0...31.
Разница в несколько раз это "тож самое" ?

Что за бред. Я на них сколько игрушек адаптировал, вся работа на ассемблере в памяти. Берете картинку, убираете ее из игры, область памяти зачищаете, пишете туда свой код.
Там же отлаживаете. И когда все готово прошиваете ультрафиолетом. Ассмблер, компилятор, все как положено.
Помню точно, прошивка в ПЗУ это только финальный вариант, а так вся работа не поверите, в памяти и на магнитной ленте. Елы палы как вообще мы тогда работали....

А я перфоленты помню. Сам не программировал тогда, только заправлял. И схемы разрабатывал.

какая картинка еще, я из него контроллер синтезатора для радиостанции спаял

Раз только начали, то стандартные задачи - разобраться со средой разработки, прошивкой, отладкой. Затем инициализация периферии. Всё это на первых порах умещается и отлаживается в RAM процессора. И быстрее, и флэшка не "изнашивается", хотя не видел ни одного "изношенного" ещё на своей практике. Обычно они гибнут по другим причинам. К моменту когда отлаживаемый код перестанет помещаться в RAM наберётесь экспириенса, аппаратные модули отладите - отпадёт необходимость прошивать процессор по каждому чиху.

Рекомендую обратить внимание на технологию RTT - хорошо помогает отлаживаться.

За 20 лет не протер ни одного чипа.
Спалил одну AVR и один STM32F373 по невнимательности.

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