Many thanks for those who help me! (:
I got a problem here...
If i were to use 3 types of interrupts(external interrupt0, timer0 and timer1) in one single program, how should i go about writing the codes in the program?
Well, it's good enough for the PCI bus on a PC. OH, come on. do not make "PC technology" a qualifier.
A polling loop would just adjust its loop frequency. A interrupt-driven solution will completely starve low-prio interrupts. Don't assume that all interrupts produce received data, or ticks, and that a lower service frequency means a failure. A lower polling frequency of a temperature sensor need not break the application. and as I said in my previous post: "ISR reading it is cheap (2 lines) you can skip processing it if you need to. This, coming to think of it makes the reading an ISR and the processing polled. Anyhow, I would consider it an error if something, whether significant or not, was occasionally skipped.
2) we must also try to make our code self-repairing. ... were perfect, we would not need any watchdog timers... well a watchdog tries, in effect make a 'self repair" regardless of polled or ISR
An ISR is written to handle the conditions it has been specified to handle. That is not the same as being required to handle all possible events a device may be able to generate. If I don't turn on a FIFO for a serial device, there is no need for the ISR to know about FIFO events. However, a problem that results in the serial device issuing a FIFO event to an ISR that doesn't know about it may result in the device generating an infinite number of FIFO interrupts. I have no idea what this means, there is no '51 with a FIFO.
It is a programming error to not service any events I have enabled. which is MUCH MORE likely to happen with polling than with an ISR
3) It normally takes less code for a polled solution to gracefully continue with limited capabilities in case of a hradware error. Now you are talking PC again. an embedded syatem has no purpose "continuing with limited capabilities"
Interruptifobia? No! Just a question of selecting tools. My current ARM project has 16 out of 28 possible interrupt sources covered by interrupt handlers, so I can't be too scared of interrupts I would not suspect you as a sufferer, but many exist.
The polling loop will continue to do the "batch" jobs. A fully interrupted solution will permanently stop batch jobs if any interrupt source jams. Again you are talking PC again. an embedded syatem has no purpose "continuing with limited capabilities"
Always remember: There is no use to have an ISR never miss to detect the reception of a serial character, if the "main loop" is jammed and can't process the data in the receive buffers. Such a unit is dead. If the problem is because of a broken hw device, it doesn't matter if the unit has a watchdog. After the reboot it will just deadlock again. AH, now you realize we are talking embedded
Per, I see from your statements that you are "talking PC (alike)" and I am "talking embedded". This is two totally different worlds.
I know of no true embedded system where there is ANY point in "continuing woth limited capabilities" if you want to give some non-exotic examples, I'd like to see them.
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
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'
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).
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...