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.
Interrupts: can be lost?
Started by ●July 7, 2020
Reply by ●July 7, 20202020-07-07
On 8/7/20 8:38 am, pozz wrote:> 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.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.
Reply by ●July 7, 20202020-07-07
On Tuesday, July 7, 2020 at 6:38:55 PM UTC-4, pozz wrote:> 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.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 response 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. Maybe 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 missed. A flaw in software or hardware can make any portion of a processor system fail. Recall the infamous floating point bug in the Intel processors of a couple decades ago. I also don't see any supporting information in your claims of interrupt failures being "practically impossible" to prevent. If you are basing your claim on this article, I don't see your claim as being 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 "unlikely". 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 multiple interrupt levels just don't happen in hardware. Why make problems that are harder to solve than the problem you are trying to solve? -- Rick C. - Get 1,000 miles of free Supercharging - Tesla referral code - https://ts.la/richard11209
Reply by ●July 8, 20202020-07-08
Il 08/07/2020 01:11, Clifford Heath ha scritto:> On 8/7/20 8:38 am, pozz wrote: >> 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. > > 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.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".> 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.
Reply by ●July 8, 20202020-07-08
Il 08/07/2020 01:14, Rick C ha scritto:> On Tuesday, July 7, 2020 at 6:38:55 PM UTC-4, pozz wrote: >> 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. > > 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 response 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. Maybe 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 missed. > > A flaw in software or hardware can make any portion of a processor system fail. Recall the infamous floating point bug in the Intel processors of a couple decades ago. > > I also don't see any supporting information in your claims of interrupt failures being "practically impossible" to prevent.That is not may claim, I only cited a sentence of a book I'm reading.> If you are basing your claim on this article, I don't see your claim as being 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 "unlikely". 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 multiple interrupt levels just don't happen in hardware. Why make problems that are harder to solve than the problem you are trying to solve?
Reply by ●July 8, 20202020-07-08
On 08/07/2020 00:38, pozz wrote:> 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.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.
Reply by ●July 8, 20202020-07-08
On 08/07/2020 08:13, pozz wrote:> Il 08/07/2020 01:11, Clifford Heath ha scritto: >> On 8/7/20 8:38 am, pozz wrote: >>> 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. >> >> 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. > > 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". >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.
Reply by ●July 8, 20202020-07-08
On 2020-07-08 10:02, David Brown wrote:> On 08/07/2020 00:38, pozz wrote: >> 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. > > 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).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 . @ .
Reply by ●July 8, 20202020-07-08
Il 08/07/2020 10:43, Niklas Holsti ha scritto:> On 2020-07-08 10:02, David Brown wrote: >> On 08/07/2020 00:38, pozz wrote: >>> 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. >> >> 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). > > 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". >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.
Reply by ●July 8, 20202020-07-08
Il 08/07/2020 09:02, David Brown ha scritto:> On 08/07/2020 00:38, pozz wrote: >> 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. > > 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).However I have the suspect the author didn't refer to multiple events of the *same* source. > [...] If you have multiple sources of interrupts [...] it is > practically impossible to create code that will deal correctly > with all possible combinations of interrupts. It's yet an obscure sentence for me. A sentence that seems to be the foundation of the entire book.
