STM32СubeMX и подобные Опции

[-AZ-]

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

[makc]

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

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

[AlexandrY]

важно не только что именно применяется (какая библиотека), но и каким образом.

Само определение 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.

[haker_fox]

У кого нет столько времени, понятно, альтенативы HAL-у не имеет.

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

[AlexandrY]

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

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

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

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

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

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

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

[Эдди]

работа с АЦП в моем пректе универсального модуля

Все хорошо, кроме двух грубых ошибок: 1) комментарии на русском языке, 2) использование "магических чисел" вместо макросов или перечислений.

[mantech]

Все хорошо, кроме двух грубых ошибок: 1) комментарии на русском языке

И что в этом плохого?

Дла реализации промышленного проекта 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 - все работает отлично, и самое главное радуют затраты времени на конфигурацию и последующие ремапы выводов.

На счет затрат по времени - согласен, а вот на счет остального - не факт. Как-то делал пробный проект на MQX и их демо, взятых за основу. Так вот, все вроде работало, я обрадовался, пока не решил "поиграться" с усб-флешкой, воткнул ее, вытащил, и так раза 3, почему 3? Потому что на 4й все зависло намертво... Вот и решил потом все писать сам.

[Эдди]

И что в этом плохого?

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

// а отписывающиеся тут в пользу [censored], похоже, кроме мигания светодиодов и "примеров от ST" ничего не делали, иначе поняли бы, что быстрей написать "на голом CMSIS", чем ковыряться в кривом коде кала...

[Quasar]

// а отписывающиеся тут в пользу [censored], похоже, кроме мигания светодиодов и "примеров от ST" ничего не делали, иначе поняли бы, что быстрей написать "на голом CMSIS", чем ковыряться в кривом коде кала...

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

Например, у меня есть ряд проектов, в которых на STM32F4 крутится DMR стек (стек цифровой радиосвязи) с вокодером, TCP/IP стек и USB в режиме виртуального COM порта. Все это крутится на одной из популярных легковесных ОС. DMR стек реализовывал я, совместно с еще одним разработчиком - специалистом по ЦОС и помехоустойчивому кодированию. От процессора необходима реализация базовых функция, типа принять поток по SPI/I2S/I2C, встроенный EMAC, таймеры, USB phy. СТшный HAL с вышеописанными функциями вполне справляется. Основная сложность таких проектов - в прикладной логике (стеки протоколов, обработка сигналов и т.п.), и деньги платятся за это. Если не стоит задачи жесткой оптимизации (на диком масс-продашене такое вполне возможно), колупаться с изучением конкретного камня не имеет никакого смысла, ну будет софтовый оверхед, ну выберете камень посильнее и все. Словить какие-то тяжелые баги, например в HAL'овском драйвере SPI или I2C достаточно тяжело, оно либо работает, либо нет. Намного важнее, сосредоточиться на тех задачах, которые собственно и требуют решения в ходе разработки. А судя по тому, как все тут переживают за код в HAL'е, который, как и любой другой код, естественно имеет ряд недостатков, создается впечатление, что люди дальше дерганья GPIO и работе с SPI не уходят в своих трудах.

От HAL очевидно придется уйти только тем, у кого:
1) Дикая серия и камень взят впритык, ибо на больших сериях каждый доллар на счету;
2) Если у вас жесткие требования по потреблению.

[pitt]

Есть мнение, что те, кто отрицательно пишет про HAL не умеют работать с чужым кодом или очень любят охотится на блох там, где нужно охотиться на медведя.
...
От HAL очевидно придется уйти только тем, у кого:
1) Дикая серия и камень взят впритык, ибо на больших сериях каждый доллар на счету;
2) Если у вас жесткие требования по потреблению.

А еще тогда, когда надо чтобы работало всегда, например, safety critical. Так, к слову, некоторые очень любят исполхзовать Linux, чтобы, например, лампочкой поморгать... Выбор инструментария и ответственность эа результаты его применение целиком лежит на разработчике. Нельзя запретить желающим писать с кубическим акцентом...

[Quasar]

А еще тогда, когда надо чтобы работало всегда, например, safety critical. Так, к слову, некоторые очень любят исполхзовать Linux, чтобы, например, лампочкой поморгать... Выбор инструментария и ответственность эа результаты его применение целиком лежит на разработчике. Нельзя запретить желающим писать с кубическим акцентом...

А лампочкой поморгать это safety critical? Как вообще лампочка связана с safety critical? Вообще удивительно какой бардак у многих в голове.

Ok, зайдем с другой стороны, как вы подтверждаете safety critical? Ваш софт проходит сертификацию на DO-178B, например, или вы просто по "пацанский зуб даете"?

Какой-нибудь управляемый L2 коммутатор D-link или soho роутер от них же, ни разу не лампочкой поморгать, но в нем скорее всего обычный линукс. И там это решение вполне оправдано, так как там не стоит задачи в спец. сертификации. А вот на бортовом вычислителе боинга 737 вы линукс не встретите, и не потому, что он сильно сложнее, а потому, что сделав вычислитель на линукс вы упашетесь его сертифицировать и доказывать что оно надежно. Потому что в настоящем safety critical надо доказывать, а не просто трындеть.

Если проект подразумевает safety critical с соответствующей сертификацией, то он подразумевает и соответствующее количество трудочасов и денег на него. В рамках этого проекта, естественно, разумно выделить группу для написания надежной замены ST'шному HAL'у. С которой потом, можно будет пройти все сертификации. А когда у вас задача спроектировать железку без доп. требований по надежности, а вы все равно тратите время на перепись HAL'а, полагая (почему-то?), что ваш быдло код лучше "индусского", вы просто разбазариваете время и деньги, отвлекаясь от основной задачи.