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

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

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

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

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

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

не надо себя преподносить за всех. и цитату привели и обсосано везде: разные есть применения. если вы не получаете по жопке за лишний использованный байт, то у вас работа отличается от того кто получает по этой самой жопке. достали уже "медийщики" мнящие себя эмбеддеррами. используйте рпи. они вообще дешевле грязи и мощи поболе чем в стм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 МГц ядра.

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