Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #31146
| From | pozz <pozzugno@gmail.com> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: I2C Communication between two Microcontrollers |
| Date | 2022-07-06 11:20 +0200 |
| Organization | A noiseless patient Spider |
| Message-ID | <ta3k53$dh4$1@dont-email.me> (permalink) |
| References | <9f2f7fd6-24ee-4eb5-8c3d-4b3db5b296bcn@googlegroups.com> <ta3b8u$3vja9$1@dont-email.me> <ta3evo$3vtt1$1@dont-email.me> <ta3h2e$47a$1@dont-email.me> |
Il 06/07/2022 10:27, Stephen Pelc ha scritto: > On 6 Jul 2022 at 09:52:23 CEST, "pozz" <pozzugno@gmail.com> wrote: > >> I found that I2C peripherals embedded in most of MCUs are very complex >> and most of the time they aren't reliable. >> After some testing, I usually decide to write a bit-banging I2C code. > > I have to agree here. I2C is conceptually simple, bu it is an edge triggered > protocol and is very sensitive to noise unless you use buffer devices. Sorry for my stupid question, what do you mean with buffer devices? When you have master and slave on the same board, you put a wire between SDA/SCL pins and a couple of pull-up resistors. > It > is excellent for master devices, but writing the slave software is much more > complex to cover all cases. > > A client of ours carefully wrote hardware drivers for their CPUs and put > them on test. They saw one failure every hour or so. They then reverted > to the bit-bang drivers supplied by us with the compiler. No failures in two > weeks. Same for me. I2C hardware peripherals don't add any pro against a bit-bang solution (I'm talking always for masters), at least if you write blocking code that waits for the end of I2C transaction. > I have looked at these problems every few years or so, and the problem > for hardware drivers has always been fast noise pulses on the I2C lines. > By fast I mean up to several 10s of nanoseconds at a volt or so. Yes, I think one solution is to reset and reconfigure the peripheral (if possible) when the software detects some problems. > On the other hand we once did a hospital autoclave for which all I/O was > over I2C and it was rock solid ... but we used the recommended buffer > chips everywhere. Again, what are buffer chips?
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
I2C Communication between two Microcontrollers Neelakantappa M <neelakantamaagi253@gmail.com> - 2022-07-05 06:28 -0700
Re: I2C Communication between two Microcontrollers pozz <pozzugno@gmail.com> - 2022-07-05 16:22 +0200
Re: I2C Communication between two Microcontrollers Richard Damon <Richard@Damon-Family.org> - 2022-07-05 22:33 -0400
Re: I2C Communication between two Microcontrollers David Brown <david.brown@hesbynett.no> - 2022-07-06 08:49 +0200
Re: I2C Communication between two Microcontrollers pozz <pozzugno@gmail.com> - 2022-07-06 09:52 +0200
Re: I2C Communication between two Microcontrollers Stephen Pelc <stephen@vfxforth.com> - 2022-07-06 08:27 +0000
Re: I2C Communication between two Microcontrollers pozz <pozzugno@gmail.com> - 2022-07-06 11:20 +0200
Re: I2C Communication between two Microcontrollers Stef <me@this.is.invalid> - 2022-07-06 13:43 +0200
Re: I2C Communication between two Microcontrollers Stephen Pelc <stephen@vfxforth.com> - 2022-07-06 15:49 +0000
Re: I2C Communication between two Microcontrollers David Brown <david.brown@hesbynett.no> - 2022-07-06 11:52 +0200
Re: I2C Communication between two Microcontrollers chris <chris-nospam@tridac.net> - 2022-07-07 17:19 +0100
Re: I2C Communication between two Microcontrollers Dimiter_Popoff <dp@tgi-sci.com> - 2022-07-07 19:49 +0300
Re: I2C Communication between two Microcontrollers Richard Damon <Richard@Damon-Family.org> - 2022-07-07 23:22 -0400
Re: I2C Communication between two Microcontrollers Mike Perkins <spam@spam.com> - 2022-08-05 22:07 +0100
Re: I2C Communication between two Microcontrollers Richard Damon <Richard@Damon-Family.org> - 2022-08-05 21:10 -0400
csiph-web