interrupts

A level-trigged interrupt can kill an application if the external hardware for some reason gets into trouble and don't deactivate the input signal.
1) why ever use level triggered
2) how would polling not "kill an application" if the above happened.

A memory overwrite somewhere that happens to turn on an interrupt source too much which the ISR wasn't supposed to handle, can also result in the application locking up. Every time the ISR returns, the processor generates a new interrupt because the ISR didn't know to clear/acknowledge the event flag.
1) "A memory overwrite" will get you in trouble regardless of interrupt or polling.
2) "the ISR didn't know to clear/acknowledge the event flag" is a programming error which will give trouble regardless

The interrupt handler would need some protective logic to try and detect an unreasonable amount of interrupts, while a polling loop would iterate through all input sources without needing deadlock-protection.
here you, while being correct in the statemnt are wrong. If "an unreasonable amount of interrupts" happen something is wrong and polling will not remove what is wrong.

Remember that even if most embedded applications tend to use interrupts, our toolbox of possible solutions can be very large, and there are always situations where multiple solutions can solve a problem in a good way.
Of course, I agree with this, however, I see waaaay too much interruptifobia getting people in trouble.

I can't really see a reason to argue against polling. It is just one very valid method to implement something.
I both agree and disagree.
Polling IS a solution in some (rare) instances, however, it should not be a preference because of the side effects or interruptifobia. I have seen way more polling, that ISRs falling by the wayside when an unrelated change was made.

In a situation where every single device is interrupt-driven, it can be very hard to know if the main loop is guaranteed to always have enough CPU capacity available to be able to do the required processing of received data.
same for polling. Whether you use an ISR or polling, the "CPU capacity available" must handle the same 'exceptions' (e.g. much UART processing vs none)

In a system where some devices are polled, the system may for example gracefully decrease the poll frequency of the polled devices. An example is to poll the ADC to check the voltage of an accumulator. No data is lost by the poll frequency being reduced at high load. It just affects how fast the unit turns off to protect the accumulator from deep-discharge.
equally easy to do in an ISR. just say "if the main do not get every value read in the (2 line ling) ISR processed, so what.

ONE ISSUE: if you use this microcontroller (the '51) as a microprocessor it does, of course, not matter the least which method you use. However in most microcontroller applications the 'cost' of missing an event is very high.

Erik

PS I do, very rarely, use polling and IMHO polling routines takes much more care to write re impact than ISRs.

A level-trigged interrupt can kill an application if the external hardware for some reason gets into trouble and don't deactivate the input signal.
1) why ever use level triggered
2) how would polling not "kill an application" if the above happened.

A memory overwrite somewhere that happens to turn on an interrupt source too much which the ISR wasn't supposed to handle, can also result in the application locking up. Every time the ISR returns, the processor generates a new interrupt because the ISR didn't know to clear/acknowledge the event flag.
1) "A memory overwrite" will get you in trouble regardless of interrupt or polling.
2) "the ISR didn't know to clear/acknowledge the event flag" is a programming error which will give trouble regardless

The interrupt handler would need some protective logic to try and detect an unreasonable amount of interrupts, while a polling loop would iterate through all input sources without needing deadlock-protection.
here you, while being correct in the statemnt are wrong. If "an unreasonable amount of interrupts" happen something is wrong and polling will not remove what is wrong.

Remember that even if most embedded applications tend to use interrupts, our toolbox of possible solutions can be very large, and there are always situations where multiple solutions can solve a problem in a good way.
Of course, I agree with this, however, I see waaaay too much interruptifobia getting people in trouble.

I can't really see a reason to argue against polling. It is just one very valid method to implement something.
I both agree and disagree.
Polling IS a solution in some (rare) instances, however, it should not be a preference because of the side effects or interruptifobia. I have seen way more polling, that ISRs falling by the wayside when an unrelated change was made.

In a situation where every single device is interrupt-driven, it can be very hard to know if the main loop is guaranteed to always have enough CPU capacity available to be able to do the required processing of received data.
same for polling. Whether you use an ISR or polling, the "CPU capacity available" must handle the same 'exceptions' (e.g. much UART processing vs none)

In a system where some devices are polled, the system may for example gracefully decrease the poll frequency of the polled devices. An example is to poll the ADC to check the voltage of an accumulator. No data is lost by the poll frequency being reduced at high load. It just affects how fast the unit turns off to protect the accumulator from deep-discharge.
equally easy to do in an ISR. just say "if the main do not get every value read in the (2 line ling) ISR processed, so what.

ONE ISSUE: if you use this microcontroller (the '51) as a microprocessor it does, of course, not matter the least which method you use. However in most microcontroller applications the 'cost' of missing an event is very high.

Erik

PS I do, very rarely, use polling and IMHO polling routines takes much more care to write re impact than ISRs.