NVIC Question.

[siddj]

Posted on May 07, 2009 at 23:10

NVIC Question.

[siddj]

Posted on May 17, 2011 at 13:11

I have a timer that interrupts every 5 seconds. Inside the the timer IRQhandler, I have a loop which i cannot get out of for over 5 seconds in certain cases. When this happens, I end up missing the next interrupt cos i am stuck in my loop within my interrupt handler. Is there any way that I can unmask my interrupt, by getting out of the loop within my IRQ?

Here is the sample/pseudo code. //this interrupt happens every 5 seconds. TIM4_IRQHandler(void) { { .....loop which might be over 5 seconds in some cases...... need to break out of this loop if it is more than 5 seconds ............................. } }

[brunoalltest]

Posted on May 17, 2011 at 13:11

I don´t think it is a good ideia to have a Interrupt Handler that long.

I always try to keep interrupts as short as possible. There a lot of techniques that help it. I don´t know much about your application, but a state machine seems to fit it.

[miles]

Posted on May 17, 2011 at 13:11

5 seconds in an interrupt service routine is way too long. When I time my ISRs, if one is even near 1ms, I'll fix it. IMO you shouldn't spend more than a couple hundred clock cycles in any ISR, it'll cause you trouble eventually.

If you want a simple alternative, declare a volatile flag that is set by the ISR, and watch for it in your idle loop. This way you can still have interrupt driven drivers for things like UART communication, that will work no matter what the CPU usage is in the idle loop. If your ISR is for a hardware peripheral, you can do something easy like put the data from the hardware into a circular buffer (an array with a head and tail pointer, that wrap), and pull it out of there in your idle loop when you notice the flag is set. If you want a more complicated way to fix it, use an RTOS, and use multiple tasks, that communicate with queues, semaphores, or mutexes. I am using

http://www.freertos.org/

at work right now, and like it a lot. IMO it's just as good as commercial RTOSes that people pay a lot of money for, and it greatly helps architect modular software on a small microcontroller like an STM32. There are, of course, many cases where *any* OS is overkill, but until you have some experience with an RTOS, you can't very well identify those cases. So if you're a hobbyist, check out FreeRTOS, and even if your current project doesn't require that level of complexity, something you do in the future probably will.

[picguy]

Posted on May 17, 2011 at 13:11

I agree with the others on this thread. Anything even close to 5 seconds is WAY to long to hang in an ISR.

It sounds like you want (need?) to suspend your mainline for 5+ seconds. In your ISR I would fire up a lower priority ISR. Use some RAM flags to avoid reentrancy issues. A generalized approach uses what I call an EISR – Extended ISR. When an ISR can not finish in some reasonable number of microseconds a simple queue entry is made. It could be as simple as setting a bit in a word in RAM. If this is the only bit set in that word a lower priority interrupt service is entered. Else, the EISR is already running. In that case the EISR exit sees one or more work requests (bits) and calls the appropriate code. Cortex-M3 interrupts are fast. In/Out 24 clocks – including instruction prefetch if vectors and your code are in flash. The transition from a higher to lower priority ISR takes IIRC 4 or 6 clocks. It sounds as if you could use the design efforts of a senior person to recast your long-running ISR. I.e. don’t loop for something – interrupt when it happens. If this were a different type of forum I might try to sell some design expertise....