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?
Ah, I understand what you meant.
read any datasheet for modern derivative that can be woken up from sleep mode by e.g. int0. I recall none that will wake up fron an edge int, all I recall require a level int to wake up.
Erik
Erik,
you wrote
The exception to the above is some derivatives requirement for a wake up interrupt, but similar detection can be done there.
what is a wake interrupt in this context? what do you mean?
most level triggered interrupts reset "the level" in the ISR. in such a case it is easy to check if the reset "worked" and take action if not.
THUS, even a level triggered interrupt can be detected stuck and disabled.
Per, You are right, but frankly, most of the embedded code I have seen so far does not take into consideration that a signal might "get stuck". I have to admit - I don't always check that either. I do when there is functional reason to do so - a signal remaining high for too long may indicate that the machine is experiencing some mechanial failure, and then I indicate an error and stop everything to prevent somebody from being squashed...
It will "cause havoc" even if polled.
No. A polling loop will/may run slower, but will continue to run. It is only the loop time that controls how often the signal gets polled. It is only when/if the program contains something silly like:
while (signal_x_active) process_signal_x();
that it gets into troubles if the signal is stuck.
A constantly generated interrupt will totally kill anything that hasn't higher priority than the interrupt. The main loop may not get enough processor time to be able to notice the stuck interrupt.
Since the majority of applications perform most of their jobs outside of interrupts, they are very sensitive to a interrupt handler constantly being trigged.
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...
which is, of course, true. but it won't if it is edge triggered :)
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).
As Per Westermark mentioned in the following post, a level triggered interrupt that remains asserted can cause havoc. That can happen even if a peripheral is shutdown! It will "cause havoc" even if polled.
Hello again erik, you wrote: I would always, where appropiate provide 'failsafe' but have yet to come across 'working with limited capabilities'
erik, As Per Westermark mentioned in the following post, a level triggered interrupt that remains asserted can cause havoc. That can happen even if a peripheral is shutdown! I still didn't finish reading all posts, but another con I can think of, is that often when using interrupts you are bound to a certain processor pin, making portability a little more difficult.
Lots of too narrow assumptions in your answers.
You are still missing the issue.
Completely ignoring my argument:
My full text did specifically say...
No! You have a rigid mind, and have decided that you want to think that I am talking PC.
Give up, it's hopeless. You're venturing into another universe that operates according to completely rigid laws invented by its creator.
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
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.
View all questions in Keil forum