Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #29834

Re: Interrupts: can be lost?

Show all headers | View raw

On 7/9/2020 21:04, Rick C wrote:
> 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.
> 

Second source in the context of processors is overrated. Rewind about 40
years when the 6809 had a second source, a 6309 from Hitachi to
no effect on the processor lifespan.
With some luck and a lot of careful consideration one can pick a
processor which will live for >10 years. I have managed that with
the 68hc11, 68340, mpc5200b, mcf52211... not so sure about the
mpc824x, but my design with it did not live long enough for this
to matter (yet it did a good job aiding the migration 68k -> power).

I can't speak firsthand on the toolchains people use as those I use
are 100% mine, I can even run on a VM emulating the 6809 in dps windows
what I ran before I had all toolchains mine, things I have written
back in the 80-s.

I know some people archive entire machines so they can replicate the
design process years later if needed; but with flash memories relying
on tinier and tinier gate charges this becomes less and less viable
(I have a dps machine on my desk 20+ years old, and I have 10+ years
old netMCA devices in the field which show no issues... I think flash
memories of a few megabytes which will hold charge for 10+ years
are still available, time will tell.

Dimiter
======================================================
Dimiter Popoff, TGI             http://www.tgi-sci.com
======================================================
http://www.flickr.com/photos/didi_tgi/

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web