STM32 NVIC priority

[MichaelAtSamraksh]

NVIC_PriorityGroupConfig(NVIC_PriorityGroup_0); vs 4.

(*Nathan posted a line comment when I asked if he knew about the change. I am creating an issue to document the problem for future reference.)

Changing interrupt controller priority grouping has the potential to have a big impact on our performance. I recall that using zero priority groups makes all interrupts equal so potentially less likely to starve low priority-interrupts. But using zero priority groups could starve high-priority interrupts. This is why blanket large commits like 5bd4e5f6019a780faa9a9cedf87fbf4fd58db7ff are a really bad idea-- 13k additions and 6k deletions without provenance to back up the changes. No idea when it was changed before the big commit.

this could affect our ability to get good timing.

We have been down this road before (around late 2014) when the priority grouping was being changed for some USART testing.

After this is address, we need to add a comment near STM32__AITC.cpp line 109 to consult everybody before changing NVIC settings.

[MichaelAtSamraksh]

... I think that this is relatively high priority but below Demo prep priority unless we immediately need better timing.

... also the test should be to execute different priority groupings while running Nathan's interrupt statistics counter or better, since some interrupts are wired directly out of the STM32_AITC.cpp code if i recall.

[Nathan-Stohs]

... also the test should be to execute different priority groupings while running Nathan's interrupt statistics counter or better, since some interrupts are wired directly out of the STM32_AITC.cpp code if i recall.

You mean wired (that is, defined) outside of STM32_AITC.cpp? Only USART1_IRQHandler as I recall.

[MichaelAtSamraksh]

Yes, I wanted to note for future reference that if we go that route of counting ISR calls, we need to be sure to extend the ISR counter code to all ISR entry points including USART1_IRQHandler.