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

[-AZ-]

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

[makc]

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

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

[halfdoom]

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

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

[makc]

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

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

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

Само определение HAL (hardware abstraction layer) указывает на его слабость.
Как можно абстрагировать hardware если мы выбираем его за его уникальность?

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

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

Т.е. как минимум в некотрых случаях HAL в принципе будет неприемлем если хотим использовать периферию инновационным способом.
Каким бы образом вы HAL не применяли он однозначно вас изолирует от кучи полезной функциональности конкретной периферии.

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

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