Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #29761 > unrolled thread
| Started by | pozz <pozzugno@gmail.com> |
|---|---|
| First post | 2020-07-08 00:38 +0200 |
| Last post | 2020-07-13 08:35 +0200 |
| Articles | 20 on this page of 64 — 18 participants |
Back to article view | Back to comp.arch.embedded
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 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
| From | Chris <xxx.syseng.yyy@gfsys.co.uk> |
|---|---|
| Date | 2020-07-30 19:05 +0100 |
| Message-ID | <rfv25k$pr6$1@gioia.aioe.org> |
| In reply to | #29885 |
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
[toc] | [prev] | [next] | [standalone]
| From | Dimiter_Popoff <dp@tgi-sci.com> |
|---|---|
| Date | 2020-07-31 00:21 +0300 |
| Message-ID | <rfvdkv$uh$1@dont-email.me> |
| In reply to | #29901 |
On 7/30/2020 21:05, Chris wrote: > On 07/30/20 01:53, Rick C wrote: >> On Wednesday, July 29, 2020 at 8:11:11 PM UTC-4, Chris wrote: >>> On 07/30/20 00:47, Rick C wrote: >>>> On Wednesday, July 29, 2020 at 5:57:54 PM UTC-4, Chris wrote: >>>>> On 07/29/20 21:23, Rick C wrote: >>>>>> On Wednesday, July 29, 2020 at 2:44:46 PM UTC-4, Chris wrote: >>>>>>> On 07/10/20 07:28, Rick C wrote: >>>>>>>> On Friday, July 10, 2020 at 2:01:49 AM UTC-4, Clifford Heath wrote: >>>>>>>>> On 10/7/20 11:41 am, Rick C wrote: >>>>>>>>>> On Thursday, July 9, 2020 at 6:22:24 PM UTC-4, >>>>>>>>>> lasselangwad...@gmail.com wrote: >>>>>>>>>>> torsdag den 9. juli 2020 kl. 20.47.25 UTC+2 skrev Paul Rubin: >>>>>>>>>>>> Rick C<gnuarm.deletethisbit@gmail.com> writes: >>>>>>>>>>>>> I have yet to find a single ARM processor that had a true, pin >>>>>>>>>>>>> compatible second source. >>>>>>>>>>>> >>>>>>>>>>>> I thought there were some Chinese clones of the lower end >>>>>>>>>>>> STM32F series >>>>>>>>>>>> but I haven't paid close attention. >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> yep, I know there are several clones of STM32F103xxxx >>>>>>>>>> >>>>>>>>>> So "clone" equals "second source"??? >>>>>>>>> >>>>>>>>> Not really. They haven't licensed ST's masks, they've just >>>>>>>>> designed >>>>>>>>> their own chips to match the documented behaviour. >>>>>>>>> >>>>>>>>> The chips I know of are by GigiDevice and Mindmotion, part numbers >>>>>>>>> GD32F3??? and MM32F??? to match the STM32F???. >>>>>>>>> >>>>>>>>> I see over 100 variants waiting on reels in JLCPCB's fab. >>>>>>>>> >>>>>>>>> Clifford Heath. >>>>>>>> >>>>>>>> Ok, then they are pretty useless as second sources. I see >>>>>>>> someone mentioned bugs that are being worked out. Not >>>>>>>> encouraging. Is Gigidevice a company that makes FPGAs? Or am I >>>>>>>> mixing them up with someone else? Ah, I see I have downloaded >>>>>>>> their data sheets, so I guess I was looking at a low cost RISC-V >>>>>>>> board and also have info on their ARM ST clone chip. Wait, it's >>>>>>>> the same chip! No sign of FPGAs. That was one of the other >>>>>>>> companies like AGM, Anlogic or maybe Gowin. AGM has an >>>>>>>> interesting data sheet, but it's two years old and no sign of >>>>>>>> the device. >>>>>>>> >>>>>>> >>>>>>> Seems to me that companies that box themselves into a corner over >>>>>>> processors and second sources get what they deserve and is generally >>>>>>> a sign of poor strategy and project management. I've worked on a >>>>>>> couple of projects using essentially obsolete 8051 hardware, >>>>>>> recommended a redesign using a more modern architecture, but they >>>>>>> were not listening. Result was a greatly extended development time, >>>>>>> costs, difficult ongoing software maintenance and compromises >>>>>>> everywhere due to banked architecture for code and data. Having said >>>>>>> that, have used the silabs 80F... series for a couple of small >>>>>>> projects which worked really well. You wouldn't want to look at the >>>>>>> asm op from the compiler, but more than adequate for the task and >>>>>>> all written in C... >>>>>>> >>>>>>> Chris >>>>>> >>>>>> If a product requirement is to use only second sourced devices, >>>>>> that's the requirement. How do you propose getting around that? >>>>>> >>>>> >>>>> Fire the manager involved ?. >>>>> >>>>> As I said, if you box yourself into a corner in the design, then >>>>> choices become limited. I prefer to take a higher level view and >>>>> try to abstract the hardware into functions that are common to >>>>> most micros. For example comms, timers and other core functions. >>>>> Define a set of call interfaces into that required functionality, >>>>> then all that's needed is an abstraction layer between that and >>>>> the underlying hardware. There are great benefits in terms of code >>>>> reuse, reliablity, cost and project times. Use a subset of processor >>>>> capabilities and deal with special cases as needed. There is some >>>>> work, but develop over a few projects, to end up with a set of known >>>>> good library code that can be added to and reused indefinately. I >>>>> think it was Win NT that first publicised the idea of a hw abstraction >>>>> layer, but with the speed of modern micros, you can apply that idea to >>>>> just about any embedded project. >>>>> >>>>> The whole idea is to design assuming that the hardware will change >>>>> over time, new requirements, performance, cost, whatever, as new >>>>> micros come to market. The exact opposite of s design frozen in >>>>> time, with all the hassle that involves... >>>>> >>>>> Chris >>>> >>>> Ok, I get it. You don't understand requirements. There are >>>> perfectly valid reasons for wanting second sources on parts that >>>> obviously have never applied on projects you've worked on. So you >>>> don't understand why anyone will need that requirement. >>>> >>>> Whether you understand or not, that's a valid requirement and firing >>>> the manager to change the requirement will only result in a failure >>>> of the project. >>>> >>>> If you want to discuss the issue, I'm happy to do that, but you are >>>> going to need to change a lot of your assumptions for us to >>>> communicate. >>>> >>> >>> ???... >>> >>> Oh, I understand requirements, but while second sourcing is always a >>> desirable thing for any manufactured item, it gets more and more >>> difficult to ensure with the ever increasing complexity and feature >>> set of modern micros, all of which differ. All I was trying to do >>> was suggest a different way of looking at things, but if you have >>> already made your mind up, not much point really. Find a different >>> solution, it's that simple. Just because you demand something >>> won't make it magically happen, or that it's even possible. >>> >>> The only people who have a financial muscle to ensure second source >>> and decades supply guarantee are probably defence and avionics, but >>> most of industry doesn't work that way, far too expensive. Best you >>> can hope to do is choose a vendor agnostic architecture, like arm, >>> for example, where there's chance you will be able to make at least >>> some of the code common to several vendor's product... >>> >>> Chris >> >> You do not understand, which shows in your use of the term "desirable". >> >> This is getting absurd. You want to make the issue about the whim of >> a manager or myself and you don't understand that redesigning a >> produce at times is literally not an option because of the huge >> expense. You must not have worked on anything that needed more than >> just testing and it was out the door. >> >> My current product had to go through various levels of certification >> before it could be used. A part on the board is getting expensive to >> buy and eventually will be unavailable. I might be willing to design >> a new board with a different part, but the company who buys them may >> not be willing to pay for the certifications. At that point the >> product will be dead. >> >> There are apps where the certs are very expensive, like space or >> various safety related uses. Nuke plants are an example. >> >> I'm not going to continue to bat this around with you when you clearly >> are not getting the concept. > > > Oh, I understand requirements, but while second sourcing is always a > desirable thing for any manufactured item, it gets more and more > difficult to ensure with the ever increasing complexity and feature > set of modern micros, all of which differ. All I was trying to do > was suggest a different way of looking at things, but if you have > already made your mind up, not much point really. Find a different > solution, it's that simple. Just because you demand something > won't make it magically happen, or that it's possible. > > The only people who have a financial muscle to ensure second source > and decades supply guarantee are probably defence and avionics, but > most of industry doesn't work that way, far too expensive. Best you > can hope to do is choose a vendor agnostic architecture, like arm, > for example, where there's chance you will be able to make at least > some of the code common to several vendor's product... > > Chris > > I think I get the concept, but if there is no second source for a part, > what's your solution ?. Only thing I can see to ensure continuity is > to buy a product lifetime set of parts... > > Chris > Basically lifetime buy is the only way indeed, second source or not; second sources are not immortal just like first ones. While Rick's point about certification is valid it is hard to imagine how a customer will be willing to bear the cost of that certification and not the (probably minor in comparison) cost of a lifetime part buy. But people do all sorts of things when planning ahead, you never know what is behind the corner. We all cope with the times which "are a changin'" , sometimes we get it right sometimes we don't. Dimiter ====================================================== Dimiter Popoff, TGI http://www.tgi-sci.com ====================================================== http://www.flickr.com/photos/didi_tgi/
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-08-04 20:40 +0200 |
| Message-ID | <rgca2j$r0n$1@dont-email.me> |
| In reply to | #29885 |
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. >
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2020-08-04 14:36 -0700 |
| Message-ID | <2aa97863-3761-431c-9955-69ce3721bd95o@googlegroups.com> |
| In reply to | #29907 |
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
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2020-08-04 22:32 -0400 |
| Message-ID | <SSoWG.29043$tL.10161@fx15.iad> |
| In reply to | #29907 |
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.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-08-05 15:26 +0200 |
| Message-ID | <rgec1l$md8$1@dont-email.me> |
| In reply to | #29909 |
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.
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2020-07-30 08:31 +0300 |
| Message-ID | <1gi4iftfba5sovfrn7460m17ntbuu486f6@4ax.com> |
| In reply to | #29880 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2020-07-30 07:53 +0100 |
| Message-ID | <y7uUG.2515955$aGl.1663214@fx36.am4> |
| In reply to | #29889 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2020-07-30 08:10 -0400 |
| Message-ID | <fNyUG.211946$DO2.30993@fx45.iad> |
| In reply to | #29878 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2020-07-09 18:40 -0700 |
| Message-ID | <205e5d07-ce28-429e-8753-1bc32615fd28o@googlegroups.com> |
| In reply to | #29801 |
On Thursday, July 9, 2020 at 2:47:25 PM UTC-4, Paul Rubin wrote: > 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. Yes, that is exactly what a company will be counting on for 20 years of support, Chinese clones. Are you actually reading the thread? > > 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. You still need the OS and hardware interfaces. Can you still buy a copy of XP? -- Rick C. --- Get 1,000 miles of free Supercharging --- Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-07-10 09:09 +0200 |
| Message-ID | <re946o$a8t$1@dont-email.me> |
| In reply to | #29812 |
On 10/07/2020 03:40, Rick C wrote: > On Thursday, July 9, 2020 at 2:47:25 PM UTC-4, Paul Rubin wrote: >> 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. > > Yes, that is exactly what a company will be counting on for 20 years of support, Chinese clones. Are you actually reading the thread? > > >>> 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. > > You still need the OS and hardware interfaces. Can you still buy a copy of XP? > Separate your parts into the bits that generate code, and the rest. The toolchain is important - the compiler, libraries and build-critical parts. The IDE is not critical, nor are debuggers, programmers, etc. I don't (usually) archive VM's - I archive folders with toolchains. You only need a VM if the tools won't run on later OS's (or DOSBox or Wine). It can be a lot more difficult if the toolchain has some kind of licensing and protection mechanism. You might have to archive physical computers, not just VM's, to get that all preserved. I don't believe you can still buy a license for XP. But an installation CD from long ago works perfectly well as an installation CD now (especially if it is an iso file for a VM...). You have IIRC 30 days to use it before the "activation" mechanism locks you out. (And there are ways around that too, if you want to go down that path.)
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2020-07-10 01:41 -0700 |
| Message-ID | <2f413003-6bbe-4163-ae23-23dd7f676595o@googlegroups.com> |
| In reply to | #29825 |
On Friday, July 10, 2020 at 3:09:15 AM UTC-4, David Brown wrote: > On 10/07/2020 03:40, Rick C wrote: > > On Thursday, July 9, 2020 at 2:47:25 PM UTC-4, Paul Rubin wrote: > >> 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. > > > > Yes, that is exactly what a company will be counting on for 20 years of support, Chinese clones. Are you actually reading the thread? > > > > > >>> 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. > > > > You still need the OS and hardware interfaces. Can you still buy a copy of XP? > > > > Separate your parts into the bits that generate code, and the rest. The > toolchain is important - the compiler, libraries and build-critical > parts. The IDE is not critical, nor are debuggers, programmers, etc. I > don't (usually) archive VM's - I archive folders with toolchains. You > only need a VM if the tools won't run on later OS's (or DOSBox or Wine). > > It can be a lot more difficult if the toolchain has some kind of > licensing and protection mechanism. You might have to archive physical > computers, not just VM's, to get that all preserved. > > I don't believe you can still buy a license for XP. But an installation > CD from long ago works perfectly well as an installation CD now > (especially if it is an iso file for a VM...). You have IIRC 30 days to > use it before the "activation" mechanism locks you out. (And there are > ways around that too, if you want to go down that path.) All vendor supplied tool chains for FPGAs have licensing. The only way to continue to use an old license is to continue to reset the date on the machine. Even if you have a perpetual license you have to renew the license file. I recall finding out about that on a CAE system from 40 years ago. I asked what happens if the company goes under and the guy just shrugged. I don't recall which company it was from, but it was on Apollo computers. Anyone remember them? I think they got bought by Sun, no? Looks like it was HP! -- Rick C. +-- Get 1,000 miles of free Supercharging +-- Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-07-10 13:47 +0200 |
| Message-ID | <re9kgo$t7s$1@dont-email.me> |
| In reply to | #29829 |
On 10/07/2020 10:41, Rick C wrote: > On Friday, July 10, 2020 at 3:09:15 AM UTC-4, David Brown wrote: >> On 10/07/2020 03:40, Rick C wrote: >>> On Thursday, July 9, 2020 at 2:47:25 PM UTC-4, Paul Rubin wrote: >>>> 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. >>> >>> Yes, that is exactly what a company will be counting on for 20 >>> years of support, Chinese clones. Are you actually reading the >>> thread? >>> >>> >>>>> 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. >>> >>> You still need the OS and hardware interfaces. Can you still buy >>> a copy of XP? >>> >> >> Separate your parts into the bits that generate code, and the rest. >> The toolchain is important - the compiler, libraries and >> build-critical parts. The IDE is not critical, nor are debuggers, >> programmers, etc. I don't (usually) archive VM's - I archive >> folders with toolchains. You only need a VM if the tools won't run >> on later OS's (or DOSBox or Wine). >> >> It can be a lot more difficult if the toolchain has some kind of >> licensing and protection mechanism. You might have to archive >> physical computers, not just VM's, to get that all preserved. >> >> I don't believe you can still buy a license for XP. But an >> installation CD from long ago works perfectly well as an >> installation CD now (especially if it is an iso file for a VM...). >> You have IIRC 30 days to use it before the "activation" mechanism >> locks you out. (And there are ways around that too, if you want to >> go down that path.) > > All vendor supplied tool chains for FPGAs have licensing. The only > way to continue to use an old license is to continue to reset the > date on the machine. Even if you have a perpetual license you have > to renew the license file. I recall finding out about that on a CAE > system from 40 years ago. I asked what happens if the company goes > under and the guy just shrugged. I don't recall which company it was > from, but it was on Apollo computers. Anyone remember them? I think > they got bought by Sun, no? Looks like it was HP! > In a perfect world (from my viewpoint!), development software doesn't need any kind of license renewal, internet connection, time-limitation, software lock, USB dongle, etc., to work. And it works on Linux with little or no requirements for particular distributions or non-default libraries. I have nothing against paying for software or a license - that's okay. I also don't mind paying yearly fees for updates. But when I buy the software, I want the software I bought to be useable from any system, at any time in the future. There can be /legal/ restrictions (single user, single company, single project, whatever), but I don't want /technical/ restrictions that limit my ability to use the software. I've dealt with enough crap from software locked to laptops that died, software that "phones home" to servers that no longer exist, dongles that don't work, etc. This kind of nonsense just makes honest users use workarounds. I have more than enough virtual machines with virtual network cards that all have the same MAC address, and have at least four ancient hard disks that all have the same serial number. And I have seen a computer with its time and date locked to an old date because the old license dongle worked but the new one did not. I don't always get things the way I want, but these things are a significant influence for my choice of tools, and therefore my choice of hardware. I've rejected microcontroller families solely on the basis of a lack of Linux support in their development tools. And if I do any more FPGA work, the way the license and "software protection" is handled will definitely be a factor in choosing devices and tools. (I don't claim it will be the overriding factor - there are bigger differences and fewer vendor choices in the FPGA world than in the microcontroller world.)
[toc] | [prev] | [next] | [standalone]
| From | Dimiter_Popoff <dp@tgi-sci.com> |
|---|---|
| Date | 2020-07-11 13:41 +0300 |
| Message-ID | <rec50m$qeo$1@dont-email.me> |
| In reply to | #29798 |
On 7/9/2020 21:04, Rick C wrote: > On Thursday, July 9, 2020 at 8:16:18 AM UTC-4, David Brown wrote: >> On 08/07/2020 16:35, Rick C wrote: >>> On Wednesday, July 8, 2020 at 10:07:24 AM UTC-4, David Brown wrote: >>>> On 08/07/2020 16:01, Rick C wrote: >>>>> On Wednesday, July 8, 2020 at 7:57:43 AM UTC-4, Tauno Voipio >>>>> wrote: >>>>>> On 8.7.20 11.43, Niklas Holsti wrote: >>>>>>> On 2020-07-08 10:02, David Brown wrote: >>>>>>>> On 08/07/2020 00:38, pozz wrote: >>>>>>>>> https://www.safetty.net/download/pont_pttes_2001.pdf >>>>>>>>> >>>>>>>>> Page 13 Note carefully what this means! There is a >>>>>>>>> common misconception among the developers of embedded >>>>>>>>> applications that interrupt events will never be lost. >>>>>>>>> This simply is not true. If you have multiple sources of >>>>>>>>> interrupts that may appear at ‘random’ time intervals, >>>>>>>>> interrupt responses can be missed: indeed, where there >>>>>>>>> are several active interrupt sources, it is practically >>>>>>>>> impossible to create code that will deal correctly with >>>>>>>>> all possible combinations of interrupts. >>>>>>>>> >>>>>>>>> Those words are incredible for me. I suspect I didn't get >>>>>>>>> the point of the author. I don't think that interrupt >>>>>>>>> events on modern microntrollers can be lost in some >>>>>>>>> circumstances. >>>>>>>> >>>>>>>> The book was written in 2001, using a microcontroller >>>>>>>> that, while very popular (and still not dead), was 20 years >>>>>>>> out of date at the time. I haven't looked at it yet, and >>>>>>>> can't judge the quality of the book. But beware that some >>>>>>>> things in it could be limited by that microcontroller >>>>>>>> architecture. >>>>>>>> >>>>>>>> However, the principle here is correct. It is part of a >>>>>>>> more general principle that is actually quite simple: >>>>>>>> >>>>>>>> If you have event counters or trackers that have limited >>>>>>>> capacity, and you do not handle the events before that >>>>>>>> capacity is exceeded, your system will lose events (by >>>>>>>> either ignoring new ones, or ejecting old ones). >>>>>>> >>>>>>> Indeed. >>>>>>> >>>>>>> Note that the book's author clearly has an axe to grind >>>>>>> here[1], because he advocates using "time triggering" instead >>>>>>> of event- (interrupt-) triggering. So he's trying to make you >>>>>>> afraid of interrupts. >>>>>>> >>>>>>> Of course a similar problem applies to time-triggered >>>>>>> systems: if you trigger a task every millisecond, but the >>>>>>> task sometimes needs more than a millisecond to complete... >>>>>>> something bad can happen. >>>>>>> >>>>>>> [1] Or, as is said here in Finland, "he has his own cow in >>>>>>> the ditch". >>>>>> >>>>>> >>>>>> The writer is advocating the 8051 family, which is awfully >>>>>> clumsy for running real multi-threading. Besides, it should be >>>>>> forgotten in favor of e.g. the Cortex-M processors, which are >>>>>> even at least as inexpensive as the 8051's with required >>>>>> support. >>>>>> >>>>>> (Mooo! from southern Finland). >>>>> >>>>> That would be nice in an ideal world. I know of one designer >>>>> that will still use the 8051 processor in designs that require a >>>>> second source and longevity of supply. When qualification of a >>>>> design is very expensive these properties can be very important. >>>>> If the 8051 is the only processor that meets these requirements >>>>> then that is the one you will use. >>>> >>>> Yes, but it is not the only option. >>>> >>>>> >>>>> There are many, many ARM MCUs on the market today. Which ones >>>>> will still be around in 20 years? >>>>> >>>> >>>> The ones that manufacturers say they will continue to produce. >>>> Any manufacturer with automotive customers will have long-term >>>> guarantees. (I don't know how common 20 year lifetimes are - I >>>> haven't had to look /that/ long.) >>>> >>>> Second sources are not easy if you need /exact/ matches, but your >>>> friendly local distributors can help. >>> >>> You seem to miss the point. The 8051 IS the only processor that you >>> can find with second sources and guarantees of extreme longevity. >>> That's why he used it. >>> >> >> I didn't miss the point. The 8051 is not a processor that you can buy, >> it is a family of related variations of a core that is found in many >> microcontrollers. Virtually all 8051-based microcontrollers are >> single-source, and have the same types of longevity as other >> microcontrollers (10 years+ is typical, with 15 to 20 years or more for >> specialised parts). There is nothing special about the 8051 except that >> it is already old, and you'd have a hard time finding 8051 parts now >> that are guaranteed to be produced for /another/ 20 years - it doesn't >> help if it has been produced for the /past/ 20 years. > > Everything you say is true except for the parts that aren't. That many people make non-pin compatible variations on the 8051 is irrelevant. The fact is that there are second sources of pin compatible parts and that there are makers who are promising to supply the devices for a period of time. If you want confirmation of this you can go over to sci.electronics.design and post to Joerg. He is the one using the 8051 for these exact reasons. > > >> What you said was that the 8051 was the only "processor" that fitted the >> requirements of longevity. Now, it might well be that in this >> particular case, the chip you have is the only option that fitted. But >> it does not mean that it is true in general. I am confident that if I >> asked my distributors, they could find long-lived ARM microcontrollers >> (as well as PowerPC, and various other cores). Second source for an >> identical chip is hard to find, but they do exist (especially if you are >> willing to pay for it - there are companies that store bare dies for >> decades and will package them when a customer needs them, and there are >> companies that do specialised versions of standard chips for military or >> other special-needs customers). But you only talked about second source >> for the core - presumably it is software and tools that are qualified >> here, rather than the hardware. > > Not sure what you are talking about companies storing bare die. The context was standard devices that aren't going into space or otherwise have a hugely inflated price. > > I have yet to find a single ARM processor that had a true, pin compatible second source. There may be some in the automotive sector that are not available to those needing thousands a year rather than millions per year. But even then I've not found them. Each manufacturer produces their own line of products and compete based on the little differences that make their product "better" rather than being a second source to someone else. > > Not sure what you are trying to say about the tools. Anyone who wishes to maintain a design for >10 years or even five needs to archive the tools and and the machine they run on. I presently have that problem. The tools from >10 years ago still seem to run on my recent PC running Win10, but who knows what will happen next time I update? I may need to resurrect a 15 year old desktop running Win2k. > Second source in the context of processors is overrated. Rewind about 40 years when the 6809 had a second source, a 6309 from Hitachi to no effect on the processor lifespan. With some luck and a lot of careful consideration one can pick a processor which will live for >10 years. I have managed that with the 68hc11, 68340, mpc5200b, mcf52211... not so sure about the mpc824x, but my design with it did not live long enough for this to matter (yet it did a good job aiding the migration 68k -> power). I can't speak firsthand on the toolchains people use as those I use are 100% mine, I can even run on a VM emulating the 6809 in dps windows what I ran before I had all toolchains mine, things I have written back in the 80-s. I know some people archive entire machines so they can replicate the design process years later if needed; but with flash memories relying on tinier and tinier gate charges this becomes less and less viable (I have a dps machine on my desk 20+ years old, and I have 10+ years old netMCA devices in the field which show no issues... I think flash memories of a few megabytes which will hold charge for 10+ years are still available, time will tell. Dimiter ====================================================== Dimiter Popoff, TGI http://www.tgi-sci.com ====================================================== http://www.flickr.com/photos/didi_tgi/
[toc] | [prev] | [next] | [standalone]
| From | Tauno Voipio <tauno.voipio@notused.fi.invalid> |
|---|---|
| Date | 2020-07-08 17:33 +0300 |
| Message-ID | <re4lfc$ro2$1@dont-email.me> |
| In reply to | #29778 |
On 8.7.20 17.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. > > There are many, many ARM MCUs on the market today. Which ones will still be around in 20 years? I designed a bunch of instruments with ARM7TDMI 20 years ago, and the chips are still around. -- -TV
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2020-07-08 09:31 -0700 |
| Message-ID | <f16356d5-7b65-4fc1-9cec-7371fa2b5211o@googlegroups.com> |
| In reply to | #29782 |
On Wednesday, July 8, 2020 at 10:33:20 AM UTC-4, Tauno Voipio wrote: > On 8.7.20 17.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. > > > > There are many, many ARM MCUs on the market today. Which ones will still be around in 20 years? > > > 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. -- Rick C. +- Get 1,000 miles of free Supercharging +- Tesla referral code - https://ts.la/richard11209
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-07-09 14:30 +0200 |
| Message-ID | <re72kn$or7$1@dont-email.me> |
| In reply to | #29784 |
On 08/07/2020 18:31, Rick C wrote: > On Wednesday, July 8, 2020 at 10:33:20 AM UTC-4, Tauno Voipio wrote: >> On 8.7.20 17.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. >>> >>> There are many, many ARM MCUs on the market today. Which ones >>> will still be around in 20 years? >> >> >> 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? I look at manufacturers' websites, and I ask distributors. It's not hard to learn what the manufacturers plan to have in their long-term programs (to the best of their abilities, of course). Other devices simply continue to be produced as long as there are customers - the 68332 microcontroller, for example, has been produced for over 30 years. > > The 8051 is the cockroach of MCUs. It will survive virtually > anything in the semiconductor industry... much to the chagrin of most > designers. Are you talking about the original 8051 - the Intel MCS-51 in its big DIP package, or are you talking about the /core/ that is used in all sorts of variations by large numbers of manufactures in different incompatible microcontrollers? > > 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. >
[toc] | [prev] | [next] | [standalone]
| From | Przemek Klosowski <przemek@tux.dot.org> |
|---|---|
| Date | 2020-07-19 18:38 +0000 |
| Message-ID | <rf23ui$r4n$1@dont-email.me> |
| In reply to | #29784 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Dimiter_Popoff <dp@tgi-sci.com> |
|---|---|
| Date | 2020-07-19 23:11 +0300 |
| Message-ID | <rf29ed$dcr$1@dont-email.me> |
| In reply to | #29849 |
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/
[toc] | [prev] | [next] | [standalone]
| From | Rick C <gnuarm.deletethisbit@gmail.com> |
|---|---|
| Date | 2020-07-19 13:43 -0700 |
| Message-ID | <c2f6e16f-e335-4cba-ab10-b2f47edb2906o@googlegroups.com> |
| In reply to | #29849 |
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
[toc] | [prev] | [next] | [standalone]
Page 3 of 4 — ← Prev page 1 2 [3] 4 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web