On Wed, 08 Jul 2020 09:31:38 -0700, Rick C wrote:>> I designed a bunch of instruments with ARM7TDMI 20 years ago, and the >> chips are still around. > > Was there any guarantee of that? Are they second sourced if the > original maker stops making them? 20 years ago did you know these chips > would be around now? > > All manner of devices survive the years, but how do you know which ones > will and which ones won't? > > The 8051 is the cockroach of MCUs. It will survive virtually anything > in the semiconductor industry... much to the chagrin of most designers. > > I would love if the world would pick a half dozen MCUs in as many > packages and designate them as the next generation 8051 to be made for > 50 years. It would make many project life cycles much simpler.Maybe that's an argument to use Risc-V---you know you'd be able to burn it into whatever programmable logic is available in 50 years. Of course the trick is that for cost reasons you want to use a hardware implementation today---I am not 100% sure that the entire system for today's hardware Risc-V are open sourced---the core CPU of course is, and there are many peripherals available, but I think some peripherals may be proprietary.
Interrupts: can be lost?
Started by ●July 7, 2020
Reply by ●July 19, 20202020-07-19
Reply by ●July 19, 20202020-07-19
On 7/19/2020 21:38, Przemek Klosowski wrote:> On Wed, 08 Jul 2020 09:31:38 -0700, Rick C wrote: > >>> I designed a bunch of instruments with ARM7TDMI 20 years ago, and the >>> chips are still around. >> >> Was there any guarantee of that? Are they second sourced if the >> original maker stops making them? 20 years ago did you know these chips >> would be around now? >> >> All manner of devices survive the years, but how do you know which ones >> will and which ones won't? >> >> The 8051 is the cockroach of MCUs. It will survive virtually anything >> in the semiconductor industry... much to the chagrin of most designers. >> >> I would love if the world would pick a half dozen MCUs in as many >> packages and designate them as the next generation 8051 to be made for >> 50 years. It would make many project life cycles much simpler. > > Maybe that's an argument to use Risc-V---you know you'd be able to burn > it into whatever programmable logic is available in 50 years. > > Of course the trick is that for cost reasons you want to use a hardware > implementation today---I am not 100% sure that the entire system for > today's hardware Risc-V are open sourced---the core CPU of course is, and > there are many peripherals available, but I think some peripherals may be > proprietary. >I think people put too much into processor longevity. Code can be compiled for another core at much lower cost (including tooling cost) than people are willing to pay for using sub optimal hardware today in the hope it will pay off decades later. About 20 years ago I had something like 10 megabytes of sources written in 68k assembly. At the time - early 90-s - when I picked the 68k (a cpu32 really) processor this was just the best part I could buy. At some point early this century the best part I could buy was power (PPC as they had it back then) based; it did cost me a year to manage what now is vpa (virtual processor assembler) and move on, having practically all my code working again. Was by far the better deal for me than if I had wasted myself into compromising using this or that, looking for toolchains etc. No chance I could have been 10% as efficient as I have been just because I had complete control over my tools. IOW get the best deal you can get at the moment where other people except you are involved (e.g. chip makers) and do things you have complete control of really well so you don't have to do them again. Dimiter ====================================================== Dimiter Popoff, TGI http://www.tgi-sci.com ====================================================== http://www.flickr.com/photos/didi_tgi/
Reply by ●July 19, 20202020-07-19
On Sunday, July 19, 2020 at 2:38:14 PM UTC-4, Przemek Klosowski wrote:> On Wed, 08 Jul 2020 09:31:38 -0700, Rick C wrote: > > >> I designed a bunch of instruments with ARM7TDMI 20 years ago, and the > >> chips are still around. > > > > Was there any guarantee of that? Are they second sourced if the > > original maker stops making them? 20 years ago did you know these chips > > would be around now? > > > > All manner of devices survive the years, but how do you know which ones > > will and which ones won't? > > > > The 8051 is the cockroach of MCUs. It will survive virtually anything > > in the semiconductor industry... much to the chagrin of most designers. > > > > I would love if the world would pick a half dozen MCUs in as many > > packages and designate them as the next generation 8051 to be made for > > 50 years. It would make many project life cycles much simpler. > > Maybe that's an argument to use Risc-V---you know you'd be able to burn > it into whatever programmable logic is available in 50 years. > > Of course the trick is that for cost reasons you want to use a hardware > implementation today---I am not 100% sure that the entire system for > today's hardware Risc-V are open sourced---the core CPU of course is, and > there are many peripherals available, but I think some peripherals may be > proprietary.If your goal is to create a product that needs to be constructed and sold for many years, being able to use programmable logic is not of much utility. Unless the board was originally designed with the same part available today, a board respin will be required which will mean a re-certification effort which is often more expensive than designing the board in the first place. If you are just building something with no critical requirements, then sure, use whatever chip you want. Back when ARMs were just starting to be widespread I predicted they would take over from the other MCUs because people would want a common platform available from many makers. Someone explained very clearly that the CPU is the least important part of the CPU. Compilers manage the details of 99% of the code and the startup code is often provided. But the peripherals is the part that varies between makers hugely and that can be the source of significant code changes when porting to new processors. So RISC-V, ARM, 8051... not really so important unless you need to design and certify a product once for the next 20 years or longer. Then the 8051 stands out from the crowd. -- Rick C. +-+ Get 1,000 miles of free Supercharging +-+ Tesla referral code - https://ts.la/richard11209
Reply by ●July 29, 20202020-07-29
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
Reply by ●July 29, 20202020-07-29
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... > > ChrisIf 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
Reply by ●July 29, 20202020-07-29
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
Reply by ●July 29, 20202020-07-29
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... > > ChrisOk, 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
Reply by ●July 29, 20202020-07-29
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.
Reply by ●July 29, 20202020-07-29
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
Reply by ●July 29, 20202020-07-29
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
