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?