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 кил из мегабайта или двух флэша проца, то почему нет?

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

[smalcom]

Много написано, прочитал по диагонали, потому могу и повторить чьти-то слоа - извините уж.

ТС, вы вот пишите в заголовке

пожалуйста, без холивара

а в теме что за хрень:

Прошли те времена, когда на асме писали и биты (не байты!) экономили, железо подешевело, зато себестоимость времени разработчика увеличилась.

не надо себя преподносить за всех. и цитату привели и обсосано везде: разные есть применения. если вы не получаете по жопке за лишний использованный байт, то у вас работа отличается от того кто получает по этой самой жопке. достали уже "медийщики" мнящие себя эмбеддеррами. используйте рпи. они вообще дешевле грязи и мощи поболе чем в стм32.

И по сути: HAL или SPL?
Баги есть и там, и там. Кишки ковырять можно и там, и там. Странно, что опытные разработчики(а может "опытные") всё чаще задают такой вот вопрос. Разработчик выбирает не библиотечку, а парадигму, которой он будет
придерживаться. Если вы будете ковырять кишки HAL, то он вам не нужен, он не для этого написан. Разработчик может использовать много всяких инструментов. Тот же редактор или IDE. Вы же не спрашиваете на форуме
какой редактор лучше: kwrite или gedit? Это тупо. Вы читаете документацию, сравниваете возможности или, если информации слишком много(как редакторов под линукс), то спрашиваете: подскажите редактор с подсветкой
выделенной части слова. Профессиональные навыки - это тоже как маленький организм в вашем организме: идейная направленность, приемлемые парадигмы, освоенные приёмы, направление упоротости или "религиозная"
предвзятость. Обычно у опытного разработчика не встаёт вопрос, что именно использовать. Если перефразировать немного, то получится вот такое содержание подобных тем:

опытный: годами работал молотком, вот понравилось работать кувалдой. но другие говорят, что это ламерство и ей не надо привыкать работать. подскажите чем лучше забить гвоздь.
тролль1: головой.
гуру1: я уже 30 лет аккуратно вставляю гвозди руками. это медленно, но надёжно: не повреждается структура дерева, нет дополнительных затрат энергии на взмахи.
гуру2: достали малыши. какого размера гвоздь? куда вбивать? какие допустимые вибрационные нагрузки?
и т.д. и т.п.

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

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

И, естественно, приведу примеры.
1. Попросили человека написать программу для МК. Он был из типа малоопытный консерватор. Т.е. на асме, с использованием сторонних библиотек, за которые он не несёт ответственности. Т.е. из-за того, что человек
не захотел переучиться на ЯВУ, надо было ждать, а потом проверять - правильно ли он написал умножение uint32 и int32.
2. Мне необходимо было ускорить некий код под AMD64: эмуляция TLB другого процессора. После мытарств: D, C++, C, решено было сделать на асме. Потрачено два дня на изучения особенностей AMD64 и написание
кода. Здесь следует заметить, что у меня были эти два дня, чётко выделенные на подобное исследование. В большинстве случаев у разработчика нет этого времени и он вынужден быть консерватором по неволе. И
результат - написал так же как "gcc -O2". С точки зрения продвижения проекта - два дня в трубу. Но в личном опыте появилась строка - не надо пихать асм куда надо и не надо, если ты хорошо владеешь ЯВУ. Т.е.
не используй чужой опыт и инструмент, если недостаточно хорошо им владеешь. Сначала научись одинаково владеть обоими инструментами и при постановке задачи будешь знать какой использовать.
3. Вот тут, кстати, раскрою ещё и вопрос поддержки. Нужен был USB-Audio для stm32f4. STM сказал адью и запилил это уже в кубе. Программа, в которую это надо добавить уже есть, т.е. под кубы и халы переписывать
готовую программу в сжатые сроки никто не будет. Берём USB из кубохала, перепиливаем под SPL. И ещё оптимизируем работу с буферами вывода. В данном случае произошло смешение парадигм, но с уклонном в
собственную.
4. И пример полного принятия чужой парадигмы(для баланса)) ). Это когда после WinThreads или POSIX Threads ты пробуешь Qt'шные слоты. Но сама идея так делать хороша и это очень удобно(там где уместно). И данная
парадигма принимается, без консервативного пихания потоков на любой чих.

холивар? ну вы сами начали.