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

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

Советую для начала взять libopencm3, а потом потихоньку свое сварганить, т.к. любая библиотека — это жиробасище то еще... Скажем, в реализации "полуаппаратного" 1-wire я местами напрямую регистрами инициализировал таймеры и ПДП, т.к. библиотека давала слишком большие задержки.

А что, в HAL есть модули для "полуаппаратного" 1-wire?

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

Если за что и хаять HAL, то только не за результирующий объем кода.

Да, спасибо за напоминание о "третьем пути", как-то не подумал посмотреть еще какие-то библиотеки. на первый взгляд- довольно прозрачно. И как замечательно документировано!

это когда cross-module?
у меня вроде как три раза пробегает...

Извините, а libopencm3 под кейлом будет работать?
Они пишут "The most heavily tested toolchain is "gcc-arm-embedded" .... Other toolchains should work, but have not been nearly as well tested."

При чем здесь объем кода? А ничего, что тупо все эти "джампы" и манипуляции с регистрами при выполнении уймы функций, занимает довольно-таки значительное время?


Без понятия, я вообще не в курсе, что такое "кейл". Ни разу в жизни не видел.
Пользуюсь geany в качестве редактора (хоть geany и IDE), компиляю make'ом (gcc-none-eabi), прошиваю через бутлоадер при помощи stm32flash (тем же make'ом), отлаживаю через USB (CDC).

Буквально на прошлой неделе в соседней теме обсуждали портирование на IAR.
Если вдумчиво подойти, должно нормально взлететь.

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

Да, я вчера ночью ту тему по диагонали прочитал- там в 90% сообщений обсуждают неотносящиеся к либе вопросы, так что зерна (обсуждения портирования) я не заметил, уже сегодня утром там задал тот же вопрос.
Спасибо за наводку, перечитаю еще раз.

Жесть, "компиляю make'ом (gcc-none-eabi)" и после этого восклицать "все эти "джампы" и манипуляции....занимает довольно-таки значительное время?"

А в курсе что только из-за GCC вы убиваете почти половину производительности процессора?

В проекте с цифровой обработкой звука применяется компилятор arm-none-eabi (GCC с launchpad.net). Рассматривая критические места в дизассемблере, пришел к выводу, что лучше соптимизировать не сильно получится - т.е. в коде учитывается конвеер, не мгновенное вычисление функция плавающей точки сопроцессором...
SPL/HAL не использую, но многократную вложенность функций моих библиотек компилятор прекрасно инлайнит.

Сообщение отредактировал Genadi Zawidowski - Nov 5 2015, 07:48

А в курсе, что подобные слова надо либо предварять фразой "мне Рабинович по телефону напел", либо приводить результаты тестирования?

Будет. Но стартап от Кейла

Кто такой бред выдумал?

про HAL

в драйвере CAN-а HAL_UNLOCK не вызывается, если все три мейлбокса заняты (типа, индусский код?). после этого драйвер встает (по крайней мере пришлось исправить код HAL, чтобы заработало)

в драйвере UART при запуске приема и передачи по DMA - иногда данные терялись (ORE) - скорость 115к у проца ~50МГц - как такое происходит я не понимаю - сделано была высокоприоритетная задача во FreeRTOS, которая ждала завершения приема и перезапускала ...receive_dma...
после переписывания драйвера (перезапуск DMA в обработчике) - ORE перестало происходить - тут может я не разабрался, но осадочек остался
кстати полезная фича в UART 373-го прерывание по таймауту (железное, не софт, я в ПЛИС всегда так в УАРТах делаю) не поддерживается в HAL - то есть по любому драйвер надо переписывать

нафига они еще каких-то дебильных оберток к FreeRTOS-ным функциям понаделали - тоже х.з.

===============

то есть как всегда (по-моему у 386-го или 186-го был уже графический официальный конфигуратор железа) - быстро что-то склепать, вполне все это в тему cubemx, HAL и т.д.
но если начинать копать вглубь - то неприятные впечатления гарантированы

Вот именно про это я и писал - HAL по DMA запускает передачу последнего байта, а, затем, по прямому поллингу TC дожидается завершения передачи последнего байта - и это в функции обработки прерывания DMA.

На скорости 115 кбод это приводит к завешиванию равных и более низкопроиоритетных прерываний (ну и всего нижележащего) примерно на 12 мксек (длительность передачи одного байта). Соответственно завешивается приемник (если он на равном или низшем приоритете) и получаем ORE.

Это легко убирается либо коррекцией кода HAL, либо снижением приоритета прерываний DMA передачи ниже DMA приема (именно priority, а не subpriority).