I am not sure if this is the appropriate place to ask this, could instead open up Issue versus OpenCr and/or documentation… Or maybe does not mater?
Looking at the sstm32f74.pdf file in chapter 10 NVIC, it talks about
What I am wondering is 16 priority levels… It does not include very much information about this, except:
All interrupts including the core exceptions are managed by the NVIC. For more information
on exceptions and NVIC programming, refer to programming manual PMxxxx.
So wondering which manual is this?
I am also wondering what strategy is or should be used for assigning the interrupt priorities. I would assume things like system clocks would have the highest priority, maybe some high speed peripheral devices with little overhead will be next, like UART data available… And maybe most things Mid value…
What I see currently in the code is:
variants/OpenCR/hw/driver/drv_can.c: HAL_NVIC_SetPriority(CAN1_RX0_IRQn, 4, 0);
variants/OpenCR/hw/driver/drv_can.c: HAL_NVIC_SetPriority(CAN2_RX1_IRQn, 4, 1);
variants/OpenCR/hw/driver/drv_exti.c: HAL_NVIC_SetPriority(EXTI0_IRQn, 2, 0);
variants/OpenCR/hw/driver/drv_exti.c: HAL_NVIC_SetPriority(EXTI1_IRQn, 2, 0);
variants/OpenCR/hw/driver/drv_exti.c: HAL_NVIC_SetPriority(EXTI2_IRQn, 2, 0);
variants/OpenCR/hw/driver/drv_exti.c: HAL_NVIC_SetPriority(EXTI3_IRQn, 2, 0);
variants/OpenCR/hw/driver/drv_exti.c: HAL_NVIC_SetPriority(EXTI4_IRQn, 2, 0);
variants/OpenCR/hw/driver/drv_exti.c: HAL_NVIC_SetPriority(EXTI9_5_IRQn, 2, 0);
variants/OpenCR/hw/driver/drv_exti.c: HAL_NVIC_SetPriority(EXTI15_10_IRQn, 2, 0);
variants/OpenCR/hw/driver/drv_i2c.c: HAL_NVIC_SetPriority(I2C1_EV_IRQn, 0, 0);
variants/OpenCR/hw/driver/drv_i2c.c: HAL_NVIC_SetPriority(I2C1_ER_IRQn, 0, 0);
variants/OpenCR/hw/driver/drv_i2c.c: HAL_NVIC_SetPriority(I2C2_EV_IRQn, 0, 0);
variants/OpenCR/hw/driver/drv_i2c.c: HAL_NVIC_SetPriority(I2C2_ER_IRQn, 0, 0);
variants/OpenCR/hw/driver/drv_spi.c: HAL_NVIC_SetPriority(DMA1_Stream4_IRQn, 1, 1);
variants/OpenCR/hw/driver/drv_spi.c: HAL_NVIC_SetPriority(DMA1_Stream3_IRQn, 1, 1);
variants/OpenCR/hw/driver/drv_spi.c: HAL_NVIC_SetPriority(DMA2_Stream1_IRQn, 1, 1);
variants/OpenCR/hw/driver/drv_spi.c: HAL_NVIC_SetPriority(DMA2_Stream0_IRQn, 1, 1);
variants/OpenCR/hw/driver/drv_timer.c: HAL_NVIC_SetPriority(TIM4_IRQn, 10, 0);
variants/OpenCR/hw/driver/drv_timer.c: HAL_NVIC_SetPriority(TIM1_UP_TIM10_IRQn, 10, 0);
variants/OpenCR/hw/driver/drv_timer.c: HAL_NVIC_SetPriority(TIM8_UP_TIM13_IRQn, 10, 0);
variants/OpenCR/hw/driver/drv_timer.c: HAL_NVIC_SetPriority(TIM8_TRG_COM_TIM14_IRQn, 10, 0);
variants/OpenCR/hw/driver/drv_timer.c: HAL_NVIC_SetPriority(TIM6_DAC_IRQn, 10, 0);
variants/OpenCR/hw/driver/drv_uart.c: HAL_NVIC_SetPriority(USART6_IRQn, 0, 0);
variants/OpenCR/hw/driver/drv_uart.c: HAL_NVIC_SetPriority(DMA1_Stream5_IRQn, 0, 0);
variants/OpenCR/hw/driver/drv_uart.c: HAL_NVIC_SetPriority(USART2_IRQn, 0, 0);
variants/OpenCR/hw/driver/drv_uart.c: HAL_NVIC_SetPriority(DMA1_Stream1_IRQn, 0, 0);
variants/OpenCR/hw/driver/drv_uart.c: HAL_NVIC_SetPriority(USART3_IRQn, 0, 0);
variants/OpenCR/hw/driver/drv_uart.c: HAL_NVIC_SetPriority(UART8_IRQn, 0, 0);
variants/OpenCR/hw/usb_cdc/usbd_conf.c: HAL_NVIC_SetPriority(OTG_FS_IRQn, 6, 0);
variants/OpenCR/hw/usb_cdc/usbd_conf.c: HAL_NVIC_SetPriority(OTG_HS_IRQn, 6, 0);
The ones for i2c are ones I am playing with and I will change those to a lower priority. Not sure what, maybe 8?
Question, should these be documented somewhere? Should user code be able to understand this and change some of the default values. Example suppose I wish connect something to GPIO pin 2 and have it do something when the pin changes state: attachInterrupt(2, &my_function)
And we wish to do this only when things are pretty idle, i.e. at a low priority. The hard part here is knowing that this pin would go to interrupt: EXTI9_5_IRQn
And this same interrupt is used for interrupt pins 5-9 This one is pin 6.
Another question/wondering: Are the interrupt vectors fixed at compile/boot time or can they be dynamically set? That is is the interrupt vector stored in ROM or RAM? On Teensy boards, the interrupt vector is moved to RAM at startup time, this allows calls like attachInterruptVector(, &function);
Which like most things as pros and cons. Cons are the vector could get corrupted.
Pros; If this is available, I would probably use it with Wire library. Why have interrupt vector pointing to code in HAL/Drv code base for those apps not using I2C? instead if the begin() method calls to HAL/DRV could install the driver at install time, then if nothing in system references Wire, than this code is not brought in.
Likewise maybe there could be two different implementations of I2C code (Wire or I2c…), which could define their own interrupt handler…
Again used on Teensy for examples like the above for external pin 2, but instead I need it as fast as possible. Currently the ISR has calls to check the state of interrupt pins 5, 6, 7, 8, 9 and if I know my app will only use interrupt on that one pin, than could have the code instead just call: HAL_GPIO_EXTI_IRQHandler(GPIO_PIN_6);
Again not sure if this is the appropriate place to ask these questions…