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

1. Есть две функции приема по CAN: HAL_CAN_Receive() и HAL_CAN_Receive_IT(). В чем между ними разница? Генерит ли HAL_CAN_Receive() прерывания, если нет - как ей пользоваться?
2. При каких условиях запускаются обработчики прерываний USB_LP_CAN1_RX0_IRQHandler() и CAN1_RX1_IRQHandler()?
3. Как пользоваться HAL_CAN_RxCpltCallback() и почему Cube не создает эту функцию вместе с прочими обработчиками прерываний?

Примеров c HAL в интернетах очень мало, поэтому я не смог найти ответов на эти вопросы... заранее спасибо.

Сообщение отредактировал nya - Nov 11 2015, 08:41

1. Из названия понятно, кажется мне. Если нет прерываний - ждем-опрашиваем.
3. Создает пустышку-затычку с атрибутом __weak. Ведь никто не может читать Ваши мысли... Вы сами у себя в программе пишите обработчик. Без атрибута, тогда Ваша код будет иметь приоритет.

Но зачем два обработчика - Handler и Callback?

Это для того, чтобы Вы не возились с регистрами. HAL - Hardware Abstraction Level (Layer).

Так это понятно. Но я сейчас нашел таки рабочий пример для CAN - http://geektimes.ru/post/255534/
Похоже, в моем коде были неправильно выставлены настройки фильтров, вот прерывания и не вызывались.
Поэкспериментировав, выяснил, что оба этих обработчика работают одинаково хорошо. И запускаются одновременно. Поэтому все-такие непонятно в чем между ними разница и когда нужно использовать Handler, а когда - Callback. В обоих случаях "ручной труд" с регистрами равен нулю.

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

То есть я должен писать обработчики Callback в main.c вместо того, чтобы лезть в stm32***_it.c?

Пишите, где хотите... в своем коде. Ведь их код может быть со временем изменен в новой версии.

Да. Так будет правильно.

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

этот HAL переплюнул легендарный индусский код. Его даже в кач-ве справочника использовать нельзя.
но и это цветочки.
по идее, описание регистров всей линейки stm32 должно уместиться в пару файлов 25-30 кб, с весьма удобным API вместо 100 метровых библиотек ни о чем.

Сообщение отредактировал _Pasha - Nov 12 2015, 04:34

Как правило: тот кто не хочет возиться с регистрами, возится с кучей кривых исходников написанных школьниками. А потом ещё идёт и строчит в форумы "хелп ми!"....


согласен с Вами.

Я за среднее. Не люблю возиться с регистрами (тем не менее, знаю их и могу анализировать исходники), но и HAL - ужас.
Должна быть либа, абстрагирующая от регистров с четким todo. stdlib был ближе к моему идеалу, нежели HAL. libopencm3 - ничего

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

Подниму тему по аналогичному вопросу.
Есть STM32 с bsp кокос. Есть пины подключенные в ISM приемопередатчику и отслеживающие его состояния(помимо SPI связи с ним) Задача в обработчике прерывания запрещать и разрешать прерывания(в т.ч. в обработчике скажем void EXTI2_IRQHandler(void) его же и запрещать) ну и дополнительно переключать срабатывания по фронтам. Т.е четко отслеживать передний фронт и потом переключиться на отслеживание заднего фронта.
По запрещению и разрешению:
Сначала пробовал с помощью NVIC_EnableIRQ(); NVIC_DisableIRQ();
Потом написал поделку c использованием NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE/DISABLE
Работает на половину ((
Вопрос такой: надо ли после каждого такого телодвижения заново инициализировать PIN по пути GPIO->EXTI->NVIC?
К сожалению лог/анализатора нет и в схему также вносит значительные искажения отладка.