STM32 HAL EXTI

[Vadim1984]

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

Код: Выделить всё

void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin)

, кто в stm32f1xx_it.c, причем во втором случае юзеркод мы can воткнуть в два места.

Код: Выделить всё

void EXTI1_IRQHandler(void)
{
  /* USER CODE BEGIN EXTI1_IRQn 0 */

  /* USER CODE END EXTI1_IRQn 0 */
  HAL_GPIO_EXTI_IRQHandler(GPIO_PIN_1);
  /* USER CODE BEGIN EXTI1_IRQn 1 */

  /* USER CODE END EXTI1_IRQn 1 */
}

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

[Мурик]

Вопрос: Как лучше то!?

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

[Vadim1984]

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

[tar]

или с использованием SPL

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

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

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

Вопрос: Как лучше то!?

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

[Мурик]

чем он внезапно стал лучше чем HAL

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

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

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

[afz]

Если говорить о проектах, собранных из кубиков (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.

[tar]

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

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

Не проще в том плане что кроме даташита нужно еще изучать документацию на HAL

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

Не хочется разбираться с регистрами, есть SPL.

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

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

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

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

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

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

[Мурик]

Оптимальнее с точки зрения чего? времени?

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

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

[afz]

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

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

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