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

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

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

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

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

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

про 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).

Ужас.
Полагаю, тема раскрыта

Да уж. жестоко.

Огромное спасибо всем откликнувшимся! Не дали погрязнуть в.

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

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

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

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

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



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

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

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

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

Во молодняк пошел.
Я эти результаты еще на телесисах выкладывал, если вам это что-то говорит.
Потом на сахаре неоднократно. Может вы и на сахаре не были ?
Да и здесь не раз.


Но есть конечно и результаты сравнения самых последних версий.
Но пока руки не доходят статью написать.

Никогда GCC не приближался по эффективности к Keil-у или IAR-у.

Уважаемый smalcom, пожалуйста, отредактируйте свое сообщение, оставьте в нем только Ваш опыт работы с HAL, CMSIS, подобными библиотеками STM/Cortex и уберите высказывания, провоцирующие холивар весь неконструктивный текст .
Если этого сделано не будет в течении 24 часов от написания этого Вашего письма- я закрою тему и именно Вы будете тому причиной.

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

Вообще-то Вам ее и открывать было незачем тем более, что и слушать неугодное не желаете.

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

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

а это

холивар или нет?

похоже, что



зы.

приступайте. я не собираюсь ничего удалять.

Думаю что через несколько лет HAL дорастёт до такого же user-frendli состояния, как сама среда разработки. А пока нафиг его.

А я думаю, что однажды сделанное никто переделывать не будет. Только ошибки будут исправляться. Так и останется 10-уровневое наслоение функций. Вот где "стек" так "стек".

Тогда фильтруйте СВОИ эмоции.



Хороший "стек" сделать очень трудно и в результате он смотрится "просто" и "естественно". То что есть этот конкретный HAL это просто "куча" .

Согласен. Так бывает, когда нет "головы" (руководителя), определяющую вертикаль (стек). Когда работники договариваются по горизонтали. Или когда в той голове нет царя.

В-общем, HAL я обошел стороной, но решил хоть "среднеуровневый" StdPeriph Library попользовать (использую STM32F070)
Ну и нарвался на ошибку в одной вроде бы простой функции, USART_GetITStatus()

Засада в том, что прерывание по переполнению приемника (ORE) может возникнуть в двух случаях, и, соответственно, может быть разрешено двумя способами, а не одним как прочие "одноклеточные".
А вот этот USART_GetITStatus() выдает итоговый флаг "произошло прерывание от источника ORE" только в случае если оно разрешено через EIE. Если ORE разрешено установкой RXNEIE - то функция вернет результат "прерывание от ORE не произошло". Редиска.

Лечится просто, нужно анализировать собственно сами флаги, через USART_GetFlagStatus().

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

SPL тоже не подарок и ошибок в ней много. Мусора поменьше, зато разбирательств с кривой периферией ST побольше.

Еще пример, про скорость работы.
Замена проверки возникновения прерывания

на прямую проверку того же:


дает ускорение выполнения этой проверки почти на 1 микросекунду (если точно- на 0.96 us).

Каждая проверка. Одна микросекунда дополнительно из-за использования библиотечной функции, и это на 48 МГц ядра.

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

Это 200 тактов? Что-то явный перебор. Я сам не люблю StdPeriphLib, но надо быть объективным. Вы, по всей видимости, не отключили макрос USE_FULL_ASSERT. Если он определён, то там производится куча проверок параметров.

48. Даже меньше, там же не целая микросекунда. Пустяки... Но, все равно, жалко.

Как тут заметили, тактов меньше (46), но могло бы быть и 200- они часто в этих библиотеках используют сдвиг для формирования битовых флагов. То есть в функцию передают номер бита, а дальше двигают. Универсально, да. Но расточительно.
Очень многое из этих функций можно было бы организовать через дефайны или инлайны, без потери универсальности.
Ну да ладно, даренному коду в сорцы не смотрят (если работает). Но я уже прочуствовал, почему народ кривится.

Да, я обсчитался, не в ту сторону уможил . Но и 48 многовато. Вы всё же для полной ясности гляньте макрос USE_FULL_ASSERT (он обычно определяется в файлах типа stm32f4xx_conf.h).

Не-не, выключен. есть только закомментированная строка (у меня в stm32f0xx_conf.h).

Могу сказать насколько код вырастает:

без USE_FULL_ASSERT:
Total ROM Size (Code + RO Data + RW Data) 16352 ( 15.97kB)

с USE_FULL_ASSERT:
Total ROM Size (Code + RO Data + RW Data) 22924 ( 22.39kB)

попробую позже измерить с включенным USE_FULL_ASSERT, интересно насколько изменяется скорость выполнения библиотечных функций.

Да, забыл сказать- это все при оптимизации по дефолту, -O2