Interrupts: can be lost?

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
https://www.safetty.net/download/pont_pttes_2001.pdf

Page 13
Note carefully what this means! There is a common misconception among  
the developers of embedded applications that interrupt events will never  
be lost. This simply is not true. If you have multiple sources of  
interrupts that may appear at ?random? time intervals, interrupt  
responses can be missed: indeed, where there are several active  
interrupt sources, it is practically impossible to create code that will  
deal correctly with all possible combinations of interrupts.

Those words are incredible for me. I suspect I didn't get the point of  
the author. I don't think that interrupt events on modern microntrollers  
can be lost in some circumstances.

Re: Interrupts: can be lost?
On 8/7/20 8:38 am, pozz wrote:
Quoted text here. Click to load it

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.

Re: Interrupts: can be lost?
Il 08/07/2020 01:11, Clifford Heath ha scritto:
Quoted text here. Click to load it

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".


Quoted text here. Click to load it


Re: Interrupts: can be lost?
On 08/07/2020 08:13, pozz wrote:
Quoted text here. Click to load it

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.



Re: Interrupts: can be lost?
On Tuesday, July 7, 2020 at 6:38:55 PM UTC-4, pozz wrote:
Quoted text here. Click to load it
  
Quoted text here. Click to load it
terrupt  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
  
Quoted text here. Click to load it

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?  

--  

  Rick C.

  - Get 1,000 miles of free Supercharging
We've slightly trimmed the long signature. Click to see the full one.
Re: Interrupts: can be lost?
Il 08/07/2020 01:14, Rick C ha scritto:
Quoted text here. Click to load it

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


Quoted text here. Click to load it

Re: Interrupts: can be lost?
On Wednesday, July 8, 2020 at 2:16:27 AM UTC-4, pozz wrote:
Quoted text here. Click to load it
er
 interrupt
Quoted text here. Click to load it
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.
Quoted text here. Click to load it
em fail.  Recall the infamous floating point bug in the Intel processors of
 a couple decades ago.
Quoted text here. Click to load it
 failures being "practically impossible" to prevent.
Quoted text here. Click to load it

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.  

--  

  Rick C.

  + Get 1,000 miles of free Supercharging
We've slightly trimmed the long signature. Click to see the full one.
Re: Interrupts: can be lost?
On 08/07/2020 00:38, pozz wrote:
Quoted text here. Click to load it

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.

Re: Interrupts: can be lost?
On 2020-07-08 10:02, David Brown wrote:
Quoted text here. Click to load it

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.

[1] Or, as is said here in Finland, "he has his own cow in the ditch".

--  
Niklas Holsti
niklas holsti tidorum fi
We've slightly trimmed the long signature. Click to see the full one.
Re: Interrupts: can be lost?
Il 08/07/2020 10:43, Niklas Holsti ha scritto:
Quoted text here. Click to load it


Quoted text here. Click to load it

Quoted text here. Click to load it

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.

Re: Interrupts: can be lost?
Quoted text here. Click to load it

"time-triggered" is special variant of polled system.  With
polled system it is pretty clear that you need to poll
frequently enough and after testing you can be resonably
sure that various pieces run in allocated time.

With interrupt-driven system at first glance one can think
that much slower processor will do the job.  Namely, it is
typical that on average there are no or little problematic
coincidencies.  So is system is fast enough to handle
each interrupt separately it may appear to work.  Problem
is that coincidencies happen.  They happen infrequently
enough that testing for them is hard or impossible.  But
coincidencies may cause failure in operation.  Related
problem is correctness of code.  For long time it is
known that is essentially imposible to test correctness
is interrupt driven system.  More precisly, it is imposible
to test interaction of components.  So system must be
correct by design.  It is known how to do this.  But
correct design requires effort and apparently many
programmers lack needed knowledge.  So simpler
alternatives may look attractive, especially to
managers and regulatory agencies.

--  
                              Waldek Hebisch

Re: Interrupts: can be lost?
On Thursday, July 9, 2020 at 7:25:00 PM UTC-4, snipped-for-privacy@math.uni.wroc.pl wrote:
Quoted text here. Click to load it

For example, MISRA ;-)

Re: Interrupts: can be lost?
Il 10/07/2020 01:24, snipped-for-privacy@math.uni.wroc.pl ha scritto:
Quoted text here. Click to load it

How to do this? :-)

Re: Interrupts: can be lost?
On Friday, July 10, 2020 at 2:09:39 AM UTC-4, pozz wrote:
Quoted text here. Click to load it

You are looking for an education on interrupt design in MCU systems?  I can recommend a few good companies who teach this material.  It is also covered in many text books.  

Once again, I will say, this is no small reason why I like FPGA design in HDL.  It just doesn't have this sort of complexity.  The only complexity is from the design itself, nothing added gratuitously.  

--  

  Rick C.

  -++ Get 1,000 miles of free Supercharging
We've slightly trimmed the long signature. Click to see the full one.
Re: Interrupts: can be lost?
On 10/07/2020 08:09, pozz wrote:
Quoted text here. Click to load it

Quoted text here. Click to load it

Roughly speaking, you have to know how often the different interrupts
can occur, what priorities they have, how long you take to handle them -
that kind of thing.  And you have to calculate the worst-case scenarios
so that you can guarantee that you don't lose (important) events if you
are unlucky in the ordering and timing.  As Waldek says, you generally
can't check this sort of thing by testing as it is usually very
difficult to make the timing in the test happen in exactly the right
places.  (It's like race conditions in multi-threading systems in that
aspect.)

If you use timing-driven polling, it is often easier to be sure of
things because you have more regularity in the system.

And if you use a microcontroller with appropriate peripherals for the
task, it is also much simpler.  Peripherals with buffers, DMAs, etc.,
that can handle at least a little of the timing autonomously means you
have a lot more flexibility in how you need to react to events in software.


Re: Interrupts: can be lost?
On 8.7.20 11.43, Niklas Holsti wrote:
Quoted text here. Click to load it


Quoted text here. Click to load it

Quoted text here. Click to load it


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).

--  

-TV


Re: Interrupts: can be lost?
On Wednesday, July 8, 2020 at 7:57:43 AM UTC-4, Tauno Voipio wrote:
Quoted text here. Click to load it
ver
, interrupt
ill
f
ers
? I
Quoted text here. Click to load it
? But
Quoted text here. Click to load it

eral
Quoted text here. Click to load it
  
Quoted text here. Click to load it
e  
Quoted text here. Click to load it
  
Quoted text here. Click to load it
n  
Quoted text here. Click to load it

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?  

--  

  Rick C.

  -- Get 1,000 miles of free Supercharging
We've slightly trimmed the long signature. Click to see the full one.
Re: Interrupts: can be lost?
On 08/07/2020 16:01, Rick C wrote:
Quoted text here. Click to load it

Yes, but it is not the only option.

Quoted text here. Click to load it

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.

Re: Interrupts: can be lost?
On Wednesday, July 8, 2020 at 10:07:24 AM UTC-4, David Brown wrote:
Quoted text here. Click to load it
ses can be
Quoted text here. Click to load it

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.  

--  

  Rick C.

  -+ Get 1,000 miles of free Supercharging
We've slightly trimmed the long signature. Click to see the full one.
Re: Interrupts: can be lost?
On 08/07/2020 16:35, Rick C wrote:
Quoted text here. Click to load it

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.


Site Timeline