[Ruslan1 16]

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

 

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

 

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

[murmur 0]

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

[ШСА 0]

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

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

[Ruslan1 16]

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

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

[Сергей Борщ 119]

1. Избыточность сгенерированного кода. Начитался в интернете про "бесконечные перепроверки", но в самом коде HAL увидел, что они зависят от дефайна "USE_FULL_ASSERT. Может, те кто пишет про перепроверки просто не знают о возможности их отключения?

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

 

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

 

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

[ViKo 1]

Cube и его HAL никак не связаны с Keil, они созданы разными фирмами. В Cube можно создать проект под разные IDE. У Keil есть свое творение - RTE.

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

 

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

[Ruslan1 16]

Еще один минус HAL в голову пришел- время жизни (поддержки со стороны ST).

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

 

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

 

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

 

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

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

Все зависит от количества проблем в HAL, время отладки становится менее предсказуемым.

 

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

[esaulenka 5]

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

В случае "что-то пошло не так" разобраться в этом наслоении абстракций довольно сложно.

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

 

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

Заодно и виновный во всех косяках доступен :-)

 

 

PS что присутствующие подразумевают под CMSIS, я не понял. Есть CMSIS core - набор функций/макросов для доступа к ядру и его периферии (NVIC, например). Это есть, и это удобно.

А идея "все производители чипов напишут единообразный CMSIS Driver API" не взлетела. Я, во всяком случае, не видел.

http://www.arm.com/products/processors/cor...ce-standard.php

 

[Corvus 1]

Еще один минус HAL в голову пришел- время жизни (поддержки со стороны ST).

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

 

Ну поменял и что? Проекты, сделанные на SPL от этого хуже не стали. Для F1 Cube давно вышел.

http://www.st.com/web/catalog/tools/FM147/...LN1897/PF260820

Про "опыт использования HAL" звучит смешно. Опыт в знаниях периферии семейства и особенностей её работы. А через какую прослойку ей рулить - дело пятнадцатое.

Вся эта история "готовые библиотеки vs самописное руление битиками" напоминает очередной виток "ASM vs C". :rolleyes:

[VCucumber 0]

в кубе докопаться до дна - сложнее, приходится верить на слово

куб вполне можно нужно было делать на spl

сейчас же весь наработанный код улетел в корзину

точно так поступал атмель, ну и всем известно, что с ним стало

 

[Integro 0]

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

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

 

А поводу выбора, что пользовать, здесь нужно принимать решение в зависимости от проекта.

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

 

Ну и стоит понимать следующие вещи:

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

- Библиотеки обладают избыточностью кода

- Библиотеки ускоряют процес разработки (с учетом того, что вы знакомы с библиотекой)

 

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

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

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

 

[_Pasha 0]

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

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

 

Мне лично куб нужен для удобного обозрения цоколевки.

Кстати, бесчисленные xml оттуда можно вытянуть и приспособить для собственного кодогенератора.

Но это тоже больше из области фантастики. xml->json|dict->python

[rudy_b 1]

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

 

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

 

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

[VCucumber 0]

xml->json|dict->python

xml->c#->c->bin

или вообще

xml->c#->c#

 

[Ruslan1 16]

Ну что же, немного прояснил кое-что для себя

1. Не могу работать в структуре Куба. хочу структуру файлов, которую раньше использовал и привык

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

3. См выше. Тефаль Куб & HAL думают за нас. это хорошо, но не очень. Они, конечно, молодцы, но нужно извращаться, если мне нужна только часть из их кода, а остальное чтобы просто не мешало.

 

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

 

Сам HAL- при грамотном использовании имеет право на жизнь.

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

Если даже не использовать, то, как минимум, полезно посмотреть как оно там в HAL сделано.

 

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

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