CMSIS, SPL, LL, HAL обзор особенностей наиболее популярных библиотек для микроконтроллеров STM32.
Вставка
- Опубліковано 25 кві 2020
- Детальный рассказ об особенностях и методах работы с популярными библиотеками для микроконтроллеров STM32. CMSIS, SPL, HAL.
Рассказывается об особенностях построения кода, доступности документации и личном опыте автора.
01:20 - библиотека CMSIS
19:26 - библиотека SPL
28:40 - библиотеки LL и HAL.
Отладочные платы с STM32:
s.click.aliexpress.com/e/_A2IVXm
s.click.aliexpress.com/e/_AnYSDe
Канал в телеграмм - t.me/vladimir_medintsev
Канал Яндекс.Дзен - zen.yandex.ru/vladimir_medintsev
Канал на RuTube - rutube.ru/channel/1797552/
Канал на UA-cam - / vladimirmedintsev
------------------------------------------
Если вы хотите поддержать автора канала номер карты Сбер:
2202-2023-2480-4008
------------------------------------------ - Наука та технологія
Благо - прошли те времена, когда людям для освоения электроники была доступна только одна библиотека, причём не ХАЛ или ЛЛ, а та, которая с девяти до шести с прерыванием на обед :)
Причём, не в каждом городе она была, и не в каждой можно было найти реально полезные книги :)
А как же полурабочие схемы ежемесячного журнала радио? Тогда я на эту "кучку" смотрел как на что-то особо ценное
@@BB-ti9bf Оно ещё работает?
@@user-kl4xm2yb7p что оно? Можно конкретнее сформулировать вопрос?
@@BB-ti9bf схемы "Радио"
@@user-kl4xm2yb7p Как-то захотелось собрать частотомер на МК по схеме из Радио, как раз в то время заинтересовался электроникой, купил детальки, вытравил плату кое-как, а через месяц в следующем номере вышло продолжение статьи с исправлением ошибки в дорожках платы. Долго ругался и забил болт на схемы из этого журнала.
Спасибо!!! Рассказываете интересно, доходчиво.
Благодарю! хоть у кого-то правильный подход к обучению, всё чётко, по делу.
Владимир, спасибо Вам за просвещение! Все четко и по делу.
Спасибо большое. Очень четко и доступно, все по полочкам. Для начинающего с STM, просто как карта сокровищ и не приходится биться лбом в стену, разюбираясь в незнакомых названиях.
Спасибо за ролик. Это именно те объяснения, что я и искал.
Спасибо!
**********
Грамотно, толково, в тему!
Спасибо Вам большое. Если бы не Вы было бы очень тяжко, продолжайте пожалуйста.
Спасибо! Такая информация для меня, чайника, очень ценна, ибо ее трудно узнавать "из книг".
Спасибо за структурированные знания.
Невероятно качественное видео! Спасибо.
Реально полезное видео!
Спасибо! Очень полезная информация!
Да это лучшее видео по STM.
Спасибо!!! Очень доступно и понятно все!!!
Благодарю за качественно поданный материал.
И полностью присоединяюсь - чтобы для каждой б""ди, которая злоупотребляет директивами компилятора для конфигурирования подключаемых библиотек, был отдельный особо сильно разогретый котел с кипящими фекалиями.
Вы - молодец... Держетесь
Спасибо за видео.
Благодарю за разъяснение, теперь понял
Очень достойное объяснение...
Содержательно и по делу
Thanks! Really great review! Puts all things on its own place. Easy to understand for non native russkogovoryashih. (I have no cyrillic keys).
Thanks a lot.
только начал знакомиться с стм32 процами, всегда работал (хобби) только с авр.
с первых строк нашел отличное применение хал и кубМХ - делаем конфиг, смотрим в какие регистры что пихает отладчиком - и делаем то же самое руками, но более оптимизировано. в итоге скорость работы кода ощутимо выше, размер кода и занятой памяти проца - ощутимо ниже.
но это легко все дается тогда, когда хорошо знаком с регистрами авр - здесь просто больше регистров и возможностей конфигураций.
ардуинщикам не понять :))
зы. спасибо за видео, есть очень хорошие мысли, советы и примеры.
Спасибо за видео. Я тоже придерживаюсь Вашего мнения. Зачастую периферию инициализирую кубом на hal, а потом уже работаю через смсис. Что касается излишних проверок: тут недавно с одним человеком общался, который считает себя гуру. Так он говорит, что много проверок - это хорошо и так должно быть, а если контроллер не успевает, то возьмите контроллер помощнее. Я считаю, что такой подход не всегда приемлем, потому что мощней МК - это цена, или мощней просто может и не быть контроллера.
Спасибо!
Только начал осваивать, спасибо за видео.
Если вы посмотрите на "блокировки" (критические секции), то обнаружите, что, по при отсутствии OS это пустые функции. Такие ф-ции будут соптимизированы компилятором (в релизной моде),, т.е. их вызова не будет.
Проверки типа assert также не компилируются в релизе.
Проверки на то, инициализирован ли тот или иной аппаратный модуль, не выглядят избыточными, т.к. его ведь можно и деинициализировать в процессе работы (например, для экономии питания).
Элементарные проверки "на вшивость" параметров и т.п. - да, их, скорее всего, следовало бы обертывать в условную компиляцию вроде #ifdef DEBUG.
Всякие прокладки в виде структур - плата за универсальность по отношению к разным типам контроллеров. М.б. их можно было бы получше причесать? Не настолько вник в структуру, чтобы утверждать, что это возможно. Ну и обратную совместимость никто не отменял; вполне возможно, что новые контроллеры плохо лезли в старые рамки, так что приходилось что=-то приделывать на костылях...
Документация и правда так себе, сгенерена зачастую автоматом (т.е. бесполезна), комменты, имеющиеся в исходниках, и которых по идее более-менее достаточно, в ней не отображаются.
Но в целом жить можно. Я уж не говорю про старые времена, когда вообще ничего подобного не было, ваяли все ручками на ассемблере с нуля. 🙂
Автор, отлично, просто, доступно, благодарю. Сам работаю с TI и NXP. Но пришлось сделать проект на STM32. Почитал форумы, и от таких противоречивых мнений потемнело в голове. На мой взгляд право имеют на жизнь *ВСЕ ТРИ БИБЛИОТЕКИ + LL* . Всё зависит от проекта + оптимизация. Никто не мешает смешивать в проекте использование. И это хороший подход. С автором не согласен по поводу SPL, т.к. её проще всего оптимизировать, ввиду её понимания, и меньшей загруженности перекрестными ссылками, калбэкфункциями и прочим. За 15 лет работы с контроллерами PIC, TI, NXP, Freescale в итоге остался на TI и NXP (в т.ч. freescale). Последние контроллеры подкупают тем, что они работают так, как от них этого ожидаешь, и библиотеки к ним такие-же, и оптимизация работы, отладка у последних очень хорошо организована. Но последние тоже пошли по типу HAL, и время выполнения такого кода значительно увеличилось. Оптимизация - вообще отдельная тема. Но, снова же, когда начал писать проект на HAL под ST - жопа началась при первом же использовании USB CAN UART, и начались танцы с бубном. И эти танцы с бубном решаются через изменение кода HAL, тот же USB, с буфером, задержкаи... У того же NXP - всё работает так, как ты от него ожидаешь. Купил VID, и пошло производство. *А вот с ST - это слезы, ругня с заказчиком, избирательная совместимость....* Как можно делать такие ошибки??? Алё, ST программеры!!!
NXP шикарны, абсолютно согласен.
Отлично, как всегда.
Я пропагандирую за LL . Как ни крути, а в ReferenceManual приходится смотреть, когда периферия не работает с первого раза (то есть всегда). А если все равно приходится разбираться в регистрах, то все преимущество HAL сходит на нет.
LL предоставляет человекопонятную обертку для работы непосредственно с регистрами, то есть функции именуются в большинстве случаев так, чтобы было понятно, чего они делают.
Самое главное: работа с периферией - это от силы процентов 5 от всего функционала прибора. Остальное - бизнес-логика. Поэтому один раз пишете свои обертки для выполнения нужных операций с периферией, и больше в них не заглядываете.
ну так один раз напиши на CMSIS, зачем тебе LL?
@@olegpetroff6186 , чтобы меньше букв набирать.
Ага. + в большинстве случаев, Достаточный уровень абстракции от регистров для переноса на другое железо т.е. можно и функции LL переписать под другое железо, если придется, фактически не затрагивая основной код
Ну а для сложных штук, типа USB можно и hal использовать
А программировать МК на серьезном уровне, без заглядывается в мануалы и регистры - это утопия (или Ардуина)
считаю что проверки в хал нужны и важны так как не каждый программист все так добротно проверяет.
Спасибо
Спасибо! Тумана стало чуточку меньше.
Скоро приду к вам на обучение)))
Нас этим не испугать.
Согласен с вашим подходом: писать на HAL и где надо оптимизировать на CMSIS. Так как я совсем недавно перешёл с AVR на STM32, данный подход очень понравился и упростил вход.
Если досконально изучить референс мануал, то cmsis окажется проще библиотек ардуино.
Отличное видео!
Я бы сказал прям хрестоматийное.
Здравые размышления. И подробно описали. Спасибо. Не нужно усложнять себе жизнь искусственно. : )
Гениальное видео !!!
Все расставлено по своим местам.
Главное, HAL опустили, после ассемблера на AVR он меня очень бесит.
Я топлю за CMSIS, да, дольше и труднее осваивать, но это дает огромное преимущество: постоянно куришь RM, в результате ты понимаешь, что делаешь, как, зачем и почему, и в случае каких-то затыков, быстро дакапываешься до причин. Ну и код компактный и очень быстрый. В случае, если ты знаешь только HAL, аббревиатура RM для тебя неизвестна, в случае какого затыка - ты приехал. По вопросу ускорения - во всех проектах всё нормально комментирую, и чаще всего просто беру готовые, отлаженные куски кода.
Я тоже топлю за cmsis, reference manual наше все, он понятен интуитивно, выучил одну периферию - выучил все! Кроме нюансов, разумеется. Полный контроль над каждым шагом процессора, никакого оверхеда, оптимизируй код как хочешь.
Раньше тоже так думал, оптимизация, полный контроль, это же круто.
Или вот тоже расточительство, оверхед: например, проект в компании - звуковая реклама на компьютерах i3, управляемая централизованно с сервера, код на Java. Казалось бы, ну это же смешно, зачем каждому магазину i3??! Почему не stm32 High destiny + ethernet + sd на 2Гб? А ответ прост.
Как только ты делаешь что-то круче чем I2C, I2S, SPI, UART, например ETHERNET или USB, CAN, MODBUS вот тут только начинает потраченное время перевешивать все на себя, а еще ладно бы запустить! Так еще и драйвер надо, колбеки на каждый пакет данных У-УХ!!
Никому не интересно платить за уже написанное, или сделанное, зачем платить команде программистов зарплату несколько месяцев, чтобы они писали драйвер, если производитель его и так даст бесплатно? А потом отлаживать? Встают вопросы, кто будет поднимать девопс под тестинг, кто будет все это тестировать? Писать тесты, кейсы?
Как сделать переносисмость, как организовать читаемость, расширяемость? И главное как поддерживать в актуальном состоянии? Почему самописный драйвер на bare-metal будет лучше бизнесу?
@@starterh1684 вы пишите чисто про свою ситуацию. Но у других людей она может быть иной. Производительность и чистота кода могут быть на первом месте. А если нужно шлёпать много и быстро, то да - тогда и подход другой.
@@vovanstarasov8212 при чем тут нашлепать. И вопрос не в людях. Человек написал про профессиональную разработку ПО. Там есть определенный цикл и свои требования без них никак. Вот если вы для себя лично пишете вот тогда другой разговор.
Использую только RM. Все структуры, регистры, абстракции описываю самостоятельно. самостоятельно. Нравится мне так. :-)
П.с. И ртос тоже самописная.
спасибо, очень грамотное и простое видео для "погружения в тему".
Когда думал что смогу достаточно быстро освоить микроконтроллер, никого не было рядом, чтобы подсказать, насколько я наивен...
Какой контроллер взять для опытов? Конечно самый дешевую и популярную плату bluepill с stm32F103c8. Кто ж знал, что с ней я соберу просто какое-то немереное количество багов... С hal и cmsis как то еще работает (не все проверял), но в mbed все через ж*, в ардуино (взял от безысходности) rtc с батаейкой тоже не захотел запускаться...
Итого для простого проектика необходимо изучить просто тонну информации... не говоря уже, что после ООП (delphi, php, phyton, js) Си вызывает уныние (длинные_предлинные_методы_потому_что _нет_namespace, инкапсуляции тоже нет)
По крупицам собираю информацию о программировании C++ embeded. Но информации как кот наплакал. Открытых библиотек нет. Итого, есть некоторые попытки написать свою абстракцию...
thnaks!
Могу предположить, что HAL писали разработчики, которые до этого в основном писали код для выполнения на ПК - очень большое кол-во верификаций это "привычка" делать правильно работая с динамически меняющимися данными. А работая с периферией, например, нам не нужно "на лету" переконфигурировать её, конфигурация выполняется на начальном уровне, в зависимости от проектирования железяки. Всё. Вот об этом разработчики HAL не подумали. Ну и естественно такой подход повлиял на скорость работы кода библиотеки, к сожалению.
В моих проектах приходится периодически переконфигурировать периферию налету, но решаю это все на дубовом cmsis, полет нормальный
Тут вот какое дело. Embedded предполагает что ваше устройство может быть залито эпоксидкой/бетоном/поднято на 60 метров на вышку. И в теории программист на цмсис может забыть или сознательно не включить какую-то проверку в код, пушо такая ситуация возникает раз в поколение. По закону подлости такая ситуация возникает в самый неподходящий момент. Что из этого следует? В библиотеку хал включаются все возможные проверки, и программист идет по ним как по чек-листу. Типа, я проверил тип, проверил деление на ноль, привел к флоату, проверил статус-код, обработал атлуп, и т.д. Смотрите на это с такой точки зрения.
@@00ASpid00 И что HAL не поможет а усугубит. Чем меньше разраб думает, тем хуже код. А иллюзия что волшебная либа все за него сделает, только вредит!
@@FastChargeIsFuture перечитай мой коммент еще раз, только внимательнее. Для того чтобы пользоваться HAL нужно знать доку на HAL, а лучше HAL и CMSIS. HAL упрощает и ускоряет разработку - это действие более высокого уровня абстракции и большей выразительности одной строки готового кода. Где там про ""меньше думать"?
@@00ASpid00 в результате все как с С#: создаём 3 поля ввода и кнопку +, код кнопки а=поле1 б=поле2 в=а+б, и значение поля 3=в. Компилируем. Вес программы 200 мб, при запуске отжирает гиг оперативки. Утрирую, но масштаб проблемы ясен, + опасный расслабон" можно индусить, там за меня все проверено". Последствия могут быть еще печальнее
Я, как человек работающий с STM32 микроконтролерами более 5-ти лет напишу свое мнение по этому поводу:
Для создания проекта и конфигурации периферии - HAL + CubeMX
Там где нужно "подправить" и оптимизировать - LL.
Для "дёрганья" пином например, достаточно использовать HAL_GPIO_WritePin()
В то же время при работе например с SPI-дисплеем данные ему лучше слать напрямую (SPI1->DR) чем через халовскую функцию
Есть настоящие маньяки, которые конфигурируют периферию посредством CMSIS работают исключительно "на регистрах". Я к таким ребятам не отношусь. Это уж слишком
Согласен с вами полностью. Единственное бывают случаи, когда хал не все функции переферии способны настроить, но единичные случаи.
Как вариант - CMSIS + Макросы, вот пример:
we.easyelectronics.ru/blog/STM32/3191.html
@Александр DMA не каждому дано, особенно новичкам
С spi лучше dma, если есть возможность
Скажу что LL лучше SPL потому хосты что там функции инлайновские а значит вы напрямую практически с регистрами работаете. Спасибо за видео
спецификатор инлайн не означает, что функция будет инлайниться (так же как и наоборот). Это происходит на усмотрение компилятора
@@Gregor812 все верно
Ничего не понял но очень интересно!!! Спасибо!!! Обязательно пересмотрю это видео как закрою свои пробелы!! Дай вам бог здоровья тоже!!
Конечно разные команды занимаются написанием библиотек HAL от того они и разные в зависимости от серии. Но не это плохо, плохо когда никто из них не занимается своевременным обновлением документации. Я пока не дошел до встречи с подобной проблемой, все еще впереди.
Давно писал проект тля stm32 и использовал CMSIS. И там были именно структуры и функции. Напрямую с регистрации я не работал. Все описание было в хедерах. А сами функции в сишных файлах. Может она передала в HAL конкчно. Нужно посмотреть как сейчас. Но ХАЛ тогда тоже был, но я выбрал смсис.
"можем в main.c написать" и где же он находится и как подключен к проекту? Если в нем писать с использованием CMSIS дефайнов и функции, то только они и скомпилируются? Без всяких HALов?
Обсуждение местоположения файла main.c серьезно?
Застрял на SPL, довольно удобная и понятная штука. Пробовал HAL и просто ужаснулся. Заглядываю в любую функцию и вижу что и та ещё состоит из кучи функций, целая матрёшка из функций, до работы с регистрами там ещё добраться надо. В SPL открываешь любую функцию и уже сразу же видишь непосредственную работу с регистрами. Ну думаю ещё LL посмотреть, ещё не пробовал, возможно подсяду на неё. Вообщем с SPL выруливал во многих вещах
Это уже не функции внутри функции, а макросы в основном. Они упрощают читаемость кода и не плохо обрабатываются на уровне компиляции.
Поддержу. Тоже почему-то показалось удобнее с LL работать, чем с HAL.
А можно ли сделать так, чтобы cubemx генерировал код не с Hal, a c cmsis?
Можно с LL, просто генерировать на Cmsis нет никакого смысла, можно и руками один единственный include прописать и cmsis подключен.
Что-то не заметил, что бы в HAL сделали поддержку RTOS. Как было "USE_RTOS should be 0 in the current HAL release" так и осталось. Или я что-то упускаю?
Скажите, а вы изучали CMSIS Driver? Концептуально выглядит очень интересно (если я все правильно понял) - универсальный API для периферии между микроконтроллерами разных фирм, поверх которой могут строиться драйверы какого-то оборудования. Концепция красивая. Но она существенно меньше распространена. Я лишь раз ее касался, она мне показалась еще более тяжелой, чем HAL (на примере пары простейших прошивок), и вообще похоже, что она вдохновлена Linux драйверами и POSIX.
Спасибо за Ваш труд. Очень интересно слушать. Как на сегодняшний день оцениваете de от st? Стоит ли переходить с кейла на куб ide? Уменя линукс.
Ну уже версия 1.03 пока развивают. Полноценно переходить еще тяжело т.к. детские болезни остались. Но на линуксе альтернатив не много. Пугает то, что ST не сильно много проектов доводит до конца.
Лучше возьмите связку Visual Studio Code + plugin-ы С/С++ и Cortex Debug + makefile и работа будет намного производительнее, чем в кубе.
Спасибо
@@chipsoft1 Что вы имеете ввиду под "намного производительнее"? у меня проект с кучей логики с freeRTOS, lwip и обработкой данных, проект полностью пересобирается за 15 сек. про простые правки или простые приложения вообще молчу 2- 4 сек. Куда быстрее? И в чем смысл выигрыша в 3-5 сек? Другое дело если вам удобнее перечисленные средства.
Большое спасибо. Очень полезный обзор. Отдельное спасибо за указания на полезные сопутствующие документы. Позвольте уточнить один вопрос. На 34:34 вы говорите о ситуации когда для добавления периферии "не хочется" перегенерировать проект CubeMX-ом. Правильно понимаю, что "не хочется" потому, что неизбежно затрутся оптимизированные вручную куски кода и их опять придется корректировать вручную, ведь пользовательский код сохраняется только в специально обозначенных местах? HAL-овский код конечно сильно пухлый и в критических местах его почти всегда приходится подменять оптимизированными вставками. А параллельная жизнь с CubeMX это как две хозяйки на одной кухне. Может ошибаюсь и есть стандартный механизм сосуществования, просто я не знаю? Или "не хочется" имеет и другие причины?
У меня есть несколько проектов которые писаны - переписаны и от традиционного кода там уже ничего не осталось. Т. е. их перегенерация в кубе вообще невозможна. С течением лет, там смесь из HAL и CMSIS. А как в этом случае добавить периферию? Честно говоря я вообще не сторонник постоянно задействовать куб. Обычно я просто создаю проект и подключаю периферию в кубе, но потом уже не возвращаюсь, а все необходимые изменения только руками.
@@VladimirMedintsev Ваш подход понятен, но проблема лежит настолько на поверхности, что просто почти наверняка кто-то уже пытался ее решить. Встретите что-нибудь на эту тему - поделитесь пожалуйста. Я конечно тоже поделюсь если будет чем. По идее, надо искать в руководстве по CubeMX. Они предусмотрели места для пользовательского кода, возможно есть и механизм переопределения (а не редактирования) функций инициализации или "замораживающие" дефайны. Вы полностью прочли это руководство или местами? Не встречался какой-то раздел с рекомендациями по применению?
Возможно это упоминалось, на камнях где мало флеш памяти, например 030f4, где ее 16кБ, уход от HAL в пользу чистого CMSIS оправдан на мой взгляд
11:00 - наконец-то хоть кто-то адекватно объяснил как это сделать!
Вы мне немного приоткрыли веки на ARM. Так то я любитель и довольствовался AVR и после Atmel Studio я даже диодом поморгать не мог, хотя частенько для AVR делал ассемблерные вставки и думал, ща Arm за день одолею, но...
Отличный обзор спасибо
Освоить STM32 не так уж и трудно :
1. Настроить тактовый модуль RCC.
2. Включить тактирование нужного модуля периферии.
3. Настроить GPIO под альтернативную функцию (если есть необхдимость)
4. Настроить нужную периферию.
5. Включить модуль.
Операции стандартны и универсальны, разница только в регистрах модулей. Да и то, все биты в регистрах как правило включать не потребуется - их так много из за универсальности применения, включаем только нужные.
если в кубе перегенерировать и добавить дополнительную периферию, то все предыдущих изменения будут выкинуты ?
Нет, они сохранятся.
Да нормально HAL написан, все как по учебнику, а учебники это Turbo Vision или Microsoft Fundation Classes. :), да что там библиотеки, сама Windows, точнее ее SDK так же написана..
так вот почему так тупит в win10 на моем стареньком компе!))
@@alexey-art-studio Ну я не знаю, насколько старенький ваш комп, но на буке 2008г., и даже 2006г.(одноядерный селерон) вполне себе можно нормально работать! Ну да, приходится некоторое время подождать, пока всё прогрузится и отработает телеметрия, но потом-то номана! А если ссд-шечку втулить и памяти добавить, то загрузка win10 занимает 28 сек, а не 3,5 минуты! 👍🤪
Очень интересно узнать Ваше мнение по поводу того, что же шустрее работает? Есть ли какие нюансы в оптимизации кода при использовании разных библиотек? Был один человек, который утверждал, что LowLayer экономичнее по размеру и шустрее. Но так ли это критично с Вашей точки зрения. Насколько я понял, именно HAL охватывает всю линейку микропроцессоров
Мое мнение очень простое. Если человек считает себя профессионалом, то он должен знать и HAL и LL и CMSIS. А при написании своего кода использовать ту библиотеку, которая соответствует проекту. Что это значит? Это значит, что за час работы программиста мы платим деньги. На библиотеке HAL он напишет код за сутки, а с использованием CMSIS аналогичный код за 2 недели. При этом возвращаясь к коду, он как профессионал должен видеть и его недостатки и если в коде есть фрагменты критичные к скорости, логично эти фрагменты написать на CMSIS. Только эти фрагменты кода, а никак не весь проект.
Это все-равно, что в строительстве можно отлить куб 10*10*10 метров из чистого бетона и потом при помощи наждачки вырезать из этого куба красивый дачный домик, а можно этот домик собрать из стандартных блоков и только в местах, где нужна красота, тщательно сделать красоту.
@@VladimirMedintsev А еще вставить светодиодики в куб.. Спасибо за Ваш ответ. Но я говорю с Вами не как профессионал, а как человек занимающийся этим на любительском уровне. Работал с SPL и CMSIS. Как по мне, HAL - тот же хрен, но только в профиль. В лучшем случае смог бы претендовать на джуна, но тем не менее сделал несколько , на мой взгляд, серьезных проектов
Вы бы не могли подсказать как сильно изменяются cmsis от контроллера к контроллеру. Допустим, f1xx серии и f3xx серии. Просто между f100 и f103 я не заметил сильных изменений. Конечно, я пишу небольшие программки. Возможно, в больших проектах это более заметно.
Да меняется же не библиотека. Меняется периферия самого МК. Вы можете взять reference manual на эти серии и сравнить. CMSIS только обслуживает то, что заложено в самом микроконтроллере. А вот внутри одной серии разумеется изменения минимальные.
@@VladimirMedintsev, спасибо я вас понял.
Кстати а никто вроде не утверждает, что HAL как-то облегчает работу с ОСРВ. Все равно во всех примерах пишут о использовании мьютексов и задач-ворот даже если используется HAL.
Прошу прощения за комментарий не по теме, подскажите литературу для изучения электроники. Знаю более менее основы, ТОЭ. Было бы интересно, по каким книгам вы учились этому делу.
Спасибо большое за видео, как всегда здорово)
Вы прям по больному. Нету на русском языке хорошей литературы. Государство это никак не субсидирует, а издательствам при таком низком спросе на техническую литературу не выгодно ее переводить.
@@VladimirMedintsev а если на английском что-то?
@Vlad Kosten Хотел бы поправить. "Искусство схемотехники" не годится для начинающих. Книга хороша когда ты уже знаешь матчасть и тебе нужно почитать про конкретные решения. А вот для изучения цифры есть очень хорошая книга - "ЦИФРОВАЯ СХЕМОТЕХНИКА И АРХИТЕКТУРА КОМПЬЮТЕРА" Харрис, Харрис.
Тоже заметил в F103 ногодрыг СMSIC - 3.4 мГц, SPL - 1.7 мГц, в HAL - 1,2 мГц, Жаль что SPL - забросили. Спасибо за уроки и труд. Понемногу начал грызть STM32H7 - жаль что только куб и только HAL . на CMSIC - почти листок кода - запуск кварц + шина + тактирование 2-3 блока.
Владимир не планируете уроки по H7 ?
Честно говоря я не делаю уроков. Это мой личный блог, я просто делаю видео на интересные мне темы. Никого не поучаю.
По H7 видео точно не будет. У меня нету задачи под этот камень. Будут видео про серии G0, L4 и про моего любимца WB55.
С последним я немного освоился и надо будет начинать его показывать.
Ну а на самом деле я просто делаю электронику под заказ и если в процессе мне кажется что-то интересным то появляется видео.
@@VladimirMedintsev Будем ждать от вас видео по wb55. Пока по нему мало что в инете есть. Да и самих камней не много.
Чисто теоретически скоро все всё-равно перейдут на С++ или джаву. Посмотрите на али, детские часы с экраном, аккумом и lte стоит 1000 руб. А работает на андройде.
@@valkoder_ex305 Не скажу за джаву, а чем вам С++ не нравится? Я на С++ и пишу, на тех же SPL, LL и HAL. Вот не вижу разницы между C и С++ кроме удобства. И компилятор не увидит, если хоть немного понимать что делаешь.
Только что написал по этой теме. Ногодрыг это дебилизм. Это зачем нужно? Что бы что? Ну хорошо, а если нужно дрыгать одновременно двумя ногами на разных портах? А тремя? А будут ли они одновременно дрыгаться? Или все таки со смещением. Где нужно дрыгать ногой с частотой 3.4Мгц нужно использовать уже другие подходы. И использовать другие схемные решения.
Как подключить fatfs в keil и настроить для spi без использования cubemix .В силу моей не опытности мне попадается крайне противоречивая информация в сети
Просто подключите заголовочный файл и пропишите функции чтения записи. Нет в этом ничего сложного. У fatfs хорошая справка.
@@VladimirMedintsev Спасибо ,буду пробовать
оптимизацию компиляции на максимум, и не будет много лишнего кода.
на мой взгляд, дальше хал переделают в ооп, запихнут всё в классы, и программисту будет еще проще.
По своему опыту знаю, что полагаться на компиляторную оптимизацию не следует. Чаще всего я сразу отключаю оптимизацию и стараюсь писать сам оптимальный код. Компилятор может такого наоптимизировать, что повыбрасывает куски кода, которые на его взгляд лишние. То есть без оптимизации устройство работает, а после оптимизации - нет. И еще хорошо, если это сразу выявляется. А то вдруг становится не рабочей редко используемая часть кода? Не, я за надежность и уверенность.
@@serjkp если после оптимизации компилятора не работает код, то код написан неверно. Вы хоть сравнивали в ассемблере код с оптимизацией и без неё? Компилятор делает такие оптимизации, которые вручную не сделать.
рекомендую для первого запуска в ноль оптимизацию, запустилось?, потом на максимум, и ловить реальные баги.
@@romanoffro5163 ну это как-бы секрет Полишенеля ;)
Не могу сообразить как работать с функцией библиотеки cmsis DSP arm_pid,куда записывать опорное значение?
Есть на сайте кейла прям целая статья на эту тему. www.keil.com/pack/doc/CMSIS/DSP/html/group__PID.html
Я создаю указатель на структуру, далее записываю в структуру значения коэффициентов , инициализирую, далее в цикле использую основную функцию ,пишу туда измеренное АЦП значение , функция возвращает мне результат. В какой элемент структуры я должен записывать опорное значение?
input sample это уже и есть ошибка. Опорное значение не нужно.
@@VladimirMedintsev , спасибо большое, сейчас попробую
Я столкнулся с переносимостью кода библиотеки LL для портов ввода/вывода при использовании микроконтроллеров STM32F407 и STM32F103. В них по разному реализованы дефайны портов ввода вывода
При использовании LL_GPIO_ResetOutputPin имеет внутри разную реализацию
1) STM32F407
__STATIC_INLINE void LL_GPIO_ResetOutputPin(GPIO_TypeDef *GPIOx, uint32_t PinMask)
{
WRITE_REG(GPIOx->BSRR, (PinMask > GPIO_PIN_MASK_POS) & 0x0000FFFFU);
}
2) STM32F103
__STATIC_INLINE void LL_GPIO_ResetOutputPin(GPIO_TypeDef *GPIOx, uint32_t PinMask)
{
WRITE_REG(GPIOx->BRR, (PinMask >> GPIO_PIN_MASK_POS) & 0x0000FFFFU);
}
Так например при вызове LL_GPIO_ResetOutputPin(GPIOB, 0x0F
Viacheslav Ohinskyi LL не переносится между разными семействами.
почему нет различия? inline добавили
Вопрос. Можно ли использовать библиотеку LL для работы с freertos? Или нужно использовать HAL так как она не блокирует ресурсы.
Можно
@@VladimirMedintsev А как "можно" если получается в CubeMX нельзя? Не переключается оно там для Lwip (который с FreeRTOS используется тут), для USB не переключается тоже. Тогда получается тут 2 библиотеки будут вместе использоваться? Тогда совсем бардак будет и больше памяти еще к тому же заберет? Еще хотел написать, что совсем недавно стал изучать активно STM32 и Ваш ролик помог. Спасибо Вам огромное человеческое.
@@ajdarseidzade688 Достаточно собрать проект без FreeRTOS с LL. А потом скачав FreeRTOS с официального сайта прикрутить ее руками. Там делов на несколько минут. Я не всегда все собираю кубом до самого конца. Он помогает сильно и я его использую, но без фанатизма.
@@VladimirMedintsev Понятно. Еще раз благодарен (и за совет не до конца все сделать кубом).
@@ajdarseidzade688 Я попытаюсь сделать небольшое видео и объяснить как я это делаю.
Это возможно не совсем правильно с точки зрения разработки, но я нашел для себя оптимальное решение.
41:54 Что значит: С последующим упрощением кода при необходимости?
Это на CMSIS упрощение?
Я хочу начать программирование мк. Хочу выучить как работает микроконтроллер, а не просто непонятные мне слова писать.
По описаниям библиотека CMSIS как раз то что мне нужно.
Не слишком ли она будет сложная для начинающих? Смогу ли я в ней разобраться?
Если вы поставили перед собой такую цель, то первое, что вам необходимо сделать это выучить язык Си. CMSIS это всего -лишь библиотека, которую можно легко понять всего за несколько часов, но для этого необходима база.
@@VladimirMedintsev Да, язык Си я учил последние пол года.
Я информацию лучше усваиваю в видео формате, но к сожалению в русскоязычном интернете на тему CMSIS очень мало структурированной информации.
А там не нужна структурированная информация. Вы подключаете к своему проекту библиотеку CMSIS в соответствии с тем какое ядро вы используете. Потом открываете Reference Manual на микроконтроллер и видите там описание регистров. Эти самые имена вам уже и даны в define библиотеки CMSIS. Все обзор закончен больше никакие знания не требуются.
а что с libopencm3? они конечно пишут что либа в стадии разработки, но вроде довольно не плоха и поддерживает большинство популярных мк далеко не только стм32
Я не знаю как отвечать на такие вопросы. Универсальная библиотека это я понимаю в работе с изображением или с сетью. Но когда речь идет о базовых функциях тут лично я не стал бы наводить бардак. Еще и по той причине, что универсальность это всегда жертвовать или функционалом или скоростью.
@@VladimirMedintsev но Вы же сами сказали что все мк работают на ядре cortex отсюда и универсальность.
@@curlybrace6694 Ядро и все что к нему относится это Cortex. Но вы забываете что периферия и память уже на усмотрение конкретного вендора, там и есть куча отличий в реализации даже в линейках одного производителя. Это отлично прослеживается у всех без исключения производителей. Т. к. конструкторская мысль она не стоит на месте. По этой причине попытка универсальности гораздо хуже даже самодельных библиотек. Но если хочется потратить время в пустую. Не смею мешать.
Вот тоже поддержу за openlibcm3. Даже если посмотреть github, то приличное количество толковых opensourse проектов использует именно эту либу.
Честно говоря, opencm3 - такое же дерьмо, как и кал-SPL. Разве что, дерьмо не столь откровенное (быдлокода там намного меньше). Но все равно совать ассерты в функции (да и вообще вызывать функции на каждый чих) - это идиотизм. Единственный вменяемый способ сделать "библиотечку" для С - использовать гору макросов и static inline функций. Но лучше написать кучу шаблонов на С++, тогда на выходе получите лучше, чем если б сами на асме писали, а код будет компактный и понятный.
Владимир, я правильно понимаю, что библиотека LL так же развивается как и HAL ?
Да, они обновляются одномоментно. Горубо говоря LL это замена SPL.
@@VladimirMedintsev Я ещё заметил, что не для всей периферии доступен LL, например для того же CAN, он не доступен в кубе..
Но могу выделить плюс в пользу HAL, что он мне помог вникнуть в работу CAN драйвера, правда я потратил пару недель, но теперь я смог бы обойтись и без него, общаясь напрямую с регистрами, но не вижу в этом смысла, т.к в любом случае, нужно писать много строк кода, множество структур, функций, что бы инициализировать управлять и мониторить те же ошибки, а в случае с HAL, всё упрощается, пару кликов и куб с генерирует скелет кода и сэкономит много времени и вероятность совершить ошибку, т.е много строк кода будут в любом случае написаны, путь и на свой лад, но время займёт много...
А какие то куски, где что то не устраивает в реализации HAL, можно переписать и уже обращаться напрямую к регистрам.
Хотя, конечно HAL занимает много места, но учитывая стоимость камней и их разнообразия, место остаётся вагон и маленькая тележка)
Это моё, скромное мнение..
@@smart_electrics_il Спасибо за такое мнение. Я, как новичок в STM32, прислушиваюсь ко всем мнениям и делаю выводы.
Под F4 похоже с HAL и LL всё грустно: документация не обновлялась с 2017 года. LL не для всех блоков. Например USB только как HAL, однако файл с данным блоком называется stm32f4xx_ll_usb, в котором код HAL, но в документации о нём не слова, поскольку она описывает файл stm32f4xx_hal_hcd. Поэтому непонятно, зачем нужен первый файл, да и использование LL таким образом ограничено. Да и сам CUBE может создать инециализацию USB только под HAL.
Документация в виде комментариев в самих файлах библиотеки вполне достаточна. Там есть все основные моменты.
Давно написал собственный HAL, что позволяет использовать контроллеры разных производителей. Но это связано с зоопарком устройств на работе. Если бы проекты небыли взаимосвязаны, наверное пользовался бы CMSIS.
Ну, вот я пришёл к микроконтроллерам начав с stm8, где использование стандартных функций сильно сжирает флэш, а первоначальное конфигурирование регистров периферии не очень-то требует проверки, ну Вы же понимаете, что за значение пихаете в регистр. Потом всё плавно, хотя нет, не очень перетекло к stm32, и, освоив работу с регистрами на прямую, воспользовался CMSIS. А стоит ли разбираться с HAL теперь. И нет, не соглашусь, что код плохо копируем. На мой взгляд это не так. Куда большая проблема, - отсутствие внятного комментария при обращении к нему спустя длительное время :) Комментарий кажется не очень-то нужным, когда всё ещё в процессе... а вот потом....
Мне кажется, что assert всегда учитывает флаги компиляции, и может быть пропущен, если это требуется. По крайней мере нормальные разработчики так бы и сделали.
Такой вопрос возник, почему такое повальное увлечение МК от STM, если у TI всё более качественно сделано?
Большая доступность, хорошая цена. Производитель в европе, а не америка, лучше логистика. Хорошая поддержка. Гарантия доступности. Ну короче это комплексный вопрос. И уж чего я точно не стал бы использовами это микроконтроллеры от TI. Есть гораздо более интересные производители но менее доступные.
@@VladimirMedintsev уже заказывал не одну тысячу stm32, у всех производство или Китай или Малайзия. В условиях нынешней глобализации разницы нет где производятся электронные компоненты, заказать можно все и доставка по времени будет одинакова как для одного так и другого производителя.
@@VladimirMedintsev Почему" не стал бы использовами это микроконтроллеры от TI"?
"более интересные производители" это какие?
@@chipsoft1 Порой дело не в доставке как таковой, а в некоторых санкционных действиях. Мне без разницы где конкретно заливают в пластик плавленный песок, но часто с производителем (разработчиком) физически находящимся в европе договориться проще чем с ребятами из-за океана.
@@user-ot5js1gy5j Ну например NXP.
Ничего не понял. Как это можно не блокировать доступ к периферии? Если вы не заблокируете доступ к абстракции так 2 потока могут безконтрольно туда навалить своих данных или еще хуже переконфигурировать перефирию в процессе операции. Тут просто другого выхода нет кроме как блокировка. Вы же сами сказали что HAL ориентирован на FreeRTOS.
Если кратко, то блокировка это не единственный метод обеспечения потокобезопасности. А реализация блокировки в HAL далеко не самая эффективная.
На мою думку STM не вистачає репозиторію як у Arduino: у мене є вихідні, а готових бібліотек-прикладів нема, але є бажання прикрутити до MCU RFID: з чого почати та й взагалі де той початок не зрозуміло. Можна покопатися в Arduino IDE, знайти та пофіксити файли заголовків але значно простіше було якби в STM32Cube IDE була кнопка "створити проект Arduino" (щось таке).
Adam Ibragimov да ладно, для СТМ библиотек не меньше чем для Ардуино
Самое ужасное, что есть в библиотеке HAL - это первые четыре символа в названии каждой функции. Серьезно, неужели нельзя было это как-то иначе сделать?
Связка CMSIS и LL... Пока самое лучшее для начинающий и профессионалов
Ага, а на западе пишут на HAL, вот наивные да?
@@VladimirMedintsev скорее всего все зависит от типа проекта .... Это конечно не агрумент с моей стороны... У меня товарищ в Праге он работает в фирме что разрабатывает топливораздаточные колонки ... И говорит у них stm32 пишут только на cmsis.. даже без ll ( но справедливости ради пишут это все в keil) , мой личный опыт ... Показал что для меня HAL... Не самый понятный ( ... А вот cmsis или ll действительно дают больше возможностей.... Мне кажется что все же лучше писать на cmsis
Если человек является профессионалом то он должен писать с использованием того инструмента, который позволяет получить требуемое качество за требуемое время. И если какая-то задача может быть решена за 2 часа на HAL, то использовать в этой задаче CMSIS и тратить большее время - просто глупо. Во всём мире является хорошей практикой программирование с использованием библиотек абстракций и только в том месте, где требуется оптимизация кода или его ускорение необходимо применять переход на низкий уровень вплоть до ассемблерных вставок. Тезис о том что HAL мне не понятен или понятен здесь абсолютно не является аргументом. Спор о том с использованием каких библиотек программировать является полностью глупым. Весь мир выбирает тот инструмент который лучше для проекта и только в нашей стране точнее в русскоговорящем сегменте интернета попадаются люди которые утверждают абсолютно противоположное.
Представьте себе, есть заказ. Заказчик платит за него условные 10.000 руб. Я могу сделать эту работу на библиотеке HAL за 2 часа или я могу это сделать на библиотеке cmsis за 10 часов. При прочих равных условиях если мне не требуется супер оптимизация какую библиотеку нужно выбрать?
@@VladimirMedintsev ну это больше вопрос предпочтений .... более надежнее и оптимизированней код получается на LL это некий компромисс между CMSIS и HALL . да на простой проект не буду спорить ,на CMSIS тот еще вид извращений (знаю по себе )... LL решает те-же самые задачи что и HAL но намного качественнее + у LL меньше проблем с реализацией периферии чем у HAL. да и те проблемы что есть у LL легко (относительно ) решаются
Зачем говорить, что CMSIS плохо читаемый, когда вместо "GPIOA->BSRR=0001U" можно писать "GPIOA->BSRR |= GPIO_BSRR_BS0" и получается прекрасно читаемый код ( сходу понятно, что нулевой пин мы выставили в единицу/ Bit Set 0).
Про переносимость кода Вы тоже умолчали, что, к примеру, написав инициализацию тактирования к одному МК она подойдёт и к большинству других контроллеров той же линейки и даже старших ядер с небольшими поправками. И так касаемо почти всей периферии, за исключением GPIO(на старых МК она разнится с новыми) ну это с тем, с чем я столкнулся.
Ctrl+c и Ctrl+v, пожалуйста пользуйтесь.
Не считаю себя профессионалом, наоборот я только учусь, многого не знаю, просто высказал своё мнение.
Недосмотрел ролик до конца, бросил его посмотрев часть про CMSIS, не очень интересно смотреть на такое узколобое разъяснение библиотек и пропаганду HAL, уж простите, если где-то неправ.
Если помнить что такое bsrr, и хз как это переносить на другую архитектуру, например. Все таки GPIOsetPin (пример абстрактный) - намного понятнее
Это аббревиатура, такая же как USART. Человеку с юартом не работавшему будет и USART непонятно и GPIO.
BSRR = Bit Set Reset Register.
Искренне надеюсь, что вы не подписчик этого канала, а просто случайно перешли по ссылке.
@@VladimirMedintsev аргументировано
Вы учитесь в правильном направлении!
Ого, в большинстве времени использовать HAL. Я на нём вообще ничего сложнее hello world'а сделать не могу: получается ардуинщина какая-то
Это видео не совсем про CMSIS. CMSIS не стандартизует обращение к GPIO и ADC
В смысле не стандартизует? Ничего, что в состав CMSIS входит DSP?
@@VladimirMedintsev Хотел написать не DSP, а ADC. CMSIS не стандартизирует работу с ADC.
Еще интереснее. К ADC (по вашим словам не стандартизует), а вот к DAC стандартизует? А к DMA? Или не стандартизует только к GPIO и ADC?
@@VladimirMedintsev. на сайте арма перечислено все, что станадртизирует CMSIS. DMA, ADC, DAC, GPIO там нет. Прямую ссылку не могу дать, ютуб ее удаляет
Спасибо!
Жопа кругом, теперь понятно окончательно!
Как вариант - CMSIS + Макросы, вот пример:
we.easyelectronics.ru/blog/STM32/3191.html (Удобная настройка GPIO портов)
Кто бы написал.... "Настоящих буйных мало - вот и нету вожаков."
Спасибо любопытная статья.
@@VladimirMedintsev да, осталось дело за малым ;)
у SPL были екземплы, а у HALа нет нифига
Как это нет экземплов? Я чуть со стула не упал... Их сотни, лежат в каталоге репозитории куба-мх
Блин, хоть кто то объясняет нормально эту муть
Ну блин вы просто не поняли в чем смысл дефайнов при конфигурации в HAL. Смысл то в том что для каждой серии контроллера свой заголовочный файл. Мало того вам нужно посмотреть а какой хидер нужо прописать, а там еще можно не тот символ поставить. Куда проще просто раскоментить уже написанную строку. И допустим если вы хотите перепрыгнуть на другую серию вам придется в ручную все эти хидеры править. Плюс таким образом они ввели единую точку конфигурации, а не прыгать по разным файлам. Короче то что это не понятно зачем это не правда, цель была действительно абстрагироваться от серии.
Я однозначно за HAL. И я не понимаю людей которым не хватает скорости работы HAL. Лично мне сложно представить ситуацию в которой бы я правил библиотеку HAL из за нехватки производительности... И не совсем понятно чем вас не устраивает проверка assert param, она ведь проверяется на этапе сборки проекта компилятором, в суммой программе она не выполняется...
Все от задач зависит, вот у меня была задача, создавать пачки импульсов , с проамируемой длиной импульса паузой между импульсами и количество импульсов, задача была что бы можно было от 1 микросекунды до 100 микросекунд, вот теперь попробуй это сделать на хале на 103 контроллере ))) Сразу скажу не выйдет, на смисе удалось выжать от 2 микросекунд. на хале и близко не подойдеш к таким параметрам. Да можно взять более скоростной контроллер, вот только где их взять сей час по вменяемой цене, а вот 103 валяется куча.
Автору , пожалуйста используйте правильное произношение: не "Дэ эм А" , а "Ди Эм Эй". Не "ГеПэ И О" , а "Джи Пи Ай йО". А так все нормально.
Я буду использовать те выражения, которые мне удобны и привычны.
Чувствую себя тупым..
ХАЛ - сила, ЦМСИС - могила. Халу масти, цмсису по пасти.
Спасибо