On 05/08/2020 04:32, Richard Damon wrote:
> On 8/4/20 2:40 PM, David Brown wrote:
>>
>> And if you are a good designer and project partner, when a customer
>> makes a requirement that you think is likely to be a bad idea, you
>> question it.  You challenge it.  You try to find alternative solutions
>> that will give a better result overall for the project.  (It's unlikely,
>> however, that the best alternative is "fire the manager" !)  The
>> customer is /not/ always right - at least not at first.  As an
>> electronics designer and consultant, it is part of your job to tell the
>> customer if you don't think they are asking for the right thing - if you
>> give them what they ask for, not what they want or need, then you are
>> doing them a disservice.  Of course this will mean that sometimes a
>> customer will move on and find an alternative supplier.  That's part of
>> the job too.
>>
> 
> And sometimes the customer is VERY important, spending more than the
> next several possible customers for this sort of product combined (and
> the power to prevent you from selling to some of them). If you complain
> to loudly that they don't really know what they want, they are more than
> willing to find other suppliers, and if you make them too upset, they
> might black list you, effectively making you change your line of business.

Of course - as I said, there is no single right answer.  Occasionally it 
even makes sense to spend time, effort on money working on something 
that you know is fruitless, because it is important for keeping the 
customer.  And obviously you are more diplomatic in how you put things 
to the customer than one might be in a newsgroup!

We have had cases of a customer come to us with concrete requirements, 
have us tell them that the requirements are not realistic but we can 
help them with alternative ideas and solutions, and they have chosen to 
go away and find another development company.  Then after having wasted 
significant time and money with another company that tried and failed to 
fulfil the original requirements, they came back to us to find out how 
to get what they actually need, not what they asked for.

> 
> There ARE good reasons to spec parts to have second sources (and note,
> second source does NOT mean someone else has made a knock off clone of
> the part, for this purpose, second source tends to mean the company has
> an official second source agreement with the other firm.
> 

Oh, sure.  And occasionally those reasons might be good enough to make 
it worth doing.  But usually it's just wishful thinking on the part of 
the customer.  After all, from the customer's viewpoint, they have good 
reason for requiring the device to be small, cheap, long-lasting, 
suitable for production anywhere, and so on - that doesn't mean the 
requirements are realistic or the best choice for the project as a 
whole.  Helping the customer get the requirements right is part of the job.

On 8/4/20 2:40 PM, David Brown wrote:
> 
> And if you are a good designer and project partner, when a customer
> makes a requirement that you think is likely to be a bad idea, you
> question it.  You challenge it.  You try to find alternative solutions
> that will give a better result overall for the project.  (It's unlikely,
> however, that the best alternative is "fire the manager" !)  The
> customer is /not/ always right - at least not at first.  As an
> electronics designer and consultant, it is part of your job to tell the
> customer if you don't think they are asking for the right thing - if you
> give them what they ask for, not what they want or need, then you are
> doing them a disservice.  Of course this will mean that sometimes a
> customer will move on and find an alternative supplier.  That's part of
> the job too.
> 

And sometimes the customer is VERY important, spending more than the
next several possible customers for this sort of product combined (and
the power to prevent you from selling to some of them). If you complain
to loudly that they don't really know what they want, they are more than
willing to find other suppliers, and if you make them too upset, they
might black list you, effectively making you change your line of business.

There ARE good reasons to spec parts to have second sources (and note,
second source does NOT mean someone else has made a knock off clone of
the part, for this purpose, second source tends to mean the company has
an official second source agreement with the other firm.

On Tuesday, August 4, 2020 at 2:40:24 PM UTC-4, David Brown wrote:
> On 30/07/2020 02:53, Rick C wrote:
> 
> > 
> > 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.
> 
> Almost every serious product needs some level of certification.  And for 
> almost every serious product, there will be multiple critical parts for 
> which there is no drop-in second source with identical characteristics. 
>   And even when second sources exist, there will be no more guarantees 
> that they will be produced longer than the original part.  And for 
> almost every serious product, the engineering costs for re-design and 
> re-certification are high if parts do end up needing replaced.
> 
> You are not in some special situation here - this is life for 
> electronics designers and producers the world over.  There are all sorts 
> of ways to limit the risks and limit the resulting costs.  Requiring 
> "second source" for one component is one possibility - but it is rarely 
> a good idea overall.  It's better to run the risk of having to pay some 
> extra costs for a re-certification ten years in the future than to be 
> guaranteed to pay extra costs now for trying to design the product with 
> a hopelessly outdated device.
> 
> But one thing you can be sure of - there are no fixed answers that 
> always apply.  You deal with each project in the way that works best for 
> that project.
> 
> And if you are a good designer and project partner, when a customer 
> makes a requirement that you think is likely to be a bad idea, you 
> question it.  You challenge it.  You try to find alternative solutions 
> that will give a better result overall for the project.  (It's unlikely, 
> however, that the best alternative is "fire the manager" !)  The 
> customer is /not/ always right - at least not at first.  As an 
> electronics designer and consultant, it is part of your job to tell the 
> customer if you don't think they are asking for the right thing - if you 
> give them what they ask for, not what they want or need, then you are 
> doing them a disservice.  Of course this will mean that sometimes a 
> customer will move on and find an alternative supplier.  That's part of 
> the job too.
> 
> > 
> > There are apps where the certs are very expensive, like space or
> > various safety related uses.  Nuke plants are an example.
> > 
> 
> Sure - and what percentage of electronics development projects do these 
> account for?  Rounded to the nearest percent, nothing.  (And I've worked 
> on a few safety-related projects - second source was never an issue.)
> 
> > I'm not going to continue to bat this around with you when you
> > clearly are not getting the concept.
> >

Everything you posted is irrelevant, immaterial or tangential to the issue of second sources.  So, nothing to reply to. 

Enjoy. 

-- 

  Rick C.

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

On 30/07/2020 02:53, Rick C wrote:

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

Almost every serious product needs some level of certification.  And for 
almost every serious product, there will be multiple critical parts for 
which there is no drop-in second source with identical characteristics. 
  And even when second sources exist, there will be no more guarantees 
that they will be produced longer than the original part.  And for 
almost every serious product, the engineering costs for re-design and 
re-certification are high if parts do end up needing replaced.

You are not in some special situation here - this is life for 
electronics designers and producers the world over.  There are all sorts 
of ways to limit the risks and limit the resulting costs.  Requiring 
"second source" for one component is one possibility - but it is rarely 
a good idea overall.  It's better to run the risk of having to pay some 
extra costs for a re-certification ten years in the future than to be 
guaranteed to pay extra costs now for trying to design the product with 
a hopelessly outdated device.

But one thing you can be sure of - there are no fixed answers that 
always apply.  You deal with each project in the way that works best for 
that project.

And if you are a good designer and project partner, when a customer 
makes a requirement that you think is likely to be a bad idea, you 
question it.  You challenge it.  You try to find alternative solutions 
that will give a better result overall for the project.  (It's unlikely, 
however, that the best alternative is "fire the manager" !)  The 
customer is /not/ always right - at least not at first.  As an 
electronics designer and consultant, it is part of your job to tell the 
customer if you don't think they are asking for the right thing - if you 
give them what they ask for, not what they want or need, then you are 
doing them a disservice.  Of course this will mean that sometimes a 
customer will move on and find an alternative supplier.  That's part of 
the job too.

> 
> There are apps where the certs are very expensive, like space or
> various safety related uses.  Nuke plants are an example.
> 

Sure - and what percentage of electronics development projects do these 
account for?  Rounded to the nearest percent, nothing.  (And I've worked 
on a few safety-related projects - second source was never an issue.)

> I'm not going to continue to bat this around with you when you
> clearly are not getting the concept.
> 

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

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>&nbsp;&nbsp;&nbsp;&nbsp; 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.&nbsp; I see 
>>>>>>>> someone mentioned bugs that are being worked out.&nbsp; Not 
>>>>>>>> encouraging.&nbsp; Is Gigidevice a company that makes FPGAs?&nbsp; Or am I 
>>>>>>>> mixing them up with someone else?&nbsp; 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.&nbsp; Wait, it's 
>>>>>>>> the same chip!&nbsp; No sign of FPGAs.&nbsp; That was one of the other 
>>>>>>>> companies like AGM, Anlogic or maybe Gowin.&nbsp; 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.&nbsp; 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&nbsp; 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.&nbsp; You don't understand requirements.&nbsp; There are 
>>>> perfectly valid reasons for wanting second sources on parts that 
>>>> obviously have never applied on projects you've worked on.&nbsp; 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.&nbsp; 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.&nbsp; 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.&nbsp; A part on the board is getting expensive to 
>> buy and eventually will be unavailable.&nbsp; 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.&nbsp; At that point the 
>> product will be dead.
>>
>> There are apps where the certs are very expensive, like space or 
>> various safety related uses.&nbsp; 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/

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

On 7/29/20 5:57 PM, 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...

Usually, this Log Term Support requirements come from an industry (like
Defense) where the 'customer' is going to spend a LOT of effort
evaluating, proving and certify the design. And because of this they
want to be sure that the design (and exactly the design) that was
certified will be usable for what they see as the effective life of the
program.

f you used a part that becomes no longer available, and re-spin the
design to use a new part, they need to evaluate how much now needs to be
re-certified, which may cost YEARS of effort and a LOT of money. Now, if
you are willing to take PERSONAL responsibility, that the new item
behaves exactly as the old, and if some grunt doesn't notice an
anomalous result and bombs a village, YOU pay the reparations, go ahead.
Or for a different segment, a medical device that has gone though
rigorous testing to prove safety and some small change you make happens
to be able to be linked to a possibility that it killed a patient.

Many systems don't need the newest and shiniest system parts, but want
proven and reliable parts. Parts with long term supply promises, which
often include things like second source agreements, tend to provide
those promises better.

This market isn't like the consumer market where you actually often want
a soft of short lifetime of a given product so you can come out
regularly with new and improved versions, and perhaps convince people to
upgrade.

On 30/07/20 06:31, upsidedown@downunder.com wrote:
> On Wed, 29 Jul 2020 16:47:36 -0700 (PDT), Rick C
> <gnuarm.deletethisbit@gmail.com> wrote:
> 
>>
>> 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.
> 
> One should also consider the political risk with some politically
> unstable countries like USA, Russia or China. For this reason. better
> use components in which the primary manufacturer is outside these
> political risky countries to avoid licensing issues.
> 


Well, if you have read the news over the past couple of days,
that may rule out intel processors. Unless, that is, intel
can actually get its act together with its 7nm process.

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