Is there a good practice for the NVIC Interrupt table priority ?

[Lionel1]

Hi,

Sorry for my stupid question but I am always in doubt when I give the priority in the NVIC table for DMA, UART, SPI, Timer, ...

Is there a rule like for example set all DMA at 0 ?

How to know what peripherals must have the highest priority and how to order them when you have several DMA, UART, ... ?

Thanks,

Lionel

[Tesla DeLorean]

Which part specifically? The CM0 handles things differently than the M3/M4

Generally I'd use the priority to encode pre-emption levels, the ordering of things within a level at the tail-chain point might have relevance if the loading is high, and persistent.

Make your interrupt handlers (and callbacks) SHORT, for a USART anything that takes more than 1 byte time needs to be deferred, ie serviced and queued for another task.

The RULE is understand what you're doing, what are the expectations with the interrupts, and the rate at which you are generating them.

Understand your available service window, if your DMA HT/TC are occuring at 100 ms intervals, and will continue without immediate intervention, you DON'T need to have a super-critical interrupt priority.

If you have to service something within 100us or it will break and lose data, you'd better give those immediate priority, and have them preempt whatever other nonsense you have going on.

Start by writing down a table of your interrupt sources, how frequently they might fire, in the worst case, and how much time you take to service them in the code called under interrupt context.

Doubt usually comes from a failure to understand how they system works, and what you're causing to happen in it. Start with a fundamental understanding of how the micro-controller functions and dispatches interrupts. The TRM (Technical Reference Manual) would be controlling document, for a softer interpretation perhaps review the books by Joseph Yiu.

[idrissmc]

Clive Two.Zero what do you mean by 1 byte time?

[Tesla DeLorean]

What @Bob S​ says in his post below

But basically the time it takes for you to receive a byte over the wire (per your understanding how serial transmission and USARTs actually function), for a stream of data packed tightly one byte after the other.

So say you're streaming a GPS/GNSS receiver with data at 9600 baud, your interrupt has received the last byte of a sentence and you want to parse/process that sentence. If your decode routines faffs about for 100ms, prints stuff to other USARTs, and blocks, you will miss characters coming in for the next sentence. Things that will take an indeterminate time to process and manage should be pushed to a worker task, or digested in your main() loop. Things which have absolute service deadlines, should be managed quickly in an interrupt handler, or callback routine.

Have you taken any lessons/schooling on C development or embedded programming?

[Bob S]

"1 byte time" is the time it takes to transmit or receive 1 byte over the UART (or SPI, or I2C). For example, for a UART with 8-bit data at 115200 baud, it takes 86.8us for one byte (8 data bits plus 1 start bit plus 1 stop bit). So if you are using interrupt driven Tx or Rx, you need to be able to service that UART's interrupt at least once every 86 microseconds.

[Lionel1]

Hi

Thanks for your answer. It is for M4 (STM32F4xx).

I understand the concept of "1 byte time" and that what I generally do. But when you have several things to do in the same time, for example get data from an UART, refresh the LCD by I2C, store the formatted data to a SD-Card by SPI, send others data in Wifi by SPI, ... you quickly go in doubt !!

In this example, UART is important so the priority is set to 0. LCD is not critical so I can set 2 or 3 for the priority. SD-Card and Wifi are set to 1.

But question : when you use DMA, you have to set 2 priority. One for DMA and one for the device. Do you must set the same priority for the two or higher for the DMA ?

Thanks,

Lionel