[Hiehachi 0]

Работал с HAL_UART_Receive_IT(). Хал включил не спрося обработку по EIE (так ему захотелось) и упетлял кудато, не выполнив банальную очистку (два простых безусловных действия, без петляния)- вышел из интерупта - на этом всё и закончилось ;(. В общем эта проблема + куча кода по проверке своих статусов- видимо для RTOS-ов, много кода в контексте прерывания. В общем не чувствовалась рука профи.

 

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

 

Потом подзабыл ту проблемку с уартом, лет через 5 взял попробовать ETHERNET на STM32F429, на своём боарде. Создал проэкт на кубе со всеми настройками, после в Кейле поменял на свой код инициализацию внешнего PHY-RMII (под KSZ8041 вроде, там другие биты были в автоопределении 10/100), думал всё. По дефайнам настроил количество буферов и режимы. Ну и начались траблы то иногда пакеты тупо дублировались при передачи то приёма не было (по дефайнам установил 1 буфер на приём и 1 на передачу - в этом и была проблема, код кала оптимизирован на минимум двойную буферизацию - коряво, на 4 буфера - лучше двойной, но не идеал). У меня проэкт не позволял транжировать память 4-мя буферами на приём и на передачу... собственно когда эта периферия используется опционально по необходимости.

(реализовывал код под ARP, IP/UDP - код старый обкатаный еще на RTL8019, LPC1768, STM32F207). Провозился дня два - под вечер снёс этот кал; за два часа поставил пример сервера на lwIp (или как он там называется) - для того чтобы выудить две базовые функции на RX и TX, выудил, сервер снёс так-же. Пересоздал новый проэкт на базе SPL и по екзамплах юзания езернета с lwIp - за 3-5 часа и всё работало как надо.

 

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

Изменено 16 марта, 2018 пользователем картошка

[serglg 0]

Работал с HAL_UART_Receive_IT(). Хал включил не спрося обработку по EIE (так ему захотелось) и упетлял кудато, не выполнив банальную очистку (два простых безусловных действия, без петляния)- вышел из интерупта - на этом всё и закончилось ;(. В общем эта проблема + куча кода по проверке своих статусов- видимо для RTOS-ов, много кода в контексте прерывания. В общем не чувствовалась рука профи.

 

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

 

У меня в нескольких проектах постоянно используется HAL_UART_Receive_IT().

И что я делаю не так?

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

 

[Hiehachi 0]

У меня в нескольких проектах постоянно используется HAL_UART_Receive_IT().

И что я делаю не так?

 

Все правильно делаешь. Читай только постов 20 перед последним, будешь в теме. ;)

[Quasar 18]

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

 

Судя по тому что вы написали, проблема у вас в уровне именно вашей квалификации, а не тех, кто пишет HAL...

 

Если подитожить, многие здесь на форуме используют HAL, многие в МИРе используют HAL, обсуждений в интернете море. Но есть какой-то процент несостоявшихся гениев, у которых HAL не работает ВООБЩЕ, и поэтому они все пишут сами. Пишут они исключительно самый лучший, безглючный, эффективный и красивый код. Я уверен, это только их проблема, индивидуальная.

[Eddy_Em 1]

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

[serglg 0]

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

 

Гении пишут исключительно на АСМе STM32. :-)

 

[mantech 34]

Гении пишут исключительно на АСМе STM32. :-)

 

Неправда! Гении пишут Искусственный интеллект на асме под линуксом! B)

 

А по существу, важно не то, на чем пишешь, а понимаешь-ли что написал :rolleyes:

Изменено 17 марта, 2018 пользователем mantech

[halfdoom 0]

Недавно был один пример, когда использование библиотек типа HALa может оправданным. Попросили сделать небольшой и дешевый контроллер для управления простым устройством по WIFI. У нас есть подходящая серийная плата на STM, но цена и размеры несколько великоваты. Сотрудник предложил вариант на ESP8266 - дешево и вроде даже работает. Поскольку заказ разовый, особая надежность не требуется, то вполне оправдано использовать обертки вроде ардуин, поскольку полное изучение и написание с нуля абсолютно не целесообразно. В итоге все работает и все довольны, но понятно, что на промышленное применение такое не пойдет.

[SapegoAL 0]

Судя по тому что вы написали, проблема у вас в уровне именно вашей квалификации, а не тех, кто пишет HAL...

Судя теме, человек приводит описание ошибок с которыми он сталкивался, а также видно, что он их устранял, доводя проект до конца именно с использованием HAL. То есть не просто накидал, изменённую модификацию тестового примера от ST. Топикстартер просит поделится своим опытом, и картошка делится.

А вы, извините, просто переходите на личности, и ссылаетесь при этом на "многих". Вас бы забанить за хамство.

Напишите ... я использовал HAL реализовал 500 проектов такойто сложности. Хомутов не встречал. Тогда будет по теме топика.

Если подитожить, многие здесь на форуме используют HAL, многие в МИРе используют HAL, обсуждений в интернете море. Но есть какой-то процент несостоявшихся гениев, у которых HAL не работает ВООБЩЕ, и поэтому они все пишут сами. Пишут они исключительно самый лучший, безглючный, эффективный и красивый код. Я уверен, это только их проблема, индивидуальная.

Давайте будем точны. На самом деле вы не знаете сколько разработчиков в МИРе используют HAL, насколько они его изменяют, насколько они довольны результатами использования. То есть цена данному пассажу = 0. А далее опять банальное хамство. А ведь вас не оскорбляли.

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

 

На мой взгляд плюс один - достаточно быстрое вхождение.

Минус - обратная сторона плюса. HAL является промежуточным уровнем, со всеми вытекающими. А именно:

1. Это новая сущность. Его надо изучить. Иначе как применять? Причём изучение само собой не вытекает из CPU, CPU ВСЁ равно изучить придётся, иначе применять будете коряво.

Вот прямо простой пример по тексту обсуждения. По UARTу вам надо знать как он работает (какие режимы, как DMA обслуживается, как обработка ошибок осуществляется и так далее). Кроме того вам надо почитать как работает HAL (чем отличается один вызов от другого. Есть переменные и макросы специфичные). Иногда дополнительные данные ПРЯМО указаны в комментах на HAL, но далеко не всегда. Иногда они дублирующие. Иногда полностью не закрывают твои потребности. Чем лучше ты знаешь HAL - тем грамотнее и удачнее будет его применение.

2. HAL вещь универсальная. Он таким и должен быть. Причём к нему 2 прямо противоположных требования. Быть универсальным и быть простым. А так не бывает. В результате он становится всё более сложным и навёрнутым. Соответственно требует всё больше времени на изучение (см. п. 1). С другой стороны становится всё более громоздким, а значит медленным. И это неизбежно. Это противоречие, которое никогда не будет решено.

3. HAL это составная часть коммерческого продукта. Это маркетинговая программа. Это просто очевидно. ST заплатила нормальную сумму SEGGERу. Что просто так? Из любви к программистам? Заплатила пишущим индусам. Просто так?

Ну это даже обсуждать не хочется. При этом одна из целей маркетинга - привязать клиента к своему продукту насмерть. Эта задача решается за счёт выполнения 2 условий:

a) Простота использования решений только ST.

б) Высокая сложность перехода с решений ST на решения других фирм.

Куб справляется с этим заданием на 100%.

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

 

 

[serglg 0]

На мой взгляд плюс один - достаточно быстрое вхождение.

 

При этом одна из целей маркетинга - привязать клиента к своему продукту насмерть. Эта задача решается за счёт выполнения 2 условий:

a) Простота использования решений только ST.

б) Высокая сложность перехода с решений ST на решения других фирм.

Куб справляется с этим заданием на 100%.

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

 

Ну вот потому я и использую HAL.

И зачем мне другие производители, если цена на STM32 меня вполне устраивает?

 

 

[juvf 10]

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

Вот видите как происходит: один пишет "я попробовал хал - не получилось, переписал со своим кодом", другой читает "я попробовал хал, нашел в нем ошибку, переписал со своим кодом".

но "не получилось" != "нашел ошибку"

Пока что картошка ни привёл какого-либо описания ошибок в хале. Вот как выглядят ошибки в коде и их описание. 5 строчек исполняемого кода, в нём 4 ошибки. Код, чуть менее, чем полностью состоит из ошибок.

 

Вас бы забанить за хамство.

нет там хамства, а по поводу квалификации - тоже есть сомнения....

ни чего не скажу про квалификацию кого-либо, но пугает следующее ....

Работал с HAL_UART_Receive_IT(). Хал включил не спрося обработку по EIE (так ему захотелось) и упетлял кудато, не выполнив банальную очистку

1)прерывание по FE может быть только при EIE и DMAR. Т.е. до вызова HAL_UART_Receive_IT() у вас флаги EIE и DMAR были в "0", а после становились "1" и вы начинали улетать в прерывание по FE? Где в HAL_UART_Receive_IT() выставляется EIE и DMAR? Где по вашему ошибка в хале и как нужно былобы написать "не по индусски"?

 

2)"так ему захотелось" - что это значит? "Машина дура, что ей скажут, то она и делает" (С). У вас есть исходники хал. Где в хале указания включить флаги EIE и DMAR при приеме по уарту с прерываниями? Вы же проффесианал, как вы можете говорить "так ему захотелось"? Так ещё допустимо сказать про Windows, про закрытую библиотеку или про gcc, но у вас хал в виде исходников, которые вы себе в проект добавляете - всё в ваших руках, и вы пишете "ему захотелось"!?

 

3)вот у меня случай.... void Handler_EXTI_9(){}; - обработчик EXTI_9 (хал генерит). Попал в прерывание, в нем не очищяется флаг EXTI9(просто заглушка "{}"), и навеки завис в этом прерывании. Я прерывания ексти9 не заказывал, ни в кубе, ни в хале, и в своем коде. Судя по логике картошки, в этом прерывании нужно сбросить флаг, т.е. хал должен был в этом прерывании проверить флаг и сбросить его. Я так не думаю. Я полез разбираться - с какого перепугу я попал в EXTI9? Нашел ошибку в своем коде, ошибся с инитом GPIO/EXTI. Поправил - больше не попадал в это прерывание и флаг мне в нем ни какой очищать не нужно.

Подход картошки: попал в прерывание по FE, которое не заказывал - давай в прерывании искать анализ FE, выяснил что нет сброса FE и сделал вывод - код глючный. эээээээ.... что то там про "В общем не чувствовалась рука профи." (С)

 

Можно встретить нерабочий код код, который у вас не заработал, тут есть 2 пути, либо отказаться его использовать, либо потратить время и найти ошибку. Если пошли по пути 2 и нашли ошибку - то можно смело заявить "В хале есть ошибки, не тратье время", если по пути 1, то можно сказать "хал неудобен, документация плохая, непонятно, я не смог на нем сделать обмен по УАРТ, я без хала быстрее напишу". Остальные сами сделают выводы относительно хала. Но у картошки я вижут путь 1 и заявление - "в нем ошибка!". А где ошибка? Пойдя по пути 2 вы, скорее всего найдете можете найти ошибку у себя.

 

ps Если вы обнаружили, что флаги EIE и DMAR самопроизавольно встают хал где-то выставляет по своему хотению.... есть же в отладке брейкпоинты по чтению и/или записи и/или обращению к определённому адресу ОЗУ. Можно поставить брейкопинт по записи в USART_CR3 и отловить то место где "хал хочет".

 

 

 

Причём изучение само собой не вытекает из CPU, CPU ВСЁ равно изучить придётся, иначе применять будете коряво.

Не совсем так.... клокирование - галочки в кубе наставил и забыл про клоки. Без кала - там адское клокирование... ковырять битики, вчитываться в описание регистров.... UART - в кубе галкой разрешил - нужные GPIO подсветились, тут же в гуях перекинул на нужные (да и вообще прикинул куда можно прокинуть уарт), на соседней вкладке задал 115200, 8bit, 1stop - и забыл. А без хала крути клоки, gpio, alt_gpio, uart, nvic.... там только задать правильно 115200, при условии что 8МГц кварц, всякие плл и прескалеры.... с халом в лет инит уарта. И не нужно изучать как задается 115200 в уарте, какими регистрами и по каким формулам считается.

[SapegoAL 0]

нет там хамства, а по поводу квалификации - тоже есть сомнения....

ни чего не скажу про квалификацию кого-либо, но пугает следующее ....

К Вам претензий никаких. Всё по теме. Хамство я увидел в посте halfdoom.

Не совсем так.... клокирование - галочки в кубе наставил и забыл про клоки. Без кала - там адское клокирование... ковырять битики, вчитываться в описание регистров.... UART - в кубе галкой разрешил - нужные GPIO подсветились, тут же в гуях перекинул на нужные (да и вообще прикинул куда можно прокинуть уарт), на соседней вкладке задал 115200, 8bit, 1stop - и забыл. А без хала крути клоки, gpio, alt_gpio, uart, nvic.... там только задать правильно 115200, при условии что 8МГц кварц, всякие плл и прескалеры.... с халом в лет инит уарта. И не нужно изучать как задается 115200 в уарте, какими регистрами и по каким формулам считается.

Вот именно, что не совсем так...

Галочки в кубе это хорошо конечно. Но я у себя в проекте, к примеру, запускаю кварц - проверяю - не запустился - запускаю HSI настраиваю PLL - выставляю признак ошибки оборудования. Аналогично поступаю с RTC кварцем. По крайней мере, на момент написания проекта, в библиотеках ST этого не было.

Работать с портами через библиотеку ST вообще для меня непонятная вещь. Это уже обсуждалось 10 раз. Есть ряд красивых решений и ST под них ниразу не подходит.

Всякие там nvic буквально макросами пишутся CMSIS и хидеров.

Но ещё раз говорю - я же не возражаю. Просто это надо изучать. Причём нормально времени потратить. И тогда, правильно, проблем с USART не будет. Если реально это изучить, включая листинги...

Ну так извините. Приём с передачей модбаса строк 20 вместе с обработкой регистров. Передача через DMA тоже 10 строк вместе с двумя прерываниями. Работы день... Два вместе с отладкой. Ну скажем, для меня.

На изучение HALа, у меня уйдёт больше. Причём при подключении он подтянет 5 библиотек.

Возьмём пример.

Начал писать bootloader. Решил дабы время не тратить задействовать HAL. Там было буквально пару функций. В результате штук 5 библиотек подтянулось. Глянул даташит... Просто обалдел. Там всего то занести ключ да записать. Короче самописанных 3 процедуры по 5 строчек.

Как говорится каждому своё. У одного разбор чужого и изучение нового занимает мало времени и тогда ему HAL просто песня. Для меня , зачастую, это прямая потеря времени. Мне проще самому накропать.

 

[Quasar 18]

К Вам претензий никаких. Всё по теме. Хамство я увидел в посте halfdoom.

Вы увидели это в моем посте. Отвечать мне было лениво, но спасибо juvf он написал за меня. Я сделал вывод о квалификации именно по:

 

2)"так ему захотелось" - что это значит? "Машина дура, что ей скажут, то она и делает" (С). У вас есть исходники хал. Где в хале указания включить флаги EIE и DMAR при приеме по уарту с прерываниями? Вы же проффесианал, как вы можете говорить "так ему захотелось"? Так ещё допустимо сказать про Windows, про закрытую библиотеку или про gcc, но у вас хал в виде исходников, которые вы себе в проект добавляете - всё в ваших руках, и вы пишете "ему захотелось"!?

По "ему захотелось" у меня сработал триггер. Для человека HAL и открытый исходный код это какие-то загадочные и непостижимые черные ящики. О чем тут можно вообще говорить дальше? Обсудить чего еще любит HAL по выходным и четвергам?

 

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

 

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

 

Есть мнение, что те, кто отрицательно пишет про HAL не умеют работать с чужим кодом

 

 

 

[PheeL 0]

Господа, вы извините, конечно, но вот я читаю уже не первую страницу данной темы и никак понять не могу, вы постоянно упираете на HAL, но ведь там же есть ещё и LL (Low Layer)! Более того, Cube позволяет в настройках проекта переключать генерацию кода в этот API (LL). А там практически всё, что вы так любите - прямое обращение к регистрам периферии, только с вменяемыми названиями функций и регистров, чтобы можно было потом код _читать_ и поддерживать, а не в битах спотыкаться. Да, конечно, там тоже есть свои нюансы (как пример - настройка секвенсора в АЦП), но их значительно меньше (на мой взгляд) чем в HAL. И, естественно, вы не сможете сделать на LL всё. Например, драйвер FLASH там отсутствует, как-минимум для линейки F3. А для F7 там вообще нет поддержки большей части мощной периферии (SDMMC, USB, DCMI, LTDC, ETH и др.). Но, вы собрались её всю программировать руками? Простите, USB, где в документации 10 страниц одного _перечисления_ регистров! Могу пожелать только много времени, удачи и усердия.

P.S. Для простой периферии на STM32 используйте LL и будет вам счастье. Для мощной - решайте сами.

[serglg 0]

Но я у себя в проекте, к примеру, запускаю кварц - проверяю - не запустился - запускаю HSI настраиваю PLL - выставляю признак ошибки оборудования. Аналогично поступаю с RTC кварцем. По крайней мере, на момент написания проекта, в библиотеках ST этого не было.

 

 

Когда у меня были проблемы с кварцем 32768, то HAL меня прекрасно тыкал носом - "LSE не запустился". Сразу вваливался в ошибку (соответственно начинаю мыть плату :-)).

 

Вы про это?

Изменено 21 марта, 2018 пользователем serglg