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

Groups > comp.arch.embedded > #29761 > unrolled thread

Interrupts: can be lost?

Back to article view | Back to comp.arch.embedded

Contents

  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 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#29798

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

[toc] | [prev] | [next] | [standalone]

#29799

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

[toc] | [prev] | [next] | [standalone]

#29801

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.

[toc] | [prev] | [next] | [standalone]

#29805

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

[toc] | [prev] | [next] | [standalone]

#29806

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.

[toc] | [prev] | [next] | [standalone]

#29813

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

[toc] | [prev] | [next] | [standalone]

#29817

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.

[toc] | [prev] | [next] | [standalone]

#29820

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.  

-- 

  Rick C.

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

[toc] | [prev] | [next] | [standalone]

#29876

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

[toc] | [prev] | [next] | [standalone]

#29877

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? 

-- 

  Rick C.

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

[toc] | [prev] | [next] | [standalone]

#29878

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

[toc] | [prev] | [next] | [standalone]

#29880

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.  

-- 

  Rick C.

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

[toc] | [prev] | [next] | [standalone]

#29881

On 30/7/20 9:47 am, Rick C wrote:
> On Wednesday, July 29, 2020 at 5:57:54 PM UTC-4, Chris wrote:
>> 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...
> 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.

Even with a strict second-source policy, actually validating the device 
after with the second source will require some additional work. Do 
product managers require validation of correct operation with any second 
source *before* they need to switch to it? Because if not, they should 
expect the possibility of additional work (including minor code changes) 
when they do decide to switch. All of which means that in many or most 
cases, it's entirely possible to consider the GD32 chips as a second 
source for the STM32 ones.

CH.

[toc] | [prev] | [next] | [standalone]

#29884

On Wednesday, July 29, 2020 at 8:04:29 PM UTC-4, Clifford Heath wrote:
> On 30/7/20 9:47 am, Rick C wrote:
> > On Wednesday, July 29, 2020 at 5:57:54 PM UTC-4, Chris wrote:
> >> 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...
> > 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.
> 
> Even with a strict second-source policy, actually validating the device 
> after with the second source will require some additional work. Do 
> product managers require validation of correct operation with any second 
> source *before* they need to switch to it? Because if not, they should 
> expect the possibility of additional work (including minor code changes) 
> when they do decide to switch. All of which means that in many or most 
> cases, it's entirely possible to consider the GD32 chips as a second 
> source for the STM32 ones.

Of course they would verify the second source worked.  I designed a board I expected to be making for some time.  The FPGA came in two flavors, 3.3 volt only or 1.8 volt core.  I designed the board to use either with an optional step down regulator.  I had to build the board with two of the 1.8 volt chips to verify they worked ok.  Good thing too... the FPGA subsequently went EOL and while Arrow bought up a bunch of them, the price of the 3.3 volt only version has doubled and tripled.  I bought 2000 of the 1.8 volt versions a year ago for about $2 each in contrast to the $30 price the 3.3 volt versions are getting now.  Just waiting for the next order. 

I also used a hybrid footprint to work with either an ADI or Maxim analog switch.  The ADI part has gone up in price a bit, but still cheaper than the maxim part.  I also tested that.  Never had to use it though. 

Having choices in parts purchasing can extend the life of a produce or keep it affordable. 

I think it was 2008 when I designed that board. 

-- 

  Rick C.

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

[toc] | [prev] | [next] | [standalone]

#29886

On 30/7/20 10:46 am, Rick C wrote:
> On Wednesday, July 29, 2020 at 8:04:29 PM UTC-4, Clifford Heath wrote:
>> On 30/7/20 9:47 am, Rick C wrote:
>>> On Wednesday, July 29, 2020 at 5:57:54 PM UTC-4, Chris wrote:
>>>> 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...
>>> 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.
>>
>> Even with a strict second-source policy, actually validating the device
>> after with the second source will require some additional work. Do
>> product managers require validation of correct operation with any second
>> source *before* they need to switch to it? Because if not, they should
>> expect the possibility of additional work (including minor code changes)
>> when they do decide to switch. All of which means that in many or most
>> cases, it's entirely possible to consider the GD32 chips as a second
>> source for the STM32 ones.
> 
> Of course they would verify the second source worked.  I designed a board I expected to be making for some time.
[snip]

Nice work.

> Having choices in parts purchasing can extend the life of a produce or keep it affordable.

And so the GD32 parts could likewise be validated as a second source for 
STM32, contrary to your earlier claim.

CH.

[toc] | [prev] | [next] | [standalone]

#29887

On Wednesday, July 29, 2020 at 9:04:47 PM UTC-4, Clifford Heath wrote:
> On 30/7/20 10:46 am, Rick C wrote:
> > On Wednesday, July 29, 2020 at 8:04:29 PM UTC-4, Clifford Heath wrote:
> >> On 30/7/20 9:47 am, Rick C wrote:
> >>> On Wednesday, July 29, 2020 at 5:57:54 PM UTC-4, Chris wrote:
> >>>> 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...
> >>> 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.
> >>
> >> Even with a strict second-source policy, actually validating the device
> >> after with the second source will require some additional work. Do
> >> product managers require validation of correct operation with any second
> >> source *before* they need to switch to it? Because if not, they should
> >> expect the possibility of additional work (including minor code changes)
> >> when they do decide to switch. All of which means that in many or most
> >> cases, it's entirely possible to consider the GD32 chips as a second
> >> source for the STM32 ones.
> > 
> > Of course they would verify the second source worked.  I designed a board I expected to be making for some time.
> [snip]
> 
> Nice work.
> 
> > Having choices in parts purchasing can extend the life of a produce or keep it affordable.
> 
> And so the GD32 parts could likewise be validated as a second source for 
> STM32, contrary to your earlier claim.

Hardly.  From what I believe you have written, they have had several issues of non-compatibility and have fixed those issues.  For my use, sure, that would not be a bad thing.  For many uses, no changes are allowed because potentially no longer meeting some spec.  

If you have a serious need for a component that will meet all specifications for an extended period of time Chinese knockoffs are not a second source.  I'm pretty sure I would not even consider them. 

The part I use can be bought on Aliexpress and other venues for much cheaper than through approved vendors.  I ain't doin' that because there is too much chance of counterfeits and crap.  

-- 

  Rick C.

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

[toc] | [prev] | [next] | [standalone]

#29890

On 30/7/20 2:16 pm, Rick C wrote:
> On Wednesday, July 29, 2020 at 9:04:47 PM UTC-4, Clifford Heath wrote:
>> On 30/7/20 10:46 am, Rick C wrote:
>>> On Wednesday, July 29, 2020 at 8:04:29 PM UTC-4, Clifford Heath wrote:
>>>> On 30/7/20 9:47 am, Rick C wrote:
>>>>> On Wednesday, July 29, 2020 at 5:57:54 PM UTC-4, Chris wrote:
>>>>>> 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...
>>>>> 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.
>>>>
>>>> Even with a strict second-source policy, actually validating the device
>>>> after with the second source will require some additional work. Do
>>>> product managers require validation of correct operation with any second
>>>> source *before* they need to switch to it? Because if not, they should
>>>> expect the possibility of additional work (including minor code changes)
>>>> when they do decide to switch. All of which means that in many or most
>>>> cases, it's entirely possible to consider the GD32 chips as a second
>>>> source for the STM32 ones.
>>>
>>> Of course they would verify the second source worked.  I designed a board I expected to be making for some time.
>> [snip]
>>
>> Nice work.
>>
>>> Having choices in parts purchasing can extend the life of a produce or keep it affordable.
>>
>> And so the GD32 parts could likewise be validated as a second source for
>> STM32, contrary to your earlier claim.
> 
> Hardly.  From what I believe you have written, they have had several issues of non-compatibility

I don't know that. But it has been an issue with chips that have been 
cloned in a similar way, for example the AVR-like chips that aren't from 
Atmel. Yet the majority of Arduino sketches (yuk, child's play, 
admittedly) still "just work". The differences are known and can be 
worked around, to write code that works on both authentic and cloned chips.

I also don't know (and doubt) that the clone chips have been revised, 
but as long as you buy the correct version, there's no problem.

> For many uses, no changes are allowed because potentially no longer meeting some spec.

If you validate the design on two different chips, and can continue to 
acquire the same versions, then there should be no problem.

> If you have a serious need for a component that will meet all specifications for an extended period of time Chinese knockoffs are not a second source.

Wake up sunshine! Almost all the "US" chips are now made in China. One 
of the last hold-outs is Intel, and they're falling behind. You'll need 
to take early retirement if you refuse to use Chinese chips.

CH

[toc] | [prev] | [next] | [standalone]

#29903

On Thursday, July 30, 2020 at 2:36:53 AM UTC-4, Clifford Heath wrote:
> On 30/7/20 2:16 pm, Rick C wrote:
> > On Wednesday, July 29, 2020 at 9:04:47 PM UTC-4, Clifford Heath wrote:
> >> On 30/7/20 10:46 am, Rick C wrote:
> >>> On Wednesday, July 29, 2020 at 8:04:29 PM UTC-4, Clifford Heath wrote:
> >>>> On 30/7/20 9:47 am, Rick C wrote:
> >>>>> On Wednesday, July 29, 2020 at 5:57:54 PM UTC-4, Chris wrote:
> >>>>>> 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...
> >>>>> 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.
> >>>>
> >>>> Even with a strict second-source policy, actually validating the device
> >>>> after with the second source will require some additional work. Do
> >>>> product managers require validation of correct operation with any second
> >>>> source *before* they need to switch to it? Because if not, they should
> >>>> expect the possibility of additional work (including minor code changes)
> >>>> when they do decide to switch. All of which means that in many or most
> >>>> cases, it's entirely possible to consider the GD32 chips as a second
> >>>> source for the STM32 ones.
> >>>
> >>> Of course they would verify the second source worked.  I designed a board I expected to be making for some time.
> >> [snip]
> >>
> >> Nice work.
> >>
> >>> Having choices in parts purchasing can extend the life of a produce or keep it affordable.
> >>
> >> And so the GD32 parts could likewise be validated as a second source for
> >> STM32, contrary to your earlier claim.
> > 
> > Hardly.  From what I believe you have written, they have had several issues of non-compatibility
> 
> I don't know that. But it has been an issue with chips that have been 
> cloned in a similar way, for example the AVR-like chips that aren't from 
> Atmel. Yet the majority of Arduino sketches (yuk, child's play, 
> admittedly) still "just work". The differences are known and can be 
> worked around, to write code that works on both authentic and cloned chips.
> 
> I also don't know (and doubt) that the clone chips have been revised, 
> but as long as you buy the correct version, there's no problem.
> 
> > For many uses, no changes are allowed because potentially no longer meeting some spec.
> 
> If you validate the design on two different chips, and can continue to 
> acquire the same versions, then there should be no problem.
> 
> > If you have a serious need for a component that will meet all specifications for an extended period of time Chinese knockoffs are not a second source.
> 
> Wake up sunshine! Almost all the "US" chips are now made in China. One 
> of the last hold-outs is Intel, and they're falling behind. You'll need 
> to take early retirement if you refuse to use Chinese chips.
> 
> CH

Look "sunshine", if you are going to talk nonsense, there is no point in discussing the issue.  Chips made in China are not the same as "knockoffs" and most chips are not made in the PRC.  Most chips are made in Taiwan and other Asian countries.  

Get your facts straight before your resort to insults.  It makes you look fatuous.  

I don't think I'm going to continue to discuss this issue with you since you have repeatedly failed to understand the significant issues.  

Enjoy. 

-- 

  Rick C.

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

[toc] | [prev] | [next] | [standalone]

#29882

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

[toc] | [prev] | [next] | [standalone]

#29885

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.  

-- 

  Rick C.

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

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.arch.embedded

csiph-web