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

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

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

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

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

Давайте будем точны. На самом деле вы не знаете сколько разработчиков в МИРе используют 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 с другими производителями на аналогичных условиях.

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

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

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

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 и отловить то место где "хал хочет".



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

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

Вот именно, что не совсем так...
Галочки в кубе это хорошо конечно. Но я у себя в проекте, к примеру, запускаю кварц - проверяю - не запустился - запускаю HSI настраиваю PLL - выставляю признак ошибки оборудования. Аналогично поступаю с RTC кварцем. По крайней мере, на момент написания проекта, в библиотеках ST этого не было.
Работать с портами через библиотеку ST вообще для меня непонятная вещь. Это уже обсуждалось 10 раз. Есть ряд красивых решений и ST под них ниразу не подходит.
Всякие там nvic буквально макросами пишутся CMSIS и хидеров.
Но ещё раз говорю - я же не возражаю. Просто это надо изучать. Причём нормально времени потратить. И тогда, правильно, проблем с USART не будет. Если реально это изучить, включая листинги...
Ну так извините. Приём с передачей модбаса строк 20 вместе с обработкой регистров. Передача через DMA тоже 10 строк вместе с двумя прерываниями. Работы день... Два вместе с отладкой. Ну скажем, для меня.
На изучение HALа, у меня уйдёт больше. Причём при подключении он подтянет 5 библиотек.
Возьмём пример.
Начал писать bootloader. Решил дабы время не тратить задействовать HAL. Там было буквально пару функций. В результате штук 5 библиотек подтянулось. Глянул даташит... Просто обалдел. Там всего то занести ключ да записать. Короче самописанных 3 процедуры по 5 строчек.
Как говорится каждому своё. У одного разбор чужого и изучение нового занимает мало времени и тогда ему HAL просто песня. Для меня , зачастую, это прямая потеря времени. Мне проще самому накропать.

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


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



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

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

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

Вы про это?

Кто нибудь в курсе какие ОС и какой язык программирования используют для написания ПО для беспилотных автомобилей?

Она полностью бессмысленна. Это как споры вендовозов и линуксоидов. Одним нравится мышкой тыкать, а другим — вникать в то, что они делают. Одни апеллируют к саморазвитию, другие — к "зато я бабосов больше нагребу".

Нашел


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

Да его и в любых других проектах не используют, если предполагают дальнейшие модификации. Потому что сгенерированный код нечеловекочитаем! Это примерно как XML: формат абсолютно не предназначен для непосредственной правки, если хочешь вручную параметры править, то используй INI или JSON.

А в Airbus мужики не согласны Они вовсю используют матлабоский кодогенератор из Simulink/скриптов в Си/Си++.
https://www.mathworks.com/company/user_stor...sed-design.html

И в Toyota: https://www.mathworks.com/company/user_stor...s-and-silm.html

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

Хотите сказать что они свою знаменитую педаль-убийцу на матлабе делали?
У меня сложилось мнение что там был коктейль из трёх ингредиентов: C + MISRA + кривые руки, последний самый важный, без него ничего не получится.

Нет. Так и думал, что за нее зацепятся. Такое могло произойти как с "ручным", так и с "автоматическим" кодом. Матлабоские кодогенераторы, по крайней мере по их спецификациям, соответствуют классам безопасности вплоть до SIL 4: https://www.mathworks.com/help/certkitiec/u...w-overview.html
Нельзя отрицать факта, что круппнейшие разработчики в своих проектах используют кодогенерацию. Мы не знаем их workflow: в каком виде они используют полученный код, что изменяют, как сопрягают с имеющимся, как тестируют. Но использование его - это факт.

P.S. прочитал сначала "падла-убийца"

Не знаю, как за бугром, а в России машины-роботы обречены на провал. У нас для того, чтобы не попадать в аварийную ситуацию, нужно нарушать правила, т.е. "ездить как все", а не "как надо". "Тупая машина" будет делать то же, что и блондинка из анекдотов: тупить на дороге, из-за чего создавать аварийную ситуацию.

Надо просто роботизацию с дорожных катков начинать.
Так одним махом обе российские проблемы и решим.

Укатаем дураков в дороги? =D

Не ради спора, а чтоб расширить кругозор.... на сколько мне известно, все ПО работающее на борту пишется на Ада, также для на борту крутится какая-то АдаОС.
То, что я увидел по вашей ссылке про аирбас, так это то, что они в матлабе на симулинке написали модель топливного менеджера и симулировали различные условия.


по рабочекрестьянски - они годогенератором делают модели и тестбенчи. Я не носитель аглицкого, но упоминаний, что на борту использут с/с++ и годогенерированый код я не увидел. Если есть информациа о написании бортового ПО на с/с++, поделитесь пожалуйста.

более того, в беспилотных ам тоже самое, что и в аирбасе...



ps да такое вообще могло произойти и без ПО, педаль могла банально за коврик зацепиться.

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

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

Нашел русскоязычную версию: https://matlab.ru/success-story/Airbus_A380_rus_print.pdf
Вы правы, здесь говорится о создании моделей, а не конечном продукте. Но ведь потом написанное сравнивается с ней как с эталоном. Так или иначе доверие к моделям должно быть огромным, а в них используется кодогенерация.

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

Касательно, собственно, куба, вопрос.
Есть ли какая-то возможность создать в нём проект полностью на LL-драйверах под STM32F100?
Последняя версия требует хотя бы одного драйвера на HAL (RCC не в счёт - там отдельная кухня), иначе кодогенерация намертво зависает. М.б. что-то делаю не так? В аттаче пример, из периферии используются: USART, SPI, ADC, DAC, IWDG, RTC, с десяток GPIO и один таймер.
Вопрос не совсем праздный - стоит так: стоит ли изучать 2000+ страниц мануала на это счастье или ограничиться 700 страницами референса?

Мы так для К580ИК80 писали программы в 1982 году. :-)
Точнее так. На бумажке всё же мнемокоды. Потом рядом столбиком переводили в HEX-код, который уже вручную вписывали в память.