Interrupts: can be lost?

On Thursday, July 9, 2020 at 8:16:18 AM UTC-4, David Brown wrote:
> 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.

Everything you say is true except for the parts that aren't.  That many people make non-pin compatible variations on the 8051 is irrelevant.  The fact is that there are second sources of pin compatible parts and that there are makers who are promising to supply the devices for a period of time.  If you want confirmation of this you can go over to sci.electronics.design and post to Joerg.  He is the one using the 8051 for these exact reasons. 


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

Not sure what you are talking about companies storing bare die.  The context was standard devices that aren't going into space or otherwise have a hugely inflated price.  

I have yet to find a single ARM processor that had a true, pin compatible second source.  There may be some in the automotive sector that are not available to those needing thousands a year rather than millions per year.  But even then I've not found them.  Each manufacturer produces their own line of products and compete based on the little differences that make their product "better" rather than being a second source to someone else.  

Not sure what you are trying to say about the tools.  Anyone who wishes to maintain a design for >10 years or even five needs to archive the tools and and the machine they run on.  I presently have that problem.  The tools from >10 years ago still seem to run on my recent PC running Win10, but who knows what will happen next time I update?  I may need to resurrect a 15 year old desktop running Win2k.

-- 

  Rick C.

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

On 2020-07-09 14:04, Rick C wrote:

<sniiiip>
> Not sure what you are trying to say about the tools.  Anyone who
> wishes to maintain a design for >10 years or even five needs to
> archive the tools and and the machine they run on.  I presently have
> that problem.  The tools from >10 years ago still seem to run on my
> recent PC running Win10, but who knows what will happen next time I
> update?  I may need to resurrect a 15 year old desktop running
> Win2k.

Archive a VM or container.

Cheers

Phil Hobbs


-- 
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

Rick C <gnuarm.deletethisbit@gmail.com> writes:
> I have yet to find a single ARM processor that had a true, pin
> compatible second source.

I thought there were some Chinese clones of the lower end STM32F series
but I haven't paid close attention.

> Not sure what you are trying to say about the tools.  Anyone who
> wishes to maintain a design for >10 years or even five needs to
> archive the tools and and the machine they run on.  I presently have
> that problem.  The tools from >10 years ago still seem to run on my
> recent PC running Win10, but who knows what will happen next time I
> update?  I may need to resurrect a 15 year old desktop running Win2k.

I think current practice is to run your system inside a VM that you
snapshot so you can later reproduce it.  In critical systems you do that
whenever you make a software release, so you snapshot not only the
current source code (revision control already does that), but also the
complete tool chain including compilers, libraries, all the build
artifacts, and the whole OS.

torsdag den 9. juli 2020 kl. 20.47.25 UTC+2 skrev Paul Rubin:
> Rick C <gnuarm.deletethisbit@gmail.com> writes:
> > I have yet to find a single ARM processor that had a true, pin
> > compatible second source.
> 
> I thought there were some Chinese clones of the lower end STM32F series
> but I haven't paid close attention.
> 

yep, I know there are several clones of STM32F103xxxx

On Thursday, July 9, 2020 at 6:22:24 PM UTC-4, lasselangwad...@gmail.com wrote:
> torsdag den 9. juli 2020 kl. 20.47.25 UTC+2 skrev Paul Rubin:
> > Rick C <gnuarm.deletethisbit@gmail.com> writes:
> > I thought there were some Chinese clones of the lower end STM32F series
> > but I haven't paid close attention.
> 
> yep, I know there are several clones of STM32F103xxxx

But they're not exactly compatible.
I heard they fixed some of the bugs.

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

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

On Thursday, July 9, 2020 at 2:47:25 PM UTC-4, Paul Rubin wrote:
> Rick C <gnuarm.deletethisbit@gmail.com> writes:
> > I have yet to find a single ARM processor that had a true, pin
> > compatible second source.
> 
> I thought there were some Chinese clones of the lower end STM32F series
> but I haven't paid close attention.

Yes, that is exactly what a company will be counting on for 20 years of support, Chinese clones.  Are you actually reading the thread? 


> > Not sure what you are trying to say about the tools.  Anyone who
> > wishes to maintain a design for >10 years or even five needs to
> > archive the tools and and the machine they run on.  I presently have
> > that problem.  The tools from >10 years ago still seem to run on my
> > recent PC running Win10, but who knows what will happen next time I
> > update?  I may need to resurrect a 15 year old desktop running Win2k.
> 
> I think current practice is to run your system inside a VM that you
> snapshot so you can later reproduce it.  In critical systems you do that
> whenever you make a software release, so you snapshot not only the
> current source code (revision control already does that), but also the
> complete tool chain including compilers, libraries, all the build
> artifacts, and the whole OS.

You still need the OS and hardware interfaces.  Can you still buy a copy of XP? 

-- 

  Rick C.

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

On Thursday, July 9, 2020 at 6:22:24 PM UTC-4, lasselangwad...@gmail.com wrote:
> torsdag den 9. juli 2020 kl. 20.47.25 UTC+2 skrev Paul Rubin:
> > Rick C <gnuarm.deletethisbit@gmail.com> writes:
> > > I have yet to find a single ARM processor that had a true, pin
> > > compatible second source.
> > 
> > I thought there were some Chinese clones of the lower end STM32F series
> > but I haven't paid close attention.
> > 
> 
> yep, I know there are several clones of STM32F103xxxx

So "clone" equals "second source"???

-- 

  Rick C.

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

On 10/7/20 11:41 am, Rick C wrote:
> On Thursday, July 9, 2020 at 6:22:24 PM UTC-4, lasselangwad...@gmail.com wrote:
>> torsdag den 9. juli 2020 kl. 20.47.25 UTC+2 skrev Paul Rubin:
>>> Rick C <gnuarm.deletethisbit@gmail.com> writes:
>>>> I have yet to find a single ARM processor that had a true, pin
>>>> compatible second source.
>>>
>>> I thought there were some Chinese clones of the lower end STM32F series
>>> but I haven't paid close attention.
>>>
>>
>> yep, I know there are several clones of STM32F103xxxx
> 
> So "clone" equals "second source"???

Not really. They haven't licensed ST's masks, they've just designed 
their own chips to match the documented behaviour.

The chips I know of are by GigiDevice and Mindmotion, part numbers 
GD32F3??? and MM32F??? to match the STM32F???.

I see over 100 variants waiting on reels in JLCPCB's fab.

Clifford Heath.