STM32: регистровый CMSIS или высокоуровневый HAL ?, ПРосто выскажите аргументы за или против, пожалуйста, без холивара Опции

[Ruslan1]

Здравствуйте,

В очередной раз хочется что-то улучшить, попробовал взять от жизни от Куба и STM программистов побольше. Попробовал автоматом сгенерированный проект- На нужном мне (незнакомом до этого) STM32F0 камне поставить FreeRTOS и в одной из задач помигать светодиодом- заняло примерно пару часов вместе с установкой новой версии кейла и Куба.
Причем править ничего не пришлось, ну дописал в задачу функцию "HAL_GPIO_TogglePin(GPIOA,GPIO_PIN_5);" для моргания и все. Причем задача тоже была создана из конфигуратора Куба.

Поспрашивал окружающих программеров, почему же все-таки CMSIS применяют? Были высказаны причины:
1. HAL заточен под Кейл и не работает с другими компиляторами.
2. если переходить от STM на другие, то придется переписывать, а CMSIS- он стандарт

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

Найденные мной в интернете недостатки HAL (как и его предшественника, SPL):
1. Избыточность сгенерированного кода. Начитался в интернете про "бесконечные перепроверки", но в самом коде HAL увидел, что они зависят от дефайна "USE_FULL_ASSERT. Может, те кто пишет про перепроверки просто не знают о возможности их отключения?
Ну и в HAL многое через структуры делается, это как бы много лишнего кода. Но как по мне- совсем не минус при отладке, я структуры очень люблю, они мне и при использовании камней с считанными сотнями байт RAM не мешали, не то что с килобайтами.
2. Сложность и многоуровневость (и засчет этого низкое быстродействие) критических частей- например, при использовании прерываний. Вроде бы через коллбеки и так далеее и получается не просто, а наоборот запутанно.
3. Непереносимость. А что, CMSIS переносим между изготовителями и править в регистрах ничего не нужно?
4. Наличие большого количества глюков в HAL. Мда?
5. неполный доступ к ресурсам. Ну так всегда можно уйти на нижний уровень.

Из личного, достоинства HAL:
1. скорость написания работающего кода
2. малый размер пользовательской части программы
3. читабельность.


Так за что же не любят HAL?
Я не новичок в программировании МК, но не понимаю, почему нужно по старинке в каждый регистр лезть при выполнении стандартных процедур (CMSIS), а не пользоваться высокоуровневой оберткой этого же действа (HAL)?
Прошли те времена, когда на асме писали и биты (не байты!) экономили, железо подешевело, зато себестоимость времени разработчика увеличилась.

Ну и, опять же, почему я не могу типичную часть программы сделать на HAL (применив, по сути, готовое), а критические участки выполнить на низкоуровневом CMSIS ? почему CMSIS и HAL противопоставляют друг другу, как по мне- так они отлично сочетаются.
Любое HAL-действо может быть переписано на низкий уровень, но только когда это нужно, а не вся программа сразу на CMSIS, или я не прав?


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

Upd: позволю процитировать, очень близко к тому что я думаю (автор- hd44780, но прочитано на другом форуме)

CMSIS - это не HAL, это та же прямая работа с регистрами. И если Вы через год начнёте читать, то CMSIS Вас не спасёт от чтения ДШ.
Поэтому вопрос переформулируется как SPL или регистры.
А это уже религия, по поводу которой вылита бездонная бочка разного холивара и даже личных оскорблений и всё равно каждый при своём.

Поэтому пишите на чём хотите. Как Вам удобнее.
Лично я люблю SPL. С её тормозами столкнулся всего лишь раз. Ну и переписал этот кусочек на регистрах . Но это не повод "огульно охаивать" весь SPL.
Багов в ней пока не находил.
Ещё, за что ругают SPL, это большой объём результирующего кода. Да, это так. Согласен. Но если моя прошивка занимает 200 кил из мегабайта или двух флэша проца, то почему нет?

Это как девушки - кому брюнетки, кому блондинки. А кому и те и те .

[Integro]

1. HAL заточен под Кейл и не работает с другими компиляторами.

Работает также с IAR, Keil4/5, TrueStudio

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

Ну и стоит понимать следующие вещи:
- В новых библиотеках могут быть баги. Но у ST хорошая поддержка за полтора года, кол-во багов снизилось практически до нуля, как мне кажется (Я говорю о коде библиотек, не об интерфейсе Cude)
- Библиотеки обладают избыточностью кода
- Библиотеки ускоряют процес разработки (с учетом того, что вы знакомы с библиотекой)

И я бы порекомендовал не слушать коменты подобного рода:

Нафиг-нафиг это HAL.

В любом случае будет полезно нагрузить мозг освоением чего либо нового, в данном случае HAL.

[_Pasha]

В любом случае будет полезно нагрузить мозг освоением чего либо нового, в данном случае HAL.

Для чего? Нечем заняться? Лучше быть ближе к даташиту чем непонятно к чему.

Мне лично куб нужен для удобного обозрения цоколевки.
Кстати, бесчисленные xml оттуда можно вытянуть и приспособить для собственного кодогенератора.
Но это тоже больше из области фантастики. xml->json|dict->python

[Огурцов]

xml->json|dict->python

xml->c#->c->bin
или вообще
xml->c#->c#

[Ruslan1]

Ну что же, немного прояснил кое-что для себя
1. Не могу работать в структуре Куба. хочу структуру файлов, которую раньше использовал и привык
2. Посмотрел USART. мда, как-то они намутили с проверками и коллбеками, через эту цепь вызовов даже в прерывании продираться нужно, причем вызовы с аргументами. А у меня есть интерфейсы, где таймауты жестко заданы (например, sdi-12, или modbus-rtu ), или прерывания от внешних сигналов. И даже если я засуну свой код в предусмотренное для этого место в исходнике, то вызов HAL_UART_IRQHandler() никуда не денется. А если его удалить, то при следующей генерации кода он опять возникнет.
3. См выше. Тефаль Куб & HAL думают за нас. это хорошо, но не очень. Они, конечно, молодцы, но нужно извращаться, если мне нужна только часть из их кода, а остальное чтобы просто не мешало.

В-общем, автогенератор проекта не нравится точно. Автогенератор хорош, но только для последующего copy-paste в мой проект его кусков кода.

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

Недостатки - большая избыточность кода из-за его универсальности - дикое количество ветвлений. Для примера сосчитал соотношение в одном критическом месте - порядка 1000 к 1

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