interrupts

OH, come on. do not make "PC technology" a qualifier.
Completely ignoring my argument: level-trigged interrupts allows interrupt sharing. I han have a hardware with 100+ signals to supervise. I can't readily have a hw chip with 100+ interrupt pins. Oring of interrupt sources is a very valid concept and can't be ignored "just because".
I have no problem with your statement "sometimes you need level" however I DO have a problem with "PC technology as a qualifier". Now I ask you: "what makes it more difficult to kill a hung level in an ISR than in the main" and "how often in true non-exotic embedded do you operate with limited capability" DO note, that I am by no means saying that you, in case of (partial) failure should not provide a safe "shut down"

ISR reading it is cheap (2 lines) you can skip processing it if you need to.
Yes, it's enough to turn off a flag to disable an interrupt. But it can be very hard for an ISR to know that there is a problem and make the decision to disable itself. And if you do add code, it can be very hard to test that code.
not really. I'll illustrate with an example: A 'parallel read' ISR detect that the value it supplied to the main has not been read OOPS>

A round-robin loop will not starve any other device/signal making sure that low-priority (as in allowing a long latency but requiring a finite finish time) will get serviced.
as stated above an ISR can do the same

Now you are talking PC again. an embedded syatem has no purpose "continuing with limited capabilities"
No! You have a rigid mind, and have decided that you want to think that I am talking PC. You also want to think that no embedded system has a purpose continuing with limited capabilities.
as above I hold "continuing with limited capabilities" to be advanced exotic, whereas I fully agree in "going failsafe" e.g. an elevator shold go to a floor and stop, open the door and shut down.

The electronics in your car detects a malfunction. The "best" way would probably be to turn off. However, loosing your engine on a freeway can be very dangerous, so your little embedded system will just have to try to continue, even if blindfolded.
OK, I'll almost buy that one. However the transmission processor in my former truck did not "continue with limited capabilities" but went failsafe (permanent 2nd gear)

An elevator controller can't just blindly shut down either. but neither "continue with limited capability" that would be dangerous, It should go to a safe place.

Should a bus-stop sign turn off just because the light sensor has started to report completely bogus values?
Not a bus stop but a bus sign (my product) goes 'failsafe' in that case. There are rules and regulations that prohibit e.g. full intensity after dark.

A traffic light that detects an error should do it's darndest to try to flash a yellow light
again not "working with limited capability, but going to failsafe mode.

Everywhere around you, the world is full of embedded systems that can't be allowed to just "blue screen" or turn off, but should go to failsafe mode

I would always, where appropiate provide 'failsafe' but have yet to come across 'working with limited capabilities'.

Now to conclude: I really do not see what "working with limited capabilities" has to do with ISR vs polling. In either case you can detect the OOPS and, in my case, go failsafe. what you do is, ofc course depending on the spec you are given.

I know of NOTHING you can not equally well make detect an oops in an ISR as in polled mode. But I do know a whole lot of failures that have been due to someones interruptifobia.

have a great weekend

Erik

OH, come on. do not make "PC technology" a qualifier.
Completely ignoring my argument: level-trigged interrupts allows interrupt sharing. I han have a hardware with 100+ signals to supervise. I can't readily have a hw chip with 100+ interrupt pins. Oring of interrupt sources is a very valid concept and can't be ignored "just because".
I have no problem with your statement "sometimes you need level" however I DO have a problem with "PC technology as a qualifier". Now I ask you: "what makes it more difficult to kill a hung level in an ISR than in the main" and "how often in true non-exotic embedded do you operate with limited capability" DO note, that I am by no means saying that you, in case of (partial) failure should not provide a safe "shut down"

ISR reading it is cheap (2 lines) you can skip processing it if you need to.
Yes, it's enough to turn off a flag to disable an interrupt. But it can be very hard for an ISR to know that there is a problem and make the decision to disable itself. And if you do add code, it can be very hard to test that code.
not really. I'll illustrate with an example: A 'parallel read' ISR detect that the value it supplied to the main has not been read OOPS>

A round-robin loop will not starve any other device/signal making sure that low-priority (as in allowing a long latency but requiring a finite finish time) will get serviced.
as stated above an ISR can do the same

Now you are talking PC again. an embedded syatem has no purpose "continuing with limited capabilities"
No! You have a rigid mind, and have decided that you want to think that I am talking PC. You also want to think that no embedded system has a purpose continuing with limited capabilities.
as above I hold "continuing with limited capabilities" to be advanced exotic, whereas I fully agree in "going failsafe" e.g. an elevator shold go to a floor and stop, open the door and shut down.

The electronics in your car detects a malfunction. The "best" way would probably be to turn off. However, loosing your engine on a freeway can be very dangerous, so your little embedded system will just have to try to continue, even if blindfolded.
OK, I'll almost buy that one. However the transmission processor in my former truck did not "continue with limited capabilities" but went failsafe (permanent 2nd gear)

An elevator controller can't just blindly shut down either. but neither "continue with limited capability" that would be dangerous, It should go to a safe place.

Should a bus-stop sign turn off just because the light sensor has started to report completely bogus values?
Not a bus stop but a bus sign (my product) goes 'failsafe' in that case. There are rules and regulations that prohibit e.g. full intensity after dark.

A traffic light that detects an error should do it's darndest to try to flash a yellow light
again not "working with limited capability, but going to failsafe mode.

Everywhere around you, the world is full of embedded systems that can't be allowed to just "blue screen" or turn off, but should go to failsafe mode

I would always, where appropiate provide 'failsafe' but have yet to come across 'working with limited capabilities'.

Now to conclude: I really do not see what "working with limited capabilities" has to do with ISR vs polling. In either case you can detect the OOPS and, in my case, go failsafe. what you do is, ofc course depending on the spec you are given.

I know of NOTHING you can not equally well make detect an oops in an ISR as in polled mode. But I do know a whole lot of failures that have been due to someones interruptifobia.

have a great weekend

Erik

Hello again erik,
you wrote:
I would always, where appropiate provide 'failsafe' but have yet to come across 'working with limited capabilities'

Now I am probably a little fish when compared to you, but yesterday I had a discussion with a colleague that worked for a company making communication equipment for trains and she seemed to contadict the above statement. In their products, when digital control is gone (processor fried, some software failure) they switch to analog control driven by a small CPLD, which has very limited capabilites indeed (due to hardware cost).

I would always, where appropiate provide 'failsafe' but have yet to come across 'working with limited capabilities'

Now I am probably a little fish when compared to you, but yesterday I had a discussion with a colleague that worked for a company making communication equipment for trains and she seemed to contadict the above statement. In their products, when digital control is gone (processor fried, some software failure) they switch to analog control driven by a small CPLD, which has very limited capabilites indeed (due to hardware cost).

so the "digital control" is failsafe and if it fails the rest works with "limited capabilites".

where is the contradiction.

Most radio stations have a backup transmitter, a backup is not the main working with limited capabilities, it is a backup (which may have less power).

Erik

Agreed, but consider the following: if your main controller and the backup run the same code and are generally the same system, it is very possible the even the backup will not deal well with the conditions that killed daddy (given that it is a software failure, of course). example? The Arian 5 self destruction...