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

В очередной раз хочется что-то улучшить, попробовал взять от жизни от Куба и 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, но прочитано на другом форуме)

подпишусь на тему.

Я тоже, но только если HAL годится не только для Keil. Я CooCos-ник.

Насколько я вижу, в пакете от ST есть HAL только для EWARM, MDK-ARM, TrueSTUDIO. Уже не только Кейл.

Не это не отменяет того факта, что на каждый чих вызывается невстраиваемая функция. И действие, которое сводится к записи одного числа в один регистр выливается в выделение месте на стеке, заполнение структуры и вызов функции. Таким образом маленькая быстрая программа вдруг становится большой и медленной. Кроме того, загаживание исходника бесконечным заполнением структур не улучшает его читаемость.

На самом деле даже при работе через регистры в большинстве случаев каждый сам пишет свой HAL, в соответствии со своими представлениями о прекрасном. То есть идея HAL сама по себе-то правильная, а вот реализация снова (первый раз - SPL) не удалась.

P.S. обычно в такие религиозные споры не вмешиваюсь, но ваш вопрос составлен аргументированно, поэтому ответил.

Cube и его HAL никак не связаны с Keil, они созданы разными фирмами. В Cube можно создать проект под разные IDE. У Keil есть свое творение - RTE.
Мигать диодом можно и в Cube. Но я пробовал USB CDC сделать, и оно, грубо говоря, не заработало. И погрузиться в дебри функций до полного (просветления) дна мне не удалось. Теперь потихонечку плыву сам, по регистрам. У Keil USB CDC для STM32F3xx тоже создать невозможно, не хватает драйвера. И уже больше года тянется.

Что касается CMSIS, то это творение ARM. Ему доверяю (но проверяю), пользуюсь.

Еще один минус HAL в голову пришел- время жизни (поддержки со стороны ST).
ST уже поменял свою SPL на HAL, надолго ли. И уже, вроде бы, не делают HAL для стареньких STM32F1 (если интернет не врет). Что они на замену HAL придумают послезавтра и какие камни объявят устаревшими- мне не сообщали. Неприятно, так как весь накопленный опыт использования HAL может быть невостребован. А вот CMSIS как был так и продолжает существовать как основа всего этого зоопарка. Хм.



Вот я и думаю: понимаю, что использование функций HAL и CMSIS в одном проекте на уровне пользовательского кода как-то "необычно", но можно просто попробовать все оборачивать в функции. Написал на HAL- не заработало или заработало не так как нужно, тогда написал свою HAL- обертку для данного действия. Так сказать "MyHAL библиотека", а от STM_HAL остается только идея и куча дефайнов и определений структур для вызова.
Ну и таки да, конечно, инлайны и дефайны хороши, опять же- решаемо в узких местах заменой "HAL_**()" на "MyHAL_**()" по мере надобности, иди просто полным переписыванием модуля без использования в конкретном месте HAL-овского оверхеда. Но есть надежда, что кое-что переписывать не понадобится.
Все зависит от количества проблем в HAL, время отладки становится менее предсказуемым.

Как всегда- истина где-то посередине.

Нафиг-нафиг это HAL.
В случае "что-то пошло не так" разобраться в этом наслоении абстракций довольно сложно.
Судя по слухам "в HAL используется Keil RTOS", "HAL поддерживается только в Keil" и т.д., это не только моя проблема :-)

Библиотеки уровня "подрыгать ножкой" и "включить ШИМ" пишутся под конкретные требования на коленке за полчаса.
Заодно и виновный во всех косяках доступен :-)


PS что присутствующие подразумевают под CMSIS, я не понял. Есть CMSIS core - набор функций/макросов для доступа к ядру и его периферии (NVIC, например). Это есть, и это удобно.
А идея "все производители чипов напишут единообразный CMSIS Driver API" не взлетела. Я, во всяком случае, не видел.
http://www.arm.com/products/processors/cor...ce-standard.php

Ну поменял и что? Проекты, сделанные на SPL от этого хуже не стали. Для F1 Cube давно вышел.
http://www.st.com/web/catalog/tools/FM147/...LN1897/PF260820
Про "опыт использования HAL" звучит смешно. Опыт в знаниях периферии семейства и особенностей её работы. А через какую прослойку ей рулить - дело пятнадцатое.
Вся эта история "готовые библиотеки vs самописное руление битиками" напоминает очередной виток "ASM vs C".

в кубе докопаться до дна - сложнее, приходится верить на слово
куб вполне можно нужно было делать на spl
сейчас же весь наработанный код улетел в корзину
точно так поступал атмель, ну и всем известно, что с ним стало

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

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

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

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

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

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

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

HAL прекрасно работает с IAR, и, на мой взгляд, весьма полезная деталь - позволяет быстро сконфигурить всю периферию и удобно с ней работать.

Недостатки - большая избыточность кода из-за его универсальности - дикое количество ветвлений. Для примера сосчитал соотношение в одном критическом месте - порядка 1000 к 1. Но это не является проблемой, отдельные критические места просто заменяются более оптимальными функциями сдернутыми с исходников HAL. Нарисовать их с нуля не получится - периферия у ST описана совершенно погано и без необходимых подробностей - и вот они, как раз, и вытаскиваются из кода HAL.

Есть там и кривоватые решения, например при передаче по RS через DMA все хорошо, но HAL ожидает завершение передачи последнего байта поллингом - и завешивает все на уровне прерывания на время передачи байта. Но это сразу видно по коду и легко обходится.

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

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

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

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


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