LAS9891

вот спасибо. Теперь выходит, для прерывания можно назначить только один источник. Товарищ был прав:

У меня на самом деле GD32F103RB, и тут я не нашёл System configuration controller Вообще пост получился исключительный. Мне было лень внимательно читать даташит и решил быстренько спросить на форуме. Я как всегда ожидал ответа в стиле "читай даташит", ну и готовился, что закидают помидорами, а тут на две страницы ответов/споров, даже после того, как я уже выяснил то, что хотел изначально. Магия блин. Вопрос не глобального масштаба - а популярности... В серьёзных темах ответа не дождешься, только "читайдаташитами" закидают.

Да ничего не мешает. Меня интересовало есть ли возможность проверить это по регистрам EXTIx, ну раз нет, значит определю по другому. проверим

Всем спасибо, я выяснил что хотел.

Согласен. Но изначально были условия: уже готовая схема, обязательный опрос кнопок по прерываниям.

Я думал, что я что-то не дочитал про External interrupt. Надеялся, что есть какой-то регистр (который относится к External interrupt), в котором это отражается.

Как же ответить на поставленный вопрос?

Есть stm32. На пин PA0 и на пин PB0 установлены кнопки. На оба пина настроено и включено прерывание NVIC_EnableIRQ(EXTI0_IRQn). Согласно документации PA0 и PB0 приходятся на линию EXTI0. При нажатии одной из кнопок возникает прерывание EXTI0_IRQHandler. Как в обработчике прерывания определить с какого пина возникло прерывание? Вариант 1: в обработчике прерывания проверить уровень на пинах PA0 и PB. Есть ещё варианты?

А как лучше? в main.c в while(1){} её ждать ?

Сохранили пару дней жизни мне

Почему именно должно? Если приоритет кнопки будет находиться в интервале между 10 и 15 (приоритеты 11, 12, 13, 14) это будет неправильно? Приоритет кнопки и configMAX_SYSCALL_INTERRUPT_PRIORITY обязательно должны быть равны? Или это рекомендация из соображений экономии памяти и т. д. ?

Почему? Хотя и так тоже работает Всё заработало когда сделал так: #define configKERNEL_INTERRUPT_PRIORITY 255 #define configMAX_SYSCALL_INTERRUPT_PRIORITY 175

Наверно имелось в виду: ((250 & 0xF0) >> 4) = 10 Согласны ли Вы с ? Я сделал так: #define configKERNEL_INTERRUPT_PRIORITY 255 #define configMAX_SYSCALL_INTERRUPT_PRIORITY 250 В контроллере прерывания настроил так: При запуске отладки, до нажатия кнопки (прерывания) всё вроде норм. После нажатия случается один раз прерывание и всё виснет тут: void vPortValidateInterruptPriority( void ) { uint32_t ulCurrentInterrupt; uint8_t ucCurrentPriority; /* Obtain the number of the currently executing interrupt. */ ulCurrentInterrupt = vPortGetIPSR(); /* Is the interrupt number a user defined interrupt? */ if( ulCurrentInterrupt >= portFIRST_USER_INTERRUPT_NUMBER ) { /* Look up the interrupt's priority. */ ucCurrentPriority = pcInterruptPriorityRegisters[ ulCurrentInterrupt ]; /* The following assertion will fail if a service routine (ISR) for * an interrupt that has been assigned a priority above * configMAX_SYSCALL_INTERRUPT_PRIORITY calls an ISR safe FreeRTOS API * function. ISR safe FreeRTOS API functions must *only* be called * from interrupts that have been assigned a priority at or below * configMAX_SYSCALL_INTERRUPT_PRIORITY. * * Numerically low interrupt priority numbers represent logically high * interrupt priorities, therefore the priority of the interrupt must * be set to a value equal to or numerically *higher* than * configMAX_SYSCALL_INTERRUPT_PRIORITY. * * Interrupts that use the FreeRTOS API must not be left at their * default priority of zero as that is the highest possible priority, * which is guaranteed to be above configMAX_SYSCALL_INTERRUPT_PRIORITY, * and therefore also guaranteed to be invalid. * * FreeRTOS maintains separate thread and ISR API functions to ensure * interrupt entry is as fast and simple as possible. * * The following links provide detailed information: * https://www.FreeRTOS.org/RTOS-Cortex-M3-M4.html * https://www.FreeRTOS.org/FAQHelp.html */ configASSERT( ucCurrentPriority >= ucMaxSysCallPriority ); // <-------------------------------------------------------ВОТ ТУТ } Что не верно?

3) Макрос configKERNEL_INTERRUPT_PRIORITY - это макрос, который определяет приоритет прерывания, используемого для тиков FreeRTOS. Т.е. это приоритет прерывания SysTick микроконтроллера равный 14. Так или не так? 4) Макрос configMAX_SYSCALL_INTERRUPT_PRIORITY - это макрос, который устанавливает наивысший приоритет ЧЕГО?, из которого могут быть вызваны защищенные для прерываний функции FreeRTOS API, т.е. функции в названии которых есть FromISR (например xSemaphoreGiveFromISR). Так или не так? Тока приоритет чего? прерываний или задач

1) Как вообще сосуществуют понятия приоритет прерываний и приоритет задач? Вот в STMке назначено 16 приоритетов вытеснения и 0 субприоритетов на прерывания. Эта цифра 16 относится только к приоритетам прерываний или ещё также и к приоритетам задач? 2) Вот в STMке чем меньше число (номер) приоритета, тем выше приоритет. Это утверждение относится только к приоритетам прерываний или и к приоритетам задач? 3) Макрос configKERNEL_INTERRUPT_PRIORITY - это макрос, который определяет приоритет прерывания, используемого для тиков FreeRTOS. Т.е. это приоритет прерывания SysTick микроконтроллера. Так или не так? 4) Макрос configMAX_SYSCALL_INTERRUPT_PRIORITY - это макрос, который устанавливает наивысший приоритет ЧЕГО?, из которого могут быть вызваны защищенные для прерываний функции FreeRTOS API, т.е. функции в названии которых есть FromISR (например xSemaphoreGiveFromISR). Так или не так? 5) Для макросов из пунктов 3 и 4 приоритеты должны быть выбраны из диапазона 0...15. Так или не так? Т.е. контроллер тут получается законодатель мод? 6) Везде пишут, что если SysTick используется для шедулера, то приоритет SysTickа нужно сделать самым низким, я сделал его 15 при настройке контроллера. Значит ли это, что и configKERNEL_INTERRUPT_PRIORITY должен быть равен 15 ?