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

Groups > comp.arch.embedded > #29902

Re: Interrupts: can be lost?

From Dimiter_Popoff <dp@tgi-sci.com>
Newsgroups comp.arch.embedded
Subject Re: Interrupts: can be lost?
Date 2020-07-31 00:21 +0300
Organization TGI
Message-ID <rfvdkv$uh$1@dont-email.me> (permalink)
References (16 earlier) <rfsrcs$17di$1@gioia.aioe.org> <05f12585-0dfa-473c-8e96-5fac9753b682o@googlegroups.com> <rft36l$1rta$1@gioia.aioe.org> <9b717da0-b64f-41c2-822b-2616420a70c2o@googlegroups.com> <rfv25k$pr6$1@gioia.aioe.org>

Show all headers | View raw

On 7/30/2020 21:05, Chris wrote:
> On 07/30/20 01:53, Rick C wrote:
>> On Wednesday, July 29, 2020 at 8:11:11 PM UTC-4, Chris wrote:
>>> On 07/30/20 00:47, Rick C wrote:
>>>> On Wednesday, July 29, 2020 at 5:57:54 PM UTC-4, Chris wrote:
>>>>> On 07/29/20 21:23, Rick C wrote:
>>>>>> On Wednesday, July 29, 2020 at 2:44:46 PM UTC-4, Chris wrote:
>>>>>>> On 07/10/20 07:28, Rick C wrote:
>>>>>>>> On Friday, July 10, 2020 at 2:01:49 AM UTC-4, Clifford Heath wrote:
>>>>>>>>> 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.
>>>>>>>>
>>>>>>>> Ok, then they are pretty useless as second sources.  I see 
>>>>>>>> someone mentioned bugs that are being worked out.  Not 
>>>>>>>> encouraging.  Is Gigidevice a company that makes FPGAs?  Or am I 
>>>>>>>> mixing them up with someone else?  Ah, I see I have downloaded 
>>>>>>>> their data sheets, so I guess I was looking at a low cost RISC-V 
>>>>>>>> board and also have info on their ARM ST clone chip.  Wait, it's 
>>>>>>>> the same chip!  No sign of FPGAs.  That was one of the other 
>>>>>>>> companies like AGM, Anlogic or maybe Gowin.  AGM has an 
>>>>>>>> interesting data sheet, but it's two years old and no sign of 
>>>>>>>> the device.
>>>>>>>>
>>>>>>>
>>>>>>> Seems to me that companies that box themselves into a corner over
>>>>>>> processors and second sources get what they deserve and is generally
>>>>>>> a sign of poor strategy and project management. I've worked on a
>>>>>>> couple of projects using essentially obsolete 8051 hardware,
>>>>>>> recommended a redesign using a more modern architecture, but they
>>>>>>> were not listening. Result was a greatly extended development time,
>>>>>>> costs, difficult ongoing software maintenance and compromises
>>>>>>> everywhere due to banked architecture for code and data. Having said
>>>>>>> that, have used the silabs 80F... series for a couple of small
>>>>>>> projects which worked really well. You wouldn't want to look at the
>>>>>>> asm op from the compiler, but more than adequate for the task and
>>>>>>> all written in C...
>>>>>>>
>>>>>>> Chris
>>>>>>
>>>>>> If a product requirement is to use only second sourced devices, 
>>>>>> that's the requirement.  How do you propose getting around that?
>>>>>>
>>>>>
>>>>> Fire the manager involved ?.
>>>>>
>>>>> As I said, if you box yourself into a corner in the design, then
>>>>> choices become limited. I prefer to take a higher level view and
>>>>> try to abstract  the hardware into functions that are common to
>>>>> most micros. For example comms, timers and other core functions.
>>>>> Define a set of call interfaces into that required functionality,
>>>>> then all that's needed is an abstraction layer between that and
>>>>> the underlying hardware. There are great benefits in terms of code
>>>>> reuse, reliablity, cost and project times. Use a subset of processor
>>>>> capabilities and deal with special cases as needed. There is some
>>>>> work, but develop over a few projects, to end up with a set of known
>>>>> good library code that can be added to and reused indefinately. I
>>>>> think it was Win NT that first publicised the idea of a hw abstraction
>>>>> layer, but with the speed of modern micros, you can apply that idea to
>>>>> just about any embedded project.
>>>>>
>>>>> The whole idea is to design assuming that the hardware will change
>>>>> over time, new requirements, performance, cost, whatever, as new
>>>>> micros come to market. The exact opposite of s design frozen in
>>>>> time, with all the hassle that involves...
>>>>>
>>>>> Chris
>>>>
>>>> Ok, I get it.  You don't understand requirements.  There are 
>>>> perfectly valid reasons for wanting second sources on parts that 
>>>> obviously have never applied on projects you've worked on.  So you 
>>>> don't understand why anyone will need that requirement.
>>>>
>>>> Whether you understand or not, that's a valid requirement and firing 
>>>> the manager to change the requirement will only result in a failure 
>>>> of the project.
>>>>
>>>> If you want to discuss the issue, I'm happy to do that, but you are 
>>>> going to need to change a lot of your assumptions for us to 
>>>> communicate.
>>>>
>>>
>>> ???...
>>>
>>> Oh, I understand requirements, but while second sourcing is always a
>>> desirable thing for any manufactured item, it gets more and more
>>> difficult to ensure with the ever increasing complexity and feature
>>> set of modern micros, all of which differ. All I was trying to do
>>> was suggest a different way of looking at things, but if you have
>>> already made your mind up, not much point really. Find a different
>>> solution, it's that simple. Just because you demand something
>>> won't make it magically happen, or that it's even possible.
>>>
>>> The only people who have a financial muscle to ensure second source
>>> and decades supply guarantee are probably defence and avionics, but
>>> most of industry doesn't work that way, far too expensive. Best you
>>> can hope to do is choose a vendor agnostic architecture, like arm,
>>> for example, where there's chance you will be able to make at least
>>> some of the code common to several vendor's product...
>>>
>>> Chris
>>
>> You do not understand, which shows in your use of the term "desirable".
>>
>> This is getting absurd.  You want to make the issue about the whim of 
>> a manager or myself and you don't understand that redesigning a 
>> produce at times is literally not an option because of the huge 
>> expense.  You must not have worked on anything that needed more than 
>> just testing and it was out the door.
>>
>> My current product had to go through various levels of certification 
>> before it could be used.  A part on the board is getting expensive to 
>> buy and eventually will be unavailable.  I might be willing to design 
>> a new board with a different part, but the company who buys them may 
>> not be willing to pay for the certifications.  At that point the 
>> product will be dead.
>>
>> There are apps where the certs are very expensive, like space or 
>> various safety related uses.  Nuke plants are an example.
>>
>> I'm not going to continue to bat this around with you when you clearly 
>> are not getting the concept.
> 
> 
> Oh, I understand requirements, but while second sourcing is always a
> desirable thing for any manufactured item, it gets more and more
> difficult to ensure with the ever increasing complexity and feature
> set of modern micros, all of which differ. All I was trying to do
> was suggest a different way of looking at things, but if you have
> already made your mind up, not much point really. Find a different
> solution, it's that simple. Just because you demand something
> won't make it magically happen, or that it's possible.
> 
> The only people who have a financial muscle to ensure second source
> and decades supply guarantee are probably defence and avionics, but
> most of industry doesn't work that way, far too expensive. Best you
> can hope to do is choose a vendor agnostic architecture, like arm,
> for example, where there's chance you will be able to make at least
> some of the code common to several vendor's product...
> 
> Chris
> 
> I think I get the concept, but if there is no second source for a part,
> what's your solution ?. Only thing I can see to ensure continuity is
> to buy a product lifetime set of parts...
> 
> Chris
> 

Basically lifetime buy is the only way indeed, second source or not;
second sources are not immortal just like first ones.
While Rick's point about certification is valid it is hard to
imagine how a customer will be willing to bear the cost of
that certification and not the (probably minor in comparison)
cost of a lifetime part buy.
But people do all sorts of things when planning ahead, you never
know what is behind the corner. We all cope with the times which
"are a changin'" , sometimes we get it right sometimes we don't.

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