[_Pasha 0]

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

Ужас.

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

[Ruslan1 17]

Ужас.

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

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

 

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

[smalcom 0]

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

 

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

пожалуйста, без холивара

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

Прошли те времена, когда на асме писали и биты (не байты!) экономили, железо подешевело, зато себестоимость времени разработчика увеличилась.

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

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

 

Во молодняк пошел.

Я эти результаты еще на телесисах выкладывал, если вам это что-то говорит.

Потом на сахаре неоднократно. Может вы и на сахаре не были ?

Да и здесь не раз.

 

 

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

Но пока руки не доходят статью написать.

 

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

[Ruslan1 17]

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

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

Если этого сделано не будет в течении 24 часов от написания этого Вашего письма- я закрою тему и именно Вы будете тому причиной.

 

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

[zltigo 1]

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

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

 

 

[Ruslan1 17]

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

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

[smalcom 0]

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

 

а это

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

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

 

похоже, что

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

 

 

зы.

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

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

[MiklPolikov 0]

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

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

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

[ViKo 1]

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

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

[zltigo 1]

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

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

 

 

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

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

 

[ViKo 1]

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

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

[Ruslan1 17]

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

Ну и нарвался на ошибку в одной вроде бы простой функции, USART_GetITStatus()

 

Засада в том, что прерывание по переполнению приемника (ORE) может возникнуть в двух случаях, и, соответственно, может быть разрешено двумя способами, а не одним как прочие "одноклеточные".

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

 

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

 

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

 

[rudy_b 1]

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

[Ruslan1 17]

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 МГц ядра.

 

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