Господа эксперты! Помогите разобраться!
Использую HAL для небольшого проекта, хочу ловить EXTI, столкнулся с тем, что в различных уроках обработчик прописывают по разному, кто b main.c функцией , кто в stm32f1xx_it.c, причем во втором случае юзеркод мы can воткнуть в два места.

Вопрос: Как лучше то!?
Сам искал ответа в гугле, в хол_мануале, по файлам библиотек не понял
Кто умеет, плиз, накидайте полезных ссылок или пару строк объяснений как это делают опытные кошатники

Лучше отказаться от лишнего слоя абстракции - HAL и писать на регистрах или с использованием SPL. Это проще и оптимальнее.

Согласен. Но сейчас хочу разобратсья с Hal

А с каких пор SPL не "слоя абстракции" и чем он внезапно стал лучше чем HAL?


Это очевидно не проще и очевидно не оптимальнее.



Обычно можно почитать в HAL мануале + вы можете посмотреть определение этих функций.
Лучше сразу учится читать мануалы и все такое, без этого никуда. А потом уже пофиг будет на чем и что и какие камни программить

Достаточно изучить код библиотек SPL и HAL чтобы понять что в SPL меньше лишних действий.

Не проще в том плане что кроме даташита нужно еще изучать документацию на HAL. Не хочется разбираться с регистрами, есть SPL.
В коде HAL библиотеки много лишнего и про оптимальность говорить не нужно. Это все равно что сказать что оптимально ехать из Москвы в Подмосковье через Камчатку.

Если говорить о проектах, собранных из кубиков (STM32CubeMX), то лучше всего вписать в main между /* USER CODE BEGIN Includes */ и /* USER CODE END Includes */ #include для своего хедера, в котором, среди прочего, прописана программа, допустим, void my_main(void); а между /* USER CODE BEGIN 2 */ и /* USER CODE END 2 */ вызов этой программы. Хедер и программу поместить в папки inc и src кубического проекта, после чего забыть обо всём, нагенерированном Кубиком и писать свой код только в этих .h и .c файлах. Достоинства: не надо ковыряться и размещать свой код во множестве нагенерированных файлов, в любой момент можно выкинуть этот проект и собрать из кубиков новый, после чего вписав в кубический main те самые две строчки спокойно подключить всё своё наработанное к новому проекту.

А по существу заданного вопроса, проще всего вписать в тот самый свой .c-файл, в котором, собственно, и пишем свою программу, функцию
void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin)
в которой и обрабатывать EXTI.

Отчасти разве что. По сути они почти одинаковые. HAL просто написан более универсально.



А что документацию на SPL изучать уже не надо? боже что ты несешь.



С SPL видимо все разбираются с детства, еще со времен когда учатся шнурки завязывать.



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

Итого: не оптимальнее с точки зрения времени и не проще.

Я могу понять, что бы топить за чистый цимис, ладно, возбуждает тебя дротить регистры, и говорить "какой я молодец, вот тут я использую битмаппинг портов и экономлю по 2 операции" это еще можно понять. Но что бы топить за SPL вместо HAL это чем надо думать? HAL поддерживается и развивается, кучу продуктов ST выпускается из расчета автоматизации разработки. Явно перспективнее переложить автоматизацию на плечи разработчика камня и заниматься логикой. Обновления HAL выходят постоянно, дыри и проблемы закрываются и он уже давно работает хорошо.

Если кто то привык пользоваться определенными инструментами это еще не значит что объективно их нужно советовать.

Представьте себе.
Я раньше немного использовал куб и не раз сталкивался с багами и отличиями в зависимости от версии. Было и такое что генерированный проект переставал компилироваться после обновления куба приходилось создавать проект с нуля, все настраивать и переносить код с предыдущего проекта тратя на это время и силы. Так что да, использование SPL сэкономит время. Я в этом на практике убедился.

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

И не один раз. И мой подход (две строчки в кубическом main(), а все остальное - в своих .c и .h) позволяет сократить перенос кода с предыдущего проекта до минимума. Остается чисто кубическая работа - настроить интерфейсы, назначить ножки и т.п., т.е. то самое, для чего это Кубик, в общем-то, и предназначен.

То же самое весьма полезно и при переходе на другой камень. Я клепаю один проект, начал его на STM32F103VET6, потом без проблем перенес его на STM32F407VET6. Модифицировать текуший проект Кубик не дал, так я, по-простому, нащелкал новый, подключил к нему свои исходники, которые были в проекте с F103, и все. Ну, не считая того, что у 407-го ножками GPIO манипулируют слегка по-другому (часть регистров другие), пришлось подправить. В итоге, я спортил проект со 103-го на 407-й меньше, чем за полдня.