Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #29761 > unrolled thread
| Started by | pozz <pozzugno@gmail.com> |
|---|---|
| First post | 2020-07-08 00:38 +0200 |
| Last post | 2020-07-13 08:35 +0200 |
| Articles | 20 on this page of 64 — 18 participants |
Back to article view | Back to comp.arch.embedded
Interrupts: can be lost? pozz <pozzugno@gmail.com> - 2020-07-08 00:38 +0200
Re: Interrupts: can be lost? Clifford Heath <no.spam@please.net> - 2020-07-08 09:11 +1000
Re: Interrupts: can be lost? pozz <pozzugno@gmail.com> - 2020-07-08 08:13 +0200
Re: Interrupts: can be lost? David Brown <david.brown@hesbynett.no> - 2020-07-08 09:13 +0200
Re: Interrupts: can be lost? Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-07 16:14 -0700
Re: Interrupts: can be lost? pozz <pozzugno@gmail.com> - 2020-07-08 08:16 +0200
Re: Interrupts: can be lost? Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-08 06:55 -0700
Re: Interrupts: can be lost? David Brown <david.brown@hesbynett.no> - 2020-07-08 09:02 +0200
Re: Interrupts: can be lost? Niklas Holsti <niklas.holsti@tidorum.invalid> - 2020-07-08 11:43 +0300
Re: Interrupts: can be lost? pozz <pozzugno@gmail.com> - 2020-07-08 12:24 +0200
Re: Interrupts: can be lost? antispam@math.uni.wroc.pl - 2020-07-09 23:24 +0000
Re: Interrupts: can be lost? Dave Nadler <drn@nadler.com> - 2020-07-09 17:13 -0700
Re: Interrupts: can be lost? pozz <pozzugno@gmail.com> - 2020-07-10 08:09 +0200
Re: Interrupts: can be lost? Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-09 23:39 -0700
Re: Interrupts: can be lost? David Brown <david.brown@hesbynett.no> - 2020-07-10 08:59 +0200
Re: Interrupts: can be lost? Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2020-07-08 14:57 +0300
Re: Interrupts: can be lost? Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-08 07:01 -0700
Re: Interrupts: can be lost? David Brown <david.brown@hesbynett.no> - 2020-07-08 16:07 +0200
Re: Interrupts: can be lost? Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-08 07:35 -0700
Re: Interrupts: can be lost? David Brown <david.brown@hesbynett.no> - 2020-07-09 14:16 +0200
Re: Interrupts: can be lost? Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-09 11:04 -0700
Re: Interrupts: can be lost? Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2020-07-09 14:32 -0400
Re: Interrupts: can be lost? Paul Rubin <no.email@nospam.invalid> - 2020-07-09 11:47 -0700
Re: Interrupts: can be lost? lasselangwadtchristensen@gmail.com - 2020-07-09 15:22 -0700
Re: Interrupts: can be lost? Dave Nadler <drn@nadler.com> - 2020-07-09 15:35 -0700
Re: Interrupts: can be lost? Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-09 18:41 -0700
Re: Interrupts: can be lost? Clifford Heath <no.spam@please.net> - 2020-07-10 16:01 +1000
Re: Interrupts: can be lost? Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-09 23:28 -0700
Re: Interrupts: can be lost? Chris <xxx.syseng.yyy@gfsys.co.uk> - 2020-07-29 19:44 +0100
Re: Interrupts: can be lost? Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-29 13:23 -0700
Re: Interrupts: can be lost? Chris <xxx.syseng.yyy@gfsys.co.uk> - 2020-07-29 22:57 +0100
Re: Interrupts: can be lost? Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-29 16:47 -0700
Re: Interrupts: can be lost? Clifford Heath <no.spam@please.net> - 2020-07-30 10:04 +1000
Re: Interrupts: can be lost? Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-29 17:46 -0700
Re: Interrupts: can be lost? Clifford Heath <no.spam@please.net> - 2020-07-30 11:04 +1000
Re: Interrupts: can be lost? Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-29 21:16 -0700
Re: Interrupts: can be lost? Clifford Heath <no.spam@please.net> - 2020-07-30 16:36 +1000
Re: Interrupts: can be lost? Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-31 11:26 -0700
Re: Interrupts: can be lost? Chris <xxx.syseng.yyy@gfsys.co.uk> - 2020-07-30 01:11 +0100
Re: Interrupts: can be lost? Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-29 17:53 -0700
Re: Interrupts: can be lost? Chris <xxx.syseng.yyy@gfsys.co.uk> - 2020-07-30 19:05 +0100
Re: Interrupts: can be lost? Dimiter_Popoff <dp@tgi-sci.com> - 2020-07-31 00:21 +0300
Re: Interrupts: can be lost? David Brown <david.brown@hesbynett.no> - 2020-08-04 20:40 +0200
Re: Interrupts: can be lost? Rick C <gnuarm.deletethisbit@gmail.com> - 2020-08-04 14:36 -0700
Re: Interrupts: can be lost? Richard Damon <Richard@Damon-Family.org> - 2020-08-04 22:32 -0400
Re: Interrupts: can be lost? David Brown <david.brown@hesbynett.no> - 2020-08-05 15:26 +0200
Re: Interrupts: can be lost? upsidedown@downunder.com - 2020-07-30 08:31 +0300
Re: Interrupts: can be lost? Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-07-30 07:53 +0100
Re: Interrupts: can be lost? Richard Damon <Richard@Damon-Family.org> - 2020-07-30 08:10 -0400
Re: Interrupts: can be lost? Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-09 18:40 -0700
Re: Interrupts: can be lost? David Brown <david.brown@hesbynett.no> - 2020-07-10 09:09 +0200
Re: Interrupts: can be lost? Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-10 01:41 -0700
Re: Interrupts: can be lost? David Brown <david.brown@hesbynett.no> - 2020-07-10 13:47 +0200
Re: Interrupts: can be lost? Dimiter_Popoff <dp@tgi-sci.com> - 2020-07-11 13:41 +0300
Re: Interrupts: can be lost? Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2020-07-08 17:33 +0300
Re: Interrupts: can be lost? Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-08 09:31 -0700
Re: Interrupts: can be lost? David Brown <david.brown@hesbynett.no> - 2020-07-09 14:30 +0200
Re: Interrupts: can be lost? Przemek Klosowski <przemek@tux.dot.org> - 2020-07-19 18:38 +0000
Re: Interrupts: can be lost? Dimiter_Popoff <dp@tgi-sci.com> - 2020-07-19 23:11 +0300
Re: Interrupts: can be lost? Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-19 13:43 -0700
Re: Interrupts: can be lost? pozz <pozzugno@gmail.com> - 2020-07-08 13:19 +0200
Re: Interrupts: can be lost? Richard Damon <Richard@Damon-Family.org> - 2020-07-09 08:00 -0400
Re: Interrupts: can be lost? dalai lamah <antonio12358@hotmail.com> - 2020-07-11 12:12 +0200
Re: Interrupts: can be lost? pozz <pozzugno@gmail.com> - 2020-07-13 08:35 +0200
Page 1 of 4 [1] 2 3 4 Next page →
| From | pozz <pozzugno@gmail.com> |
|---|---|
| Date | 2020-07-08 00:38 +0200 |
| Subject | Interrupts: can be lost? |
| Message-ID | <re2thr$ke8$3@dont-email.me> |
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.
[toc] | [next] | [standalone]
| From | Clifford Heath <no.spam@please.net> |
|---|---|
| Date | 2020-07-08 09:11 +1000 |
| Message-ID | <%i7NG.63680$I15.26756@fx36.iad> |
| In reply to | #29761 |
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.
[toc] | [prev] | [next] | [standalone]
| From | pozz <pozzugno@gmail.com> |
|---|---|
| Date | 2020-07-08 08:13 +0200 |
| Message-ID | <re3o6r$fmg$1@dont-email.me> |
| In reply to | #29762 |
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.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-07-08 09:13 +0200 |
| Message-ID | <re3rlu$13d$1@dont-email.me> |
| In reply to | #29767 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2020-07-07 16:14 -0700 |
| Message-ID | <a291b83d-1e6f-4bb9-b1b7-2d111feb7a0bo@googlegroups.com> |
| In reply to | #29761 |
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
[toc] | [prev] | [next] | [standalone]
| From | pozz <pozzugno@gmail.com> |
|---|---|
| Date | 2020-07-08 08:16 +0200 |
| Message-ID | <re3obo$fmg$2@dont-email.me> |
| In reply to | #29763 |
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?
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2020-07-08 06:55 -0700 |
| Message-ID | <3ec09d06-7df8-44f8-b99e-8171fa573597o@googlegroups.com> |
| In reply to | #29768 |
On Wednesday, July 8, 2020 at 2:16:27 AM UTC-4, pozz wrote: > 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. 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 author can't actually show the malfunction, how can anyone hope to understand what he is talking about? Tempest in a teacup comes to mind. -- Rick C. + Get 1,000 miles of free Supercharging + Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-07-08 09:02 +0200 |
| Message-ID | <re3r2n$tme$1@dont-email.me> |
| In reply to | #29761 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Niklas Holsti <niklas.holsti@tidorum.invalid> |
|---|---|
| Date | 2020-07-08 11:43 +0300 |
| Message-ID | <hmlf8uFcbh7U1@mid.individual.net> |
| In reply to | #29769 |
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
. @ .
[toc] | [prev] | [next] | [standalone]
| From | pozz <pozzugno@gmail.com> |
|---|---|
| Date | 2020-07-08 12:24 +0200 |
| Message-ID | <re46tr$v8v$1@dont-email.me> |
| In reply to | #29772 |
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.
[toc] | [prev] | [next] | [standalone]
| From | antispam@math.uni.wroc.pl |
|---|---|
| Date | 2020-07-09 23:24 +0000 |
| Message-ID | <re8909$bd5$1@z-news.wcss.wroc.pl> |
| In reply to | #29773 |
pozz <pozzugno@gmail.com> wrote:
> 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.
"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
[toc] | [prev] | [next] | [standalone]
| From | Dave Nadler <drn@nadler.com> |
|---|---|
| Date | 2020-07-09 17:13 -0700 |
| Message-ID | <3d8e6da6-5580-421c-b012-d020115a8cf3o@googlegroups.com> |
| In reply to | #29808 |
On Thursday, July 9, 2020 at 7:25:00 PM UTC-4, anti...@math.uni.wroc.pl wrote: > ...correct design requires effort and apparently many > programmers lack needed knowledge. So simpler > alternatives may look attractive, especially to > managers and regulatory agencies. For example, MISRA ;-)
[toc] | [prev] | [next] | [standalone]
| From | pozz <pozzugno@gmail.com> |
|---|---|
| Date | 2020-07-10 08:09 +0200 |
| Message-ID | <re90n0$n5q$1@dont-email.me> |
| In reply to | #29808 |
Il 10/07/2020 01:24, antispam@math.uni.wroc.pl ha scritto: > [...] > So system must be correct by design. It is known how to do this. How to do this? :-)
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2020-07-09 23:39 -0700 |
| Message-ID | <c88c6443-0da4-45f9-b70e-7d77f7213081o@googlegroups.com> |
| In reply to | #29818 |
On Friday, July 10, 2020 at 2:09:39 AM UTC-4, pozz wrote: > Il 10/07/2020 01:24, antispam@math.uni.wroc.pl ha scritto: > > [...] > > So system must be correct by design. It is known how to do this. > > How to do this? :-) 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 -++ Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-07-10 08:59 +0200 |
| Message-ID | <re93l3$6vo$1@dont-email.me> |
| In reply to | #29818 |
On 10/07/2020 08:09, pozz wrote: > Il 10/07/2020 01:24, antispam@math.uni.wroc.pl ha scritto: >> [...] >> So system must be correct by design. It is known how to do this. > > How to do this? :-) 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.
[toc] | [prev] | [next] | [standalone]
| From | Tauno Voipio <tauno.voipio@notused.fi.invalid> |
|---|---|
| Date | 2020-07-08 14:57 +0300 |
| Message-ID | <re4cbi$v3i$1@dont-email.me> |
| In reply to | #29772 |
On 8.7.20 11.43, Niklas Holsti wrote: > 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". 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
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2020-07-08 07:01 -0700 |
| Message-ID | <db827461-f75a-40de-b22c-15ad143c0abfo@googlegroups.com> |
| In reply to | #29775 |
On Wednesday, July 8, 2020 at 7:57:43 AM UTC-4, Tauno Voipio wrote: > On 8.7.20 11.43, Niklas Holsti wrote: > > 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". > > > 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). That would be nice in an ideal world. I know of one designer that will still use the 8051 processor in designs that require a second source and longevity 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. There are many, many ARM MCUs on the market today. Which ones will still be around in 20 years? -- Rick C. -- Get 1,000 miles of free Supercharging -- Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-07-08 16:07 +0200 |
| Message-ID | <re4jun$jjr$1@dont-email.me> |
| In reply to | #29778 |
On 08/07/2020 16:01, Rick C wrote: > On Wednesday, July 8, 2020 at 7:57:43 AM UTC-4, Tauno Voipio wrote: >> On 8.7.20 11.43, Niklas Holsti wrote: >>> 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". >> >> >> 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). > > That would be nice in an ideal world. I know of one designer that > will still use the 8051 processor in designs that require a second > source and longevity 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. Yes, but it is not the only option. > > There are many, many ARM MCUs on the market today. Which ones will > still be around in 20 years? > 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.
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2020-07-08 07:35 -0700 |
| Message-ID | <963c0abc-183d-41c3-8b3a-30771577975fo@googlegroups.com> |
| In reply to | #29779 |
On Wednesday, July 8, 2020 at 10:07:24 AM UTC-4, David Brown wrote: > On 08/07/2020 16:01, Rick C wrote: > > On Wednesday, July 8, 2020 at 7:57:43 AM UTC-4, Tauno Voipio wrote: > >> On 8.7.20 11.43, Niklas Holsti wrote: > >>> 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". > >> > >> > >> 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). > > > > That would be nice in an ideal world. I know of one designer that > > will still use the 8051 processor in designs that require a second > > source and longevity 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. > > Yes, but it is not the only option. > > > > > There are many, many ARM MCUs on the market today. Which ones will > > still be around in 20 years? > > > > 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. You seem to miss the point. The 8051 IS the only processor that you can find with second sources and guarantees of extreme longevity. That's why he used it. -- Rick C. -+ Get 1,000 miles of free Supercharging -+ Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-07-09 14:16 +0200 |
| Message-ID | <re71qd$jk4$1@dont-email.me> |
| In reply to | #29783 |
On 08/07/2020 16:35, Rick C wrote: > On Wednesday, July 8, 2020 at 10:07:24 AM UTC-4, David Brown wrote: >> On 08/07/2020 16:01, Rick C wrote: >>> On Wednesday, July 8, 2020 at 7:57:43 AM UTC-4, Tauno Voipio >>> wrote: >>>> On 8.7.20 11.43, Niklas Holsti wrote: >>>>> 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". >>>> >>>> >>>> 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). >>> >>> That would be nice in an ideal world. I know of one designer >>> that will still use the 8051 processor in designs that require a >>> second source and longevity 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. >> >> Yes, but it is not the only option. >> >>> >>> There are many, many ARM MCUs on the market today. Which ones >>> will still be around in 20 years? >>> >> >> 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. > > You seem to miss the point. The 8051 IS the only processor that you > can find with second sources and guarantees of extreme longevity. > That's why he used 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.
[toc] | [prev] | [next] | [standalone]
Page 1 of 4 [1] 2 3 4 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web