Просто хотел поделиться успешным опытом.
Как найти и исправить проблем нет. Может потому и взялся. Были проблемы с длинными обработчиками прерываний, но реорганизовал структуру драйвера, чтобы не мешало.

Собственно если посмотреть в самые-самые первые версии ARM CMSIS (в районе 1.1), то там и подразумевался единый уровень абстракции для чипов всех производителей. Типа: UART, можно выставить скорость, четность, стоп-биты, отправить-принять байт. Ethernet: можно выставить скорость, дуплекс, принять-отправить пакет. Естественно при этом теряются некоторые специфические фишки, плата за переносимость между производителями. Но производители в восторг не пришли, драйвера писать не стали. А сам ARM поддерживать зоопарк не осилил. И к версии CMSIS 2.0 эту красоту убрали, оставив поддержку только самого ядра.

Будь я модератором, убрал бы из темы 3/4 холивара и оставил полезные посты.

А вот мой случай:
В библиотеке HAL 1.1.0 - 1.4.0 для STM32L1xx был баг в функции HAL_RCC_GetSysClockFreq(), которая возвращала установленную тактовую частоту:

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

В версии 1.5.0 баг исправили

Тока хотел написать ... Опередили ...

Заинтересовало. Глянул. Свежескачанные кубы для 4xx и 2xx. Версии от ноября прошлого года. Какая там многопоточность, о чем вы?




Про то, что ради 100-килобайтного заголовочного файла с описанием регистров из CMSIS приходится качать полтораста мегабайт куба - отдельный разговор.

Оно все время не продекларировано это USE_RTOS и просто так. Пусть себе пишут (2 руками за) - 1. даренному коню в зубы не смотрят и 2. проверить/разобраться с Кубом что-то - самое то это (очень и очень многое с ним вообще-то можно проверить).

2 AleksBak.
Да никто ни на индусов ни на HAL не нападает. Задача "создать универсальную библиотеку", в принципе не решаемая. Чем более универсальна она будет, тем она будет более громоздкая. Документация по ней превысит исходную документацию на кристалл в несколько раз. Вот и всё.
В результате, чтобы задействовать функцию, приходится смотреть в доки на библиотеку и доки на кристалл. Потом ещё рыться в библиотеках ну и так далее ... То есть при каком-то уровне абстракции это просто теряет смысл.
Ну, например, взять таймер. Хотим организовать ШИМ. Читаем 10 регистров и появляется примерно следующее

Ну и управление яркостью, соответственно
TIM_PWM_LIGHT->CCR4 = teklight;
...
Если захочешь написать это с помощью HAL, то меньше не окажется ... Читать меньше тоже не придётся ... Более того, это всё ещё будет завязано ещё на какую-нибудь библиотеку и... погнали наши городских. В результате подключено 10 библиотек HAL, для того, чтобы махнуть одной ножкой... Какие преимущества то?
Это всё уже писано 10 раз.
Против самих библиотек никто не возражает. Иногда удобно. Например туда посмотреть.

Полностью на 100.0% согласен. Так и стараюсь делать вообще-то. Спс за развернутый ответ. ТС хотел в этой теме какие если есть важные ошибки в HAL - чтобы про них кто-то написал и тогда не буду тему "захламлять". До этого "наводящий" вопрос о __HAL_LOCK/__HAL_UNLOCK я спецом задал, а то так бы тут и обсуждали перевод слова "hal" и т.п.

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

Китайцы, в основном, и континентальные и островные…

Да Бог с вами. Линукс это тысячи разных программ. Так не пользуйтесь теми платформами, что используют не open source.

Да заметил. Но пока ещё далеко до завершения этой работы... Даже с идеалогией не всё в порядке.
И вообще. Посмотрите, почему линукс? Он так хорош? Да нет, просто объём работы (суммарный, а не только по ОС) таков, что реально сложно за него взяться.
Это ведь как в любом проекте. Когда его завершаешь, то видишь кучу мелочей, которые надо бы исправить. И беда в том, что на начальном этапе ты этих мелочей не заметил, или не предусмотрел механизмов которые помогают их красиво устранить. А на этапе, когда ты их видишь, к сожалению, их устранение приводит к коренной переработке всего проекта. А ты на это не готов. И количество людей, принимающих участие в проекте, не улучшает его свойств (не уменьшает количество огрехов), а, наоборот, увеличивает. И... поехало всё с нуля.
StdPeriph_Driver -> HAL_Driver ->

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

Массой НЕ "open" платформ уже просто не возможно не пользоваться, например, на какой платформе Ваш телефон?





Просто один из примеров - можно сказать флагман бизнесмодели "секс по телефону бесплатный - платите только за телефонный звонок", но конечно, не единственный.

Хуже того, в большинстве больших опенутых проектов набегают новички, которые даже уже основ НЕ смогли понять и радостно начинают ваять альтернативные яйца в профиль, но уже совсем через анус .

У меня такой подход - сначала кубом делается инициализация и настройка по максимуму.
Затем дебаггером прохожу и смотрю что всё действительно как задумывалось.
После этого выкидываю всё лишнее (вместе с кубовскими поделками).
Остается только то, что нужно (с коментариями из куба).
Из плюсов - не надо лазить по RM в поисках битов/регистров, более-менее понятные коментарии.
Ну и размер конечно.

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