Interrupts: can be lost?

It depends. Sometimes an interrupt condition might occur again before the handler has run - if another high priority thing (like another handler) is running. Sometimes, that means the interrupt still occurs, but only the latter time. For most peripherals, that still doesn't cause a fault, because the handler do the work required by the multiple interrupt condition while only running once.

If you need to count the actual interrupts, it's only reliable if the interrupt gets cleared before it happens again. So for example if you use interrupts to handle a quadrature encoder, but there's no debounce on the encoder's switches, you will miscount.

In general, an interrupt should be used to signal that some work must be done - involving checking what that work is and doing it. Responding to the interrupt is not the work, it's just how the work gets started.

But some hardware designers are stupid.

Clifford Heath.

terrupt

I believe that statement is not adequately supported in the document. The best support I found in this document were the words, "As a result, the res ponse to the second interrupt willbe at the very least delayed; under some circumstances it will be ignored altogether." which were repeated for three different conditions of mixed interrupt usage in the 8051 processor. Mayb e these are true statements for that processor under those conditions. But that is not a blanket statement about interrupt usage. Unless there is a flaw in the hardware or a flaw in the software, interrupts should not be mi ssed.

A flaw in software or hardware can make any portion of a processor system f ail. Recall the infamous floating point bug in the Intel processors of a c ouple decades ago.

I also don't see any supporting information in your claims of interrupt fai lures being "practically impossible" to prevent.

If you are basing your claim on this article, I don't see your claim as bei ng valid.

I will acknowledge that many times it can be hard to design interrupt based systems that work correctly. That doesn't mean "impossible" or even "unli kely". It means you have to give it due diligence. This is the nature of using a sequentially executing processor to emulate simultaneous execution of processes. I will also say that is why I design FPGAs in HDL. The problems of multipl e interrupt levels just don't happen in hardware. Why make problems that a re harder to solve than the problem you are trying to solve?

I don't think the author of the above quotation was thinking to multiple interrupts from the same source. He says explicitly "multiple sources of interrupts".

That is not may claim, I only cited a sentence of a book I'm reading.

The book was written in 2001, using a microcontroller that, while very popular (and still not dead), was 20 years out of date at the time. I haven't looked at it yet, and can't judge the quality of the book. But beware that some things in it could be limited by that microcontroller architecture.

However, the principle here is correct. It is part of a more general principle that is actually quite simple:

If you have event counters or trackers that have limited capacity, and you do not handle the events before that capacity is exceeded, your system will lose events (by either ignoring new ones, or ejecting old ones).

In the case of interrupts, you often just have a one bit flag - that means you have to handle that one event before the next event happens, or you will lose the event. In some cases, the interrupt flag is /not/ the counter - it merely indicates that the counter has increased since you last checked, and the real counter is tracked by the UART FIFO, or the DMA, or whatever.

But interrupts on even the most modern of microcontrollers will be lost if the "counter" overflows (by saturation). If the interrupt has its own flag but is not tied to a buffer mechanism of some sort, then multiple interrupts from that source will by shown as a single event - you know more than zero events occurred, but don't know how many if you can't guarantee that you record the event and clear the flag before the next event occurs.

Forget what the author said here - use it as inspiration to think and learn about more general points.

It is common for interrupt flags to be multiplexed in a kind of tree. A peripheral may track various events (such as UART transmit, receive, overrun, parity error) with flags in its own status register and a single interrupt. The interrupt controller will have lots of interrupt flags, but generate a few general interrupts of different priorities. The processor core will accept a small (often just one) number of interrupt lines from the interrupt controller.

If you don't respond in time (and as Clifford says, "responding" may just mean identifying and recording the event, rather than starting the real work at that time or within an interrupt function), you lose information. You lose information about the number of events, and their ordering, even if you still know that the event has happened.

Older and more limited microcontrollers often had simpler interrupt systems. For example, the interrupt controller might not have flags for all the different sources (UART, SPI, Timers, etc.), but have a single flag and an "interrupt number" register which holds the number or vector of source of the interrupt. That is a convenient system for a limited microcontroller. If you are handling an interrupt already, this can probably correctly store the next interrupt. But if more interrupts happen, you lose the information about all but one of them.

This is unlikely to be an issue with modern devices in the same way, but you may still miss out for multiplexed interrupts, and you certainly miss out on repeated interrupts.

Indeed.

Note that the book's author clearly has an axe to grind here[1], because he advocates using "time triggering" instead of event- (interrupt-) triggering. So he's trying to make you afraid of interrupts.

Of course a similar problem applies to time-triggered systems: if you trigger a task every millisecond, but the task sometimes needs more than a millisecond to complete... something bad can happen.

Indeed what I wasn't understanding was how time-triggered systems could solve the problem that is intrinsic on low-level interrupts management.

I don't think there's a solution if interrupt events are generated too fast, on event-driven or time-triggered systems.

However I have the suspect the author didn't refer to multiple events of the *same* source.

It's yet an obscure sentence for me. A sentence that seems to be the foundation of the entire book.

The writer is advocating the 8051 family, which is awfully clumsy for running real multi-threading. Besides, it should be forgotten in favor of e.g. the Cortex-M processors, which are even at least as inexpensive as the 8051's with required support.

(Mooo! from southern Finland).

er

interrupt

ll

rs

The best support I found in this document were the words, "As a result, the response to the second interrupt willbe at the very least delayed; under s ome circumstances it will be ignored altogether." which were repeated for t hree different conditions of mixed interrupt usage in the 8051 processor. Maybe these are true statements for that processor under those conditions. But that is not a blanket statement about interrupt usage. Unless there i s a flaw in the hardware or a flaw in the software, interrupts should not b e missed.

em fail. Recall the infamous floating point bug in the Intel processors of a couple decades ago.

failures being "practically impossible" to prevent.

Yes, sorry, I'm projecting the author's words to you. My point is the work makes unsupported claims. Why bother to worry with such claims? If the a uthor can't actually show the malfunction, how can anyone hope to understan d what he is talking about?

Tempest in a teacup comes to mind.

ver

, interrupt

ill

ers

? I

? But

eral

That would be nice in an ideal world. I know of one designer that will sti ll use the 8051 processor in designs that require a second source and longe vity of supply. When qualification of a design is very expensive these pro perties can be very important. If the 8051 is the only processor that meet s these requirements then that is the one you will use.

There are many, many ARM MCUs on the market today. Which ones will still b e around in 20 years?

Yes, but it is not the only option.

The ones that manufacturers say they will continue to produce. Any manufacturer with automotive customers will have long-term guarantees. (I don't know how common 20 year lifetimes are - I haven't had to look /that/ long.)

Second sources are not easy if you need /exact/ matches, but your friendly local distributors can help.

I designed a bunch of instruments with ARM7TDMI 20 years ago, and the chips are still around.

ses can be

You seem to miss the point. The 8051 IS the only processor that you can fi nd with second sources and guarantees of extreme longevity. That's why he used it.

ng

never

ls, interrupt

will

of

llers

ry

er

eneral

nd

use

han

still use the 8051 processor in designs that require a second source and l ongevity of supply. When qualification of a design is very expensive these properties can be very important. If the 8051 is the only processor that meets these requirements then that is the one you will use.

ll be around in 20 years?

Was there any guarantee of that? Are they second sourced if the original m aker stops making them? 20 years ago did you know these chips would be aro und now?

All manner of devices survive the years, but how do you know which ones wil l and which ones won't?

The 8051 is the cockroach of MCUs. It will survive virtually anything in t he semiconductor industry... much to the chagrin of most designers.

I would love if the world would pick a half dozen MCUs in as many packages and designate them as the next generation 8051 to be made for 50 years. It would make many project life cycles much simpler.

Yes, if you allow yourself to be given arbitrary constraints, it is possible to get a set of system requirements that you can't meet and you can know that at times you will lose interrupts. It is always possible to have too little processor for a given set of specifications.

What can be done is to convert your system requirements into timing constraints on pieces of the software, and with a bit of skill and experience decide if these are likely to be achievable (and then after implementing see if you met the requirements) to be able to prove that you can meet the requirements, or not.

Yes, you can 'lose' an interrupt if you don't service it in time, often the time limit being imposed by a second verison of that (or a related) interrupt occurring. It is also possible to lose interrupts by code defects that don't handle nesting of requests properly.

It has been mentioned that this was referring to an 8051, an that processor is simplistic enough that it can be hard to make sure you are handling nested requests well. I think the ISR handler needs to check for this sort of case and handle it specially.

I didn't miss the point. The 8051 is not a processor that you can buy, it is a family of related variations of a core that is found in many microcontrollers. Virtually all 8051-based microcontrollers are single-source, and have the same types of longevity as other microcontrollers (10 years+ is typical, with 15 to 20 years or more for specialised parts). There is nothing special about the 8051 except that it is already old, and you'd have a hard time finding 8051 parts now that are guaranteed to be produced for /another/ 20 years - it doesn't help if it has been produced for the /past/ 20 years.

What you said was that the 8051 was the only "processor" that fitted the requirements of longevity. Now, it might well be that in this particular case, the chip you have is the only option that fitted. But it does not mean that it is true in general. I am confident that if I asked my distributors, they could find long-lived ARM microcontrollers (as well as PowerPC, and various other cores). Second source for an identical chip is hard to find, but they do exist (especially if you are willing to pay for it - there are companies that store bare dies for decades and will package them when a customer needs them, and there are companies that do specialised versions of standard chips for military or other special-needs customers). But you only talked about second source for the core - presumably it is software and tools that are qualified here, rather than the hardware.

I look at manufacturers' websites, and I ask distributors. It's not hard to learn what the manufacturers plan to have in their long-term programs (to the best of their abilities, of course). Other devices simply continue to be produced as long as there are customers - the

Are you talking about the original 8051 - the Intel MCS-51 in its big DIP package, or are you talking about the /core/ that is used in all sorts of variations by large numbers of manufactures in different incompatible microcontrollers?