Всем привет. Ребят, очень нуждаюсь в литературе для изучения STM32, чтобы не бегать по инету и по кускам учить, а какую-нибудь целенаправленную книгу (если есть такая), где описано все подробно. Сам, можно сказать, не новичок, имеются знания языка Си, да и с микроконтроллерами работал, диоды зажигал, но я все равно не против книги, где все описано досконально, очень хочу глубже понимать.  Нашел парочку pdf в интернете, но что-то мне кажется оно такое себе. Может вы посоветуете хорошую литературу? Какой литературой пользуетесь, поделить, буду очень благодарен. Всем добра!

Так на ST'шном сайте же все есть: даташиты, мануалы и аппноуты. Плюс почитать в общих чертах документацию по ARM.
"Какая-нибудь целенаправленная книга", равно как и "уроки" будут являться жалким и неполным переводом оригинальной документации, так что незачем даже и читать это.

В наше время было популярно так называемое "Инсайдерское руководство по STM32". Для первоначального старта пойдет. Хотя оно больше как ознакомительное, ибо ему более 10 лет. А в остальном - на сайте st.com ищите нужный вам микроконтроллер, и на вкладке Documents скачиваете три основных документа:
- Datasheet на микроконтроллер с кратким описанием функционала, состава периферийных модулей, распиновки, электрических характеристик и расшифровки обозначений.
- Reference Manual с описанием всех периферийных модулей, порядка их работы, регистов и битов.
- Programming Manual с описанием работы ядра Cortex M, принципа работы прерываний, некоторых функций ядра. Ассемблерные инструкции - опционально, для ознакомления.
А так же в процессе изучения и все остальные документы, проясняющие некоторые подробности работы.

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

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

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

Reference manual и Programming manual. И Errata. И всё проч.
Неоднократно видел хвалебные отзывы на Кармин Новиелло - Освоение STM32
Сам не читал.

Я могу посоветовать, параллельно 2 проекта запустить - один своей головой думать, на основании Reference и CMSIS, и второй в CubeIDE, что-бы сверять ход своих мыслей с тем, что генерирует Cube. Тогда, потыкавшись в регистры, в случае неудачи, можно посмотреть на референсный код.
Ну, а когда код, генерируемый CubeIDE, станет понятен, можно и на него перейти.
Но, это лишь мое мнение. И, я ни на что не претендую.

Организация питания на основе надежных литиевых аккумуляторов EVE и микросхем азиатского производства

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

Подробнее>>

Ну-ну. Что-то сомневаюсь, что эти портянки кому-то в здравом уме могут показаться лучше самописного кода. Особенно учитывая их оверхед и глюки.
Единственный вариант исправиться для ST — переписать калокуб на С++. Убрать эти 100500 дебильных функций. Эти 100500 дебильных структур-инициализаторов (бывает прикольно видеть, как кто-нибудь напишет 30 строк для описания идиотской структуры — когда это можно было сделать в пяти строках на регистрах)… Все исключительно на шаблонах, constexpr'ах и т.п. В общем, чтобы все ассерты и вычисления выполнялись во время компиляции, а не в рантайме!
Но, похоже, там настолько криворукие индусы, что до сих пор этого не могут. В то время как у нескольких форумчан я видел их варианты - очень даже приличные. Взяли же они, написали для себя (правда, жадные - не выкладывают под GPL)!..

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

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

Подробнее>>

Ну неужто Эдди начал С++ изучать? Иль так просто, "слышал звон"?
Кстати, assert-ы по умолчанию отключены - void 0, пустая строка. И лишь когда есть определение FULL_ASSERT, тогда становится доступной специальная отладочная функция, которая по умолчанию тоже пустая. И эта функция, кстати, принимает текстовое имя файла и номер строки, в которой была допущена ошибка, и эта информация может быть выведена в твою любимую терминалку. Так что это твой любимый инструмент отладки и не надо на него гнать!

Самое смешной, что ХАЛ, по-сути, и так написан в стиле ООП. Только сделано это на Си, потому коряво от рождения.

Ещё момент. Посмотрите внимательно на периферию МК разных линеек и вы увидите, что есть буквально 3-4 варианта UART, примерно столько же АЦП, 1-2 варианта каждого таймера и т.д. Более того, некоторые варианты периферии отличаются наличием-отсутствием какой-то одной фичи. ИМХО, нужно просто сделать драйвер для каждого варианта периферии и как из кубиков собирать каждый МК. Более того, в большинстве линеек МК заметно, что старшие чипы разных линеек имеют одинаковую (почти) периферию. Я в проект так подбирал F0 и F7, чтобы, разобравшись на одном из них с каким-то узлом, просто перенести код для работы с на другую линейку МК.

ИМХО, ХАЛ нужно не просто переписывать на С++, а менять его архитектуру, тогда, действительно, он будет гораздо более полезен, чем сейчас.

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

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

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

Ну а для кого же ещё?

Чёт мне бензинчику в бак на заправке никто просто так не плескает - жадные наверно?

Спойлер

Для тех кто просит С++ в кубе. Вы готовы вот к такому коду? А иначе нет смысла затеваться.

Код:

template<typename TGpio, uint32_t Mask = TGpio::pins_mask>
  static consteval auto AddPinsFromRange()
  {
    return []<auto... Is>(std::index_sequence<Is...>)
    {     
      return (std::conditional_t<((1U<<Is)&Mask)!=0, TypeList<TPin<TGpio,Is, typename TGpio::tpins_mode>>, TypeList<>>{} + ...);
    } (make_reverse_index_sequence<TGpio::width>());
  }

Традиционное HAL'овское переливание из пустого в порожнее, когда одни и те же данные безо всякого изменения передаются между пятью функциями и тремя одинаковыми проверками. Да еще и запись длиннее и сложнее для понимания, чем работа с регистрами.
Для использования при инициализации это еще можно понять (однократный код имеет право быть неэффективным), хотя проблемы читаемости никуда не деваются.
Но ведь рано или поздно возникнет нужда ХАЛ'овский говнокод анализировать.

На самом деле, затея HAL очень даже правильная. Для БОЛЬШИХ проектов. Там, где нужна обширная структуризация. Потому что когда например штук пять таймеров или штуки три SPI используют фрагменты одинакового кода, есть большой смысл сократить однотипные операции.

Есть мнение: "Критикуешь - предложи лучше".

Вот ни разу не возникает. Как-то вообще фиолетово что у них там. Не понимаю, чего вы в него лезете? Чтобы больно себе сделать? Ну это имеет своё ЛГБТшное определение...

Эдя покусал?

VladislavS, так и здорово было бы: калокуберы и С-то обычно не могут осилить, так что просто слились бы вообще в туман и пытались бы таки учиться ☺
Для народа же стараюсь!

Вот ты понимаешь С++ и сделал себе эдакий аналог HAL, но вменяемый: без оверхеда и адовых простыней текста. Я С++ не понимаю, поэтому пишу сниппеты. Да вон - даже сами ST поначалу сниппеты писали и выкладывали, но почему-то дальше STM32F0 не пошли. А зря…
Я вот, кстати, обратил внимание вчера, что мой USB'шный вариант pl2303 слишком тормозной, т.к. рассчитан изначально на редкие короткие сообщения, а я выкладываю простыни дампов MLX90640 (в итоге выхлоп аж на 5-10мс блокирует выполнение, что недопустимо в нормальных условиях). Надо реализацию с круговым буфером, которую я для F303 сделал, перенести на остальные линейки. Грубо в лоб за 15 минут не получилось: подвисает где-то, похоже, придется долго и мучительно разбираться...

Вот не понимаю, как ты это делаешь? Там же одинаковый USB.

Отладчик, конечно же, не нужен.

Хорошо. Без HAL это делается проще.
Эм-м-м, написание своих библиотек. Вот, например, реализация USB: https://github.com/COKPOWEHEU/usb
Там же реализация портов ввода-вывода (pinmacro.h), тоже более удобная, чем HAL / CMSIS.
Чтобы заставить контроллер работать так, как надо мне, а не вполсилы. Тот же USB, на Хабре проскакивало сравнение HAL'овской реализации с нормальной: https://habr.com/ru/post/558556/
Свои ЛГБТ-шные определения оставьте при себе, меня они не интересуют.
Позиция Эдди мне близка. Но говорю я из своего опыта, а не повторяю чужие слова или лозунги.
Тогда уж сразу DMA на этот буфер натравливайте, копировать из памяти в USB он вроде умеет (16 бит -> 32 бита), хоть на передачу байтиков не придется ядро тратить.

Не нужен: в данной ситуации он никак не поможет. USB я отлаживал при помощи USART'а с большим буфером на 3Мбод.
Но в данном случае нужно лишь внимательно код посмотреть: скорей всего, сливая две разных штуки (т.к. USB на F303 и F103 таки частично отличается + отличается настройка GPIO и т.п.), я где-то лопухнулся и либо что-то пропустил, либо, наоборот, лишнее оставил...
Потом этим займусь - когда картинку с ИК-датчика получить смогу.

Проще, но суть остается та же. А полноценное написание на С++ резко поднимет планку вхождения и размер портянок будет тоже немалым. Хотяяя... Ардуина писана на С++, в принципе даже с наворотами. Но внутрь скетчей мало кто заглядывает, пользуются только предоставляемым функционалом. Тому же Эдди опять не угодишь - будет кричать про ардуинство, хоть даже и на С++ будет.
Большие проекты на мощном железе подразумевают достаточно сильную абстракцию. И в конечном счете вы всё равно начнете приходить к структуре, похожей на HAL, пусть и более сокращенной. Кто-то тут против assert-ов? Но assert - это встроенный в код механизм отладки с обнаружением ошибок. И этот механизм может быть реализован по-разному, в частности, выдавать в терминалку имя файла и номер строки, в которой произошла ошибка. В HAL-е assert-ы уже встроены во всех ошибко-опасных местах, но подефолту отключены через макроопределение.


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

И как это помогает посмотреть где повис код?

Всё их отличие только в том, что производитель в заголовочном файле не смог одинаково назвать вектора прерываний. Вот всё их отличие:


Добавлено after 30 minutes 3 seconds:
Не хочется на очередной круг заходить, где-то с год назад обсуждали - неоптимально написано. И с тех пор ничего не изменилось. В функции записи в конечную точку очень опасный переход от (uint8_t *) к (uint16_t *) - посмотри макрос __UNALIGNED_UINT16_READ из CMSIS, иначе когда-нибудь тут выстрелит.

Даже HAL умеет несколько ног за раз конфигурировать.

При чем здесь "повис"? USB отвалилось, т.к. что-то не вовремя (или не то) с флагами сделал. А код радостно продолжает дальше...
В отладке смотришь: одна стадия прошла, вторая, третья, тут - бац, NAK! И шукаешь, что там не то сделал.
Внутрисхемная отладка при этом ничем не поможет.
P.S. У F103 и F303 также отличается инициализация USB.
Но я уверен, что сам что-то прорукожопил. Вот, сейчас дописываю код извлечения параметров, смотрю, а у меня в цикле прохода по последовательным регистрам сам указатель на текущий регистр не инкрементируется, да еще и два раза по одному и тому же регистру бегал (там вообще в одном блоке регистров по четыре параметра для каждого пикселя!) - запихал все в один цикл.
Смотрю на тот треш от "производителя" и диву даюсь, до чего все по-дурацки сделано. А еще в даташите бешеная "формула" для вычисления pattern (который 0-1-0-1 в зависимости от номера пикселя в "шахматном" формате), зачем это - непонятно, все равно и ослу ясно, что нужно для четных пикселей использовать нулевую страницу, а для нечетных - первую.

Всем помогает...
Это неправда.

Немалым, но не возьмусь сказать, что он обязательно будет больше и сложнее, чем на Си. Все-таки отсутствие мощного препроцессора вынуждает либо выдумывать хитрые извращения, либо плевать на эффективность и делать все в рантайме. В С++ как минимум есть constexpr'ы, которые хотя бы часть задач упрощают.
Там как раз выбрали неудачное подмножество С++. Слишком много ООП, избыточная универсальность вместо системы настроек и предупреждений.
Ну, например, ШИМ там можно вывести на любые ноги, но только на двух он будет аппаратным. Как вариант, можно было выводить warning, что, мол, "Ваш ШИМ будет программным, подумайте еще раз. Если вас это устраивает, впишите #define PWM_SOFTWARE".
А с чего еще начинать изучение контроллера, как не с GPIO? То есть подобная библиотека сама пишется в самом начале освоения. Жаль только, я не видел удачного интерфейса, под который можно было бы подгонять свою.
Вот! А ведь HAL еще вдвое менее оптимальна.
Это обсуждение я, видимо, пропустил. Хотя stm32 ведь равнодушна к выравниванию, разве нет? Или там просто потеря скорости?

Начиная с какого количества ног это становится выгоднее? Для какой периферии это актуально?