Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > sci.electronics.design > #447672 > unrolled thread
| Started by | John Larkin <jjlarkinxyxy@highlandtechnology.com> |
|---|---|
| First post | 2017-02-14 14:47 -0800 |
| Last post | 2017-02-17 11:06 -0800 |
| Articles | 20 on this page of 89 — 21 participants |
Back to article view | Back to sci.electronics.design
analog failures John Larkin <jjlarkinxyxy@highlandtechnology.com> - 2017-02-14 14:47 -0800
Re: analog failures Lasse Langwadt Christensen <langwadt@fonz.dk> - 2017-02-14 15:05 -0800
Re: analog failures Reinhardt Behm <rbehm@hushmail.com> - 2017-02-15 10:52 +0800
Re: analog failures bill.sloman@ieee.org - 2017-02-14 19:00 -0800
Re: analog failures Reinhardt Behm <rbehm@hushmail.com> - 2017-02-15 11:55 +0800
Re: analog failures Joerg <news@analogconsultants.com> - 2017-02-15 07:53 -0800
Re: analog failures John Larkin <jjlarkin@highlandtechnology.com> - 2017-02-15 08:30 -0800
Re: analog failures Joerg <news@analogconsultants.com> - 2017-02-15 10:19 -0800
Re: analog failures John Larkin <jjlarkinxyxy@highlandtechnology.com> - 2017-02-15 10:53 -0800
Re: analog failures Lasse Langwadt Christensen <langwadt@fonz.dk> - 2017-02-15 10:58 -0800
Re: analog failures "Tim Williams" <tiwill@seventransistorlabs.com> - 2017-02-15 21:25 -0600
Re: analog failures John Larkin <jjlarkin@highlandtechnology.com> - 2017-02-15 20:18 -0800
Re: analog failures rickman <gnuarm@gmail.com> - 2017-02-17 15:44 -0500
Re: analog failures rickman <gnuarm@gmail.com> - 2017-02-17 15:30 -0500
Re: analog failures Joerg <news@analogconsultants.com> - 2017-02-17 14:05 -0800
Re: analog failures rickman <gnuarm@gmail.com> - 2017-02-17 17:16 -0500
Re: analog failures Joerg <news@analogconsultants.com> - 2017-02-17 14:38 -0800
Re: analog failures rickman <gnuarm@gmail.com> - 2017-02-17 17:58 -0500
Re: analog failures Joerg <news@analogconsultants.com> - 2017-02-17 15:37 -0800
Re: analog failures rickman <gnuarm@gmail.com> - 2017-02-17 18:51 -0500
Re: analog failures krw@notreal.com - 2017-02-17 20:27 -0500
Re: analog failures John Larkin <jjlarkinxyxy@highlandtechnology.com> - 2017-02-17 17:56 -0800
Re: analog failures "Tim Williams" <tiwill@seventransistorlabs.com> - 2017-02-17 21:03 -0600
Re: analog failures krw@notreal.com - 2017-02-17 22:36 -0500
Re: analog failures rickman <gnuarm@gmail.com> - 2017-02-19 00:45 -0500
Re: analog failures Joerg <news@analogconsultants.com> - 2017-02-19 08:32 -0800
Re: analog failures John Larkin <jjlarkinxyxy@highlandtechnology.com> - 2017-02-21 12:31 -0800
Re: analog failures rickman <gnuarm@gmail.com> - 2017-02-23 14:57 -0500
Re: analog failures Joerg <news@analogconsultants.com> - 2017-02-23 12:02 -0800
Re: analog failures John Larkin <jjlarkinxyxy@highlandtechnology.com> - 2017-02-17 17:27 -0800
Re: analog failures rickman <gnuarm@gmail.com> - 2017-02-17 20:39 -0500
Re: analog failures Joerg <news@analogconsultants.com> - 2017-02-18 07:41 -0800
Re: analog failures John Larkin <jjlarkin@highlandtechnology.com> - 2017-02-18 08:04 -0800
Re: analog failures Joerg <news@analogconsultants.com> - 2017-02-18 08:16 -0800
Re: analog failures Reinhardt Behm <rbehm@hushmail.com> - 2017-02-16 06:49 +0800
Re: analog failures Joerg <news@analogconsultants.com> - 2017-02-16 07:14 -0800
Re: analog failures John Larkin <jjlarkin@highlandtechnology.com> - 2017-02-16 07:24 -0800
Re: analog failures Joerg <news@analogconsultants.com> - 2017-02-16 07:41 -0800
Re: analog failures Reinhardt Behm <rbehm@hushmail.com> - 2017-02-17 13:22 +0800
Re: analog failures Joerg <news@analogconsultants.com> - 2017-02-17 06:58 -0800
Re: analog failures John Larkin <jjlarkinxyxy@highlandtechnology.com> - 2017-02-17 12:26 -0800
Re: analog failures Joerg <news@analogconsultants.com> - 2017-02-17 14:03 -0800
Re: analog failures "Tim Williams" <tiwill@seventransistorlabs.com> - 2017-02-17 21:05 -0600
Re: analog failures John Larkin <jjlarkin@highlandtechnology.com> - 2017-02-18 08:07 -0800
Re: analog failures Joerg <news@analogconsultants.com> - 2017-02-18 08:20 -0800
Re: analog failures John Larkin <jjlarkin@highlandtechnology.com> - 2017-02-18 09:20 -0800
Re: analog failures rickman <gnuarm@gmail.com> - 2017-02-19 00:48 -0500
Re: analog failures John Larkin <jjlarkinxyxy@highlandtechnology.com> - 2017-02-21 12:39 -0800
Re: analog failures "Tim Williams" <tiwill@seventransistorlabs.com> - 2017-02-21 22:54 -0600
Re: analog failures krw@notreal.com - 2017-02-17 20:33 -0500
Re: analog failures Joerg <news@analogconsultants.com> - 2017-02-18 07:37 -0800
Re: analog failures dagmargoodboat@yahoo.com - 2017-02-22 15:45 -0800
Re: analog failures Joerg <news@analogconsultants.com> - 2017-02-23 10:43 -0800
Re: analog failures krw@notreal.com - 2017-02-23 20:42 -0500
Re: analog failures "Tim Williams" <tiwill@seventransistorlabs.com> - 2017-02-24 03:31 -0600
Re: analog failures grahamholloway@graham65.plus.com - 2017-02-24 06:39 -0800
Re: analog failures Don Kuenz <g@crcomp.net> - 2017-02-24 14:58 +0000
Re: analog failures Joerg <news@analogconsultants.com> - 2017-02-25 12:48 -0800
Re: analog failures pcdhobbs@gmail.com - 2017-02-26 04:39 -0800
Re: analog failures Joerg <news@analogconsultants.com> - 2017-02-26 07:52 -0800
Re: analog failures dagmargoodboat@yahoo.com - 2017-02-24 09:02 -0800
Re: analog failures Joerg <news@analogconsultants.com> - 2017-02-25 12:44 -0800
Re: analog failures dagmargoodboat@yahoo.com - 2017-02-26 08:29 -0800
Re: analog failures Joerg <news@analogconsultants.com> - 2017-02-26 09:46 -0800
Re: analog failures John Larkin <jjlarkin@highlandtechnology.com> - 2017-02-26 10:11 -0800
Re: analog failures krw@notreal.com - 2017-02-26 17:55 -0500
Re: analog failures John Larkin <jjlarkin@highlandtechnology.com> - 2017-02-26 15:09 -0800
Re: analog failures krw@notreal.com - 2017-02-26 19:30 -0500
Re: analog failures John Larkin <jjlarkinxyxy@highlandtechnology.com> - 2017-02-27 10:37 -0800
Re: analog failures Lasse Langwadt Christensen <langwadt@fonz.dk> - 2017-02-24 09:14 -0800
Re: analog failures Joerg <news@analogconsultants.com> - 2017-02-25 12:46 -0800
Re: analog failures Klaus Kragelund <klauskvik@hotmail.com> - 2017-02-26 17:44 -0800
Re: analog failures Joerg <news@analogconsultants.com> - 2017-02-27 07:51 -0800
Re: analog failures Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2017-02-23 21:36 +0200
Re: analog failures dagmargoodboat@yahoo.com - 2017-02-24 08:38 -0800
Re: analog failures krw@notreal.com - 2017-02-24 20:20 -0500
Re: analog failures kevin93 <kevin@whitedigs.com> - 2017-02-24 17:36 -0800
Re: analog failures Ralph Barone <ralph@invalid.com> - 2017-02-15 03:25 +0000
Re: analog failures John Larkin <jjlarkin@highlandtechnology.com> - 2017-02-14 19:20 -0800
Re: analog failures Tim Wescott <seemywebsite@myfooter.really> - 2017-02-14 17:46 -0600
Re: analog failures Jim Thompson <To-Email-Use-The-Envelope-Icon@On-My-Web-Site.com> - 2017-02-14 17:50 -0700
Re: analog failures Tim Wescott <tim@seemywebsite.com> - 2017-02-14 23:49 -0600
Re: analog failures Jim Thompson <To-Email-Use-The-Envelope-Icon@On-My-Web-Site.com> - 2017-02-15 07:03 -0700
Re: analog failures John Larkin <jjlarkinxyxy@highlandtechnology.com> - 2017-02-15 10:18 -0800
Re: analog failures Tim Wescott <seemywebsite@myfooter.really> - 2017-02-15 15:06 -0600
Re: analog failures legg <legg@nospam.magma.ca> - 2017-02-16 23:06 -0500
Re: analog failures Joerg <news@analogconsultants.com> - 2017-02-17 07:00 -0800
Re: analog failures legg <legg@nospam.magma.ca> - 2017-02-17 13:22 -0500
Re: analog failures Joerg <news@analogconsultants.com> - 2017-02-17 11:06 -0800
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
| From | krw@notreal.com |
|---|---|
| Date | 2017-02-17 20:27 -0500 |
| Message-ID | <fi8faclfpk5tpnvt44abh2n351dn99nq44@4ax.com> |
| In reply to | #448082 |
On Fri, 17 Feb 2017 18:51:29 -0500, rickman <gnuarm@gmail.com> wrote: >On 2/17/2017 6:37 PM, Joerg wrote: >> On 2017-02-17 14:58, rickman wrote: >>> On 2/17/2017 5:38 PM, Joerg wrote: >>>> On 2017-02-17 14:16, rickman wrote: >>>>> On 2/17/2017 5:05 PM, Joerg wrote: >>>>>> On 2017-02-17 12:30, rickman wrote: >>>>>>> On 2/15/2017 11:30 AM, John Larkin wrote: >>>>>>>> On Wed, 15 Feb 2017 07:53:18 -0800, Joerg >>>>>>>> <news@analogconsultants.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> On 2017-02-14 19:55, Reinhardt Behm wrote: >>>>>>>>>> AT Wednesday 15 February 2017 11:00, bill.sloman@ieee.org wrote: >>>>>>>>>> >>>>>>>>>>> On Wednesday, February 15, 2017 at 1:52:23 PM UTC+11, Reinhardt >>>>>>>>>>> Behm >>>>>>>>>>> wrote: >>>>>>>>>>>> AT Wednesday 15 February 2017 07:05, Lasse Langwadt Christensen >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Den tirsdag den 14. februar 2017 kl. 23.47.11 UTC+1 skrev John >>>>>>>>>>>>> Larkin: >>>>>>>>>>>>>> http://semiengineering.com/devices-threatened-by-analog-content/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>> >>>>>>>>> IME most analog failures are caused by ESD and that is often >>>>>>>>> squarely in >>>>>>>>> the court of the board level designer. >>>>>>>>> >>>>>>>>> Upsets without subsequent chip damage are also considered a fault >>>>>>>>> where >>>>>>>>> the function is mission-critical. That is very often due to EMI. >>>>>>>>> >>>>>>>>> >>>>>>>>>>>>>> My experience is that we find a lot of bugs and documentation >>>>>>>>>>>>>> problems >>>>>>>>>>>>>> with the digital parts of mixed-signal chips. >>>>>>>>>>>>> >>>>>>>>>>>>> It does seem like when analog designers get to design the >>>>>>>>>>>>> digital >>>>>>>>>>>>> parts >>>>>>>>>>>>> of a chip it often ends up with a hairball of hazards and weird >>>>>>>>>>>>> quirks >>>>>>>>>>>> >>>>>>>>>>>> That was always my experience with part from NatSemi. Pure >>>>>>>>>>>> analog >>>>>>>>>>>> was >>>>>>>>>>>> good, pure digital was good, mixed mostly was a mess. >>>>>>>>>>> >>>>>>>>>>> Mixed signal design is difficult, and doing it on a chip, where >>>>>>>>>>> it is >>>>>>>>>>> harder to keep the noisy digital bits away from the sensitive >>>>>>>>>>> analog bits, >>>>>>>>>>> wouldn't have made it any easier. >>>>>>>>>>> >>>>>>>>>>> Sadly, mixed signal design can do a lot more than pure analog or >>>>>>>>>>> pure >>>>>>>>>>> digital, so if you have got something complicated to do, that >>>>>>>>>>> tends >>>>>>>>>>> to be >>>>>>>>>>> what you end up doing. >>>>>>>>>> >>>>>>>>>> It was never the problem of digital noise coupling into the analog >>>>>>>>>> portions >>>>>>>>>> but the digital totally mixed up, like the LM75 going into a state >>>>>>>>>> where >>>>>>>>>> only a power cycle helps to get it working again. This can be >>>>>>>>>> caused by >>>>>>>>>> noise on the I2C signals. >>>>>>>>> >>>>>>>>> >>>>>>>>> I2C is a bus I try not to use if it can be avoided because of >>>>>>>>> various >>>>>>>>> hang-ups. SPI is much more robust IME and, therefore, that is >>>>>>>>> what I >>>>>>>>> prefer. >>>>>>>> >>>>>>>> I prefer SPI too, and it's faster, but lots of people design >>>>>>>> terrible >>>>>>>> SPI interfaces, bad logic design and bad clock/data circuits. Every >>>>>>>> SPI should have schmitt inputs and safe timing margins. Maybe >>>>>>>> cooking >>>>>>>> a digital design into an analog process causes compromises, but I >>>>>>>> suspect it's just sloppy engineering. >>>>>>> >>>>>>> Not trying to be snarky, but most digital engineers work to eliminate >>>>>>> noise and to have proper clocks without noise on the transition edge. >>>>>>> Schmitt is only needed on the clock inputs, but even there proper >>>>>>> design >>>>>>> at the board level eliminates the need. >>>>>>> >>>>>> >>>>>> Schmitt is needed everywhere a signal connect to the outside world. A >>>>>> lot of uC design engineers do not understand this. >>>>> >>>>> Define "outside world". Do you mean off board? >>>>> >>>> >>>> Yes, or via a noisy area on the board. Also if slow on-board sensors are >>>> involved. >>> >>> That's why I said... >>> >>> "most digital engineers work to eliminate >>> noise and to have proper clocks without noise on the transition edge. " >>> >> >> .... and then overlook that there can be external influences into boards >> and system. Such as EMI, magnetic fields or even weird stuff like that >> inexplicable double-pulse whenever somebody uses the freight elevator. >> But who am I to complain, this stuff brought me plenty of assignments. > >I'm not overlooking anything. All that is part of the engineer's job. >A Schmitt trigger would be a panacea for none of the above. A Schmitt >trigger is useful when appropriate, but the original post was about >"every SPI" having Schmitt inputs. First, its only useful on edges and >so only the clock. Secondly it is not something you can't add >externally. I don't know why a chip designer wouldn't include a Schmitt >trigger on clock inputs, but I'm not going to second guess them on >something as unimportant as this. I'd much prefer they got the circuit >design right. I can't imagine why a Schmitt trigger should be on every clock, SPI in particular. The designer should be able to design the board so there isn't crap on the clock edges. I don't see the big deal with SPI. I've had a lot more trouble with I2C than I have with SPI but I've abused it more, too.
[toc] | [prev] | [next] | [standalone]
| From | John Larkin <jjlarkinxyxy@highlandtechnology.com> |
|---|---|
| Date | 2017-02-17 17:56 -0800 |
| Message-ID | <tj9fac5pkfmi8cr3tousj1rdmo1er6dtd5@4ax.com> |
| In reply to | #448094 |
On Fri, 17 Feb 2017 20:27:45 -0500, krw@notreal.com wrote: >On Fri, 17 Feb 2017 18:51:29 -0500, rickman <gnuarm@gmail.com> wrote: > >>On 2/17/2017 6:37 PM, Joerg wrote: >>> On 2017-02-17 14:58, rickman wrote: >>>> On 2/17/2017 5:38 PM, Joerg wrote: >>>>> On 2017-02-17 14:16, rickman wrote: >>>>>> On 2/17/2017 5:05 PM, Joerg wrote: >>>>>>> On 2017-02-17 12:30, rickman wrote: >>>>>>>> On 2/15/2017 11:30 AM, John Larkin wrote: >>>>>>>>> On Wed, 15 Feb 2017 07:53:18 -0800, Joerg >>>>>>>>> <news@analogconsultants.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> On 2017-02-14 19:55, Reinhardt Behm wrote: >>>>>>>>>>> AT Wednesday 15 February 2017 11:00, bill.sloman@ieee.org wrote: >>>>>>>>>>> >>>>>>>>>>>> On Wednesday, February 15, 2017 at 1:52:23 PM UTC+11, Reinhardt >>>>>>>>>>>> Behm >>>>>>>>>>>> wrote: >>>>>>>>>>>>> AT Wednesday 15 February 2017 07:05, Lasse Langwadt Christensen >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> Den tirsdag den 14. februar 2017 kl. 23.47.11 UTC+1 skrev John >>>>>>>>>>>>>> Larkin: >>>>>>>>>>>>>>> http://semiengineering.com/devices-threatened-by-analog-content/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> IME most analog failures are caused by ESD and that is often >>>>>>>>>> squarely in >>>>>>>>>> the court of the board level designer. >>>>>>>>>> >>>>>>>>>> Upsets without subsequent chip damage are also considered a fault >>>>>>>>>> where >>>>>>>>>> the function is mission-critical. That is very often due to EMI. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>>>>>> My experience is that we find a lot of bugs and documentation >>>>>>>>>>>>>>> problems >>>>>>>>>>>>>>> with the digital parts of mixed-signal chips. >>>>>>>>>>>>>> >>>>>>>>>>>>>> It does seem like when analog designers get to design the >>>>>>>>>>>>>> digital >>>>>>>>>>>>>> parts >>>>>>>>>>>>>> of a chip it often ends up with a hairball of hazards and weird >>>>>>>>>>>>>> quirks >>>>>>>>>>>>> >>>>>>>>>>>>> That was always my experience with part from NatSemi. Pure >>>>>>>>>>>>> analog >>>>>>>>>>>>> was >>>>>>>>>>>>> good, pure digital was good, mixed mostly was a mess. >>>>>>>>>>>> >>>>>>>>>>>> Mixed signal design is difficult, and doing it on a chip, where >>>>>>>>>>>> it is >>>>>>>>>>>> harder to keep the noisy digital bits away from the sensitive >>>>>>>>>>>> analog bits, >>>>>>>>>>>> wouldn't have made it any easier. >>>>>>>>>>>> >>>>>>>>>>>> Sadly, mixed signal design can do a lot more than pure analog or >>>>>>>>>>>> pure >>>>>>>>>>>> digital, so if you have got something complicated to do, that >>>>>>>>>>>> tends >>>>>>>>>>>> to be >>>>>>>>>>>> what you end up doing. >>>>>>>>>>> >>>>>>>>>>> It was never the problem of digital noise coupling into the analog >>>>>>>>>>> portions >>>>>>>>>>> but the digital totally mixed up, like the LM75 going into a state >>>>>>>>>>> where >>>>>>>>>>> only a power cycle helps to get it working again. This can be >>>>>>>>>>> caused by >>>>>>>>>>> noise on the I2C signals. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I2C is a bus I try not to use if it can be avoided because of >>>>>>>>>> various >>>>>>>>>> hang-ups. SPI is much more robust IME and, therefore, that is >>>>>>>>>> what I >>>>>>>>>> prefer. >>>>>>>>> >>>>>>>>> I prefer SPI too, and it's faster, but lots of people design >>>>>>>>> terrible >>>>>>>>> SPI interfaces, bad logic design and bad clock/data circuits. Every >>>>>>>>> SPI should have schmitt inputs and safe timing margins. Maybe >>>>>>>>> cooking >>>>>>>>> a digital design into an analog process causes compromises, but I >>>>>>>>> suspect it's just sloppy engineering. >>>>>>>> >>>>>>>> Not trying to be snarky, but most digital engineers work to eliminate >>>>>>>> noise and to have proper clocks without noise on the transition edge. >>>>>>>> Schmitt is only needed on the clock inputs, but even there proper >>>>>>>> design >>>>>>>> at the board level eliminates the need. >>>>>>>> >>>>>>> >>>>>>> Schmitt is needed everywhere a signal connect to the outside world. A >>>>>>> lot of uC design engineers do not understand this. >>>>>> >>>>>> Define "outside world". Do you mean off board? >>>>>> >>>>> >>>>> Yes, or via a noisy area on the board. Also if slow on-board sensors are >>>>> involved. >>>> >>>> That's why I said... >>>> >>>> "most digital engineers work to eliminate >>>> noise and to have proper clocks without noise on the transition edge. " >>>> >>> >>> .... and then overlook that there can be external influences into boards >>> and system. Such as EMI, magnetic fields or even weird stuff like that >>> inexplicable double-pulse whenever somebody uses the freight elevator. >>> But who am I to complain, this stuff brought me plenty of assignments. >> >>I'm not overlooking anything. All that is part of the engineer's job. >>A Schmitt trigger would be a panacea for none of the above. A Schmitt >>trigger is useful when appropriate, but the original post was about >>"every SPI" having Schmitt inputs. First, its only useful on edges and >>so only the clock. Secondly it is not something you can't add >>externally. I don't know why a chip designer wouldn't include a Schmitt >>trigger on clock inputs, but I'm not going to second guess them on >>something as unimportant as this. I'd much prefer they got the circuit >>design right. > >I can't imagine why a Schmitt trigger should be on every clock, SPI in >particular. The designer should be able to design the board so there >isn't crap on the clock edges. I don't see the big deal with SPI. >I've had a lot more trouble with I2C than I have with SPI but I've >abused it more, too. If you come out of a wimpy ARM pin, and run the SPI clock all over a multilayer board, to multiple targets, the edges will get slow. Slow edges splayed all around a board are very noise sensitive. Schmitts fix that, and let you run the SPI clock at a frequency that's compatible with all that capacitive loading, traces and chips combined. Noise on \CS is well avoided, too. -- John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.com
[toc] | [prev] | [next] | [standalone]
| From | "Tim Williams" <tiwill@seventransistorlabs.com> |
|---|---|
| Date | 2017-02-17 21:03 -0600 |
| Message-ID | <o88ddp$u1o$1@dont-email.me> |
| In reply to | #448104 |
"John Larkin" <jjlarkinxyxy@highlandtechnology.com> wrote in message news:tj9fac5pkfmi8cr3tousj1rdmo1er6dtd5@4ax.com... >>I can't imagine why a Schmitt trigger should be on every clock, SPI in >>particular. The designer should be able to design the board so there >>isn't crap on the clock edges. I don't see the big deal with SPI. >>I've had a lot more trouble with I2C than I have with SPI but I've >>abused it more, too. > > If you come out of a wimpy ARM pin, and run the SPI clock all over a > multilayer board, to multiple targets, the edges will get slow. Slow > edges splayed all around a board are very noise sensitive. Schmitts > fix that, and let you run the SPI clock at a frequency that's > compatible with all that capacitive loading, traces and chips > combined. > > Noise on \CS is well avoided, too. > SPI is nice because you can stuff it into and out of RS-422 transceivers, effortlessly. That can take care of a lot of ills. But still, woe be unto he who skips EMI filtering and ESD protection on signal/data pins that leave the board (and sometimes, even those within). :-) I hate I2C because its impedance is non-constant and flow is bidirectional. You can buy extender and interface chips, but you can't simply add a logic gate or something. It's a huge ecosystem of special-purpose parts, most of them NXP (of course!). I'd been told to take I2C off the board, on a few occasions. Always with much protest, from me, of course. I try to filter/protect it as well as I can, but it's always the first to fail when the EM starts flyin'. (But the worst I've been forced to implement was USB through unshielded cables. Yeah. That didn't last long. After testing, all cables and connectors became shielded, at great expense to the customer's unit cost.) Tim -- Seven Transistor Labs, LLC Electrical Engineering Consultation and Contract Design Website: http://seventransistorlabs.com
[toc] | [prev] | [next] | [standalone]
| From | krw@notreal.com |
|---|---|
| Date | 2017-02-17 22:36 -0500 |
| Message-ID | <24gfacpdcijkbhkq8vgtc2bihpvosc6uei@4ax.com> |
| In reply to | #448110 |
On Fri, 17 Feb 2017 21:03:07 -0600, "Tim Williams" <tiwill@seventransistorlabs.com> wrote: > >"John Larkin" <jjlarkinxyxy@highlandtechnology.com> wrote in message >news:tj9fac5pkfmi8cr3tousj1rdmo1er6dtd5@4ax.com... >>>I can't imagine why a Schmitt trigger should be on every clock, SPI in >>>particular. The designer should be able to design the board so there >>>isn't crap on the clock edges. I don't see the big deal with SPI. >>>I've had a lot more trouble with I2C than I have with SPI but I've >>>abused it more, too. >> >> If you come out of a wimpy ARM pin, and run the SPI clock all over a >> multilayer board, to multiple targets, the edges will get slow. Slow >> edges splayed all around a board are very noise sensitive. Schmitts >> fix that, and let you run the SPI clock at a frequency that's >> compatible with all that capacitive loading, traces and chips >> combined. >> >> Noise on \CS is well avoided, too. >> > >SPI is nice because you can stuff it into and out of RS-422 transceivers, >effortlessly. > >That can take care of a lot of ills. > >But still, woe be unto he who skips EMI filtering and ESD protection on >signal/data pins that leave the board (and sometimes, even those within). >:-) > >I hate I2C because its impedance is non-constant and flow is bidirectional. >You can buy extender and interface chips, but you can't simply add a logic >gate or something. It's a huge ecosystem of special-purpose parts, most of >them NXP (of course!). LT, too.\ >I'd been told to take I2C off the board, on a few occasions. Always with >much protest, from me, of course. I try to filter/protect it as well as I >can, but it's always the first to fail when the EM starts flyin'. The one time I was forced into it (the board and system were already designed - I just had to ae it work), I used an LT I2C accelerator. Worked like a champ. > >(But the worst I've been forced to implement was USB through unshielded >cables. Yeah. That didn't last long. After testing, all cables and >connectors became shielded, at great expense to the customer's unit cost.) Let the customer supply the cables. ;-)
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-02-19 00:45 -0500 |
| Message-ID | <o8bb9t$nu2$1@dont-email.me> |
| In reply to | #448104 |
On 2/17/2017 8:56 PM, John Larkin wrote: > On Fri, 17 Feb 2017 20:27:45 -0500, krw@notreal.com wrote: > >> On Fri, 17 Feb 2017 18:51:29 -0500, rickman <gnuarm@gmail.com> wrote: >> >>> On 2/17/2017 6:37 PM, Joerg wrote: >>>> On 2017-02-17 14:58, rickman wrote: >>>>> On 2/17/2017 5:38 PM, Joerg wrote: >>>>>> On 2017-02-17 14:16, rickman wrote: >>>>>>> On 2/17/2017 5:05 PM, Joerg wrote: >>>>>>>> On 2017-02-17 12:30, rickman wrote: >>>>>>>>> On 2/15/2017 11:30 AM, John Larkin wrote: >>>>>>>>>> On Wed, 15 Feb 2017 07:53:18 -0800, Joerg >>>>>>>>>> <news@analogconsultants.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> On 2017-02-14 19:55, Reinhardt Behm wrote: >>>>>>>>>>>> AT Wednesday 15 February 2017 11:00, bill.sloman@ieee.org wrote: >>>>>>>>>>>> >>>>>>>>>>>>> On Wednesday, February 15, 2017 at 1:52:23 PM UTC+11, Reinhardt >>>>>>>>>>>>> Behm >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> AT Wednesday 15 February 2017 07:05, Lasse Langwadt Christensen >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Den tirsdag den 14. februar 2017 kl. 23.47.11 UTC+1 skrev John >>>>>>>>>>>>>>> Larkin: >>>>>>>>>>>>>>>> http://semiengineering.com/devices-threatened-by-analog-content/ >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> IME most analog failures are caused by ESD and that is often >>>>>>>>>>> squarely in >>>>>>>>>>> the court of the board level designer. >>>>>>>>>>> >>>>>>>>>>> Upsets without subsequent chip damage are also considered a fault >>>>>>>>>>> where >>>>>>>>>>> the function is mission-critical. That is very often due to EMI. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>>>>>> My experience is that we find a lot of bugs and documentation >>>>>>>>>>>>>>>> problems >>>>>>>>>>>>>>>> with the digital parts of mixed-signal chips. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> It does seem like when analog designers get to design the >>>>>>>>>>>>>>> digital >>>>>>>>>>>>>>> parts >>>>>>>>>>>>>>> of a chip it often ends up with a hairball of hazards and weird >>>>>>>>>>>>>>> quirks >>>>>>>>>>>>>> >>>>>>>>>>>>>> That was always my experience with part from NatSemi. Pure >>>>>>>>>>>>>> analog >>>>>>>>>>>>>> was >>>>>>>>>>>>>> good, pure digital was good, mixed mostly was a mess. >>>>>>>>>>>>> >>>>>>>>>>>>> Mixed signal design is difficult, and doing it on a chip, where >>>>>>>>>>>>> it is >>>>>>>>>>>>> harder to keep the noisy digital bits away from the sensitive >>>>>>>>>>>>> analog bits, >>>>>>>>>>>>> wouldn't have made it any easier. >>>>>>>>>>>>> >>>>>>>>>>>>> Sadly, mixed signal design can do a lot more than pure analog or >>>>>>>>>>>>> pure >>>>>>>>>>>>> digital, so if you have got something complicated to do, that >>>>>>>>>>>>> tends >>>>>>>>>>>>> to be >>>>>>>>>>>>> what you end up doing. >>>>>>>>>>>> >>>>>>>>>>>> It was never the problem of digital noise coupling into the analog >>>>>>>>>>>> portions >>>>>>>>>>>> but the digital totally mixed up, like the LM75 going into a state >>>>>>>>>>>> where >>>>>>>>>>>> only a power cycle helps to get it working again. This can be >>>>>>>>>>>> caused by >>>>>>>>>>>> noise on the I2C signals. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I2C is a bus I try not to use if it can be avoided because of >>>>>>>>>>> various >>>>>>>>>>> hang-ups. SPI is much more robust IME and, therefore, that is >>>>>>>>>>> what I >>>>>>>>>>> prefer. >>>>>>>>>> >>>>>>>>>> I prefer SPI too, and it's faster, but lots of people design >>>>>>>>>> terrible >>>>>>>>>> SPI interfaces, bad logic design and bad clock/data circuits. Every >>>>>>>>>> SPI should have schmitt inputs and safe timing margins. Maybe >>>>>>>>>> cooking >>>>>>>>>> a digital design into an analog process causes compromises, but I >>>>>>>>>> suspect it's just sloppy engineering. >>>>>>>>> >>>>>>>>> Not trying to be snarky, but most digital engineers work to eliminate >>>>>>>>> noise and to have proper clocks without noise on the transition edge. >>>>>>>>> Schmitt is only needed on the clock inputs, but even there proper >>>>>>>>> design >>>>>>>>> at the board level eliminates the need. >>>>>>>>> >>>>>>>> >>>>>>>> Schmitt is needed everywhere a signal connect to the outside world. A >>>>>>>> lot of uC design engineers do not understand this. >>>>>>> >>>>>>> Define "outside world". Do you mean off board? >>>>>>> >>>>>> >>>>>> Yes, or via a noisy area on the board. Also if slow on-board sensors are >>>>>> involved. >>>>> >>>>> That's why I said... >>>>> >>>>> "most digital engineers work to eliminate >>>>> noise and to have proper clocks without noise on the transition edge. " >>>>> >>>> >>>> .... and then overlook that there can be external influences into boards >>>> and system. Such as EMI, magnetic fields or even weird stuff like that >>>> inexplicable double-pulse whenever somebody uses the freight elevator. >>>> But who am I to complain, this stuff brought me plenty of assignments. >>> >>> I'm not overlooking anything. All that is part of the engineer's job. >>> A Schmitt trigger would be a panacea for none of the above. A Schmitt >>> trigger is useful when appropriate, but the original post was about >>> "every SPI" having Schmitt inputs. First, its only useful on edges and >>> so only the clock. Secondly it is not something you can't add >>> externally. I don't know why a chip designer wouldn't include a Schmitt >>> trigger on clock inputs, but I'm not going to second guess them on >>> something as unimportant as this. I'd much prefer they got the circuit >>> design right. >> >> I can't imagine why a Schmitt trigger should be on every clock, SPI in >> particular. The designer should be able to design the board so there >> isn't crap on the clock edges. I don't see the big deal with SPI. >> I've had a lot more trouble with I2C than I have with SPI but I've >> abused it more, too. > > If you come out of a wimpy ARM pin, and run the SPI clock all over a > multilayer board, to multiple targets, the edges will get slow. Slow > edges splayed all around a board are very noise sensitive. Schmitts > fix that, and let you run the SPI clock at a frequency that's > compatible with all that capacitive loading, traces and chips > combined. Schmitt trigger inputs don't "fix" noise. They may mask the problem if it is not so severe. I don't recall ever seeing an edge so degraded by loading that it started having noise problems. Your problem isn't the lack of Schmitt trigger inputs, your problem is excessive loading on a clock line. Add some clock buffers. > Noise on \CS is well avoided, too. Only if CS is an edge triggered signal. Fix your noise problem and you don't need to worry about the lack of built in Schmitt trigger inputs. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Joerg <news@analogconsultants.com> |
|---|---|
| Date | 2017-02-19 08:32 -0800 |
| Message-ID | <egtvlfFba1lU1@mid.individual.net> |
| In reply to | #448309 |
On 2017-02-18 21:45, rickman wrote: > On 2/17/2017 8:56 PM, John Larkin wrote: >> On Fri, 17 Feb 2017 20:27:45 -0500, krw@notreal.com wrote: >> >>> On Fri, 17 Feb 2017 18:51:29 -0500, rickman <gnuarm@gmail.com> wrote: >>> >>>> On 2/17/2017 6:37 PM, Joerg wrote: >>>>> On 2017-02-17 14:58, rickman wrote: >>>>>> On 2/17/2017 5:38 PM, Joerg wrote: >>>>>>> On 2017-02-17 14:16, rickman wrote: >>>>>>>> On 2/17/2017 5:05 PM, Joerg wrote: >>>>>>>>> On 2017-02-17 12:30, rickman wrote: >>>>>>>>>> On 2/15/2017 11:30 AM, John Larkin wrote: >>>>>>>>>>> On Wed, 15 Feb 2017 07:53:18 -0800, Joerg >>>>>>>>>>> <news@analogconsultants.com> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> On 2017-02-14 19:55, Reinhardt Behm wrote: >>>>>>>>>>>>> AT Wednesday 15 February 2017 11:00, bill.sloman@ieee.org >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>>> On Wednesday, February 15, 2017 at 1:52:23 PM UTC+11, >>>>>>>>>>>>>> Reinhardt >>>>>>>>>>>>>> Behm >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> AT Wednesday 15 February 2017 07:05, Lasse Langwadt >>>>>>>>>>>>>>> Christensen >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Den tirsdag den 14. februar 2017 kl. 23.47.11 UTC+1 >>>>>>>>>>>>>>>> skrev John >>>>>>>>>>>>>>>> Larkin: >>>>>>>>>>>>>>>>> http://semiengineering.com/devices-threatened-by-analog-content/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> IME most analog failures are caused by ESD and that is often >>>>>>>>>>>> squarely in >>>>>>>>>>>> the court of the board level designer. >>>>>>>>>>>> >>>>>>>>>>>> Upsets without subsequent chip damage are also considered a >>>>>>>>>>>> fault >>>>>>>>>>>> where >>>>>>>>>>>> the function is mission-critical. That is very often due to >>>>>>>>>>>> EMI. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>>>>>> My experience is that we find a lot of bugs and >>>>>>>>>>>>>>>>> documentation >>>>>>>>>>>>>>>>> problems >>>>>>>>>>>>>>>>> with the digital parts of mixed-signal chips. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> It does seem like when analog designers get to design the >>>>>>>>>>>>>>>> digital >>>>>>>>>>>>>>>> parts >>>>>>>>>>>>>>>> of a chip it often ends up with a hairball of hazards >>>>>>>>>>>>>>>> and weird >>>>>>>>>>>>>>>> quirks >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> That was always my experience with part from NatSemi. Pure >>>>>>>>>>>>>>> analog >>>>>>>>>>>>>>> was >>>>>>>>>>>>>>> good, pure digital was good, mixed mostly was a mess. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Mixed signal design is difficult, and doing it on a chip, >>>>>>>>>>>>>> where >>>>>>>>>>>>>> it is >>>>>>>>>>>>>> harder to keep the noisy digital bits away from the sensitive >>>>>>>>>>>>>> analog bits, >>>>>>>>>>>>>> wouldn't have made it any easier. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Sadly, mixed signal design can do a lot more than pure >>>>>>>>>>>>>> analog or >>>>>>>>>>>>>> pure >>>>>>>>>>>>>> digital, so if you have got something complicated to do, that >>>>>>>>>>>>>> tends >>>>>>>>>>>>>> to be >>>>>>>>>>>>>> what you end up doing. >>>>>>>>>>>>> >>>>>>>>>>>>> It was never the problem of digital noise coupling into the >>>>>>>>>>>>> analog >>>>>>>>>>>>> portions >>>>>>>>>>>>> but the digital totally mixed up, like the LM75 going into >>>>>>>>>>>>> a state >>>>>>>>>>>>> where >>>>>>>>>>>>> only a power cycle helps to get it working again. This can be >>>>>>>>>>>>> caused by >>>>>>>>>>>>> noise on the I2C signals. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I2C is a bus I try not to use if it can be avoided because of >>>>>>>>>>>> various >>>>>>>>>>>> hang-ups. SPI is much more robust IME and, therefore, that is >>>>>>>>>>>> what I >>>>>>>>>>>> prefer. >>>>>>>>>>> >>>>>>>>>>> I prefer SPI too, and it's faster, but lots of people design >>>>>>>>>>> terrible >>>>>>>>>>> SPI interfaces, bad logic design and bad clock/data circuits. >>>>>>>>>>> Every >>>>>>>>>>> SPI should have schmitt inputs and safe timing margins. Maybe >>>>>>>>>>> cooking >>>>>>>>>>> a digital design into an analog process causes compromises, >>>>>>>>>>> but I >>>>>>>>>>> suspect it's just sloppy engineering. >>>>>>>>>> >>>>>>>>>> Not trying to be snarky, but most digital engineers work to >>>>>>>>>> eliminate >>>>>>>>>> noise and to have proper clocks without noise on the >>>>>>>>>> transition edge. >>>>>>>>>> Schmitt is only needed on the clock inputs, but even there proper >>>>>>>>>> design >>>>>>>>>> at the board level eliminates the need. >>>>>>>>>> >>>>>>>>> >>>>>>>>> Schmitt is needed everywhere a signal connect to the outside >>>>>>>>> world. A >>>>>>>>> lot of uC design engineers do not understand this. >>>>>>>> >>>>>>>> Define "outside world". Do you mean off board? >>>>>>>> >>>>>>> >>>>>>> Yes, or via a noisy area on the board. Also if slow on-board >>>>>>> sensors are >>>>>>> involved. >>>>>> >>>>>> That's why I said... >>>>>> >>>>>> "most digital engineers work to eliminate >>>>>> noise and to have proper clocks without noise on the transition >>>>>> edge. " >>>>>> >>>>> >>>>> .... and then overlook that there can be external influences into >>>>> boards >>>>> and system. Such as EMI, magnetic fields or even weird stuff like that >>>>> inexplicable double-pulse whenever somebody uses the freight elevator. >>>>> But who am I to complain, this stuff brought me plenty of assignments. >>>> >>>> I'm not overlooking anything. All that is part of the engineer's job. >>>> A Schmitt trigger would be a panacea for none of the above. A Schmitt >>>> trigger is useful when appropriate, but the original post was about >>>> "every SPI" having Schmitt inputs. First, its only useful on edges and >>>> so only the clock. Secondly it is not something you can't add >>>> externally. I don't know why a chip designer wouldn't include a >>>> Schmitt >>>> trigger on clock inputs, but I'm not going to second guess them on >>>> something as unimportant as this. I'd much prefer they got the circuit >>>> design right. >>> >>> I can't imagine why a Schmitt trigger should be on every clock, SPI in >>> particular. The designer should be able to design the board so there >>> isn't crap on the clock edges. I don't see the big deal with SPI. >>> I've had a lot more trouble with I2C than I have with SPI but I've >>> abused it more, too. >> >> If you come out of a wimpy ARM pin, and run the SPI clock all over a >> multilayer board, to multiple targets, the edges will get slow. Slow >> edges splayed all around a board are very noise sensitive. Schmitts >> fix that, and let you run the SPI clock at a frequency that's >> compatible with all that capacitive loading, traces and chips >> combined. > > Schmitt trigger inputs don't "fix" noise. Sure they do. > ... They may mask the problem if > it is not so severe. I don't recall ever seeing an edge so degraded by > loading that it started having noise problems. Your problem isn't the > lack of Schmitt trigger inputs, your problem is excessive loading on a > clock line. Add some clock buffers. > >> Noise on \CS is well avoided, too. > > Only if CS is an edge triggered signal. Fix your noise problem and you > don't need to worry about the lack of built in Schmitt trigger inputs. > It's often got nothing to do with how it is triggered. I had cases where fast logic input stages did a little tarantella dance every time a signal change logic level. Just for a few hundred nsec. That did not upset the functionality of the system but was enough to fail EMC. The initial reaction of the guys was like yours in this thread: "You've got to be kidding!". Except I wasn't kidding. This is one of the reasons why I never travel to an EMC problem case without the near-field probe kit. With that you can narrow it down to the offending chip, sometimes even to the trace. -- Regards, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
| From | John Larkin <jjlarkinxyxy@highlandtechnology.com> |
|---|---|
| Date | 2017-02-21 12:31 -0800 |
| Message-ID | <kr8pacd3bmm81qcu3qomj292gq5f4eucv3@4ax.com> |
| In reply to | #448365 |
On Sun, 19 Feb 2017 08:32:45 -0800, Joerg <news@analogconsultants.com> wrote: >On 2017-02-18 21:45, rickman wrote: >> On 2/17/2017 8:56 PM, John Larkin wrote: >>> On Fri, 17 Feb 2017 20:27:45 -0500, krw@notreal.com wrote: >>> >>>> On Fri, 17 Feb 2017 18:51:29 -0500, rickman <gnuarm@gmail.com> wrote: >>>> >>>>> On 2/17/2017 6:37 PM, Joerg wrote: >>>>>> On 2017-02-17 14:58, rickman wrote: >>>>>>> On 2/17/2017 5:38 PM, Joerg wrote: >>>>>>>> On 2017-02-17 14:16, rickman wrote: >>>>>>>>> On 2/17/2017 5:05 PM, Joerg wrote: >>>>>>>>>> On 2017-02-17 12:30, rickman wrote: >>>>>>>>>>> On 2/15/2017 11:30 AM, John Larkin wrote: >>>>>>>>>>>> On Wed, 15 Feb 2017 07:53:18 -0800, Joerg >>>>>>>>>>>> <news@analogconsultants.com> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> On 2017-02-14 19:55, Reinhardt Behm wrote: >>>>>>>>>>>>>> AT Wednesday 15 February 2017 11:00, bill.sloman@ieee.org >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Wednesday, February 15, 2017 at 1:52:23 PM UTC+11, >>>>>>>>>>>>>>> Reinhardt >>>>>>>>>>>>>>> Behm >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> AT Wednesday 15 February 2017 07:05, Lasse Langwadt >>>>>>>>>>>>>>>> Christensen >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Den tirsdag den 14. februar 2017 kl. 23.47.11 UTC+1 >>>>>>>>>>>>>>>>> skrev John >>>>>>>>>>>>>>>>> Larkin: >>>>>>>>>>>>>>>>>> http://semiengineering.com/devices-threatened-by-analog-content/ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> IME most analog failures are caused by ESD and that is often >>>>>>>>>>>>> squarely in >>>>>>>>>>>>> the court of the board level designer. >>>>>>>>>>>>> >>>>>>>>>>>>> Upsets without subsequent chip damage are also considered a >>>>>>>>>>>>> fault >>>>>>>>>>>>> where >>>>>>>>>>>>> the function is mission-critical. That is very often due to >>>>>>>>>>>>> EMI. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> My experience is that we find a lot of bugs and >>>>>>>>>>>>>>>>>> documentation >>>>>>>>>>>>>>>>>> problems >>>>>>>>>>>>>>>>>> with the digital parts of mixed-signal chips. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> It does seem like when analog designers get to design the >>>>>>>>>>>>>>>>> digital >>>>>>>>>>>>>>>>> parts >>>>>>>>>>>>>>>>> of a chip it often ends up with a hairball of hazards >>>>>>>>>>>>>>>>> and weird >>>>>>>>>>>>>>>>> quirks >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> That was always my experience with part from NatSemi. Pure >>>>>>>>>>>>>>>> analog >>>>>>>>>>>>>>>> was >>>>>>>>>>>>>>>> good, pure digital was good, mixed mostly was a mess. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Mixed signal design is difficult, and doing it on a chip, >>>>>>>>>>>>>>> where >>>>>>>>>>>>>>> it is >>>>>>>>>>>>>>> harder to keep the noisy digital bits away from the sensitive >>>>>>>>>>>>>>> analog bits, >>>>>>>>>>>>>>> wouldn't have made it any easier. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Sadly, mixed signal design can do a lot more than pure >>>>>>>>>>>>>>> analog or >>>>>>>>>>>>>>> pure >>>>>>>>>>>>>>> digital, so if you have got something complicated to do, that >>>>>>>>>>>>>>> tends >>>>>>>>>>>>>>> to be >>>>>>>>>>>>>>> what you end up doing. >>>>>>>>>>>>>> >>>>>>>>>>>>>> It was never the problem of digital noise coupling into the >>>>>>>>>>>>>> analog >>>>>>>>>>>>>> portions >>>>>>>>>>>>>> but the digital totally mixed up, like the LM75 going into >>>>>>>>>>>>>> a state >>>>>>>>>>>>>> where >>>>>>>>>>>>>> only a power cycle helps to get it working again. This can be >>>>>>>>>>>>>> caused by >>>>>>>>>>>>>> noise on the I2C signals. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I2C is a bus I try not to use if it can be avoided because of >>>>>>>>>>>>> various >>>>>>>>>>>>> hang-ups. SPI is much more robust IME and, therefore, that is >>>>>>>>>>>>> what I >>>>>>>>>>>>> prefer. >>>>>>>>>>>> >>>>>>>>>>>> I prefer SPI too, and it's faster, but lots of people design >>>>>>>>>>>> terrible >>>>>>>>>>>> SPI interfaces, bad logic design and bad clock/data circuits. >>>>>>>>>>>> Every >>>>>>>>>>>> SPI should have schmitt inputs and safe timing margins. Maybe >>>>>>>>>>>> cooking >>>>>>>>>>>> a digital design into an analog process causes compromises, >>>>>>>>>>>> but I >>>>>>>>>>>> suspect it's just sloppy engineering. >>>>>>>>>>> >>>>>>>>>>> Not trying to be snarky, but most digital engineers work to >>>>>>>>>>> eliminate >>>>>>>>>>> noise and to have proper clocks without noise on the >>>>>>>>>>> transition edge. >>>>>>>>>>> Schmitt is only needed on the clock inputs, but even there proper >>>>>>>>>>> design >>>>>>>>>>> at the board level eliminates the need. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Schmitt is needed everywhere a signal connect to the outside >>>>>>>>>> world. A >>>>>>>>>> lot of uC design engineers do not understand this. >>>>>>>>> >>>>>>>>> Define "outside world". Do you mean off board? >>>>>>>>> >>>>>>>> >>>>>>>> Yes, or via a noisy area on the board. Also if slow on-board >>>>>>>> sensors are >>>>>>>> involved. >>>>>>> >>>>>>> That's why I said... >>>>>>> >>>>>>> "most digital engineers work to eliminate >>>>>>> noise and to have proper clocks without noise on the transition >>>>>>> edge. " >>>>>>> >>>>>> >>>>>> .... and then overlook that there can be external influences into >>>>>> boards >>>>>> and system. Such as EMI, magnetic fields or even weird stuff like that >>>>>> inexplicable double-pulse whenever somebody uses the freight elevator. >>>>>> But who am I to complain, this stuff brought me plenty of assignments. >>>>> >>>>> I'm not overlooking anything. All that is part of the engineer's job. >>>>> A Schmitt trigger would be a panacea for none of the above. A Schmitt >>>>> trigger is useful when appropriate, but the original post was about >>>>> "every SPI" having Schmitt inputs. First, its only useful on edges and >>>>> so only the clock. Secondly it is not something you can't add >>>>> externally. I don't know why a chip designer wouldn't include a >>>>> Schmitt >>>>> trigger on clock inputs, but I'm not going to second guess them on >>>>> something as unimportant as this. I'd much prefer they got the circuit >>>>> design right. >>>> >>>> I can't imagine why a Schmitt trigger should be on every clock, SPI in >>>> particular. The designer should be able to design the board so there >>>> isn't crap on the clock edges. I don't see the big deal with SPI. >>>> I've had a lot more trouble with I2C than I have with SPI but I've >>>> abused it more, too. >>> >>> If you come out of a wimpy ARM pin, and run the SPI clock all over a >>> multilayer board, to multiple targets, the edges will get slow. Slow >>> edges splayed all around a board are very noise sensitive. Schmitts >>> fix that, and let you run the SPI clock at a frequency that's >>> compatible with all that capacitive loading, traces and chips >>> combined. >> >> Schmitt trigger inputs don't "fix" noise. > > >Sure they do. Yup. -- John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.com
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-02-23 14:57 -0500 |
| Message-ID | <o8nene$a7s$1@dont-email.me> |
| In reply to | #448365 |
On 2/19/2017 11:32 AM, Joerg wrote: > On 2017-02-18 21:45, rickman wrote: >> On 2/17/2017 8:56 PM, John Larkin wrote: >>> On Fri, 17 Feb 2017 20:27:45 -0500, krw@notreal.com wrote: >>> >>>> On Fri, 17 Feb 2017 18:51:29 -0500, rickman <gnuarm@gmail.com> wrote: >>>> >>>>> On 2/17/2017 6:37 PM, Joerg wrote: >>>>>> On 2017-02-17 14:58, rickman wrote: >>>>>>> On 2/17/2017 5:38 PM, Joerg wrote: >>>>>>>> On 2017-02-17 14:16, rickman wrote: >>>>>>>>> On 2/17/2017 5:05 PM, Joerg wrote: >>>>>>>>>> On 2017-02-17 12:30, rickman wrote: >>>>>>>>>>> On 2/15/2017 11:30 AM, John Larkin wrote: >>>>>>>>>>>> On Wed, 15 Feb 2017 07:53:18 -0800, Joerg >>>>>>>>>>>> <news@analogconsultants.com> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> On 2017-02-14 19:55, Reinhardt Behm wrote: >>>>>>>>>>>>>> AT Wednesday 15 February 2017 11:00, bill.sloman@ieee.org >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Wednesday, February 15, 2017 at 1:52:23 PM UTC+11, >>>>>>>>>>>>>>> Reinhardt >>>>>>>>>>>>>>> Behm >>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> AT Wednesday 15 February 2017 07:05, Lasse Langwadt >>>>>>>>>>>>>>>> Christensen >>>>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Den tirsdag den 14. februar 2017 kl. 23.47.11 UTC+1 >>>>>>>>>>>>>>>>> skrev John >>>>>>>>>>>>>>>>> Larkin: >>>>>>>>>>>>>>>>>> http://semiengineering.com/devices-threatened-by-analog-content/ >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> IME most analog failures are caused by ESD and that is often >>>>>>>>>>>>> squarely in >>>>>>>>>>>>> the court of the board level designer. >>>>>>>>>>>>> >>>>>>>>>>>>> Upsets without subsequent chip damage are also considered a >>>>>>>>>>>>> fault >>>>>>>>>>>>> where >>>>>>>>>>>>> the function is mission-critical. That is very often due to >>>>>>>>>>>>> EMI. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> My experience is that we find a lot of bugs and >>>>>>>>>>>>>>>>>> documentation >>>>>>>>>>>>>>>>>> problems >>>>>>>>>>>>>>>>>> with the digital parts of mixed-signal chips. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> It does seem like when analog designers get to design the >>>>>>>>>>>>>>>>> digital >>>>>>>>>>>>>>>>> parts >>>>>>>>>>>>>>>>> of a chip it often ends up with a hairball of hazards >>>>>>>>>>>>>>>>> and weird >>>>>>>>>>>>>>>>> quirks >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> That was always my experience with part from NatSemi. Pure >>>>>>>>>>>>>>>> analog >>>>>>>>>>>>>>>> was >>>>>>>>>>>>>>>> good, pure digital was good, mixed mostly was a mess. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Mixed signal design is difficult, and doing it on a chip, >>>>>>>>>>>>>>> where >>>>>>>>>>>>>>> it is >>>>>>>>>>>>>>> harder to keep the noisy digital bits away from the >>>>>>>>>>>>>>> sensitive >>>>>>>>>>>>>>> analog bits, >>>>>>>>>>>>>>> wouldn't have made it any easier. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Sadly, mixed signal design can do a lot more than pure >>>>>>>>>>>>>>> analog or >>>>>>>>>>>>>>> pure >>>>>>>>>>>>>>> digital, so if you have got something complicated to do, >>>>>>>>>>>>>>> that >>>>>>>>>>>>>>> tends >>>>>>>>>>>>>>> to be >>>>>>>>>>>>>>> what you end up doing. >>>>>>>>>>>>>> >>>>>>>>>>>>>> It was never the problem of digital noise coupling into the >>>>>>>>>>>>>> analog >>>>>>>>>>>>>> portions >>>>>>>>>>>>>> but the digital totally mixed up, like the LM75 going into >>>>>>>>>>>>>> a state >>>>>>>>>>>>>> where >>>>>>>>>>>>>> only a power cycle helps to get it working again. This can be >>>>>>>>>>>>>> caused by >>>>>>>>>>>>>> noise on the I2C signals. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> I2C is a bus I try not to use if it can be avoided because of >>>>>>>>>>>>> various >>>>>>>>>>>>> hang-ups. SPI is much more robust IME and, therefore, that is >>>>>>>>>>>>> what I >>>>>>>>>>>>> prefer. >>>>>>>>>>>> >>>>>>>>>>>> I prefer SPI too, and it's faster, but lots of people design >>>>>>>>>>>> terrible >>>>>>>>>>>> SPI interfaces, bad logic design and bad clock/data circuits. >>>>>>>>>>>> Every >>>>>>>>>>>> SPI should have schmitt inputs and safe timing margins. Maybe >>>>>>>>>>>> cooking >>>>>>>>>>>> a digital design into an analog process causes compromises, >>>>>>>>>>>> but I >>>>>>>>>>>> suspect it's just sloppy engineering. >>>>>>>>>>> >>>>>>>>>>> Not trying to be snarky, but most digital engineers work to >>>>>>>>>>> eliminate >>>>>>>>>>> noise and to have proper clocks without noise on the >>>>>>>>>>> transition edge. >>>>>>>>>>> Schmitt is only needed on the clock inputs, but even there >>>>>>>>>>> proper >>>>>>>>>>> design >>>>>>>>>>> at the board level eliminates the need. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Schmitt is needed everywhere a signal connect to the outside >>>>>>>>>> world. A >>>>>>>>>> lot of uC design engineers do not understand this. >>>>>>>>> >>>>>>>>> Define "outside world". Do you mean off board? >>>>>>>>> >>>>>>>> >>>>>>>> Yes, or via a noisy area on the board. Also if slow on-board >>>>>>>> sensors are >>>>>>>> involved. >>>>>>> >>>>>>> That's why I said... >>>>>>> >>>>>>> "most digital engineers work to eliminate >>>>>>> noise and to have proper clocks without noise on the transition >>>>>>> edge. " >>>>>>> >>>>>> >>>>>> .... and then overlook that there can be external influences into >>>>>> boards >>>>>> and system. Such as EMI, magnetic fields or even weird stuff like >>>>>> that >>>>>> inexplicable double-pulse whenever somebody uses the freight >>>>>> elevator. >>>>>> But who am I to complain, this stuff brought me plenty of >>>>>> assignments. >>>>> >>>>> I'm not overlooking anything. All that is part of the engineer's job. >>>>> A Schmitt trigger would be a panacea for none of the above. A Schmitt >>>>> trigger is useful when appropriate, but the original post was about >>>>> "every SPI" having Schmitt inputs. First, its only useful on edges >>>>> and >>>>> so only the clock. Secondly it is not something you can't add >>>>> externally. I don't know why a chip designer wouldn't include a >>>>> Schmitt >>>>> trigger on clock inputs, but I'm not going to second guess them on >>>>> something as unimportant as this. I'd much prefer they got the >>>>> circuit >>>>> design right. >>>> >>>> I can't imagine why a Schmitt trigger should be on every clock, SPI in >>>> particular. The designer should be able to design the board so there >>>> isn't crap on the clock edges. I don't see the big deal with SPI. >>>> I've had a lot more trouble with I2C than I have with SPI but I've >>>> abused it more, too. >>> >>> If you come out of a wimpy ARM pin, and run the SPI clock all over a >>> multilayer board, to multiple targets, the edges will get slow. Slow >>> edges splayed all around a board are very noise sensitive. Schmitts >>> fix that, and let you run the SPI clock at a frequency that's >>> compatible with all that capacitive loading, traces and chips >>> combined. >> >> Schmitt trigger inputs don't "fix" noise. > > > Sure they do. Ok, they do. Are we done? >> ... They may mask the problem if >> it is not so severe. I don't recall ever seeing an edge so degraded by >> loading that it started having noise problems. Your problem isn't the >> lack of Schmitt trigger inputs, your problem is excessive loading on a >> clock line. Add some clock buffers. >> >>> Noise on \CS is well avoided, too. >> >> Only if CS is an edge triggered signal. Fix your noise problem and you >> don't need to worry about the lack of built in Schmitt trigger inputs. >> > > It's often got nothing to do with how it is triggered. I had cases where > fast logic input stages did a little tarantella dance every time a > signal change logic level. Just for a few hundred nsec. That did not > upset the functionality of the system but was enough to fail EMC. The > initial reaction of the guys was like yours in this thread: "You've got > to be kidding!". Except I wasn't kidding. This is one of the reasons why > I never travel to an EMC problem case without the near-field probe kit. > With that you can narrow it down to the offending chip, sometimes even > to the trace. Totally irrelevant to Schmitt triggers not glitching on noisy inputs. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Joerg <news@analogconsultants.com> |
|---|---|
| Date | 2017-02-23 12:02 -0800 |
| Message-ID | <eh8te6Fhni8U1@mid.individual.net> |
| In reply to | #448971 |
On 2017-02-23 11:57, rickman wrote: > On 2/19/2017 11:32 AM, Joerg wrote: >> On 2017-02-18 21:45, rickman wrote: [...] >>> ... They may mask the problem if >>> it is not so severe. I don't recall ever seeing an edge so degraded by >>> loading that it started having noise problems. Your problem isn't the >>> lack of Schmitt trigger inputs, your problem is excessive loading on a >>> clock line. Add some clock buffers. >>> >>>> Noise on \CS is well avoided, too. >>> >>> Only if CS is an edge triggered signal. Fix your noise problem and you >>> don't need to worry about the lack of built in Schmitt trigger inputs. >>> >> >> It's often got nothing to do with how it is triggered. I had cases where >> fast logic input stages did a little tarantella dance every time a >> signal change logic level. Just for a few hundred nsec. That did not >> upset the functionality of the system but was enough to fail EMC. The >> initial reaction of the guys was like yours in this thread: "You've got >> to be kidding!". Except I wasn't kidding. This is one of the reasons why >> I never travel to an EMC problem case without the near-field probe kit. >> With that you can narrow it down to the offending chip, sometimes even >> to the trace. > > Totally irrelevant to Schmitt triggers not glitching on noisy inputs. > That's what those engineers thought as well. Until the black eye at EMC. Hint: Non-Schmitt stages pass a lot of the noise towards their outputs and that can get radiated off. Or mostly conducted, picked up, and then radiated. -- Regards, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
| From | John Larkin <jjlarkinxyxy@highlandtechnology.com> |
|---|---|
| Date | 2017-02-17 17:27 -0800 |
| Message-ID | <rd8facd0n8c66itk6jr8df65s2c71d2stq@4ax.com> |
| In reply to | #448065 |
On Fri, 17 Feb 2017 14:05:20 -0800, Joerg <news@analogconsultants.com> wrote: >On 2017-02-17 12:30, rickman wrote: >> On 2/15/2017 11:30 AM, John Larkin wrote: >>> On Wed, 15 Feb 2017 07:53:18 -0800, Joerg <news@analogconsultants.com> >>> wrote: >>> >>>> On 2017-02-14 19:55, Reinhardt Behm wrote: >>>>> AT Wednesday 15 February 2017 11:00, bill.sloman@ieee.org wrote: >>>>> >>>>>> On Wednesday, February 15, 2017 at 1:52:23 PM UTC+11, Reinhardt Behm >>>>>> wrote: >>>>>>> AT Wednesday 15 February 2017 07:05, Lasse Langwadt Christensen >>>>>>> wrote: >>>>>>> >>>>>>>> Den tirsdag den 14. februar 2017 kl. 23.47.11 UTC+1 skrev John >>>>>>>> Larkin: >>>>>>>>> http://semiengineering.com/devices-threatened-by-analog-content/ >>>>>>>>> >>>> >>>> IME most analog failures are caused by ESD and that is often squarely in >>>> the court of the board level designer. >>>> >>>> Upsets without subsequent chip damage are also considered a fault where >>>> the function is mission-critical. That is very often due to EMI. >>>> >>>> >>>>>>>>> My experience is that we find a lot of bugs and documentation >>>>>>>>> problems >>>>>>>>> with the digital parts of mixed-signal chips. >>>>>>>> >>>>>>>> It does seem like when analog designers get to design the digital >>>>>>>> parts >>>>>>>> of a chip it often ends up with a hairball of hazards and weird >>>>>>>> quirks >>>>>>> >>>>>>> That was always my experience with part from NatSemi. Pure analog was >>>>>>> good, pure digital was good, mixed mostly was a mess. >>>>>> >>>>>> Mixed signal design is difficult, and doing it on a chip, where it is >>>>>> harder to keep the noisy digital bits away from the sensitive >>>>>> analog bits, >>>>>> wouldn't have made it any easier. >>>>>> >>>>>> Sadly, mixed signal design can do a lot more than pure analog or pure >>>>>> digital, so if you have got something complicated to do, that tends >>>>>> to be >>>>>> what you end up doing. >>>>> >>>>> It was never the problem of digital noise coupling into the analog >>>>> portions >>>>> but the digital totally mixed up, like the LM75 going into a state >>>>> where >>>>> only a power cycle helps to get it working again. This can be caused by >>>>> noise on the I2C signals. >>>> >>>> >>>> I2C is a bus I try not to use if it can be avoided because of various >>>> hang-ups. SPI is much more robust IME and, therefore, that is what I >>>> prefer. >>> >>> I prefer SPI too, and it's faster, but lots of people design terrible >>> SPI interfaces, bad logic design and bad clock/data circuits. Every >>> SPI should have schmitt inputs and safe timing margins. Maybe cooking >>> a digital design into an analog process causes compromises, but I >>> suspect it's just sloppy engineering. >> >> Not trying to be snarky, but most digital engineers work to eliminate >> noise and to have proper clocks without noise on the transition edge. >> Schmitt is only needed on the clock inputs, but even there proper design >> at the board level eliminates the need. >> > >Schmitt is needed everywhere a signal connect to the outside world. A >lot of uC design engineers do not understand this. > >[...] Multi-drop SPI can have clock and chip-select traces all over a board. A glitch or bounce on either can be bad news. It's nice if everything works without building matched-impedance terminated-driver tree structures. Geez, it's just SPI. MOSI and MISO don't need schmitts, but why not? -- John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.com
[toc] | [prev] | [next] | [standalone]
| From | rickman <gnuarm@gmail.com> |
|---|---|
| Date | 2017-02-17 20:39 -0500 |
| Message-ID | <o888hv$r2p$1@dont-email.me> |
| In reply to | #448093 |
On 2/17/2017 8:27 PM, John Larkin wrote: > On Fri, 17 Feb 2017 14:05:20 -0800, Joerg <news@analogconsultants.com> > wrote: > >> On 2017-02-17 12:30, rickman wrote: >>> On 2/15/2017 11:30 AM, John Larkin wrote: >>>> On Wed, 15 Feb 2017 07:53:18 -0800, Joerg <news@analogconsultants.com> >>>> wrote: >>>> >>>>> On 2017-02-14 19:55, Reinhardt Behm wrote: >>>>>> AT Wednesday 15 February 2017 11:00, bill.sloman@ieee.org wrote: >>>>>> >>>>>>> On Wednesday, February 15, 2017 at 1:52:23 PM UTC+11, Reinhardt Behm >>>>>>> wrote: >>>>>>>> AT Wednesday 15 February 2017 07:05, Lasse Langwadt Christensen >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Den tirsdag den 14. februar 2017 kl. 23.47.11 UTC+1 skrev John >>>>>>>>> Larkin: >>>>>>>>>> http://semiengineering.com/devices-threatened-by-analog-content/ >>>>>>>>>> >>>>> >>>>> IME most analog failures are caused by ESD and that is often squarely in >>>>> the court of the board level designer. >>>>> >>>>> Upsets without subsequent chip damage are also considered a fault where >>>>> the function is mission-critical. That is very often due to EMI. >>>>> >>>>> >>>>>>>>>> My experience is that we find a lot of bugs and documentation >>>>>>>>>> problems >>>>>>>>>> with the digital parts of mixed-signal chips. >>>>>>>>> >>>>>>>>> It does seem like when analog designers get to design the digital >>>>>>>>> parts >>>>>>>>> of a chip it often ends up with a hairball of hazards and weird >>>>>>>>> quirks >>>>>>>> >>>>>>>> That was always my experience with part from NatSemi. Pure analog was >>>>>>>> good, pure digital was good, mixed mostly was a mess. >>>>>>> >>>>>>> Mixed signal design is difficult, and doing it on a chip, where it is >>>>>>> harder to keep the noisy digital bits away from the sensitive >>>>>>> analog bits, >>>>>>> wouldn't have made it any easier. >>>>>>> >>>>>>> Sadly, mixed signal design can do a lot more than pure analog or pure >>>>>>> digital, so if you have got something complicated to do, that tends >>>>>>> to be >>>>>>> what you end up doing. >>>>>> >>>>>> It was never the problem of digital noise coupling into the analog >>>>>> portions >>>>>> but the digital totally mixed up, like the LM75 going into a state >>>>>> where >>>>>> only a power cycle helps to get it working again. This can be caused by >>>>>> noise on the I2C signals. >>>>> >>>>> >>>>> I2C is a bus I try not to use if it can be avoided because of various >>>>> hang-ups. SPI is much more robust IME and, therefore, that is what I >>>>> prefer. >>>> >>>> I prefer SPI too, and it's faster, but lots of people design terrible >>>> SPI interfaces, bad logic design and bad clock/data circuits. Every >>>> SPI should have schmitt inputs and safe timing margins. Maybe cooking >>>> a digital design into an analog process causes compromises, but I >>>> suspect it's just sloppy engineering. >>> >>> Not trying to be snarky, but most digital engineers work to eliminate >>> noise and to have proper clocks without noise on the transition edge. >>> Schmitt is only needed on the clock inputs, but even there proper design >>> at the board level eliminates the need. >>> >> >> Schmitt is needed everywhere a signal connect to the outside world. A >> lot of uC design engineers do not understand this. >> >> [...] > > Multi-drop SPI can have clock and chip-select traces all over a board. > A glitch or bounce on either can be bad news. It's nice if everything > works without building matched-impedance terminated-driver tree > structures. Geez, it's just SPI. > > MOSI and MISO don't need schmitts, but why not? Uh, because Schimtt triggers only deal with noise at the transition voltage and no one cares about the *exact* state of the MOSI or MISO signal when it is transitioning. If you think you need Schmitt triggers on the non-clock lines you aren't designing correctly and they won't help you anyway. -- Rick C
[toc] | [prev] | [next] | [standalone]
| From | Joerg <news@analogconsultants.com> |
|---|---|
| Date | 2017-02-18 07:41 -0800 |
| Message-ID | <egr88sFp34oU1@mid.individual.net> |
| In reply to | #448093 |
On 2017-02-17 17:27, John Larkin wrote: > On Fri, 17 Feb 2017 14:05:20 -0800, Joerg <news@analogconsultants.com> > wrote: > >> On 2017-02-17 12:30, rickman wrote: >>> On 2/15/2017 11:30 AM, John Larkin wrote: >>>> On Wed, 15 Feb 2017 07:53:18 -0800, Joerg <news@analogconsultants.com> >>>> wrote: >>>> >>>>> On 2017-02-14 19:55, Reinhardt Behm wrote: >>>>>> AT Wednesday 15 February 2017 11:00, bill.sloman@ieee.org wrote: >>>>>> >>>>>>> On Wednesday, February 15, 2017 at 1:52:23 PM UTC+11, Reinhardt Behm >>>>>>> wrote: >>>>>>>> AT Wednesday 15 February 2017 07:05, Lasse Langwadt Christensen >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Den tirsdag den 14. februar 2017 kl. 23.47.11 UTC+1 skrev John >>>>>>>>> Larkin: >>>>>>>>>> http://semiengineering.com/devices-threatened-by-analog-content/ >>>>>>>>>> >>>>> >>>>> IME most analog failures are caused by ESD and that is often squarely in >>>>> the court of the board level designer. >>>>> >>>>> Upsets without subsequent chip damage are also considered a fault where >>>>> the function is mission-critical. That is very often due to EMI. >>>>> >>>>> >>>>>>>>>> My experience is that we find a lot of bugs and documentation >>>>>>>>>> problems >>>>>>>>>> with the digital parts of mixed-signal chips. >>>>>>>>> >>>>>>>>> It does seem like when analog designers get to design the digital >>>>>>>>> parts >>>>>>>>> of a chip it often ends up with a hairball of hazards and weird >>>>>>>>> quirks >>>>>>>> >>>>>>>> That was always my experience with part from NatSemi. Pure analog was >>>>>>>> good, pure digital was good, mixed mostly was a mess. >>>>>>> >>>>>>> Mixed signal design is difficult, and doing it on a chip, where it is >>>>>>> harder to keep the noisy digital bits away from the sensitive >>>>>>> analog bits, >>>>>>> wouldn't have made it any easier. >>>>>>> >>>>>>> Sadly, mixed signal design can do a lot more than pure analog or pure >>>>>>> digital, so if you have got something complicated to do, that tends >>>>>>> to be >>>>>>> what you end up doing. >>>>>> >>>>>> It was never the problem of digital noise coupling into the analog >>>>>> portions >>>>>> but the digital totally mixed up, like the LM75 going into a state >>>>>> where >>>>>> only a power cycle helps to get it working again. This can be caused by >>>>>> noise on the I2C signals. >>>>> >>>>> >>>>> I2C is a bus I try not to use if it can be avoided because of various >>>>> hang-ups. SPI is much more robust IME and, therefore, that is what I >>>>> prefer. >>>> >>>> I prefer SPI too, and it's faster, but lots of people design terrible >>>> SPI interfaces, bad logic design and bad clock/data circuits. Every >>>> SPI should have schmitt inputs and safe timing margins. Maybe cooking >>>> a digital design into an analog process causes compromises, but I >>>> suspect it's just sloppy engineering. >>> >>> Not trying to be snarky, but most digital engineers work to eliminate >>> noise and to have proper clocks without noise on the transition edge. >>> Schmitt is only needed on the clock inputs, but even there proper design >>> at the board level eliminates the need. >>> >> >> Schmitt is needed everywhere a signal connect to the outside world. A >> lot of uC design engineers do not understand this. >> >> [...] > > Multi-drop SPI can have clock and chip-select traces all over a board. > A glitch or bounce on either can be bad news. It's nice if everything > works without building matched-impedance terminated-driver tree > structures. Geez, it's just SPI. > > MOSI and MISO don't need schmitts, but why not? > Many reasons. In micro-power systems it's a given because any fraction of a microsecond spent in transition or multiple transitions will result in increased power consumption. The other effect is that multiple triggering of the input threshold on a line that digital guys consider "unimportant" can blow EMC. Sometimes it's fun to design micro-power. Now how can we shave off two more microamps? -- Regards, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
| From | John Larkin <jjlarkin@highlandtechnology.com> |
|---|---|
| Date | 2017-02-18 08:04 -0800 |
| Message-ID | <r0sgac5v4gr462merq3tkcvivb37ncp5ou@4ax.com> |
| In reply to | #448169 |
On Sat, 18 Feb 2017 07:41:30 -0800, Joerg <news@analogconsultants.com> wrote: >On 2017-02-17 17:27, John Larkin wrote: >> On Fri, 17 Feb 2017 14:05:20 -0800, Joerg <news@analogconsultants.com> >> wrote: >> >>> On 2017-02-17 12:30, rickman wrote: >>>> On 2/15/2017 11:30 AM, John Larkin wrote: >>>>> On Wed, 15 Feb 2017 07:53:18 -0800, Joerg <news@analogconsultants.com> >>>>> wrote: >>>>> >>>>>> On 2017-02-14 19:55, Reinhardt Behm wrote: >>>>>>> AT Wednesday 15 February 2017 11:00, bill.sloman@ieee.org wrote: >>>>>>> >>>>>>>> On Wednesday, February 15, 2017 at 1:52:23 PM UTC+11, Reinhardt Behm >>>>>>>> wrote: >>>>>>>>> AT Wednesday 15 February 2017 07:05, Lasse Langwadt Christensen >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Den tirsdag den 14. februar 2017 kl. 23.47.11 UTC+1 skrev John >>>>>>>>>> Larkin: >>>>>>>>>>> http://semiengineering.com/devices-threatened-by-analog-content/ >>>>>>>>>>> >>>>>> >>>>>> IME most analog failures are caused by ESD and that is often squarely in >>>>>> the court of the board level designer. >>>>>> >>>>>> Upsets without subsequent chip damage are also considered a fault where >>>>>> the function is mission-critical. That is very often due to EMI. >>>>>> >>>>>> >>>>>>>>>>> My experience is that we find a lot of bugs and documentation >>>>>>>>>>> problems >>>>>>>>>>> with the digital parts of mixed-signal chips. >>>>>>>>>> >>>>>>>>>> It does seem like when analog designers get to design the digital >>>>>>>>>> parts >>>>>>>>>> of a chip it often ends up with a hairball of hazards and weird >>>>>>>>>> quirks >>>>>>>>> >>>>>>>>> That was always my experience with part from NatSemi. Pure analog was >>>>>>>>> good, pure digital was good, mixed mostly was a mess. >>>>>>>> >>>>>>>> Mixed signal design is difficult, and doing it on a chip, where it is >>>>>>>> harder to keep the noisy digital bits away from the sensitive >>>>>>>> analog bits, >>>>>>>> wouldn't have made it any easier. >>>>>>>> >>>>>>>> Sadly, mixed signal design can do a lot more than pure analog or pure >>>>>>>> digital, so if you have got something complicated to do, that tends >>>>>>>> to be >>>>>>>> what you end up doing. >>>>>>> >>>>>>> It was never the problem of digital noise coupling into the analog >>>>>>> portions >>>>>>> but the digital totally mixed up, like the LM75 going into a state >>>>>>> where >>>>>>> only a power cycle helps to get it working again. This can be caused by >>>>>>> noise on the I2C signals. >>>>>> >>>>>> >>>>>> I2C is a bus I try not to use if it can be avoided because of various >>>>>> hang-ups. SPI is much more robust IME and, therefore, that is what I >>>>>> prefer. >>>>> >>>>> I prefer SPI too, and it's faster, but lots of people design terrible >>>>> SPI interfaces, bad logic design and bad clock/data circuits. Every >>>>> SPI should have schmitt inputs and safe timing margins. Maybe cooking >>>>> a digital design into an analog process causes compromises, but I >>>>> suspect it's just sloppy engineering. >>>> >>>> Not trying to be snarky, but most digital engineers work to eliminate >>>> noise and to have proper clocks without noise on the transition edge. >>>> Schmitt is only needed on the clock inputs, but even there proper design >>>> at the board level eliminates the need. >>>> >>> >>> Schmitt is needed everywhere a signal connect to the outside world. A >>> lot of uC design engineers do not understand this. >>> >>> [...] >> >> Multi-drop SPI can have clock and chip-select traces all over a board. >> A glitch or bounce on either can be bad news. It's nice if everything >> works without building matched-impedance terminated-driver tree >> structures. Geez, it's just SPI. >> >> MOSI and MISO don't need schmitts, but why not? >> > >Many reasons. In micro-power systems it's a given because any fraction >of a microsecond spent in transition or multiple transitions will result >in increased power consumption. The other effect is that multiple >triggering of the input threshold on a line that digital guys consider >"unimportant" can blow EMC. Slow edges use a lot more power in conventional gates, than in schmitts. So schmitts can save power on ce and MOSI too. -- John Larkin Highland Technology, Inc lunatic fringe electronics
[toc] | [prev] | [next] | [standalone]
| From | Joerg <news@analogconsultants.com> |
|---|---|
| Date | 2017-02-18 08:16 -0800 |
| Message-ID | <egrab1Fpft2U1@mid.individual.net> |
| In reply to | #448173 |
On 2017-02-18 08:04, John Larkin wrote: > On Sat, 18 Feb 2017 07:41:30 -0800, Joerg <news@analogconsultants.com> > wrote: > >> On 2017-02-17 17:27, John Larkin wrote: [...] >>> >>> Multi-drop SPI can have clock and chip-select traces all over a board. >>> A glitch or bounce on either can be bad news. It's nice if everything >>> works without building matched-impedance terminated-driver tree >>> structures. Geez, it's just SPI. >>> >>> MOSI and MISO don't need schmitts, but why not? >>> >> >> Many reasons. In micro-power systems it's a given because any fraction >> of a microsecond spent in transition or multiple transitions will result >> in increased power consumption. The other effect is that multiple >> triggering of the input threshold on a line that digital guys consider >> "unimportant" can blow EMC. > > Slow edges use a lot more power in conventional gates, than in > schmitts. So schmitts can save power on ce and MOSI too. > Yup, cross currents. Often I wish digital designers would have at least a slight interest in analog to see some of these effects. My funniest experience was over 20 years ago. I was tasked with a large mixed-signal design. The original one was way too digital, noisy and they used power-hungry programmable logic just about everywhere. After I was done and it was integrated into their system an engineer turned it on ... click ... zzzzt .. zzzzt .. zzt ... BEEEP ... ka-clack. Now what? Turned out we had dropped below the minimum power consumption for their massive SMPS and it kept tripping off. -- Regards, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
| From | Reinhardt Behm <rbehm@hushmail.com> |
|---|---|
| Date | 2017-02-16 06:49 +0800 |
| Message-ID | <o82lpj$r0m$1@dont-email.me> |
| In reply to | #447744 |
AT Wednesday 15 February 2017 23:53, Joerg wrote: > On 2017-02-14 19:55, Reinhardt Behm wrote: >> AT Wednesday 15 February 2017 11:00, bill.sloman@ieee.org wrote: >> >>> On Wednesday, February 15, 2017 at 1:52:23 PM UTC+11, Reinhardt Behm >>> wrote: >>>> AT Wednesday 15 February 2017 07:05, Lasse Langwadt Christensen wrote: >>>> >>>>> Den tirsdag den 14. februar 2017 kl. 23.47.11 UTC+1 skrev John Larkin: >>>>>> http://semiengineering.com/devices-threatened-by-analog-content/ >>>>>> > > IME most analog failures are caused by ESD and that is often squarely in > the court of the board level designer. > > Upsets without subsequent chip damage are also considered a fault where > the function is mission-critical. That is very often due to EMI. > > >>>>>> My experience is that we find a lot of bugs and documentation >>>>>> problems with the digital parts of mixed-signal chips. >>>>> >>>>> It does seem like when analog designers get to design the digital >>>>> parts of a chip it often ends up with a hairball of hazards and weird >>>>> quirks >>>> >>>> That was always my experience with part from NatSemi. Pure analog was >>>> good, pure digital was good, mixed mostly was a mess. >>> >>> Mixed signal design is difficult, and doing it on a chip, where it is >>> harder to keep the noisy digital bits away from the sensitive analog >>> bits, wouldn't have made it any easier. >>> >>> Sadly, mixed signal design can do a lot more than pure analog or pure >>> digital, so if you have got something complicated to do, that tends to >>> be what you end up doing. >> >> It was never the problem of digital noise coupling into the analog >> portions but the digital totally mixed up, like the LM75 going into a >> state where only a power cycle helps to get it working again. This can be >> caused by noise on the I2C signals. > > > I2C is a bus I try not to use if it can be avoided because of various > hang-ups. SPI is much more robust IME and, therefore, that is what I > prefer. > > >> I had the same with a part from Microchip. It has a config bit to >> automatically reset its I2C interface after a timeout period without any >> activity on the bus. This bit is reset after power on. So if the >> interface goes gaga because of a poor POR you never get it working. >> > > Oh-oh. Sounds like they built in a loose cannon for a sledgehammer. > However, a poor POR is something the circuit designer should take care > of. Never trust any on-chip POR/BOR. Ever. Good advice if the chip has no reset pin. :-( -- Reinhardt
[toc] | [prev] | [next] | [standalone]
| From | Joerg <news@analogconsultants.com> |
|---|---|
| Date | 2017-02-16 07:14 -0800 |
| Message-ID | <eglttjFn2btU1@mid.individual.net> |
| In reply to | #447799 |
On 2017-02-15 14:49, Reinhardt Behm wrote: > AT Wednesday 15 February 2017 23:53, Joerg wrote: > >> On 2017-02-14 19:55, Reinhardt Behm wrote: >>> AT Wednesday 15 February 2017 11:00, bill.sloman@ieee.org wrote: >>> >>>> On Wednesday, February 15, 2017 at 1:52:23 PM UTC+11, Reinhardt Behm >>>> wrote: >>>>> AT Wednesday 15 February 2017 07:05, Lasse Langwadt Christensen wrote: >>>>> >>>>>> Den tirsdag den 14. februar 2017 kl. 23.47.11 UTC+1 skrev John Larkin: >>>>>>> http://semiengineering.com/devices-threatened-by-analog-content/ >>>>>>> >> >> IME most analog failures are caused by ESD and that is often squarely in >> the court of the board level designer. >> >> Upsets without subsequent chip damage are also considered a fault where >> the function is mission-critical. That is very often due to EMI. >> >> >>>>>>> My experience is that we find a lot of bugs and documentation >>>>>>> problems with the digital parts of mixed-signal chips. >>>>>> >>>>>> It does seem like when analog designers get to design the digital >>>>>> parts of a chip it often ends up with a hairball of hazards and weird >>>>>> quirks >>>>> >>>>> That was always my experience with part from NatSemi. Pure analog was >>>>> good, pure digital was good, mixed mostly was a mess. >>>> >>>> Mixed signal design is difficult, and doing it on a chip, where it is >>>> harder to keep the noisy digital bits away from the sensitive analog >>>> bits, wouldn't have made it any easier. >>>> >>>> Sadly, mixed signal design can do a lot more than pure analog or pure >>>> digital, so if you have got something complicated to do, that tends to >>>> be what you end up doing. >>> >>> It was never the problem of digital noise coupling into the analog >>> portions but the digital totally mixed up, like the LM75 going into a >>> state where only a power cycle helps to get it working again. This can be >>> caused by noise on the I2C signals. >> >> >> I2C is a bus I try not to use if it can be avoided because of various >> hang-ups. SPI is much more robust IME and, therefore, that is what I >> prefer. >> >> >>> I had the same with a part from Microchip. It has a config bit to >>> automatically reset its I2C interface after a timeout period without any >>> activity on the bus. This bit is reset after power on. So if the >>> interface goes gaga because of a poor POR you never get it working. >>> >> >> Oh-oh. Sounds like they built in a loose cannon for a sledgehammer. >> However, a poor POR is something the circuit designer should take care >> of. Never trust any on-chip POR/BOR. Ever. > > Good advice if the chip has no reset pin. :-( > I've had designs where it was like your case and then my reset pin was introduced by means of a P-channel in the VCC line. However, than meant that the data lines had to be muxed and shut off as well or the chip could be supplied through its diode paths. Only at the client's insistence. I prefer stuff that is more reliable. In this case, for example, the LM35. Unfortunely that one needs a negative supply if low temperatures have to be measured. -- Regards, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
| From | John Larkin <jjlarkin@highlandtechnology.com> |
|---|---|
| Date | 2017-02-16 07:24 -0800 |
| Message-ID | <5sgbacp5h1jgs7mv379oa1e78n2i6i64ld@4ax.com> |
| In reply to | #447861 |
On Thu, 16 Feb 2017 07:14:03 -0800, Joerg <news@analogconsultants.com> wrote: >On 2017-02-15 14:49, Reinhardt Behm wrote: >> AT Wednesday 15 February 2017 23:53, Joerg wrote: >> >>> On 2017-02-14 19:55, Reinhardt Behm wrote: >>>> AT Wednesday 15 February 2017 11:00, bill.sloman@ieee.org wrote: >>>> >>>>> On Wednesday, February 15, 2017 at 1:52:23 PM UTC+11, Reinhardt Behm >>>>> wrote: >>>>>> AT Wednesday 15 February 2017 07:05, Lasse Langwadt Christensen wrote: >>>>>> >>>>>>> Den tirsdag den 14. februar 2017 kl. 23.47.11 UTC+1 skrev John Larkin: >>>>>>>> http://semiengineering.com/devices-threatened-by-analog-content/ >>>>>>>> >>> >>> IME most analog failures are caused by ESD and that is often squarely in >>> the court of the board level designer. >>> >>> Upsets without subsequent chip damage are also considered a fault where >>> the function is mission-critical. That is very often due to EMI. >>> >>> >>>>>>>> My experience is that we find a lot of bugs and documentation >>>>>>>> problems with the digital parts of mixed-signal chips. >>>>>>> >>>>>>> It does seem like when analog designers get to design the digital >>>>>>> parts of a chip it often ends up with a hairball of hazards and weird >>>>>>> quirks >>>>>> >>>>>> That was always my experience with part from NatSemi. Pure analog was >>>>>> good, pure digital was good, mixed mostly was a mess. >>>>> >>>>> Mixed signal design is difficult, and doing it on a chip, where it is >>>>> harder to keep the noisy digital bits away from the sensitive analog >>>>> bits, wouldn't have made it any easier. >>>>> >>>>> Sadly, mixed signal design can do a lot more than pure analog or pure >>>>> digital, so if you have got something complicated to do, that tends to >>>>> be what you end up doing. >>>> >>>> It was never the problem of digital noise coupling into the analog >>>> portions but the digital totally mixed up, like the LM75 going into a >>>> state where only a power cycle helps to get it working again. This can be >>>> caused by noise on the I2C signals. >>> >>> >>> I2C is a bus I try not to use if it can be avoided because of various >>> hang-ups. SPI is much more robust IME and, therefore, that is what I >>> prefer. >>> >>> >>>> I had the same with a part from Microchip. It has a config bit to >>>> automatically reset its I2C interface after a timeout period without any >>>> activity on the bus. This bit is reset after power on. So if the >>>> interface goes gaga because of a poor POR you never get it working. >>>> >>> >>> Oh-oh. Sounds like they built in a loose cannon for a sledgehammer. >>> However, a poor POR is something the circuit designer should take care >>> of. Never trust any on-chip POR/BOR. Ever. >> >> Good advice if the chip has no reset pin. :-( >> > >I've had designs where it was like your case and then my reset pin was >introduced by means of a P-channel in the VCC line. However, than meant >that the data lines had to be muxed and shut off as well or the chip >could be supplied through its diode paths. > >Only at the client's insistence. I prefer stuff that is more reliable. >In this case, for example, the LM35. Unfortunely that one needs a >negative supply if low temperatures have to be measured. LM35 is one tricky dude. If you pull its output negative more than a couple tenths of a volt (or some spike does it for you) it will latch up. Never power them from more than 5 volts, or it will eventually latch up. It will oscillate if it sees a capacitive load, like a cable. -- John Larkin Highland Technology, Inc lunatic fringe electronics
[toc] | [prev] | [next] | [standalone]
| From | Joerg <news@analogconsultants.com> |
|---|---|
| Date | 2017-02-16 07:41 -0800 |
| Message-ID | <eglvhdFnd5lU1@mid.individual.net> |
| In reply to | #447862 |
On 2017-02-16 07:24, John Larkin wrote: > On Thu, 16 Feb 2017 07:14:03 -0800, Joerg <news@analogconsultants.com> > wrote: > >> On 2017-02-15 14:49, Reinhardt Behm wrote: >>> AT Wednesday 15 February 2017 23:53, Joerg wrote: >>> >>>> On 2017-02-14 19:55, Reinhardt Behm wrote: [...] >>>>> I had the same with a part from Microchip. It has a config bit to >>>>> automatically reset its I2C interface after a timeout period without any >>>>> activity on the bus. This bit is reset after power on. So if the >>>>> interface goes gaga because of a poor POR you never get it working. >>>>> >>>> >>>> Oh-oh. Sounds like they built in a loose cannon for a sledgehammer. >>>> However, a poor POR is something the circuit designer should take care >>>> of. Never trust any on-chip POR/BOR. Ever. >>> >>> Good advice if the chip has no reset pin. :-( >>> >> >> I've had designs where it was like your case and then my reset pin was >> introduced by means of a P-channel in the VCC line. However, than meant >> that the data lines had to be muxed and shut off as well or the chip >> could be supplied through its diode paths. >> >> Only at the client's insistence. I prefer stuff that is more reliable. >> In this case, for example, the LM35. Unfortunely that one needs a >> negative supply if low temperatures have to be measured. > > LM35 is one tricky dude. If you pull its output negative more than a > couple tenths of a volt (or some spike does it for you) it will latch > up. The datasheet recommend a resistor of such value, that just a few tens of uA are flowing. But that is only needed if low temps have to be monitored. > Never power them from more than 5 volts, or it will eventually > latch up. It will oscillate if it sees a capacitive load, like a > cable. > That's to be expected, opamps don't like that either. -- Regards, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
| From | Reinhardt Behm <rbehm@hushmail.com> |
|---|---|
| Date | 2017-02-17 13:22 +0800 |
| Message-ID | <o8617o$6de$1@dont-email.me> |
| In reply to | #447861 |
AT Thursday 16 February 2017 23:14, Joerg wrote: > On 2017-02-15 14:49, Reinhardt Behm wrote: >> AT Wednesday 15 February 2017 23:53, Joerg wrote: >> >>> On 2017-02-14 19:55, Reinhardt Behm wrote: >>>> AT Wednesday 15 February 2017 11:00, bill.sloman@ieee.org wrote: >>>> >>>>> On Wednesday, February 15, 2017 at 1:52:23 PM UTC+11, Reinhardt Behm >>>>> wrote: >>>>>> AT Wednesday 15 February 2017 07:05, Lasse Langwadt Christensen >>>>>> wrote: >>>>>> >>>>>>> Den tirsdag den 14. februar 2017 kl. 23.47.11 UTC+1 skrev John >>>>>>> Larkin: >>>>>>>> http://semiengineering.com/devices-threatened-by-analog-content/ >>>>>>>> >>> >>> IME most analog failures are caused by ESD and that is often squarely in >>> the court of the board level designer. >>> >>> Upsets without subsequent chip damage are also considered a fault where >>> the function is mission-critical. That is very often due to EMI. >>> >>> >>>>>>>> My experience is that we find a lot of bugs and documentation >>>>>>>> problems with the digital parts of mixed-signal chips. >>>>>>> >>>>>>> It does seem like when analog designers get to design the digital >>>>>>> parts of a chip it often ends up with a hairball of hazards and >>>>>>> weird quirks >>>>>> >>>>>> That was always my experience with part from NatSemi. Pure analog was >>>>>> good, pure digital was good, mixed mostly was a mess. >>>>> >>>>> Mixed signal design is difficult, and doing it on a chip, where it is >>>>> harder to keep the noisy digital bits away from the sensitive analog >>>>> bits, wouldn't have made it any easier. >>>>> >>>>> Sadly, mixed signal design can do a lot more than pure analog or pure >>>>> digital, so if you have got something complicated to do, that tends to >>>>> be what you end up doing. >>>> >>>> It was never the problem of digital noise coupling into the analog >>>> portions but the digital totally mixed up, like the LM75 going into a >>>> state where only a power cycle helps to get it working again. This can >>>> be caused by noise on the I2C signals. >>> >>> >>> I2C is a bus I try not to use if it can be avoided because of various >>> hang-ups. SPI is much more robust IME and, therefore, that is what I >>> prefer. >>> >>> >>>> I had the same with a part from Microchip. It has a config bit to >>>> automatically reset its I2C interface after a timeout period without >>>> any activity on the bus. This bit is reset after power on. So if the >>>> interface goes gaga because of a poor POR you never get it working. >>>> >>> >>> Oh-oh. Sounds like they built in a loose cannon for a sledgehammer. >>> However, a poor POR is something the circuit designer should take care >>> of. Never trust any on-chip POR/BOR. Ever. >> >> Good advice if the chip has no reset pin. :-( >> > > I've had designs where it was like your case and then my reset pin was > introduced by means of a P-channel in the VCC line. However, than meant > that the data lines had to be muxed and shut off as well or the chip > could be supplied through its diode paths. > > Only at the client's insistence. I prefer stuff that is more reliable. > In this case, for example, the LM35. Unfortunely that one needs a > negative supply if low temperatures have to be measured. I have already drawn my conclusions: Microchip is out. It was the same as with a DC/DC manufacturer. After the first heavy fail their sales called and I told him to come back when they have learned how to design. Never heard of him, maybe they have not yet learned it. -- Reinhardt
[toc] | [prev] | [next] | [standalone]
| From | Joerg <news@analogconsultants.com> |
|---|---|
| Date | 2017-02-17 06:58 -0800 |
| Message-ID | <egohbvF8ge7U1@mid.individual.net> |
| In reply to | #447971 |
On 2017-02-16 21:22, Reinhardt Behm wrote: > AT Thursday 16 February 2017 23:14, Joerg wrote: > >> On 2017-02-15 14:49, Reinhardt Behm wrote: >>> AT Wednesday 15 February 2017 23:53, Joerg wrote: >>> >>>> On 2017-02-14 19:55, Reinhardt Behm wrote: [...] >>>> >>>>> I had the same with a part from Microchip. It has a config bit to >>>>> automatically reset its I2C interface after a timeout period without >>>>> any activity on the bus. This bit is reset after power on. So if the >>>>> interface goes gaga because of a poor POR you never get it working. >>>>> >>>> >>>> Oh-oh. Sounds like they built in a loose cannon for a sledgehammer. >>>> However, a poor POR is something the circuit designer should take care >>>> of. Never trust any on-chip POR/BOR. Ever. >>> >>> Good advice if the chip has no reset pin. :-( >>> >> >> I've had designs where it was like your case and then my reset pin was >> introduced by means of a P-channel in the VCC line. However, than meant >> that the data lines had to be muxed and shut off as well or the chip >> could be supplied through its diode paths. >> >> Only at the client's insistence. I prefer stuff that is more reliable. >> In this case, for example, the LM35. Unfortunely that one needs a >> negative supply if low temperatures have to be measured. > > I have already drawn my conclusions: Microchip is out. > It was the same as with a DC/DC manufacturer. After the first heavy fail > their sales called and I told him to come back when they have learned how to > design. Never heard of him, maybe they have not yet learned it. > I have had quite good experience with Microchip. Opamps, even some LDO voltage regulators which were surprisingly stable (on the client's insistence since I never use LDO). -- Regards, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
Page 2 of 5 — ← Prev page 1 [2] 3 4 5 Next page →
Back to top | Article view | sci.electronics.design
csiph-web