Спросите у Google как произносится CAN(Controller Area Network), но не модальный глалол "can".
В английском есть понятие акроним и по правилам CAN должен произноситься как СиЭйЭн, но мои коллеги американцы произносят КАН, ну и я, соответственно, чтобы меня понимали...Кстати, модальный глалол "can" действительно произностится "кэн". Сорри фор оф топик, кэн вы клоуз ит нау?

Вот и я поимел опыт с HAL. Начальную установку и конфигурацию сделал на кубе. За 4 месяца сделал два близких устройства на STM32F429 и драйверы к ним на Линуксе. Подсоединение устройства с STM32F429 к компьютеру по USB. На компьютере бежит Астериск.
Одно устройство 16 телефонных розеток для подключения телефонов, а второе 16 телефонных линий для подключения к каждому одной телефонной линии от АТС.
Ни в коде куба ни в коде HAL править ничего не понадобилось, хотя сделал бы это не долго раздумывая. Писать свою конфигурацию заняло бы больше времени. Так что в целом HAL и кубом удовлетворен.

Проектом занимался в свободное от основной работы время.

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

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

Если аббревиатуру можно произнести слитно, а не по буквам, то почему бы и нет? Например, P-CAD.
Но "хэл" на HAL никто не скажет.
upd. скажет "хал", ближе к этому... русскими буквами не передать.

Помните, как мы работали раньше? ))) Как конфигурировали порты и флеш, настраивали тактирование? Как энтузиасты писали макросы для настройки и ПО высокого уровня для того же? И вы скажете HAL это плохо? HAL это великолепно! ))) Идея витала в воздухе. И ее неплохо реализовали. Концепция HAL с ее реентерабельностью функций и механизмом блокировки объектов отлично подходит, когда используешь RTOS. Есть некоторые шероховатости, но это детские болезни и они пройдут! Нашел баг - напиши в ST!
P.S. И индусы молодцы! Они, вообще, ребята умные - шахматы придумали )))

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

Наверное, вы не так поняли мою мысль. Я поправил, для ясности.

У него механизм этот блокировки объектов реально хороший что ли?

На укладку парашюта еще никто не жаловался... Реентерабельные функции можно вызывать из разных задач, а используя HALовский LOCK для устройств периферии не нужны мьютексы RTOS.

Нириально хороший.

Просто флажок "периферия занята". Поддержки RTOS (типа "семафор"), как и банальных критических секций, там нет.
Т.е. наблюдаем типичную хорошо спрятанную граблю - неатомарная операция "проверил - поменял - записал" выполняется, теоретически, в нескольких потоках.

Дальше только вопрос времени, когда это добро "выстрелит"...

А если проверку этого флажка делать в критической секции?

Все можно. Но только в ихней обертке cmsis_os.h нету таких вещей/обертки. А еще можно просто добавить мьютекс. Но тогда получается в обоих случаях этот HAL править нужно. А эту cmsis_os.h сам ARM первый выдвинул - так получается?

Мне кажется, надо только переделать HAL_LockTypeDef на мьютекс.
И дефайны __HAL_LOCK() / __HAL_UNLOCK() переопределить.

Ну или вручную, критическая секция в __HAL_LOCK()

А лучше одну и ту же периферию не использовать в разных задачах.