Хотел собрать мнения специалистов, на примере STM32CubeMX.
Все-таки стоит ли применять подобные вещи или это для домохозяек?
При написании больших проектов на чистых С, С++ падает скорость разработки, но пока проверишь используемые ветки HAL, получается тоже не быстро.
Есть ли подводные камни и сложности "ручной" сборки например RTOS, в Cube довольно быстро, но качество неизвестно.
Может применение библиотек производителей, пусть не совсем хороших, не так уж плохо?
Очень интересно мнение тех, кто имеет практический опыт по этой теме.

Как всегда на любой вопрос нельзя дать однозначного ответа. Всё зависит от ваших условий и вашего опыта. Я имею опыт использования библиотеки CMSIS для микроконтроллеров серии LPC. Мы решили в своё время её использовать как раз для упрощения работы, и, частично, полагали, что она избавит нас от рутины. Отчасти так и произошло. Но в каждой версии CMSIS'а я находит ошибки (I2C, DMA, SSP). Как правило, функционал этих библиотек никогда не соответствовал нашим требованиям (возможность работы с ОС, по прерываниям и т.п.). Да и самое обидное было искать ошибки в библиотеке, цель которое - избаватить нас от этого процесса. Но опыт мне дал возможность подумать, и сделать вывод: что сейчас я бы начал писать свой драйвер под каждый модуль микроконтроллера. Опираясь только на даташит, юзер мануал и т.п. Вполне возможно заглядывал бы в библиотеки как в референс-дизайн. Всё-таки люди там тоже не одну собаку съели, и некоторые моменты могут быть хорошо разжёваны. Поэтому смотрите сами. Если у вас опыт совсем небольшой, берите готовую библиотеку, ищите в ней ошибке по ходу работы, исправляйте под свои нужды. Если опыта достаточно, я полагаю вы бы не стали задавать этот вопрос. Но если опыта недостаточно, а времени - вагон с тележкой, то можете попробывать и подход, к которому я пришёл)))

Давно уже, гуру рекомендовали не использовать чужие либы, я так пошел.
Времени прошло много, да именно так как вы говорите, пишу свои драйвера на каждую периферию с полным пониманием регистров.
Но почему решил собрать актуальное мнение на сегодняшний день, сложность проектов растет, кол-во типов контролеров тоже, переносимость кода в общем-то получается никакая. И довольно сильно увеличивается время разработки. Хочется понять чем сегодня "дышит" мир гуру. Может все-таки время asm проходит...
Вопрос относится к разработкам в рамках производства, а не частных поделках.

Это быть не должно. Я использую Си++ при разработке драйверов. Хотя это не важно. Но все драйвера имеют более-менее одинаковый интерфейс. Поэтому для софта не важно, работаете вы часами внутри микроконтроллера, или это часы на i2c висят. Или это часы вообще с sntp сервера.

Оно прошло ещё лет 15 назад.

А вот тут вы зря. Это вовсе не показатель качества кода. Я работаю на производстве, если что Но и для домашних "поделок" не пишу левой пяткой через среднее ухо

Документация ко всем STM32, с которыми мне приходилось иметь дело не лезет ни в какие ворота - совершенно неоднозначная, написана не по-английски(по-видимому, французский или итальянский) и перевод ужасный. В таком случая Куб помогает понять, о чем же хотела сказать документация. Еще одно достойное применение Куба для электриков - быстро написать примитивный проверочный код для проверки железа/периферии. Для создания профессионального продукта его тоже "можно" использовать, если вас и ваших клиентов надежность интересует в последнюю очередь.
Сейчас молодые коллеги поднимут громкий крик о достоинствах этого индийского продукта, но, в конце концов, " думайте сами, решайте сами - иметь или не иметь..."

Люто минусую. За 10+ лет работы с STM всего пару раз столкнулся с неоднозначностью в документации, причём в мелочах. У писателей английский не родной язык, но текст весьма приличный. В общем, не надо напраслину возводить.

Вот, ключевые слова - если вас и ваших клиентов надежность интересует-
Значит все-таки получается не стоит рисковать с применением индусских библиотек.
Соответственно для увеличения скорости разработок необходимо увеличит штат программистов для реализации собственных драйверов(либо аутсорсинг),
основанных на полном понимании железа и регистров, а не бездумным тыканием в Cube.

И крайне желательно, нанять в этот штат программистов повыше квалификацией, чем упомянутые индусы. Если на все это есть деньги и время, то конечно лучше не использовать куб.

Возможно не стоит содержать свой штат и писать драйвера которые кто то уже точно делал, а наверное под каждую задачу искать исполнителя на постоянной основе. Так будет ещё быстрее.

Не совсем понял, а что значит не содержать свой штат, но искать кого-то на постоянной основе? В смысле стороннего исполнителя на постоянной основе?

Это субъективное мнение, имею в виду обеспечивать постоянной работой одного или двух проверенных аутсорсеров.
Аутсорсеров потому что как правило не удается найти человека в штат с необходимым опытом, практика показывает, самородки раскиданы по стране, соответственно удаленка.

Категорически против CubeMX. Уж лучше SPL - намного лучше. А если его (SPL) подправить так вообще конфета получается.

С каждым днём на форуме всё больше вопросов по Cube, HAL, SPL и т.п.
По нужности применения - вопрос дискуссионный.
Но вот подумать над тем, чтобы выделить всё это добро в отдельную ветку, надо.
На мой взгляд дискуссии о том, какой параметр и в какой функции что обозначает и для чего применяется, уже не имеет никакого отношения к микроконтроллерам.
Пусть уж люди, которые сделали выбор в пользу использования этих инструментов варятся в собственном соку.

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

применяю HAL, код из куба только для первого ознакомления изредка

По крайней мере никто не будет спорить что CubeMx с HAL гораздо более информативней и наглядней, чем старая SPL, что даёт преимущество не только бывалым специалистам, но и в особенности начинающим разработчикам, позволяя сэкономить кучу времени и сил, да, может он не такой гибкий как SPL, даже не так, мне на ум приходит сравнение куба с ножом, хорошим ножом, а SPL уже ближе к своего рода скальпелю, выбор того или иного исключительно зависит от ваших нужд

Но как разработчик, вы отвечаете за код чем то...
Как, например, можно ручаться за куски чужого кода.
Я так понимаю 2 варианта:
1 - это сидеть перепроверять используемые функции HAL.
2 - за это время написать свои функции.

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

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

Ну камни определяются исходя из конкретного проекта, где то ST, где то TI, где то EFM и т.д. абсолютно нельзя сказать что взял ST для всех проектов и все, некоторые задачи нельзя на них реализовать, приходится брать другие...

Мой скромный совет - не пытайтесь покрыть все контролеры, как бык овцу, написанием генерик драйверов под все камни. И под TI, и под EFM есть свои SPLи.

Да вот собственно с SPL ST проблем не было, как у других производителей не скажу, через регистры делал.

Рекомендую сравнить с другой аналогичной документацией.
"Если других туфель не видел — наши вот такие! Если других машин не видел — «Запорожец» вот такой! И живи!" М.М. Жванецкий.

Не надо грязи. Всё видел. Ну да, у этих покорявее, но документация вполне рабочая. А мсье изволит эстетствовать.

Почему же никто не будет спорить? Как по мне, так это полная чушь. HAL - это жуткое нагромождение макросов, которое в принципе не рассчитано на то, что его кто-то будет читать и понимать.
SPL по сравнению с HAL - это просто образец понятности.

Равняться надо на лучшее, а желающие могут спать на потолке...

Использую куб как визуализацию распиновки и первичный более-менее рабочий код инициализации. Затем не оптимальные процедуры переписываю так, как мне удобнее.
Да и там этого кода совсем немного, чтобы изучить самостоятельно.

Интересен вопрос автора выше: "Как, например, можно ручаться за куски чужого кода." - бывают ошибки и в документации на проц, и всякие эррата обновляются со временем...
А как-то же люди пишут под винду/линукс....

+5 копеек...
перевожу на русский:
- кол-во форм заготовок растёт, стамеской не успеваю быстро. скорость не рыночная.
- время стамесок проходит...


постулат 1 = можно и на азме и в байт кодах писать с УЧЁТОМ ПЕРЕНОСИМОСТИ. Было бы желание, опыт, умение...
постулат 2 = язык написания есть ВЫБОР РЕШЕНИЯ под КОНКРЕТНУЮ задачу, условия и больше ничего... у каждого языка есть плюсы и есть минусы ессесвенно.


удачи вам
(круглый)

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

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

-AZ-. Мне кажется, не стоит задавать таких вопросов, особенно на форуме. Вы сами должны решить, что Вам применять, и как. Вы всякий раз получите широкий ассортимент ответов от "Ура!" до "Долой!" и все равно останетесь перед личным выбором.

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

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

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

А не лучше ли инициализацию подглядывать в SPL ?
Или она уже совсем заброшена?

Полностью согласен.
Мне вообще кажется, что изначально не совсем верно был задан вопрос - причем тут CubeMX если речь в основном шла про HAL?

Сам CubeMX - отличная программа, очень помогает при проектировании схемы, особенно на новом процессоре - раскидывание ножек, распределение периферии, выбор и оптимизация клоков - все это с Кубом делать на порядки проще чем без него!
Да, скажут - "возьми даташит и по нему сделай клоки".
Можно.
Но я искренне завидую тем, кто способен держать в памяти все возможные комбинации множителей/делителей и частот.
Особенно, когда надо выполнить ряд условий - например иметь и частоту ядра определенную, и обеспчить USB/SDIO требуемым клоком, и уарнты обеспечить, и I2S, и наружу через МСО выдать то что нужно.

Недавно коллеги на работе белали новый проект, на базе моего старого. Использовали другой процессор. И все было классно, пока не выяснилось, что в новом проце нет делителя /3 на выводе МСО, а в старом проце - был.
Кварц стоит 24Мгц и надо на МСО иметь или 8, или 16, или 32. Так периферия требует.
А уже и плата была готова!

HAL'ом конечно лучше не пользоваться в "боевых" проектах, максимум использовать инициализацию, да и то не всегда.
Но вполне можно им пользоваться в тестовых "прикидках", чисто для ускорения времени, особенно для второстепенных вещей.
(ну вот как-то надо было поиграться с I2S, попутно с некоторым ногодрыгом и УАРТОм. I2S и написали все руками, а настройки ногодрыга и уарта - Куб сгенерил с HALом.)

P.S. стало уже ругательным слово "калокуб", но мы же не виноваты что у STM сейчас все с прставкой "Cube - вон не так давно вышел STMCube Programmer - ни малейшего отношения не имеющий ни к Кубу, ни к Халу!
Это просто STLInk Utility+FlashLoader+DfuSe, собранные в одной программе. (И что самое ценое - поддерждивающиее новые процессоры, в отличие от древнего Flash Loaderа.)

Почему у вас растет количестов типов контроллеров? Вот в чем вопрос. Почему нельзя остановиться на одном семействе?

Вспомогательные тулсы от ST, NXP, TI, Microchip... конечно нужны, поскольку выполняют роль интерактивных иллюстраций.
А стандартные доки не имеют нормальных иллюстраций.
Чужие либы нужны обязательно, вам большую часть времени стоит посвятить анализу и интеграции чужих либ.
Но функции периферии (HAL, драйвера или как их там еще называют ...) стоит писать самому.
Они по объему короткие, но сильнее всего влияют на качество реального времени.

Ни один HAL не может использовать 100% все возможности периферии.
Забавно, что юзеры HAL выбирают чипы именно по характеристикам периферии,
а потом в HAL-е не могут найти как эту периферию эффективно использовать.

Архитектура HAL-ов ST создана так чтобы покрыть всех представителей семейства сразу. Поэтому тексты избыточны и непроходимы.
А вот скажем среда от Micrium генерит строго целевые HAL-ы, заточенные только на вами выбранный чип, ничего лишнего.
Чем бесплатнее HAL, тем он больше будет подстроен под его создателей, чем под его пользователей.

Вы совершенно правы, речь в разрезе HAL драйверов периферии, которые необходимо писать самим.
Меня пытались убедить что различные доки по чипам это зло) взял Cube и Hal и погнал шлепать код не вникая в железо, регистры.
Вот и думаю, то ли отставать от темы начинаю и теряю кучу времени на свои драйвера, то ли все больше появляется людей которые не хотят этим забивать голову, но тогда как у них что то работает ?(наверно).
Интегрированные библиотеки (не драйвера) конечно нет смысла переписывать и изобретать велосипед, лучше их хорошо изучить и тестировать различными методами, как в общем-то и основной код.

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

В середине прошлого года на сайте ST про SPL все упоминания были "устаревшая", "не рекомендованная для новых проектов", "смотрите HAL".
Сейчас я смотрю, видимо после массивной критики пользователей, все эти ярлыки убрали. Стало "Active".
Более того, в последние версии CubeMX добавили поддержку SPL, можно выбрать для каждого периф.модуля, что будет применяться для генерации кода, HAL или SPL.


А по вопросу топика, то тут почитаешь коллег, и складывается впечатление, что у всех проекты в жестком реалтайме, где каждую мкс нужно экономить, + у всех времени вагоны
У меня все проекты неспешные, с быстродействием человеческой реакции, т.е. 10-ки мс. Но их много накопилось еще живых, несколько десятков. Со старых времен на ПИКах и АВРках, последних много на MSP430, а сейчас переползаем на STM32. И все это нужно поддерживать. Времени на разработку новых приборов много нет, зато потом можно не спеша, понемножку, все улучшать и доделывать. Поэтому по-быстрому генериться проект в CubeMX и делается его копия рядом.
Дальше один проект рабочий, а другой CubeMX-ный. Поскольку для меня семейство STM32 новое, наработок нет, то каждый следующий периферийный блок генерится в Кубе и переносится в рабочий проект, где уже просматриваются все HALовские функции и если они не слишком ужасны, то оставляются, если никак не лезут в мою концепцию, то пишется свое. Все макросы и прочие наслоения хидеров оставляю, ибо там так все завязано в один узел, что нужно либо все выбрасывать (а туда и CMSIS вплетен), либо все оставлять.
В результате примерно половину HALовских функций нормально применяю. А приборы по 10-15 лет выпускаются, будет еще время подчистить код

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

Лично мое скромное мнение по этому вопросу: важно не только что именно применяется (какая библиотека), но и каким образом. Как построен процесс интеграции генерируемых/данных исходников, тестирование готового продукта и т.п. Ибо итоговый результат определяется не столько используемыми библиотеками/языками программирования, а тем кто их использует и как. HAL, как и любая готовая библиотека, позволяет несколько сэкономить время при аккуратном и грамотном подходе. При этом, переходя в практическую плоскость, было бы логичным организовать репозиторий на том же github с исправлениями тех проблем, которые оригинальные разработчики почему-то обходят стороной.

Не путайте теплое с мягким... кубик генерит или LL или HAL.
LL и SPL не одно и то же.

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

Само определение HAL (hardware abstraction layer) указывает на его слабость.
Как можно абстрагировать hardware если мы выбираем его за его уникальность?
Т.е. как минимум в некотрых случаях HAL в принципе будет неприемлем если хотим использовать периферию инновационным способом.
Каким бы образом вы HAL не применяли он однозначно вас изолирует от кучи полезной функциональности конкретной периферии.

В embedded изоляцию от железа надо ограничивать BSP (board support package) и PSP (platform support package)
Но даже эти вещи слишком абстрагированы от железа.
Изоляция в виде HAL удобна видимо начинающим и неопытным программистам.
Поскольку у них от мануалов по периферии в несколько тысяч страниц возникают нехорошие чувства. Их можно понять.
По опыту скажу, чтобы приспособиться под информационную экосистему производитекля (структура, состав, стиль мануалов и т.д.) нужно несколько лет.
У кого нет столько времени, понятно, альтенативы HAL-у не имеет.

Когда я стал очень давно применять RTOS я понял, что ни один HAL и даже BSP мне не подходят.
На уровне HAL нигде не используются сервисы RTOS. Максимум могут предложить самому написать свои функции синхронизации.
Отсутствие асинхронности на уровне доступа к периферии рушит всю идеологию RTOS и принципы планирования.

Иногда BSP очень сильно интегрирован в RTOS, например так обстоит в MQX.
Тогда мне пришлось большими усилями вырвать из лап BSP управление DMA чтобы использовать его так как мне надо.
Но еще много периферии осталось под властью BSP: USB, SDIO, Ethernet
Но только потому что у них у всех есть собственный механизм DMA.

Да, вы правы, мельком посмотрел в новой версии на эти галочки, сам пока не разбирался и не применял.

А по теме топика понравились комментарии AlexandrY, очень толковые и красиво сформулированные, хоть в статью оформляй. Поддерживаю!

Расскажите, пожалуйста, как вы обращаетесь к железу в своём коде? Всё-равно же какая-то абстракция есть? Ну, например, в коде терминала (консоли) вы же не обращаетесь к регистру данных последовательного порта или ethernet'а напрямую?
И как вы поступите, если вам код нужно портировать с kinetis на stm32?

Дла реализации промышленного проекта STM32F769BI & LCD screen 7" 800x480 FreeRTOS, STemWin, FATFS, SDIO, FMC 32 bit, LTDC 24 bit, DMA2D, 3xUART, I2C, CAN, RTC, QSPI, ETM, SPI, FS USB - испоьзовался CubeMX для конфигурации всей периферии и настройки FreeRTOS и FATFS - все работает отлично, и самое главное радуют затраты времени на конфигурацию и последующие ремапы выводов.

Вы хотите сказать, что разрабатываете прошивки исключительно с полным соблюдением MISRA C? Включая их статический анализатор?

Если нет, то любой код содержит ошибки. При исполнении любого кода что-то может пойти не так (некорректная обработка внешних условий и исключительных ситуаций). Поэтому я не вижу почему HAL нельзя использовать в проектах, где цена ошибки велика и быстродействие критично (профилировку и оптимизацию никто не отменял. Я пытаюсь сказать, что в случае правильного использования HAL будет хорошо работать правило 20/80 (закон Парето). А потом, правильно его применив, потратить оставшееся время (80%) на отладку и тонкую доводку. Возможно, с патчами в коде HAL.





Есть типовые периферийный блоки для решения вполне стандартных задач (таймеры, контроллеры SPI/I2C и т.п.). Да, они отличаются функциональными особенностями и регистрами, но в целом они очень похожи и с прикладной точки зрения вполне могут быть взаимозаменяемы. Поэтому я не вижу тут никакой слабости.

Более того, HAL для разных семейств SMT32 немного отличается по API. Это можно расценить, как попытку уйти от слабости.



Пардон, но я нигде не утверждал, что HAL покрывает возможности периферии на 100%. Также не говорил, что не нужно знать возможности и особенности этой периферии. Это все знать нужно, но на это и есть процесс тонкой доводки после того, как большая часть функционала была реализована.

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

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

Абстракция как бы должна вести к лаконичности, но API HAL-ов наоборот раздуто до неприличия.
Это от того, что им еще хотят придать видимость универсальности.
Но что небоевые инженеры в офисе ST могут знать об универсальности?

Вот когда говорят, что успешно применили HAL, там с GUI от segger-а, UART-ами, SPI, Ethernet и проч., то я почти не сомневаюсь что сделано это было на базе демок от ST.
Малейшее отклонение от демки в сторону увеличения пропукной способности, более жесткого реального времени, увеличения количества одновременно работающих интерфейсов и следует разочарование.
Поскольку оказывается, что надо штудировать сразу два огромных пакета документов: мануал по программированию семейства и мануал на HAL.

Как только вы патчите HAL, то становитесь его заложником.
На новые версии уже так просто не сможете перейти и принять участие во всеобщем веселье.
Но остается необходимость детально изучать кучу абсолютно избыточных текстов вылавливая в них скрытые зависимости чтобы просто сделать минимальные изменения.

Между тем на самом деле функции работы с периферией можно сделать очень короткими и предельно прозрачными.
Например, работа с АЦП в моем пректе универсального модуля

Ну а переход на другую платформу меня меньше всего заботит.
Я уже перешел с STM32 на Kinetis и не вижу поводов переходить обратно.
Я ж сравнивал их не один год и дружил я с ST много лет. Все прикладное интресное для ST с легкостью переносится на Kinetis, но вот сказать обратное нельзя.

Мне всегда нравятся ваши подробные и развёрнутые ответы! Прочел. Надо обдумать))))

Речь, большей частью, идет об оптимальности кода и в ней HAL проигрывает по всем статьям специализированному коду. А инспекция кода HAL, при его использовании, необходима, т.к. требуется выловить все побочные эффекты каждого вызова API.



Здесь можно углубиться в непролазные дебри обсуждения каждой функции с избыточным кодом, поэтому просто отмечу - мы уже пытались базировать свой код на HAL и результат заметно хуже по времени разработки, объему бинарника и быстродействию. Но, повторюсь, у нас задачи далеки от отправки десяти байт через GSM.




И это тоже. Для сравнения, один из наших "умников" (в хорошем смысле слова), унифицировал внутренний API до такой степени, что прикладная задача практически не видит разницы между применяемыми МК семейства С2000 (TI) и STM32F3. И да, совсем забыл - все библиотеки и обертки написаны на C++ с очень жесткой типизацией всего чего только можно, поэтому даже выставить бит в одном регистре пользуясь дефайном от другого, весьма проблематично.