Interrupts: can be lost?

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

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

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

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.

On 8.7.20 17.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.
> 
> There are many, many ARM MCUs on the market today.  Which ones will still be around in 20 years?


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

-- 

-TV

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

On Wednesday, July 8, 2020 at 10:33:20 AM UTC-4, Tauno Voipio wrote:
> On 8.7.20 17.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.
> > 
> > There are many, many ARM MCUs on the market today.  Which ones will still be around in 20 years?
> 
> 
> I designed a bunch of instruments with ARM7TDMI 20 years ago, and the
> chips are still around.

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

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

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

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

-- 

  Rick C.

  +- Get 1,000 miles of free Supercharging
  +- Tesla referral code - https://ts.la/richard11209

On 7/7/20 6:38 PM, 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.

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

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

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

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

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.

On 08/07/2020 18:31, Rick C wrote:
> On Wednesday, July 8, 2020 at 10:33:20 AM UTC-4, Tauno Voipio wrote:
>> On 8.7.20 17.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.
>>> 
>>> There are many, many ARM MCUs on the market today.  Which ones
>>> will still be around in 20 years?
>> 
>> 
>> I designed a bunch of instruments with ARM7TDMI 20 years ago, and
>> the chips are still around.
> 
> Was there any guarantee of that?  Are they second sourced if the
> original maker stops making them?  20 years ago did you know these
> chips would be around now?
> 
> All manner of devices survive the years, but how do you know which
> ones will and which ones won't?

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

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

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

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