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 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | dagmargoodboat@yahoo.com |
|---|---|
| Date | 2017-02-24 09:02 -0800 |
| Message-ID | <1a268f48-ccf5-4699-9f4e-44fd973f58c1@googlegroups.com> |
| In reply to | #448963 |
On Thursday, February 23, 2017 at 1:43:23 PM UTC-5, Joerg wrote: > On 2017-02-22 15:45, dagmargoodboat@yahoo.com wrote: > > [...] > > > > > AIUI you can clear nearly all the i2c deadlocks by having the master > > cycle the clock 9 times (or by just cycling the power :). > > > > Thing is, my clients typically do not want to hear the word "nearly" :-) Which is why you'd want to design the thing so the i2c could never deadlock in the first place. But if you're like me, chastened by others' tales, you could include two levels of recovery so that even if the inconceivable happened it could ever be a critical fault, just in case. Reliable + (redundancy + retry) = spandex, belt, and suspenders. SPI can fail too if someone think's he's enabled when he isn't. What's the fallback then? But that doesn't much happen, right? > A vendor wanted to convince a client to adopt press-fit for > motherboards. Something I never liked and where I have seen failures. > Big meeting. Went like this: > > "We guarantee 99.9% contact reliability on DIN connectors" ... a certain > consultant raises hand ... "Sir, our motherboard has lots of DIN > connectors and the pin number totals 3,456. According to your statement > three to four of those could fail to connect reliably. Could you tell us > which ones those would be?" > > The meeting sort of ended. Cheers, James Arthur
[toc] | [prev] | [next] | [standalone]
| From | Joerg <news@analogconsultants.com> |
|---|---|
| Date | 2017-02-25 12:44 -0800 |
| Message-ID | <ehe8lrFk2ehU1@mid.individual.net> |
| In reply to | #449050 |
On 2017-02-24 09:02, dagmargoodboat@yahoo.com wrote: > On Thursday, February 23, 2017 at 1:43:23 PM UTC-5, Joerg wrote: >> On 2017-02-22 15:45, dagmargoodboat@yahoo.com wrote: >> >> [...] >> >>> >>> AIUI you can clear nearly all the i2c deadlocks by having the master >>> cycle the clock 9 times (or by just cycling the power :). >>> >> >> Thing is, my clients typically do not want to hear the word "nearly" :-) > > Which is why you'd want to design the thing so the i2c could never > deadlock in the first place. But if you're like me, chastened by > others' tales, you could include two levels of recovery so that even > if the inconceivable happened it could ever be a critical fault, just > in case. > > Reliable + (redundancy + retry) = spandex, belt, and suspenders. > > SPI can fail too if someone think's he's enabled when he isn't. What's > the fallback then? But that doesn't much happen, right? > Not really because the master enables and disables. So having a hung bus because or a rogue device isn't likely unless the device is physically damaged. Not so with I2C where I saw cases where a power cycle made it all come back and work fine. For a while ... [...] -- Regards, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
| From | dagmargoodboat@yahoo.com |
|---|---|
| Date | 2017-02-26 08:29 -0800 |
| Message-ID | <7a46230f-a92a-4357-89a6-e6e7caa8a8db@googlegroups.com> |
| In reply to | #449217 |
On Saturday, February 25, 2017 at 3:44:47 PM UTC-5, Joerg wrote: > On 2017-02-24 09:02, dagmargoodboat@yahoo.com wrote: > > On Thursday, February 23, 2017 at 1:43:23 PM UTC-5, Joerg wrote: > >> On 2017-02-22 15:45, dagmargoodboat@yahoo.com wrote: > >> > >> [...] > >> > >>> > >>> AIUI you can clear nearly all the i2c deadlocks by having the master > >>> cycle the clock 9 times (or by just cycling the power :). > >>> > >> > >> Thing is, my clients typically do not want to hear the word "nearly" :-) > > > > Which is why you'd want to design the thing so the i2c could never > > deadlock in the first place. But if you're like me, chastened by > > others' tales, you could include two levels of recovery so that even > > if the inconceivable happened it could ever be a critical fault, just > > in case. > > > > Reliable + (redundancy + retry) = spandex, belt, and suspenders. > > > > SPI can fail too if someone think's he's enabled when he isn't. What's > > the fallback then? But that doesn't much happen, right? > > > > Not really because the master enables and disables. So having a hung bus > because or a rogue device isn't likely unless the device is physically > damaged. Well that was my point-- > Not so with I2C where I saw cases where a power cycle made it > all come back and work fine. For a while ... Such a system plainly has a flaw somewhere--a race condition or some protocol problem--and that's obviously NOT okay. I just tied five boards together in a system comprising twenty-one i2c devices, and did it with a four-inch / two-wire bus. I2c was ideal for that. > [...] Cheers, James Arthur
[toc] | [prev] | [next] | [standalone]
| From | Joerg <news@analogconsultants.com> |
|---|---|
| Date | 2017-02-26 09:46 -0800 |
| Message-ID | <ehgik2F3ergU1@mid.individual.net> |
| In reply to | #449304 |
On 2017-02-26 08:29, dagmargoodboat@yahoo.com wrote: > On Saturday, February 25, 2017 at 3:44:47 PM UTC-5, Joerg wrote: >> On 2017-02-24 09:02, dagmargoodboat@yahoo.com wrote: >>> On Thursday, February 23, 2017 at 1:43:23 PM UTC-5, Joerg wrote: >>>> On 2017-02-22 15:45, dagmargoodboat@yahoo.com wrote: >>>> >>>> [...] >>>> >>>>> >>>>> AIUI you can clear nearly all the i2c deadlocks by having the master >>>>> cycle the clock 9 times (or by just cycling the power :). >>>>> >>>> >>>> Thing is, my clients typically do not want to hear the word "nearly" :-) >>> >>> Which is why you'd want to design the thing so the i2c could never >>> deadlock in the first place. But if you're like me, chastened by >>> others' tales, you could include two levels of recovery so that even >>> if the inconceivable happened it could ever be a critical fault, just >>> in case. >>> >>> Reliable + (redundancy + retry) = spandex, belt, and suspenders. >>> >>> SPI can fail too if someone think's he's enabled when he isn't. What's >>> the fallback then? But that doesn't much happen, right? >>> >> >> Not really because the master enables and disables. So having a hung bus >> because or a rogue device isn't likely unless the device is physically >> damaged. > > Well that was my point-- > >> Not so with I2C where I saw cases where a power cycle made it >> all come back and work fine. For a while ... > > Such a system plainly has a flaw somewhere--a race condition or some > protocol problem--and that's obviously NOT okay. > The problem is that the issue is often not controlled by the quality of the design but by that of the circuitry inside an IC, so out of the hands of the board level designer. > I just tied five boards together in a system comprising twenty-one i2c > devices, and did it with a four-inch / two-wire bus. I2c was ideal for > that. > I2C is a great idea. It's just the implementation that often isn't sufficiently rugged. -- Regards, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
| From | John Larkin <jjlarkin@highlandtechnology.com> |
|---|---|
| Date | 2017-02-26 10:11 -0800 |
| Message-ID | <qe66bch9gseiog29q752vs65k8uesvkrfh@4ax.com> |
| In reply to | #449304 |
On Sun, 26 Feb 2017 08:29:04 -0800 (PST), dagmargoodboat@yahoo.com wrote: >On Saturday, February 25, 2017 at 3:44:47 PM UTC-5, Joerg wrote: >> On 2017-02-24 09:02, dagmargoodboat@yahoo.com wrote: >> > On Thursday, February 23, 2017 at 1:43:23 PM UTC-5, Joerg wrote: >> >> On 2017-02-22 15:45, dagmargoodboat@yahoo.com wrote: >> >> >> >> [...] >> >> >> >>> >> >>> AIUI you can clear nearly all the i2c deadlocks by having the master >> >>> cycle the clock 9 times (or by just cycling the power :). >> >>> >> >> >> >> Thing is, my clients typically do not want to hear the word "nearly" :-) >> > >> > Which is why you'd want to design the thing so the i2c could never >> > deadlock in the first place. But if you're like me, chastened by >> > others' tales, you could include two levels of recovery so that even >> > if the inconceivable happened it could ever be a critical fault, just >> > in case. >> > >> > Reliable + (redundancy + retry) = spandex, belt, and suspenders. >> > >> > SPI can fail too if someone think's he's enabled when he isn't. What's >> > the fallback then? But that doesn't much happen, right? >> > >> >> Not really because the master enables and disables. So having a hung bus >> because or a rogue device isn't likely unless the device is physically >> damaged. > >Well that was my point-- > >> Not so with I2C where I saw cases where a power cycle made it >> all come back and work fine. For a while ... > >Such a system plainly has a flaw somewhere--a race condition or some >protocol problem--and that's obviously NOT okay. > >I just tied five boards together in a system comprising twenty-one i2c >devices, and did it with a four-inch / two-wire bus. I2c was ideal for >that. > > >> [...] > >Cheers, >James Arthur SPI parts have a chip select pin, so there should be no doubt about a part being selected. Deselecting a part returns it to a defined state (unless it's made by Analog Devices.) -- John Larkin Highland Technology, Inc lunatic fringe electronics
[toc] | [prev] | [next] | [standalone]
| From | krw@notreal.com |
|---|---|
| Date | 2017-02-26 17:55 -0500 |
| Message-ID | <tqm6bchuafs24f1dtop718iojqm2j9gics@4ax.com> |
| In reply to | #449316 |
On Sun, 26 Feb 2017 10:11:28 -0800, John Larkin <jjlarkin@highlandtechnology.com> wrote: >On Sun, 26 Feb 2017 08:29:04 -0800 (PST), dagmargoodboat@yahoo.com >wrote: > >>On Saturday, February 25, 2017 at 3:44:47 PM UTC-5, Joerg wrote: >>> On 2017-02-24 09:02, dagmargoodboat@yahoo.com wrote: >>> > On Thursday, February 23, 2017 at 1:43:23 PM UTC-5, Joerg wrote: >>> >> On 2017-02-22 15:45, dagmargoodboat@yahoo.com wrote: >>> >> >>> >> [...] >>> >> >>> >>> >>> >>> AIUI you can clear nearly all the i2c deadlocks by having the master >>> >>> cycle the clock 9 times (or by just cycling the power :). >>> >>> >>> >> >>> >> Thing is, my clients typically do not want to hear the word "nearly" :-) >>> > >>> > Which is why you'd want to design the thing so the i2c could never >>> > deadlock in the first place. But if you're like me, chastened by >>> > others' tales, you could include two levels of recovery so that even >>> > if the inconceivable happened it could ever be a critical fault, just >>> > in case. >>> > >>> > Reliable + (redundancy + retry) = spandex, belt, and suspenders. >>> > >>> > SPI can fail too if someone think's he's enabled when he isn't. What's >>> > the fallback then? But that doesn't much happen, right? >>> > >>> >>> Not really because the master enables and disables. So having a hung bus >>> because or a rogue device isn't likely unless the device is physically >>> damaged. >> >>Well that was my point-- >> >>> Not so with I2C where I saw cases where a power cycle made it >>> all come back and work fine. For a while ... >> >>Such a system plainly has a flaw somewhere--a race condition or some >>protocol problem--and that's obviously NOT okay. >> >>I just tied five boards together in a system comprising twenty-one i2c >>devices, and did it with a four-inch / two-wire bus. I2c was ideal for >>that. >> >> >>> [...] >> >>Cheers, >>James Arthur > >SPI parts have a chip select pin, so there should be no doubt about a >part being selected. Device selecting 21 devices is a RPTIA. Many MCUs, incuding ARMs, only have one true SSN pin. >Deselecting a part returns it to a defined state (unless it's made by >Analog Devices.) Returns the I/O interface to a defined state, anyway. The nine clock and a STOP thing usually works on I2C, unless more than the I2C interface is screwed up. All bets are off on either bus if multiple masters are used, though sometimes it's unavoidable.
[toc] | [prev] | [next] | [standalone]
| From | John Larkin <jjlarkin@highlandtechnology.com> |
|---|---|
| Date | 2017-02-26 15:09 -0800 |
| Message-ID | <ekn6bctk7o9hbj67m24n4tn9ooodof17rg@4ax.com> |
| In reply to | #449343 |
On Sun, 26 Feb 2017 17:55:31 -0500, krw@notreal.com wrote: >On Sun, 26 Feb 2017 10:11:28 -0800, John Larkin ><jjlarkin@highlandtechnology.com> wrote: > >>On Sun, 26 Feb 2017 08:29:04 -0800 (PST), dagmargoodboat@yahoo.com >>wrote: >> >>>On Saturday, February 25, 2017 at 3:44:47 PM UTC-5, Joerg wrote: >>>> On 2017-02-24 09:02, dagmargoodboat@yahoo.com wrote: >>>> > On Thursday, February 23, 2017 at 1:43:23 PM UTC-5, Joerg wrote: >>>> >> On 2017-02-22 15:45, dagmargoodboat@yahoo.com wrote: >>>> >> >>>> >> [...] >>>> >> >>>> >>> >>>> >>> AIUI you can clear nearly all the i2c deadlocks by having the master >>>> >>> cycle the clock 9 times (or by just cycling the power :). >>>> >>> >>>> >> >>>> >> Thing is, my clients typically do not want to hear the word "nearly" :-) >>>> > >>>> > Which is why you'd want to design the thing so the i2c could never >>>> > deadlock in the first place. But if you're like me, chastened by >>>> > others' tales, you could include two levels of recovery so that even >>>> > if the inconceivable happened it could ever be a critical fault, just >>>> > in case. >>>> > >>>> > Reliable + (redundancy + retry) = spandex, belt, and suspenders. >>>> > >>>> > SPI can fail too if someone think's he's enabled when he isn't. What's >>>> > the fallback then? But that doesn't much happen, right? >>>> > >>>> >>>> Not really because the master enables and disables. So having a hung bus >>>> because or a rogue device isn't likely unless the device is physically >>>> damaged. >>> >>>Well that was my point-- >>> >>>> Not so with I2C where I saw cases where a power cycle made it >>>> all come back and work fine. For a while ... >>> >>>Such a system plainly has a flaw somewhere--a race condition or some >>>protocol problem--and that's obviously NOT okay. >>> >>>I just tied five boards together in a system comprising twenty-one i2c >>>devices, and did it with a four-inch / two-wire bus. I2c was ideal for >>>that. >>> >>> >>>> [...] >>> >>>Cheers, >>>James Arthur >> >>SPI parts have a chip select pin, so there should be no doubt about a >>part being selected. > >Device selecting 21 devices is a RPTIA. Many MCUs, incuding ARMs, >only have one true SSN pin. We often bit-bang the SPI chip selects from regular port pins. Or even use a decoder. > >>Deselecting a part returns it to a defined state (unless it's made by >>Analog Devices.) > >Returns the I/O interface to a defined state, anyway. Not in the AD7793! -- John Larkin Highland Technology, Inc lunatic fringe electronics
[toc] | [prev] | [next] | [standalone]
| From | krw@notreal.com |
|---|---|
| Date | 2017-02-26 19:30 -0500 |
| Message-ID | <qhs6bchp8k69dlc01ndipblidlhjm92ffv@4ax.com> |
| In reply to | #449346 |
On Sun, 26 Feb 2017 15:09:11 -0800, John Larkin <jjlarkin@highlandtechnology.com> wrote: >On Sun, 26 Feb 2017 17:55:31 -0500, krw@notreal.com wrote: > >>On Sun, 26 Feb 2017 10:11:28 -0800, John Larkin >><jjlarkin@highlandtechnology.com> wrote: >> >>>On Sun, 26 Feb 2017 08:29:04 -0800 (PST), dagmargoodboat@yahoo.com >>>wrote: >>> >>>>On Saturday, February 25, 2017 at 3:44:47 PM UTC-5, Joerg wrote: >>>>> On 2017-02-24 09:02, dagmargoodboat@yahoo.com wrote: >>>>> > On Thursday, February 23, 2017 at 1:43:23 PM UTC-5, Joerg wrote: >>>>> >> On 2017-02-22 15:45, dagmargoodboat@yahoo.com wrote: >>>>> >> >>>>> >> [...] >>>>> >> >>>>> >>> >>>>> >>> AIUI you can clear nearly all the i2c deadlocks by having the master >>>>> >>> cycle the clock 9 times (or by just cycling the power :). >>>>> >>> >>>>> >> >>>>> >> Thing is, my clients typically do not want to hear the word "nearly" :-) >>>>> > >>>>> > Which is why you'd want to design the thing so the i2c could never >>>>> > deadlock in the first place. But if you're like me, chastened by >>>>> > others' tales, you could include two levels of recovery so that even >>>>> > if the inconceivable happened it could ever be a critical fault, just >>>>> > in case. >>>>> > >>>>> > Reliable + (redundancy + retry) = spandex, belt, and suspenders. >>>>> > >>>>> > SPI can fail too if someone think's he's enabled when he isn't. What's >>>>> > the fallback then? But that doesn't much happen, right? >>>>> > >>>>> >>>>> Not really because the master enables and disables. So having a hung bus >>>>> because or a rogue device isn't likely unless the device is physically >>>>> damaged. >>>> >>>>Well that was my point-- >>>> >>>>> Not so with I2C where I saw cases where a power cycle made it >>>>> all come back and work fine. For a while ... >>>> >>>>Such a system plainly has a flaw somewhere--a race condition or some >>>>protocol problem--and that's obviously NOT okay. >>>> >>>>I just tied five boards together in a system comprising twenty-one i2c >>>>devices, and did it with a four-inch / two-wire bus. I2c was ideal for >>>>that. >>>> >>>> >>>>> [...] >>>> >>>>Cheers, >>>>James Arthur >>> >>>SPI parts have a chip select pin, so there should be no doubt about a >>>part being selected. >> >>Device selecting 21 devices is a RPTIA. Many MCUs, incuding ARMs, >>only have one true SSN pin. > >We often bit-bang the SPI chip selects from regular port pins. Or even >use a decoder. That works for really trivial systems. It's kinda tough booting systems over bit-banged SPI, though. I often have a situation where the DSP is booted from flash but the DSP is also a slave to a uC (and the uC has to be able to update the flash). Bit banging isn't a great solution. >>>Deselecting a part returns it to a defined state (unless it's made by >>>Analog Devices.) >> >>Returns the I/O interface to a defined state, anyway. > >Not in the AD7793! Are you positive there isn't something else screwed up in the interface. I've never used a 7793 but your description does sound bad.
[toc] | [prev] | [next] | [standalone]
| From | John Larkin <jjlarkinxyxy@highlandtechnology.com> |
|---|---|
| Date | 2017-02-27 10:37 -0800 |
| Message-ID | <6tr8bc5hmqpe2ier9ekn5768prpvro67l7@4ax.com> |
| In reply to | #449356 |
On Sun, 26 Feb 2017 19:30:14 -0500, krw@notreal.com wrote: >On Sun, 26 Feb 2017 15:09:11 -0800, John Larkin ><jjlarkin@highlandtechnology.com> wrote: > >>On Sun, 26 Feb 2017 17:55:31 -0500, krw@notreal.com wrote: >> >>>On Sun, 26 Feb 2017 10:11:28 -0800, John Larkin >>><jjlarkin@highlandtechnology.com> wrote: >>> >>>>On Sun, 26 Feb 2017 08:29:04 -0800 (PST), dagmargoodboat@yahoo.com >>>>wrote: >>>> >>>>>On Saturday, February 25, 2017 at 3:44:47 PM UTC-5, Joerg wrote: >>>>>> On 2017-02-24 09:02, dagmargoodboat@yahoo.com wrote: >>>>>> > On Thursday, February 23, 2017 at 1:43:23 PM UTC-5, Joerg wrote: >>>>>> >> On 2017-02-22 15:45, dagmargoodboat@yahoo.com wrote: >>>>>> >> >>>>>> >> [...] >>>>>> >> >>>>>> >>> >>>>>> >>> AIUI you can clear nearly all the i2c deadlocks by having the master >>>>>> >>> cycle the clock 9 times (or by just cycling the power :). >>>>>> >>> >>>>>> >> >>>>>> >> Thing is, my clients typically do not want to hear the word "nearly" :-) >>>>>> > >>>>>> > Which is why you'd want to design the thing so the i2c could never >>>>>> > deadlock in the first place. But if you're like me, chastened by >>>>>> > others' tales, you could include two levels of recovery so that even >>>>>> > if the inconceivable happened it could ever be a critical fault, just >>>>>> > in case. >>>>>> > >>>>>> > Reliable + (redundancy + retry) = spandex, belt, and suspenders. >>>>>> > >>>>>> > SPI can fail too if someone think's he's enabled when he isn't. What's >>>>>> > the fallback then? But that doesn't much happen, right? >>>>>> > >>>>>> >>>>>> Not really because the master enables and disables. So having a hung bus >>>>>> because or a rogue device isn't likely unless the device is physically >>>>>> damaged. >>>>> >>>>>Well that was my point-- >>>>> >>>>>> Not so with I2C where I saw cases where a power cycle made it >>>>>> all come back and work fine. For a while ... >>>>> >>>>>Such a system plainly has a flaw somewhere--a race condition or some >>>>>protocol problem--and that's obviously NOT okay. >>>>> >>>>>I just tied five boards together in a system comprising twenty-one i2c >>>>>devices, and did it with a four-inch / two-wire bus. I2c was ideal for >>>>>that. >>>>> >>>>> >>>>>> [...] >>>>> >>>>>Cheers, >>>>>James Arthur >>>> >>>>SPI parts have a chip select pin, so there should be no doubt about a >>>>part being selected. >>> >>>Device selecting 21 devices is a RPTIA. Many MCUs, incuding ARMs, >>>only have one true SSN pin. >> >>We often bit-bang the SPI chip selects from regular port pins. Or even >>use a decoder. > >That works for really trivial systems. It's kinda tough booting >systems over bit-banged SPI, though. Well, obviously we need to do what it takes to boot a system. But port-banging chip selects later works fine. Once a target is chip selected, then we sometimes fire off an SPI engine (uP resident or built in an FPGA) or just bang the entire SPI transaction. On a 600 MHz ARM, we can software bang SPI as fast as most chips will accept it. I often have a situation where >the DSP is booted from flash but the DSP is also a slave to a uC (and >the uC has to be able to update the flash). Bit banging isn't a great >solution. We typically let an ARM boot its code off a serial flash. Once that's up, it usually reads more of the flash to program FPGAs, which is essentially SPI. > >>>>Deselecting a part returns it to a defined state (unless it's made by >>>>Analog Devices.) >>> >>>Returns the I/O interface to a defined state, anyway. >> >>Not in the AD7793! > >Are you positive there isn't something else screwed up in the >interface. I've never used a 7793 but your description does sound >bad. It has a bit counter that frames SPI packets. The counter is cleared at powerup but is not reset by deselect. So if it gets out of sync, the interface is hosed. It tends to slip counts when it gets cold, and it really doesn't like sharing the SPI interface with other chips. The fix is to use a TI chip. -- John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.com
[toc] | [prev] | [next] | [standalone]
| From | Lasse Langwadt Christensen <langwadt@fonz.dk> |
|---|---|
| Date | 2017-02-24 09:14 -0800 |
| Message-ID | <aea01369-3969-4913-8159-244ee3115243@googlegroups.com> |
| In reply to | #448963 |
Den torsdag den 23. februar 2017 kl. 19.43.23 UTC+1 skrev Joerg: > On 2017-02-22 15:45, dagmargoodboat@yahoo.com wrote: > > [...] > > > > > AIUI you can clear nearly all the i2c deadlocks by having the master > > cycle the clock 9 times (or by just cycling the power :). > > > > Thing is, my clients typically do not want to hear the word "nearly" :-) > > A vendor wanted to convince a client to adopt press-fit for > motherboards. Something I never liked and where I have seen failures. > Big meeting. Went like this: > > "We guarantee 99.9% contact reliability on DIN connectors" ... a certain > consultant raises hand ... "Sir, our motherboard has lots of DIN > connectors and the pin number totals 3,456. According to your statement > three to four of those could fail to connect reliably. Could you tell us > which ones those would be?" > > The meeting sort of ended. > he must have pulled that number from somewhere the sun doesn't shine, there is no way it is that bad
[toc] | [prev] | [next] | [standalone]
| From | Joerg <news@analogconsultants.com> |
|---|---|
| Date | 2017-02-25 12:46 -0800 |
| Message-ID | <ehe8piFk2ehU2@mid.individual.net> |
| In reply to | #449051 |
On 2017-02-24 09:14, Lasse Langwadt Christensen wrote: > Den torsdag den 23. februar 2017 kl. 19.43.23 UTC+1 skrev Joerg: >> On 2017-02-22 15:45, dagmargoodboat@yahoo.com wrote: >> >> [...] >> >>> >>> AIUI you can clear nearly all the i2c deadlocks by having the master >>> cycle the clock 9 times (or by just cycling the power :). >>> >> >> Thing is, my clients typically do not want to hear the word "nearly" :-) >> >> A vendor wanted to convince a client to adopt press-fit for >> motherboards. Something I never liked and where I have seen failures. >> Big meeting. Went like this: >> >> "We guarantee 99.9% contact reliability on DIN connectors" ... a certain >> consultant raises hand ... "Sir, our motherboard has lots of DIN >> connectors and the pin number totals 3,456. According to your statement >> three to four of those could fail to connect reliably. Could you tell us >> which ones those would be?" >> >> The meeting sort of ended. >> > > he must have pulled that number from somewhere the sun doesn't shine, there > is no way it is that bad > It was pretty bad, IMHO. One one line where they had a lot of field failures I convinced the client to send all motherboards over the solder bath. That kind of convincing was not easy, almost with kicking and screaming. But it sure fixed the problem. -- Regards, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
| From | Klaus Kragelund <klauskvik@hotmail.com> |
|---|---|
| Date | 2017-02-26 17:44 -0800 |
| Message-ID | <aa9ed293-4605-4aaa-bd28-2155c7eebdc2@googlegroups.com> |
| In reply to | #449051 |
On Friday, February 24, 2017 at 6:15:02 PM UTC+1, Lasse Langwadt Christensen wrote: > Den torsdag den 23. februar 2017 kl. 19.43.23 UTC+1 skrev Joerg: > > On 2017-02-22 15:45, dagmargoodboat@yahoo.com wrote: > > > > [...] > > > > > > > > AIUI you can clear nearly all the i2c deadlocks by having the master > > > cycle the clock 9 times (or by just cycling the power :). > > > > > > > Thing is, my clients typically do not want to hear the word "nearly" :-) > > > > A vendor wanted to convince a client to adopt press-fit for > > motherboards. Something I never liked and where I have seen failures. > > Big meeting. Went like this: > > > > "We guarantee 99.9% contact reliability on DIN connectors" ... a certain > > consultant raises hand ... "Sir, our motherboard has lots of DIN > > connectors and the pin number totals 3,456. According to your statement > > three to four of those could fail to connect reliably. Could you tell us > > which ones those would be?" > > > > The meeting sort of ended. > > > > he must have pulled that number from somewhere the sun doesn't shine, there > is no way it is that bad We use press fit in running production. I have never heard about failures, once the process is running correctly Cheers Klaus
[toc] | [prev] | [next] | [standalone]
| From | Joerg <news@analogconsultants.com> |
|---|---|
| Date | 2017-02-27 07:51 -0800 |
| Message-ID | <ehj08eFibipU1@mid.individual.net> |
| In reply to | #449362 |
On 2017-02-26 17:44, Klaus Kragelund wrote: > On Friday, February 24, 2017 at 6:15:02 PM UTC+1, Lasse Langwadt > Christensen wrote: >> Den torsdag den 23. februar 2017 kl. 19.43.23 UTC+1 skrev Joerg: >>> On 2017-02-22 15:45, dagmargoodboat@yahoo.com wrote: >>> >>> [...] >>> >>>> >>>> AIUI you can clear nearly all the i2c deadlocks by having the >>>> master cycle the clock 9 times (or by just cycling the power >>>> :). >>>> >>> >>> Thing is, my clients typically do not want to hear the word >>> "nearly" :-) >>> >>> A vendor wanted to convince a client to adopt press-fit for >>> motherboards. Something I never liked and where I have seen >>> failures. Big meeting. Went like this: >>> >>> "We guarantee 99.9% contact reliability on DIN connectors" ... a >>> certain consultant raises hand ... "Sir, our motherboard has lots >>> of DIN connectors and the pin number totals 3,456. According to >>> your statement three to four of those could fail to connect >>> reliably. Could you tell us which ones those would be?" >>> >>> The meeting sort of ended. >>> >> >> he must have pulled that number from somewhere the sun doesn't >> shine, there is no way it is that bad > > We use press fit in running production. I have never heard about > failures, once the process is running correctly > They usually happened on units where boards were pulled and plugged often. Also on systems that were exposed to very rough transport like hundreds of miles on washboard roads in a raggedy old truck. Soldering those motherboards fixed that problem. The press-fit had been performed professionally at a company that specialized in this technology but it still failed at times. -- Regards, Joerg http://www.analogconsultants.com/
[toc] | [prev] | [next] | [standalone]
| From | Tauno Voipio <tauno.voipio@notused.fi.invalid> |
|---|---|
| Date | 2017-02-23 21:36 +0200 |
| Message-ID | <o8ndh9$56d$1@dont-email.me> |
| In reply to | #448904 |
On 23.2.17 01:45, dagmargoodboat@yahoo.com wrote: > > AIUI you can clear nearly all the i2c deadlocks by having the master > cycle the clock 9 times (or by just cycling the power :). > > Cheers, > James Arthur > Except those caused by some station clamping the clock low. -- -TV
[toc] | [prev] | [next] | [standalone]
| From | dagmargoodboat@yahoo.com |
|---|---|
| Date | 2017-02-24 08:38 -0800 |
| Message-ID | <1ebacf3a-9f47-420c-8404-30b148cf1b5d@googlegroups.com> |
| In reply to | #448969 |
On Thursday, February 23, 2017 at 2:37:02 PM UTC-5, Tauno Voipio wrote: > On 23.2.17 01:45, dagmargoodboat@yahoo.com wrote: > > > > AIUI you can clear nearly all the i2c deadlocks by having the master > > cycle the clock 9 times (or by just cycling the power :). > > > > > > Except those caused by some station clamping the clock low. I just designed a one-master system where that's not a danger--slaves can't drive the clock, it's just an input to them. It would certainly be bad if another master clamped your clock low, though. I included a system-wide i2c reset for future cases. It cycles i2c power(!), which should handle even stubborn "clampers." :-0 Cheers, James Arthur
[toc] | [prev] | [next] | [standalone]
| From | krw@notreal.com |
|---|---|
| Date | 2017-02-24 20:20 -0500 |
| Message-ID | <5tm1bcp7tvqgrvjg2m5duh7l2ar50ac0vg@4ax.com> |
| In reply to | #449046 |
On Fri, 24 Feb 2017 08:38:44 -0800 (PST), dagmargoodboat@yahoo.com wrote: >On Thursday, February 23, 2017 at 2:37:02 PM UTC-5, Tauno Voipio wrote: >> On 23.2.17 01:45, dagmargoodboat@yahoo.com wrote: >> > >> > AIUI you can clear nearly all the i2c deadlocks by having the master >> > cycle the clock 9 times (or by just cycling the power :). >> > >> > >> >> Except those caused by some station clamping the clock low. > >I just designed a one-master system where that's not a danger--slaves >can't drive the clock, it's just an input to them. It would certainly >be bad if another master clamped your clock low, though. > >I included a system-wide i2c reset for future cases. It cycles i2c power(!), >which should handle even stubborn "clampers." :-0 How do you just cycle power on just the I2C?
[toc] | [prev] | [next] | [standalone]
| From | kevin93 <kevin@whitedigs.com> |
|---|---|
| Date | 2017-02-24 17:36 -0800 |
| Message-ID | <51fdd37a-08ac-44bc-abae-f10bae604522@googlegroups.com> |
| In reply to | #449104 |
On Friday, February 24, 2017 at 5:20:55 PM UTC-8, k...@notreal.com wrote: ... > >I just designed a one-master system where that's not a danger--slaves > >can't drive the clock, it's just an input to them. It would certainly > >be bad if another master clamped your clock low, though. > > > >I included a system-wide i2c reset for future cases. It cycles i2c power(!), > >which should handle even stubborn "clampers." :-0 > > How do you just cycle power on just the I2C? The more recent SMbus devices are compatible with i2c but include a 25ms timeout to avoid system lockup even when clock-stretching. kevin
[toc] | [prev] | [next] | [standalone]
| From | Ralph Barone <ralph@invalid.com> |
|---|---|
| Date | 2017-02-15 03:25 +0000 |
| Message-ID | <o80hmk$1nvk$1@gioia.aioe.org> |
| In reply to | #447694 |
Reinhardt Behm <rbehm@hushmail.com> 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/ >>> >>> 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. > The weird stuff always happens at the interface between designers that each know their stuff, but don't know the other's stuff.
[toc] | [prev] | [next] | [standalone]
| From | John Larkin <jjlarkin@highlandtechnology.com> |
|---|---|
| Date | 2017-02-14 19:20 -0800 |
| Message-ID | <4rh7ach1ahdd6giq0pv12qdrqfp1q08737@4ax.com> |
| In reply to | #447675 |
On Tue, 14 Feb 2017 15:05:30 -0800 (PST), Lasse Langwadt Christensen
<langwadt@fonz.dk> wrote:
>Den tirsdag den 14. februar 2017 kl. 23.47.11 UTC+1 skrev John Larkin:
>> http://semiengineering.com/devices-threatened-by-analog-content/
>>
>> 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
>
>
We recently designed-out the AD7793; the SPI interface is hopelessly
botched.
There was some other ADI chip, a DAC I recall, that has a bit in one
register that changes which edge of the SPI clock is active! It's not
clear what the powerup state of that bit is.
I had to do this:
----------------------
| |
data----------------- --------------------
---
| |
clock----------------------- ------------------------------
to make sure it would work.
--
John Larkin Highland Technology, Inc
lunatic fringe electronics
[toc] | [prev] | [next] | [standalone]
| From | Tim Wescott <seemywebsite@myfooter.really> |
|---|---|
| Date | 2017-02-14 17:46 -0600 |
| Message-ID | <hcqdnRnLYrVwCz7FnZ2dnUU7-fudnZ2d@giganews.com> |
| In reply to | #447672 |
On Tue, 14 Feb 2017 14:47:00 -0800, John Larkin wrote: > http://semiengineering.com/devices-threatened-by-analog-content/ > > My experience is that we find a lot of bugs and documentation problems > with the digital parts of mixed-signal chips. Yup. It's all Jim's fault. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com I'm looking for work -- see my website!
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | sci.electronics.design
csiph-web