Interrupt on interrupt

[thusharag]

I need to get know that what will happen if a macro run by an interupt ( such as TMR1)will be called by that interupt when running an another interrupt(such as TMR2) macro. And also i need to get know what will be happen if a macro run by an interupt will be called by that interupt when running the same interrupt macro. this second incident can be happened if we use big macro and higher frequency. on the other hand if the time between two interuupts is lower than the time taken to run (1 run) the exact macro asigned to it. Actually i need to get clear that in this both situations whether the currently running macro is running to the end ignoring the second or the currently running macro is stopped and run the second. please discuss this

[Jan Lichtenbelt]

Dear Ethushara,

More interrupts can be handled, depending on the number of maco calls and interrupts. They may not overflow the stack.

stack.jpg (61.19 KiB) Viewed 4659 times

Good programming prevents always that same interrupt called without ending the first (thesame) interrupt.
If you try, the result will be hard to check for faults and a stack overflow is often the result.

Kind regards

Jan Lichtenbelt

[Benj]

Hello,

Some devices may differ but this is how I see it.

An interrupt will always override the current processor call if the priority of the interrupt is greater to or the same as the current interrupt service routine. For devices without interrupt priority a new interrupt will cut in to an old interrupt macro.

Flowcode will only reset the interrupt once you have left the macro meaning if you are using a timer and the macro is longer then the period of the timer that the second and subsequent interrupts will be missed until the macro has finished.

It is always good practice to leave the interrupt macros as short as possible and do as much of the processing as you can inside the main program loop.

[medelec35]

I would also like to add:
I believe if you place a delay, or LCD routine (or any other component that has delays )or call to another macro within the delay, then the interrupt is re-enabled as soon as the interrupt macro is briefly left to service delay, or LCD routine of call to another macro. Not only will this add to the stack, it will cause corruption issues.
The interrupt routing must never be left except when reaches bottom of the interrupt.

Martin

[thusharag]

Thanks all for your details.I got the idea for flowcode.
And one more, i use to use my main program in an interupt macro coz i can set a frquency to run the program easyly and use the main program loop for just displaying some thing or sometimes just one run for starting.
But i know displying is giving wrong values sometimes as Mr martin said.
But one more advantage, if i use lcd and the main program in the main program loop wrong results comeout due to the delay of the lcd.So by using this way no issues with the main system and so don't care about the display as wrong values only in raretimes. And if i use the normal way the no of times the program run is depend on the program length so some calculation formulas have to be edited again when changing the program.
So by considering above details Please mention your adea, suggestions and disadvantages. Im looking forward for your any reply as im new to this.

[medelec35]

The best way of updating LCD is when a period of time has elapsed, then set a flag to 1, then in main or a different macro:

If Flag = 1 then update display : Flag = 0

If you don't mind sharing , would you like to post your flowchart ( PM if it's commercially sensitive) and we can help you to getting it working.

Martin