How much code in an ISR is too much.

[Psi]

This is really one of those "How long is a piece of string" type questions and there is no 100% correct or 100% incorrect answer!

A piece of string is... half as long as twice it's length   

[andyturk]

A Smörgåsbord of debounce.

[TheRevva]

The bad habit (and being lazy) would be to not bother understanding why something is good or bad and always use what others tell you is more often good.

That's quite possibly the best advise of all the posts within this thread.  Once you can truly understand ALL the reasons behind making any given choice (whether writing code, or IRL), you can be more confident of having selected the optimum choice.  When you make choices using only some fraction of knowledge, you're inherently risking a poor choice, particularly in 'fringe' cases.  This doesn't always mean the worst will happen, but you ARE somewhat relying upon Murphy taking a holiday.

I would like to touch on my display update code...

And this is a perfect example...  I hadn't considered you were using a multiplexed display (and you hadn't told us... LOL).  In hindsight, it's quite logical to multiplex the display and almost every clock out there does precisely that!!

Once I've implemented a nested interrupt: The interrupt function was called with 1 kHz. It then resets the interrupt flag, so that the interrupt could trigger again. The interrupt function itself was two parts: a fast part, which updated and averaged sensor values, timestamps etc., with the full 1 kHz. The other part was executed every 64th time, resulting in a frequency of 16 Hz (doing some floating point PID calculation, key debouncing, menu logic etc.). This slower part was interrupted by the fast part. So a kind of prioritized task manager, but with deterministic update rates for the fast and the slow part.

This can get rather complex in a hurry.  Firstly, you have to be very careful to save the interrupt context in an atomic fashion (with each nesting of interrupts savings its context in unique memory areas), and then you have to add in the complexities surrounding re-entrant code fragments.  While I'm first to admit that there's a time and a place for almost everything, I'm equally quick to state that I only take options like this when there's absolutely no others available.  (And that includes asking myself whether I've selected the right microcontroller to begin with!  For example, it might be a 'better choice' to use PIC18 family devices with dual priority interrupts rather than trying to use PIC16 family devices?)  I'm trying to recall if we have ANY code remaining that still folds the bottom half code of the ISR back into the ISR itself...  I doubt it!

[Rufus]

And this is a perfect example...  I hadn't considered you were using a multiplexed display (and you hadn't told us... LOL).  In hindsight, it's quite logical to multiplex the display and almost every clock out there does precisely that!!

I had guessed the display was multiplexed and a regular interrupt is a convenient and efficient place to poll, debounce, and edge detect switch inputs. The actions on switch inputs will modify variables (current time, alarm time(s) etc) which are already being modified or inspected in the interrupt. Modifying them from foreground code is a small can of worms which can be avoided.

So in this case doing everything in a timer interrupt is probably a good solution. If that is all the program does then as someone else pointed out you could just spin waiting for a timer to pace foreground code at the same rate. You could even have an empty interrupt handler and use a halt/sleep to pace foreground code and save some power.

There are other applications where large amounts of code will be in interrupt handlers, continuous signal processing and PWM control for motor drives or switch mode power supplies for example. I don't accept unqualified statements that lots of code in an interrupt handler = bad, or that it is a sacking offence - lol.

[glatocha]

As long as you don't loose your interrupts it is not too much.

But I do something like this. In the interrupt I set the bit, for example:
Update_ADC = 1;

And in the main() I am pooling
if (Update_ADC)
{
   Update_ADC = 0;
   ... The ADC code her ...
}

[Psi]

There are other applications where large amounts of code will be in interrupt handlers, continuous signal processing and PWM control for motor drives or switch mode power supplies for example. I don't accept unqualified statements that lots of code in an interrupt handler = bad, or that it is a sacking offence - lol.

I think it boils down to the question being wrong ( "How much code in an ISR is too much." )
It should really be "What type of code belong inside an ISR"

The amount of "code" in an ISR doesn't mean anything.
You could have an 100 option switch/case statement. It would look massive but may only execute a few commands per interrupt call.
Or you could have 100 lines of time critical multiplexing code vs 100 lines of non-critical averaging code.

[blewisjr]

I agree the question is most likely asked wrong.  Despite that I still received a lot of both helpful and useful information that will help me in all my projects.