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

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

[murmur]

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

[ШСА]

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

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

[Ruslan1]

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

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

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

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

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

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

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

[ViKo]

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

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

[Ruslan1]

Еще один минус 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]

Нафиг-нафиг это 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]

Еще один минус 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".

[Огурцов]

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

[Integro]

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

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

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

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

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

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

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

[_Pasha]

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

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

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

[rudy_b]

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

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

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

[Огурцов]

xml->json|dict->python

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

[Ruslan1]

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

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

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

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

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

[Эдди]

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

[AlexandrY]

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

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

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

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

[Ruslan1]

Советую для начала взять libopencm3
....

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

[toweroff]

Двухпроходный кейловский компилятор

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

[Ruslan1]

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

[Эдди]

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

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

Извините, а libopencm3 под кейлом будет работать?

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

[esaulenka]

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

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

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

[Ruslan1]

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

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

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

[AlexandrY]

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

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

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

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

[Genadi Zawidowsk...]

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

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

[esaulenka]

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

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

[_Pasha]

Извините, а libopencm3 под кейлом будет работать?

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

[Эдди]

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

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

[yes]

про HAL

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

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

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

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

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

[rudy_b]

в драйвере UART при запуске приема и передачи по DMA - иногда данные терялись (ORE) - скорость 115к у проца ~50МГц - как такое происходит я не понимаю
...

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

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

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

[_Pasha]

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

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

[Ruslan1]

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

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

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

[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'шные слоты. Но сама идея так делать хороша и это очень удобно(там где уместно). И данная
парадигма принимается, без консервативного пихания потоков на любой чих.

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

[AlexandrY]

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

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


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

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

[Ruslan1]

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

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

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

[zltigo]

я закрою тему и именно Вы будете тому причиной.

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

[Ruslan1]

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

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

[smalcom]

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

а это

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

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

похоже, что

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

зы.

Если этого сделано не будет в течении 24 часов

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

[MiklPolikov]

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

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

[ViKo]

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

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

[zltigo]

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

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

Вот где "стек" так "стек".

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

[ViKo]

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

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

[Ruslan1]

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

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

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

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

[rudy_b]

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

[Ruslan1]

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

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

Код

if(SET == USART_GetITStatus(USART2, USART_IT_TXE))

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

Код

if ((0!=(USART2->ISR & USART_ISR_TXE)) && (0!=(USART2->CR1 & USART_CR1_TXEIE)))

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

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

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

[AHTOXA]

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

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

[ViKo]

Это 200 тактов? Что-то явный перебор.

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

[Ruslan1]

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

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

[AHTOXA]

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

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

[Ruslan1]

Да, я обсчитался, не в ту сторону уможил . Но и 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

[ViKo]

USART_GetITStatus(USART2, USART_IT_TXE) - это функция, которую нужно вызвать и вернуться из нее. Там она еще и в стек что-нибудь сохранит, потом извлечет. вот и набежало 46 тактов.

[Tarbal]

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

Я перенес с Кейла на Кокос. Единственное что было неочевидно сходу -- использование другого имени переменной начала стэка в линкер файле. Пришлось минут 15 поискать.
В стартап файле:
Drivers\CMSIS\Device\ST\STM32F4xx\Source\Templates\gcc\startup_stm32f429xx.s


ldr sp, =_estack /* set stack pointer */
.word _estack

Заменить на

ldr sp, =_eram /* set stack pointer */
.word _eram

Иначе линкер ругается на то, что _estack неопределен.

По поводу темы. Полностью поддерживаю топик стартера. Я тоже достаточно опытный программист микроконтроллеров и не вижу больших проблем с автогенератором. Ну надо изучать структуру полученного кода. Так то что она есть это скорее достоинство. Г-код это когда бессистемное нагромождение кода без продуманных идей. А проблемы со скоростью критических прерываний если потребуется я решу. Да и то если понадобится. Какие основные проблемы с автогенерацией возможны?
1. Баги. А кто без греха?
2. Размер кода. Пока помещается никто с этим не заморачивается. Система интеграции мобильника в БМВ занимает 130 килобайт кода:
http://www.ebay.co.uk/itm/NEW-GENUINE-BMW-...0-/291387105166
Прикиньте насколько можно поджимать код, когда прижмет.
Кстати мой любимый Source Insight тоже не такой много места занимает.
3. Быстродействие. Пока не поджимает никому не важно, а начнутся проблемы -- легко решить.

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

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


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

Да ладно вам. Вы не видели кода для фрискейловского АРМа с зигби периферией. Не помню навскидку его имени. Там один хедер файл и из него ифдефами разные части программы получают разные его варианты. Натуральный шифрокод. Я даже и времени не стал тратить -- нашел обходной маневр.

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

Мне редко удавалось использовать то, что я привык. Даже не заморачиваюсь с этим.

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

Мне UART нужен для дебага только. Я только передатчик использую. Если использовать DMA, то вызывается на все строку только прерывание конец DMA. Да и передача красиво происходит. Вызвал функцию передачи и забыл. Оне не блокирующая. Реалтайм не страдает.

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

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

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

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

Что-то не вижу ожиданий в коде. Можете поподробнее рассказать пожалуйста?

CODE

/**
* @brief Handles DMA interrupt request.
* @param hdma: pointer to a DMA_HandleTypeDef structure that contains
* the configuration information for the specified DMA Stream.
* @retval None
*/
void HAL_DMA_IRQHandler(DMA_HandleTypeDef *hdma)

{
/* Transfer Error Interrupt management ***************************************/
if(__HAL_DMA_GET_FLAG(hdma, __HAL_DMA_GET_TE_FLAG_INDEX(hdma)) != RESET)
{
if(__HAL_DMA_GET_IT_SOURCE(hdma, DMA_IT_TE) != RESET)
{
/* Disable the transfer error interrupt */
__HAL_DMA_DISABLE_IT(hdma, DMA_IT_TE);

/* Clear the transfer error flag */
__HAL_DMA_CLEAR_FLAG(hdma, __HAL_DMA_GET_TE_FLAG_INDEX(hdma));

/* Update error code */
hdma->ErrorCode |= HAL_DMA_ERROR_TE;

/* Change the DMA state */
hdma->State = HAL_DMA_STATE_ERROR;

/* Process Unlocked */
__HAL_UNLOCK(hdma);

if(hdma->XferErrorCallback != NULL)
{
/* Transfer error callback */
hdma->XferErrorCallback(hdma);
}
}
}
/* FIFO Error Interrupt management ******************************************/
if(__HAL_DMA_GET_FLAG(hdma, __HAL_DMA_GET_FE_FLAG_INDEX(hdma)) != RESET)
{
if(__HAL_DMA_GET_IT_SOURCE(hdma, DMA_IT_FE) != RESET)
{
/* Disable the FIFO Error interrupt */
__HAL_DMA_DISABLE_IT(hdma, DMA_IT_FE);

/* Clear the FIFO error flag */
__HAL_DMA_CLEAR_FLAG(hdma, __HAL_DMA_GET_FE_FLAG_INDEX(hdma));

/* Update error code */
hdma->ErrorCode |= HAL_DMA_ERROR_FE;

/* Change the DMA state */
hdma->State = HAL_DMA_STATE_ERROR;

/* Process Unlocked */
__HAL_UNLOCK(hdma);

if(hdma->XferErrorCallback != NULL)
{
/* Transfer error callback */
hdma->XferErrorCallback(hdma);
}
}
}
/* Direct Mode Error Interrupt management ***********************************/
if(__HAL_DMA_GET_FLAG(hdma, __HAL_DMA_GET_DME_FLAG_INDEX(hdma)) != RESET)
{
if(__HAL_DMA_GET_IT_SOURCE(hdma, DMA_IT_DME) != RESET)
{
/* Disable the direct mode Error interrupt */
__HAL_DMA_DISABLE_IT(hdma, DMA_IT_DME);

/* Clear the direct mode error flag */
__HAL_DMA_CLEAR_FLAG(hdma, __HAL_DMA_GET_DME_FLAG_INDEX(hdma));

/* Update error code */
hdma->ErrorCode |= HAL_DMA_ERROR_DME;

/* Change the DMA state */
hdma->State = HAL_DMA_STATE_ERROR;

/* Process Unlocked */
__HAL_UNLOCK(hdma);

if(hdma->XferErrorCallback != NULL)
{
/* Transfer error callback */
hdma->XferErrorCallback(hdma);
}
}
}
/* Half Transfer Complete Interrupt management ******************************/
if(__HAL_DMA_GET_FLAG(hdma, __HAL_DMA_GET_HT_FLAG_INDEX(hdma)) != RESET)
{
if(__HAL_DMA_GET_IT_SOURCE(hdma, DMA_IT_HT) != RESET)
{
/* Multi_Buffering mode enabled */
if(((hdma->Instance->CR) & (uint32_t)(DMA_SxCR_DBM)) != 0)
{
/* Clear the half transfer complete flag */
__HAL_DMA_CLEAR_FLAG(hdma, __HAL_DMA_GET_HT_FLAG_INDEX(hdma));

/* Current memory buffer used is Memory 0 */
if((hdma->Instance->CR & DMA_SxCR_CT) == 0)
{
/* Change DMA peripheral state */
hdma->State = HAL_DMA_STATE_READY_HALF_MEM0;
}
/* Current memory buffer used is Memory 1 */
else if((hdma->Instance->CR & DMA_SxCR_CT) != 0)
{
/* Change DMA peripheral state */
hdma->State = HAL_DMA_STATE_READY_HALF_MEM1;
}
}
else
{
/* Disable the half transfer interrupt if the DMA mode is not CIRCULAR */
if((hdma->Instance->CR & DMA_SxCR_CIRC) == 0)
{
/* Disable the half transfer interrupt */
__HAL_DMA_DISABLE_IT(hdma, DMA_IT_HT);
}
/* Clear the half transfer complete flag */
__HAL_DMA_CLEAR_FLAG(hdma, __HAL_DMA_GET_HT_FLAG_INDEX(hdma));

/* Change DMA peripheral state */
hdma->State = HAL_DMA_STATE_READY_HALF_MEM0;
}

if(hdma->XferHalfCpltCallback != NULL)
{
/* Half transfer callback */
hdma->XferHalfCpltCallback(hdma);
}
}
}
/* Transfer Complete Interrupt management ***********************************/
if(__HAL_DMA_GET_FLAG(hdma, __HAL_DMA_GET_TC_FLAG_INDEX(hdma)) != RESET)
{
if(__HAL_DMA_GET_IT_SOURCE(hdma, DMA_IT_TC) != RESET)
{
if(((hdma->Instance->CR) & (uint32_t)(DMA_SxCR_DBM)) != 0)
{
/* Clear the transfer complete flag */
__HAL_DMA_CLEAR_FLAG(hdma, __HAL_DMA_GET_TC_FLAG_INDEX(hdma));

/* Current memory buffer used is Memory 1 */
if((hdma->Instance->CR & DMA_SxCR_CT) == 0)
{
if(hdma->XferM1CpltCallback != NULL)
{
/* Transfer complete Callback for memory1 */
hdma->XferM1CpltCallback(hdma);
}
}
/* Current memory buffer used is Memory 0 */
else if((hdma->Instance->CR & DMA_SxCR_CT) != 0)
{
if(hdma->XferCpltCallback != NULL)
{
/* Transfer complete Callback for memory0 */
hdma->XferCpltCallback(hdma);
}
}
}
/* Disable the transfer complete interrupt if the DMA mode is not CIRCULAR */
else
{
if((hdma->Instance->CR & DMA_SxCR_CIRC) == 0)
{
/* Disable the transfer complete interrupt */
__HAL_DMA_DISABLE_IT(hdma, DMA_IT_TC);
}
/* Clear the transfer complete flag */
__HAL_DMA_CLEAR_FLAG(hdma, __HAL_DMA_GET_TC_FLAG_INDEX(hdma));

/* Update error code */
hdma->ErrorCode |= HAL_DMA_ERROR_NONE;

/* Change the DMA state */
hdma->State = HAL_DMA_STATE_READY_MEM0;

/* Process Unlocked */
__HAL_UNLOCK(hdma);

if(hdma->XferCpltCallback != NULL)
{
/* Transfer complete callback */
hdma->XferCpltCallback(hdma);
}
}
}
}
}

[rudy_b]

...
Что-то не вижу ожиданий в коде. Можете поподробнее рассказать пожалуйста?
...

Функция HAL_UART_Transmit_DMA

Код

...
/* Set the UART DMA transfer complete callback */
    huart->hdmatx->XferCpltCallback = UART_DMATransmitCplt;
...

Функция UART_DMATransmitCplt вызывает UART_WaitOnFlagUntilTimeout(...UART_FLAG_TC...) - ожидание флага TC.

CODE

...
/* Wait for UART TC Flag */
if(UART_WaitOnFlagUntilTimeout(huart, UART_FLAG_TC, RESET, UART_TIMEOUT_VALUE) != HAL_OK)
...
HAL_UART_TxCpltCallback(huart);
}[/code]

Функция UART_WaitOnFlagUntilTimeout - ждет (!в прерывании!) установки флага TC.
[code]static HAL_StatusTypeDef UART_WaitOnFlagUntilTimeout(UART_HandleTypeDef *huart, uint32_t Flag, FlagStatus Status, uint32_t Timeout)
{
uint32_t timeout = 0;

timeout = HAL_GetTick() + Timeout;

/* Wait until flag is set */
if(Status == RESET)
{
while(__HAL_UART_GET_FLAG(huart, Flag) == RESET)
{
/* Check for the Timeout */
if(Timeout != HAL_MAX_DELAY)
{
if(HAL_GetTick() >= timeout)
{
/* Disable TXE, RXNE, PE and ERR (Frame error, noise error, overrun error) interrupts for the interrupt process */
__HAL_UART_DISABLE_IT(huart, UART_IT_TXE);
__HAL_UART_DISABLE_IT(huart, UART_IT_RXNE);
__HAL_UART_DISABLE_IT(huart, UART_IT_PE);
__HAL_UART_DISABLE_IT(huart, UART_IT_ERR);

huart->State= HAL_UART_STATE_READY;

/* Process Unlocked */
__HAL_UNLOCK(huart);

return HAL_TIMEOUT;
}
}
}
}
else
{
while(__HAL_UART_GET_FLAG(huart, Flag) != RESET)
{
/* Check for the Timeout */
if(Timeout != HAL_MAX_DELAY)
{
if(HAL_GetTick() >= timeout)
{
/* Disable TXE, RXNE, PE and ERR (Frame error, noise error, overrun error) interrupts for the interrupt process */
__HAL_UART_DISABLE_IT(huart, UART_IT_TXE);
__HAL_UART_DISABLE_IT(huart, UART_IT_RXNE);
__HAL_UART_DISABLE_IT(huart, UART_IT_PE);
__HAL_UART_DISABLE_IT(huart, UART_IT_ERR);

huart->State= HAL_UART_STATE_READY;

/* Process Unlocked */
__HAL_UNLOCK(huart);

return HAL_TIMEOUT;
}
}
}
}
return HAL_OK;
}

[Tarbal]

Спасибо.
Надо будет переписать.

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

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

[Tarbal]

Не успел переписать
Они уже сами починили. Кстати именно так как я и собирался:

Код

/**
  * @brief  DMA UART transmit process complete callback.
  * @param  hdma: DMA handle
  * @retval None
  */
static void UART_DMATransmitCplt(DMA_HandleTypeDef *hdma)
{
  UART_HandleTypeDef* huart = ( UART_HandleTypeDef* )((DMA_HandleTypeDef* )hdma)->Parent;
  /* DMA Normal mode*/
  if((hdma->Instance->CR & DMA_SxCR_CIRC) == 0)
  {
    huart->TxXferCount = 0;

    /* Disable the DMA transfer for transmit request by setting the DMAT bit
       in the UART CR3 register */
    huart->Instance->CR3 &= (uint32_t)~((uint32_t)USART_CR3_DMAT);

    /* Enable the UART Transmit Complete Interrupt */
    __HAL_UART_ENABLE_IT(huart, UART_IT_TC);
  }
  /* DMA Circular mode */
  else
  {
    HAL_UART_TxCpltCallback(huart);
  }
}

[x893]

Теоретики - как завидую Вам

[Tarbal]

Теоретики - как завидую Вам

Да ладно. Просто умные

[rudy_b]

Не успел переписать
Они уже сами починили. Кстати именно так как я и собирался:
...

Выглядит правильно. А для какого проца, какая версия либы, какой Cube?

Приводил тексты для:
проц stm32f207
либа * @version V1.0.1
* @date 25-March-2014
stm32Cube V1 version 4.6.0

Ага, загрузил последний апдейт, в новой либе
* @version V1.1.0
* @date 09-October-2015
действительно исправлено. Cube - stm32Cube V1 version 4.11.0

Но дырка с регистрами RTC все равно осталась и добавились дырка с ADC1 - пропал канал температурного сенсора. Но смотрел поверхностно, может еще что поломали.

[Tarbal]

Выглядит правильно. А для какого проца, какая версия либы, какой Cube?

Приводил тексты для:
проц stm32f207
либа * @version V1.0.1
* @date 25-March-2014
stm32Cube V1 version 4.6.0

Ага, загрузил последний апдейт, в новой либе
* @version V1.1.0
* @date 09-October-2015
действительно исправлено. Cube - stm32Cube V1 version 4.11.0

Но дырка с регистрами RTC все равно осталась и добавились дырка с ADC1 - пропал канал температурного сенсора. Но смотрел поверхностно, может еще что поломали.

stm32Cube V1.0 version 4.7.1
stm32f429

[rudy_b]

Ох, не торопитесь апгрейтить Cube, в последней версии куча гадостей, просто кошмар какой-то.

Для начала - он стал самовольно изменять настройки проекта (включает полную оптимизацию) и удаляет из него пользовательские файлы. Ну и сразу какая-то куча глюков со старыми проектами началась, до конца пока не разобрался.

[Jenya7]

лично мои впечатления.
ни с STM32 ни с HAL ни с SPL раньше интенсивно не работал. так сделал пару несложных проектов. работал напрямую с регистрами.
и тут понадобилось заточить проект на STM32. собирал проект на HAL. два дня собирал. собрал таки. дошел до функции HAL_SPI_TransmitReceive. тихонько перешел на SPL. собрал проект за пол часа целуя в его небритые щеки (или что там у него есть). все что имею сказать по этому поводу.

Сообщение отредактировал Jenya7 - Nov 29 2015, 12:25

[Allregia]

собирал проект на HAL. два дня собирал. собрал таки. дошел до функции HAL_SPI_TransmitReceive. тихонько перешел на SPL. собрал проект за пол часа целуя в его небритые щеки

Это конечно все хорошо, я сам SPL пользую (в основном для первичных нициализаций, а где надо скорость - там напрямую в регистры).
Но у меня наклевывается проект на STM32F7, и насколько я помню - для него SPL нет, а только HAL.
Что очень жаль, поскольку этот проект переводится со старого SPL-проекта на STM32F4.

[Jenya7]

Это конечно все хорошо, я сам SPL пользую (в основном для первичных нициализаций, а где надо скорость - там напрямую в регистры).
Но у меня наклевывается проект на STM32F7, и насколько я помню - для него SPL нет, а только HAL.
Что очень жаль, поскольку этот проект переводится со старого SPL-проекта на STM32F4.

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

Сообщение отредактировал Jenya7 - Nov 29 2015, 17:04

[Bloom]

Я в проектах часто использую Chibios и, соотвественно, его HAL. Сейчас его отвязали от ядра RTOS, и можно пользоваться им отдельно. На мой взгляд, получилось очень даже неплохо. Поддерживает только самое основное, если что-то нужно подкрутить под капотом, то можно и с регистрами поработать. Размер маленький получается за счет черной магии макросов.

[yanvasiij]

Добавлю свои пять копеек. Как мне кажется использование SPL или HAL обосновано, особенно при смене процессора. В одной руке даташит, в другой сгенерованный код, немного упорства и быстро начинаешь понимать, как работать с периферией. Если там и есть какие сложности или баги, то тут, на мой взгляд все просто, один раз наткнувшись на них достаточно посидеть и поковырять "потроха". После этого начинаешь прекрасно ориентироваться в исходниках и делать на этом процессоре один проект за другим. Тем более, что на STM32 не так уж и сильно эта периферия различается от процессора к процессору.

Что же касается непосредственно HAL, то, лично мне кажется, в своем стремлении абстрагироваться от регистров и низкоуровневой работы с периферией разработчики HAL переборщили. Вроде как теперь и reference manual то читать не надо (точнее похоже на то, что этого хотели добиться), но с другой стороны теперь надо читать код HAL или доку на него (кто что предпочитает). В свою очередь чтобы хорошо ориентироваться в SPL нужно все же обращаться к reference мануалу, поскольку многие типы и макроопределения введенные там непонятны без прочтения документации на проц. Но опять же и в том и другом случае разобраться то надо всего ОДИН раз, потом спокойно работаешь не заботясь о периферии.

[x893]

C HAL просто начать, но там нет нужных функций. Для их реализации надо написать немного кода, но в их идеологии. А она немного кривовата. Если посмотреть на более популярный mbed - там немного сложнее и еще более корявее. а с переходом на mbedos и yotta - стало просто мозголомкой. Но если не выходить за рамки - почти как в arduino (а это устраивает 95% "разработчиков" ).
Я использую все известные библиотеки и никаких проблем с выбором нет вообще.
Что надо использую, что не надо - удаляю и делаю своё.

Если функции инициализации делается один раз - мне все равно как она сделана, если правильно работает. Хоть на суахили. Если надо иметь кольцевой буфер, а его нет в HAL - то просто пишется нужный код. Хоть в регистры напрямую, хоть через SPL/HAL/libSTM32 и еще через что угодно.

Но всегда проще написать свою реализацию (хотя иногда она и не так красива как результат труда других людей).

[makser]

Я свои проекты делаю на SPL, потеря в тактах и байтах минимальна (давно тестил - буквально 1-2%). Сейчас переход на stm32f7 осложняется отсутствием оного для этих чипов. HAL действительно монстроподобен и похоже парой процентов потерь не обойдется.
Насчет SPL для stm32f7, есть такая мысль - судя по даташитам F7 включает в себя F4 с некоторыми новыми наворотами, т.е. по идее можно использовать SPL от F4 для F7. Осталось попробовать перенести ее.

Сообщение отредактировал makser - Apr 24 2016, 10:59

[x893]

Мне по барабану регистры, SPL, HAL - у меня код аппаратной занимает максимум 5% от всего кода (обычно 1-2%).
Вообще непонятна цель этих дискуссий.
Просто делать нечего в деревне - бабки выходят и начинают ни о чем говорить.
Хотя они при деле и время проходит незаметно.

[zltigo]

Мне по барабану регистры, SPL, HAL - у меня код аппаратной занимает максимум 5% от всего кода (обычно 1-2%).

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

[x893]

Это легко сравнивается через DWT, таймером, профайлером и всегда можно выбрать оптимальный вариант. Да и умелым программированием можно производительность угробить без регистров/SPL/HAL.

Нельзя всех сапожников заставить пользоваться одним типом молотка.

[alexp74]

Ковырял stm32f4xx_hal_eth.c и нашел интересный момент. Много записей в MAC регистры сделаны таким макаром:

Код

static void ETH_FlushTransmitFIFO(ETH_HandleTypeDef *heth)
{
  __IO uint32_t tmpreg1 = 0U;
  
  /* Set the Flush Transmit FIFO bit */
  (heth->Instance)->DMAOMR |= ETH_DMAOMR_FTF;
  
  /* Wait until the write operation will be taken into account:
     at least four TX_CLK/RX_CLK clock cycles */
  tmpreg1 = (heth->Instance)->DMAOMR;
  HAL_Delay(ETH_REG_WRITE_DELAY);
  (heth->Instance)->DMAOMR = tmpreg1;
}

Т.е. в регистр происходит запись, потом он же читается, потом задержка на от ~0 до 1-го systick и запись прочитанного опять в регистр.
Напрягает плавающая задержка. В мануале на stm32 не нашел требований по задержке...