Adrift выше писал, STM32 можно прошивать/читать разными способами/методами.
С программатором - понятно. Купите, это дешево, супер. Нно чтобы доставить, нужно время. Пока ждете доставки, включите STM32 к PC чрез USB: UART модуль к RX/TX на STM32. Чрез STM32CubeProgrammer можно и записать, и читать, и стереть STM32. Ниже: мой UART модуль на CH340G к A9/A10 на STM32F103C8T6: читаем, записиваем ...

Тут одновременно с стм32 и визио изучаю. Скопировал папку с проектом (не моим, тот что с гитхаба), решил его оставить первозданным а тренироваться на копии, создал другую папку и вставил в нее проект. Запустил скомпилировал, а в Дебуге бин старый, и он файлы проекта не видит кроме головного main, походу он из старой папки их подхватывает. Это нормально? Теперь и проект не скопировать? кстати запускаю проект из старой папки, выкидывает сообщение что он плохой, запускать не буду. Я знал что тамошние прогеры мудаки, но не знал что настолько. На дельфи раньше прожки делал, такого не было, пока серьезные дядьки не сказали "на нашем предприятии пиратское по использовать низззяяя", ну нельзя так нельзя, я больше не программист. VisioGDB релиз срок проходит, ключ просит. Сынок посоветовал cubeIDE поставить и cubeMX, с ними тоже не слава богу, сейчас затык скачать openocd не может. Толи санкции толи сам не допетриваю. Посоветуйте чего ребята.

На rutracker ломаный есть.

Займитесь чем-нибудь, что у вас лучше получается - не мучайте себя.

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

Так и приходят..... но - дальше питона мало кто продвигается. Кубокодинг на си для них - уже коцмас. А чтобы самому прочитать мануалы, разобраться по ним в периферии и самостоятельно написать код - это уже за гранью фантастики для них.
У нас в конторе основная масса - "молодые и амбициозные". И из этой массы только один или два человека умеет на си контроллеры программировать. А чтобы без Куба - ни одного.
И имхо - это не только у нас так. А везде.
Мне уже сказали, что "в моём коде во всей конторе никто не может разобраться". Потому как написан на си и без Кубов. А ведь простой си. Почти без ++ и с маленькими вкраплениями asm.

Потому - не боимся. Боимся наоборот - что на пенсию не дадут уйти.


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

Ребята здравствуйте! помогите пожалуйста с поиском CMSIS и Startup к STM32G431
Спасибо огромное!!!

Проект для STM32G431CB.

Мурик! Я вас люблю, Мурик!!!


Что то у меня тактирование от внутреннего генератора не пашет. С внешним морочится не стал( Ни у кого нет готовой настройки на 170мГц?

Первые три команды не нужны, hsi и так включен. Вторая вообще бессмысленна - зтот бит только для чтения.
Делитель M неправильно задан, там не 4 получится.
Пятая команда фактически отменяет действие четвёртой.
После включения pll надо подождать его готовности.
Последняя команда наверняка затирает в cfgr что-то полезное.

Итого: ни одной правильной команды.

Добавлено after 1 hour 36 minutes 48 seconds:
Начни с такого.

а смысл запускать такой лапоть на милигерцах?

Что такое милигерц?

Не все владеют русским. Даже если говорят на нём. И даже если пытаются учить других правильно говорить.

а как это читаеца?

Так ни чего и не понял

вам готовый ответ дали

Сконфигурируйте через Cube и не мучайте опу. Дался вам этот CMSIS - оставьте его для умных.

Эхехех. Сегодня случайно натолкнулся я на это "никто не может разобраться":

Жжжжуткое месиво из magic numbers и бестолковых смешиваний обращений к регистрам из разных периферийных модулей и прикладных вычислений. Принцип единственной ответственности (и не только он один) попран ногами. Всё склеено в такой жуткий комок, который действительно невозможно разодрать. Так обычно пишут либо начинающие, либо безграмотные. Начинающие то быть может научатся, а вот безграмотные годами пишут месиво и гордятся им. Хотя гордиться тут нечем, это безграмотная позорная мешанина.
Программирование микроконтроллеров - это не только биты и регистры, но и принципы построения вообще программного кода. И этому тоже надо учиться, а не пренебрегать. Те, кто учился в ВУЗах по специальности, это прошли в рамках образовательной программы. Остальным - самообразование никто не запрещал.

Есть такой "принцип единственной ответственности", который гласит, что функция (класс, модуль) должна отвечать только за что-то одно. Если функция работает с регистрами SPI, то она должна работать только с регистрами SPI, никаких побочных вычислений какой-то переменной faza, никаких вызовов какой-то PingMain(), которая вообще черт знает что там делает, никаких вызовов посторонних модулей. Принцип единственной ответственности! Если надо вычислить переменную faza, это делается ВНЕ этой функции. Если надо вызывать PingMain(), это делается ВНЕ этой функции. Если нужно активировать DMA, это делается ВНЕ этой фукнции. Нельзя смешивать в одной функции разные уровни - уровень работы с железом и прикладной уровень. Каждая функция занимается только тем, для чего она предназначена. WriteSpi(GetPhase(i)); - уже лучше. (Причем, орфографически правильно не faza, а phase)

Из вышесказанного следует еще один принцип - принцип открытости/закрытости. Он гласит, что если нужно расширить функционал, то не следует изменять уже написанный модуль или функцию. Добавьте этот функционал в отдельной функции, не переписывая готовой. Потому что каждое дописывание готовой функции требует повторной её отладки, тестирования. Зачем переделывать работу, которая уже была сделана?
А если потом потребуется наоборот уменьшить функционал или использовать модуль в другом месте с меньшим функционалом, потребуется опять переписывать написанный модуль, выбрасывая лишнее.

Используйте интерфейсы модулей. Взаимодействие с программным модулем должно происходить только через предоставляемый модулем интерфейс. Интерфейс - это набор функций для доступа к внутренней структуре модуля. WriteSpi() - это интерфейс модуля Spi для передачи байта. GetPhase() - это интерфейс модуля фазы чего-то там для получения значения этой фазы через вычисление.

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

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

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

PS. Есть принцип "Keep it simple, stupid", что в переводе означает "пиши проще, чувак!"

а человек-оркестр за миску риса еще и коментов должэн был накидать?

Причем здесь комменты? Там в том коде чушь собачья написана, это и без комментов видно. Никакой структуры, никакой логики, всё в навал. И я объяснил подробно, почему так. Читайте литературу по программированию.
Такое бестолковое месиво пишут либо начинающие, либо безграмотные. И это барахло никто разбирать не будет, выкинут файлы по Shift+Del и вспоминать не будут.
Если "человек-оркестр" ни в зуб ногой в теме вопроса, то пусть лучше в "оркестре" на балалайке пиликает за свою тарелку риса, коль он за еду работает. Кто не умеет, тому не следует и браться, чтоб не воротить такой вот дичи, которую потом только в помойку, на свалку истории.