how to choose wisely the interrupt priorities?

Go To Last Post
14 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello!

 

I'm working on a project that uses lot of hardware: four serial ports, one spi, one i2c, 5 ADC inputs. What I want to know is the right way to choose the priority of each device. I can't find any document that explain the right way to do it, or examples. Just how to change the interrupt priority. The system uses a cortex-m0+ uC.

 

Thanks!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Read up on the NVIC.
Do you really need to prioritise the interrupts?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
Read up on the NVIC. Do you really need to prioritise the interrupts?

 

I think I do. In one sercom I'm receiving GPS NMEA messages: on a RX interrupt, I push into a FIFO, and in the main, I extract and process. 50% of the messages had bad checksum and I've noticed that was because I was missing characters. In the main I had a delay_ms(500) for debuggin purposes and that was the problem. After removing the delay_ms(500) the checksum problems ended. And the delay functions were working with systick at 1KHz.

 

That made me think that I need to check the interrupt priorities. That and some hardware fault interrupts.

 

I've checked on NVIC and found how to change interrupt levels and how the interrupt works in Cortex-m0 but my doubt is more a software design question more than how to implement it. 

 

thanks!!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jarge.ar, I have the same problem whereby it appears some of the data in the NMEA sequence is missing or incorrect.  let me know if you find a solution to the problem.  like you I think it is a software issue.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The first question is: do you really need to use interrupts? If the i2c is the master, then you probably don't need interrupts for i2c. Similarly with the adc - do you need to sample at specific intervals or are you just reading some voltages? The main interrupts I'd use would be for a timer tick at,say, 10ms and serial interrupts.

In your current situation, one would expect the serial isr would execute quickly, but what about the adc and others? I'd suggest you try to identify the root cause so you can make a decision based on numbers, not guesses. For the most part, your serial, i2c and spi interrupts should only take a couple of microseconds each to execute. With GPS data at 4800 or 9600 baud, you have 2 or 1 ms per char to read the incoming data. Thus there should be heaps of time to process the data in main() without worrying about interrupt priorities.

 

Hardware fault interrupts are usually caused by accessing peripherals that aren't enabled and a clock applied,  out of range memory accesses or unaligned memory accesses.

In general, try to ensure your isrs do only what is needed - no lengthy computations, delays etc. Get in, do the job and get out as soon as possible. The AVR has no interrupt priorities and we seem to survive pretty well without them. 

 

If you had 500ms delay in main, that equates to 500 characters at 9600 baud - was your receive buffer big enough to handle that?

You might want to check how fast your processor is actually running - maybe it's only running the at the default speed which could be significantly less the the 48MHz or whatever you expect.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does an AVR have an NVIC? Isnt there a custom of spelling out acronyms at first use? Thats one I havent ever seen.

 

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jorge.ar wrote:
The system uses a cortex-m0+ uC.

Then why post in this forum for AVR users vs. the Atmel ARM forum, where readers will know your processor better?

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Mon. May 30, 2016 - 12:28 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

theusch wrote:

jorge.ar wrote:
The system uses a cortex-m0+ uC.

Then why post in this forum for AVR users vs. the Atmel ARM forum, where readers will know your processor better?

 

 

Why? Because this is about design, not cortex-m0+. The answer to my question applies to all microcontrollers with interrupt priorities.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:

The first question is: do you really need to use interrupts? If the i2c is the master, then you probably don't need interrupts for i2c. Similarly with the adc - do you need to sample at specific intervals or are you just reading some voltages? The main interrupts I'd use would be for a timer tick at,say, 10ms and serial interrupts.

In your current situation, one would expect the serial isr would execute quickly, but what about the adc and others? I'd suggest you try to identify the root cause so you can make a decision based on numbers, not guesses. For the most part, your serial, i2c and spi interrupts should only take a couple of microseconds each to execute. With GPS data at 4800 or 9600 baud, you have 2 or 1 ms per char to read the incoming data. Thus there should be heaps of time to process the data in main() without worrying about interrupt priorities.

 

Hardware fault interrupts are usually caused by accessing peripherals that aren't enabled and a clock applied,  out of range memory accesses or unaligned memory accesses.

In general, try to ensure your isrs do only what is needed - no lengthy computations, delays etc. Get in, do the job and get out as soon as possible. The AVR has no interrupt priorities and we seem to survive pretty well without them. 

 

If you had 500ms delay in main, that equates to 500 characters at 9600 baud - was your receive buffer big enough to handle that?

You might want to check how fast your processor is actually running - maybe it's only running the at the default speed which could be significantly less the the 48MHz or whatever you expect.

 

You're right, I2C is in master mode and SPI too, and they are working pooled (accelerometer and flash memory). GPS and GSM are at low baud rates. I think I will start adding priorities to both serial ports to ensure that systick will not interrupt the fifo push. All my interrupts are really quick (just add data to ring buffers) and the ADC is working with a state machine. I can move to polled if necesary, it's just for measure a few voltages each 1 second.

 

Thanks kartman!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Fianawarrior wrote:

jarge.ar, I have the same problem whereby it appears some of the data in the NMEA sequence is missing or incorrect.  let me know if you find a solution to the problem.  like you I think it is a software issue.

 

I've already solved the problem removing the delay. something were blocking the ISR of data received. Use a circular buffer and in the main, look for start and end character of the nmea sentence. good luck!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jorge.ar wrote:
Why? Because this is about design, not cortex-m0+. The answer to my question applies to all microcontrollers with interrupt priorities.

<eye roll>  Tell again why you chose an AVR forum, and not one similarly titled and qualified with "ARM related" ?

 

Also tell me how you might >>choose<< an interrupt priority on an AVR8?  (it is nearly correct to say that AVR8 doesn't have interrupt priorities, other than the fixed order of servicing simultaneous events)

 

 

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Mon. May 30, 2016 - 09:54 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your systick should only be updating some timer variables. If it is doung much more than that, then you'll need to look carefully at your architecture as changing interrupt priorities might solve your initial problem but cause other problems. Have a read of my tutorial on multi-tasking part 1. I used this technique on a project that had 3gps, gyro, wifi and rf link.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
Your systick should only be updating some timer variables. If it is doung much more than that, then you'll need to look carefully at your architecture as changing interrupt priorities might solve your initial problem but cause other problems. Have a read of my tutorial on multi-tasking part 1. I used this technique on a project that had 3gps, gyro, wifi and rf link.

 

My systick does almost nothing.. just turn on/off status leds, compare the ticks to set flags and nothing else.

 

I will take a look at you tutorial, thanks a lot!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

bobgardner wrote:
Does an AVR have an NVIC?
XMEGA have a Programmable Multilevel Interrupt Controller (PMIC).

http://asf.atmel.com/docs/latest/search.html?search=pmic

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Tue. May 31, 2016 - 04:13 AM