Чрезвычайно токсичное, есно с точки зрения аурдинщика.
Когда почти на любой вопрос посылают изучать доки. Когда портянки свои постят - изучай доки. Даже на риторические вопросы чисто автоматически - изучай доки.
Потому как желающих обучать языку Си не столь много. Читать документацию для клиента в режиме онлайн - можно всего несколько раз в своей жизни. Потом возникает стойкое ощущение бесполезности подобных действий. Отчего количество "откровений" ещё меньше чем рабочего кода на CMSIS.

Насчёт документации.
Скачивать доку на чип stm нужно непосредственно со страницы продукта, st.com есно. Сначала нужно прочитать название своего чипа полностью. Аурдинщики часто не понимают столь простого задания, для них всего 3-4 продукта существует на всём свете, и для каждого короткое уникальное название. ARM уже больше тысячи (учитывая китай). Одна буква, или даже графический символ - может кардинально менять направление поисков документации.

Случилось странное, у вас получилось найти страницу с доками, которых отчего-то слишком много. Крайне рекомендую установить хром с поиском в гугле, и включить отображение расширений файлов в проводнике. Документацию нужно скачать всю, в отделанную папку (чтоб не потерялось). Первый файл для изучения - самый жирный, на очень много страниц. Читать по диагонали не получится. Информация в доке представлена в очень грамотном порядке - первым идёт то, без чего невозможно продвижение вперёд. Не просто читать сверху вниз, но и применять знание в коде. Программируется чип в точно таком-же порядке как инфа представлена в доке. Это очень важный момент - он поможет вам избежать множества ошибок.
Остальные документы вам тоже нужны, но не сразу и не сейчас. Желательно иметь "слепок" документации не просто свежих версий, а версий одного времени создания. Когда вам понадобится доки, крайне желательно чтобы содержимое не менялось кардинальным образом. А там хоть трава не расти.


Не надо рекламировать примеры ужасного Си, там и без вас справляются. Если что, они все в соцсетях, и почти всегда в закрытых сообществах. Даже не знаю как они друг друга находят, по запаху наверное. Результат подобного обучения регулярно всплывает здесь, и на других ресурсах. Всплывает как какашка. Многие пользуются ёршиком, отчего вопрошающий обратно ныряет в свои соцсети, и больше не всплывает (и это хорошо).

ddr4, направьте вашу злость в правильное русло и всё получится!

У меня нет такого контроллера как у вас, но есть очень похожий. Сделал на нём самый простой проект, как я это понимаю, без всяких библиотек. Компилируется с помощью makefile. Должно и в Windows, и в Linux собираться. Только пути к компилятору прописать.

Линкерскрипт и стартап можете, конечно, посмотреть, но править в них что-то никакой необходимости нет.

Остались два .cpp файла с кодом - там и творите.



Думаю, сделать по аналогии на ваш контроллер - дело 10 минут.

GPIOE->ODR ^= 1 << 8; или GPIOE->ODR ^= GPIO_ODR_ODR8;

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

Вариантов можно много предложить. Вот так, напримерили вот такВаш совсем плохой. Почему, поспрашивайте у местных, может расскажут.

Выбираем схему BMS для заряда литий-железофосфатных (LiFePO4) аккумуляторов

Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.

Подробнее>>

На основе двухгодичного входа в мир программирования под stm (чтения форумов) придумал универсальный ответ: Иди прочитай доки, переделай нормально, иначе придет Емельянов Эдуард и тебя уничтожит.

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

Не придёт. Он является на заклинания "куб" или "windows"

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

VladislavS, точно ☺

Понятно, что в "блинке" можно спокойно ODR использовать. Но в общем случае состояние порта может поменяться DMA, периферией, в прерывании и т.п. Поэтому надежней атомарные операции использовать. А т.к. их нет, то менять состояние пина через BSRR.

Ну, до DMA тут еще как до китая, тут автор вначале хотябы просто проект бы собрал, без блинков пусть даже. Автор темы пока еще просто находится в ужасе от увиденного и от того, что STM32 - это нихрена не AVR, и всё настолько непривычно и непонятно, что он ну совсем потерялся. Так что какие уж ему тут DMA... И даже BSRR тоже нафик, пусть хоть через ODR и программный дилей сбацает. Ему щас надо простенько и примитивненько, не травмируя психику чувствительную, без излишеств.
А то я тож могу блинк через FSMC замутить, так автор темы вообще свихнется.

Потому что чтение/модификация/запись. Если в этот момент прилетит прерывание в котором похожим образом изменяется бит на том же порту, будет... Надеюсь знаете или объяснить?

Идеальнейшим вариантом для ТС было бы вычитать всю нужную документацию и практически с полного нуля начать разработку, чтобы все понять. Взять образцы, да написать свой Makefile, ld-скрипт, стартап (выкинуть все ненужное из классики - в С нафиг не надо держать все эти секции конструкторов-деструкторов, еще выкинуть запуск всякого говна вроде SystemInit - их правильней вызывать в начале main). Качнуть CMSIS с заголовочными файлами под свой камень и разрабатывать.

"Спасибо што сказали". А то без вас прям не знал. Я это узнал даже раньше, чем вы, если чо так Тожемне, "учителя" собрались, хахаха Но здесь, в примере того блинка, там никде нет потенциального "модификация-запись". Нужно же не тупо копипастить, а понимать, что где и для чего пишите. А то начали вдруг умничать прям. Ха. Вы вначале попробуйте топикстартеру доходчиво объяснить насчет сборки чистого проекта, потом будет блинками хвастаться А то топикстартер уже готов разломать пополам плату BlackPill

Компилятор всё равно их создаёт. И с чего вы взяли, что в проекте не будет С++? ТС ардуиньщик, а они на плюсах пишут.

Это неправильно. Даже если взять простые чипы, где вся память включена при подаче питания, то в Systeminit обычно поднимают тактовую. Инициализировать данные на 16 МГц или 72 МГц (или даже на 480) это достаточно большая разница в скорости запуска получается.

PS: Ещё вспомнил. Есть одна достаточно распространённая стандартная библиотека (название умолчу), которая при инициализации данных использует FPU. И если его не включить перед её вызовом, то будет такой смачный HardFault на ровном месте. Только из-за выкинутого SystemInit.

VladislavS, на отсутствие инита FPU я уже натыкался, спасибки. Но я таки предпочитаю явно иметь вызов функции systemreset() в начале main(), нежели гадать, что за хрень неведомая происходит!!!
А если нужно тупо поблимкать светодиодом на минимальной частоте, то ничего вызывать не нужно. И все идет ровно по накатанной - как написано в даташите, а не как какой-то автор нарисовал в SystemInit, который вызывается из стартапа без твоего явного желания!
В общем, все должно быть именно так, как я задумал, а не как во всяких пытхонах, где, чтобы себе выстрелить из гранатомета в голову, нужно приложить нехилые усилия...

Ну так оно и идёт всё ровно по накатанной начиная с Reset_Handler. Почему ты считаешь, что жизнь начинается с main? И кто кроме тебя в твоём проекте что-то в SystemInit может написать? Всё под контролем.

Причём здесь тянет мозгом, не волокёшь, вы на СТМке уже 10 лет сидите, а я лишь описал впечатления после 2-х дней знакомства с СТМ после AVR. Причём, если бы я не был знаком с AVR, то таких впечатлений скорее всего бы не испытал, так как сравнивать было не с чем.
Причём здесь соображалка. Пример с uart_print() у меня собрался, раз уж я понял что HAL не той версии.
Я и не собирался лезть в дебри, мне нужно было понять проект-примера это же не дебри - это на поверхности, только поверхность была большая от ld-скриптов и стартапа до HALa.
По моему вы как-то приняли на свой счёт мои впечатления о знакомстве STM32-после-АVR и перешли на обсуждения меня. Причём я написал этот отзыв после того, как уже разобрался с API HAL. Это был скорее юмор, но как мне показалось его слишком серьёзно восприняли.

Добавлено after 1 hour 9 minutes 34 seconds:

Это была не злость, а скорее юмористический отзыв, который описывал первые ощущения от знакомства с СТМ32. На момент написания которого, я уже разобрался в структуре проекта, то есть нашёл HAL, перевёл найденный пример uart-print() на свою версию HAL и собрал. То есть причины злится у меня не было. К сожалению мне пока негде его проверить собранный пример, так как выводы к плате ещё не припаял. Для проверки пытался использовать QEMU с командой:

Но программа висит и в окно эмулятора ничего не пишет. Кто-то советует делать вывод в unix сокет, но у меня Windows. Вобщем трудно понять работает ли программа, но видимо это уже на железе надо проверять. Хотя я не оставлю попыток установить QEMU в Линукс и попробовать уже там с выводом в unix-сокет.

Спасибо за пример. Как я понял это прерывания по таймеру, подробности (частота срабатывания и настройка таймера) пока не изучал.

Добавлено after 1 hour 53 minutes 51 second:

С нуля это не разработка, а скорее изучение МК. Разрабатывать приложения можно не заглядывая в CMSIS. Я так и делал в avr-gcc, там своя библиотека avr-libc встроена в компилятор.
Вобщем для разработки на STM32 достаточно рабочих примеров на HAL, можно и над ним подняться при желании, железо с натяжкой позволяет.
И так как STM не сделала свой stm-gcc, то у нас есть библиотеки CMSIS+HAL, cross-gcc + ld-скрипты.
Вот меня такой зоопарк сперва немного удивил.

ddr4, вот я начал осваивать STM32 лет 10 назад. И если бы мне тогда сказали: "не пользуйся говнищем SPL, не пользуйся говнищем opencm3", я бы не потратил лишних года 3-4 на это рукоблудие, а сразу же сел бы писать свои сниппеты под "чистый CMSIS".
Теперь их есть у меня. По мере разработки регулярно этот набор пополняю. Ну и старое стараюсь развивать: то у меня был блокирующий CDC, потом сделал на кольцевом буфере, а сейчас заметил, что скорость маловата (всего-то 6.5Мбит/с, а в теории как бы 12 должно быть), решил чуть переделать (в прерываниях отправлять следующую часть буфера, как только предыдущая отправлена). И CAN, наверное, стоит на прерывания переписать (т.к. поллинг, возможно, может пропускать сообщения на большой скорости - хотя пока что ничего подобного не замечал).

Ну дак надо было просто представлять, что STM32 после мелких AVR - это на два порядка более сложный уровень. Это не равноценная замена, как бы, это надо было сразу осознавать переход на другой уровень. Мы, когда десяток лет назад пересаживались с PIC/AVR, сразу были готовы к смене разрядности с 8 на 32 и к более сложной начинке. Например, для меня главной непоняткой было то, что стмовский даташит содержит только общее описание МК и электрические его характеристики, а описание регистров и битов находятся в двух других документах, да еще и с разделением на ядро Кортекс и периферию СТМ. Но ниче, привык, освоил.
И даже наоборот, предыдущий опыт работы с PIC/AVR очень даже помогл в освоении STM32, потому что не надо было разбираться, что такое память программ, для чего нужны таймеры и как работает SPI, I2C, UART.