Кто любит RISC в жизни, заходим, не стесняемся.
Ответить

Литература для stm32

Вт май 17, 2022 21:37:25

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

Re: Литература для stm32

Вт май 17, 2022 21:41:45

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

Re: Литература для stm32

Вт май 17, 2022 22:12:00

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

Re: Литература для stm32

Вт май 17, 2022 22:59:34

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

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

Re: Литература для stm32

Ср май 18, 2022 00:47:52

Ну, а когда код, генерируемый CubeIDE, станет понятен, можно и на него перейти.

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

Re: Литература для stm32

Ср май 18, 2022 05:33:31

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

Re: Литература для stm32

Ср май 18, 2022 06:51:39

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

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

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

Re: Литература для stm32

Ср май 18, 2022 07:08:56

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

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

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

Взяли же они, написали для себя
Ну а для кого же ещё?

(правда, жадные - не выкладывают под GPL)!..
Чёт мне бензинчику в бак на заправке никто просто так не плескает - жадные наверно?

Re: Литература для stm32

Ср май 18, 2022 07:48:46

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

Re: Литература для stm32

Ср май 18, 2022 08:21:12

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

Re: Литература для stm32

Ср май 18, 2022 08:30:37

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

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

говнокод анализировать.
Эдя покусал?

Re: Литература для stm32

Ср май 18, 2022 10:16:47

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

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

Re: Литература для stm32

Ср май 18, 2022 10:38:27

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

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

Re: Литература для stm32

Ср май 18, 2022 10:39:21

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

Re: Литература для stm32

Ср май 18, 2022 10:51:39

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

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

Re: Литература для stm32

Ср май 18, 2022 12:18:50

Без HAL это делается проще.

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

реализация портов ввода-вывода (pinmacro.h), тоже более удобная,

Та нууууу. "Волшебные циферки" и огромные портянки лишнего кода. Та нуууу... Хотя, кто как хочет, так и дрочет, как известно... Но блин, переписывать на свой лад то, что уже давно придумано - эт не та сфера, куда стоило бы применять силы.
Последний раз редактировалось НовыйДень Ср май 18, 2022 12:33:01, всего редактировалось 1 раз.

Re: Литература для stm32

Ср май 18, 2022 12:59:29

в данной ситуации он никак не поможет. USB я отлаживал при помощи USART'а с большим буфером на 3Мбод.
И как это помогает посмотреть где повис код?

т.к. USB на F303 и F103 таки частично отличается
Всё их отличие только в том, что производитель в заголовочном файле не смог одинаково назвать вектора прерываний. Вот всё их отличие:
Код:
#elif defined(STM32F1)
  #define USB_IRQn USB_LP_CAN1_RX0_IRQn
  #define USB_IRQHandler USB_LP_CAN1_RX0_IRQHandler
  #define USB_CNTR_LPMODE USB_CNTR_LP_MODE
#elif defined(STM32F3)
  #define USB_IRQn USB_LP_CAN_RX0_IRQn
  #define USB_IRQHandler USB_LP_CAN_RX0_IRQHandler


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

Там же реализация портов ввода-вывода (pinmacro.h), тоже более удобная, чем HAL / CMSIS.
Даже HAL умеет несколько ног за раз конфигурировать.

Re: Литература для stm32

Ср май 18, 2022 13:48:25

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

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

Re: Литература для stm32

Ср май 18, 2022 14:17:32

Внутрисхемная отладка при этом ничем не поможет.
Всем помогает...
P.S. У F103 и F303 также отличается инициализация USB.
Это неправда.

Re: Литература для stm32

Ср май 18, 2022 18:14:43

полноценное написание на С++ резко поднимет планку вхождения и размер портянок будет тоже немалым.

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

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