Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #30109
| From | Tauno Voipio <tauno.voipio@notused.fi.invalid> |
|---|---|
| Newsgroups | comp.arch.embedded |
| Subject | Re: I2C Single Master: peripheral or bit banging? |
| Date | 2020-11-20 19:39 +0200 |
| Organization | A noiseless patient Spider |
| Message-ID | <rp8uvt$mbe$1@dont-email.me> (permalink) |
| References | <rp7vjk$edg$1@dont-email.me> <%dPtH.19234$2j.7316@fx38.iad> <rp8j1c$k9g$1@dont-email.me> <rp8n5k$k5f$1@dont-email.me> <rp8r4d$lns$1@dont-email.me> |
On 20.11.20 18.33, pozz wrote: > Il 20/11/2020 16:25, Tauno Voipio ha scritto: > > On 20.11.20 16.15, pozz wrote: > >> Il 20/11/2020 14:09, Richard Damon ha scritto: > >> > I think the issue is by what you did when the controller started the > >> > cycle and issued a start bit to 'get' the bus, it sees that > 'someone' > >> > else did the same thing but got farther. > >> > > >> > A Start bit is done by, with SCL and SDA both high, first pull SDA > >> low, > >> > and then SCL low a bit later. When the controller pulls SDA low, it > >> then > >> > looks and sees SCL already low, so it decides that someone else > >> beat it > >> > to the punch of getting the bus, so it backs off and waits. I > suspect > >> > that at that point it releases the bus, SDA and SCL both go high at > >> the > >> > same time (which is a protocol violation) and maybe the controller > >> sees > >> > that as a stop bit and the bus now free, so it tries again, or it > just > >> > thinks the bus is still busy. > >> No, SCL and SDA stay low forever. Maybe it drives low SDA, than SCL, > >> than releases one of SCL or SDA, failing in that. > >> > >> > >> > This is NOT the I2C 'Arbitration Lost' condition, as that > pertains to > >> > the case where you think you won the arbitration, but at the same > time > >> > somoeone else also thought they won it, and while sending a bit, you > >> > find that your 1 bit became a 0 bit, so you realize (late) that you > >> had > >> > lost the arbitarion, and thus need to abort your cycle and resubmit > >> it. > >> Ok, call it bus error, I2C violation, I don't know. The peripheral is > >> full of low-level timeouts and flags signaling that some strange > >> happened. > >> But shorting SDA and SCL will not set any of this bit. > >> > >> > >> > This is a case of arbitration never won, and most devices will > require > >> > something external to the peripheral to supply any needed timeout > >> mechanism. > >> At least the peripheral should be able to report the strange bus > >> state, but it STATUS.BUSTATE is always IDLE. > >> > >> > >> > Most bit-banged master code I have seen, assumes single-master, > as it > >> > can't reliably test for this sort of arbitration lost condition, > >> being a > >> > bit to slow. > >> Of course, take a look at the subject of my post. > > > > > > If you connect SCL and SDA together, you'll create a permanent > > protocol violation. The whole I2C relies on both being separate > > and open-collector/drain. Creating an unexpected short creates > > a hardware failure. If ouy're afraid of such a situation, you should > > test for it bit-banging before initializing the hardware controller. > I know that and I don't expect it works in this situation, but my point > is another. > > If a I2C hw peripheral could hang for some reason (in my test I > volunteerly made the short, but I imagine the hang could happen in other > circumstances that is not well declared in the datasheet), you should > protect the driver code with a timeout. > You have to test your code in all cases, even when the timeout occurs. > So you have to choose the timeout interval with great care, you have to > understand if the blocking for so long is acceptable (even in that rare > situation). > > Considering all of that, maybe bit-banging is much more simple and > reliable. I have had thousands of industrial instruments in the field for decades, each running some internal units with I2C, some bit-banged and others on the hardware interfaces on the processors used, and not a single failure due to I2C hanging. Please remember that the I2C bus is an Inter-IC bus, not to be used for connections to the outside of the device, preferably only on the same circuit board. There should be no external connectors where e.g. the shorts between the SCL and SDA could happen. All the hardWare I2C controls have been able to be restored to a sensible state with a software reset after a time-out. This includes the Atmel chips. -- -TV
Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
I2C Single Master: peripheral or bit banging? pozz <pozzugno@gmail.com> - 2020-11-20 09:43 +0100
Re: I2C Single Master: peripheral or bit banging? Bernd Linsel <bl1@gmx.com> - 2020-11-20 11:38 +0100
Re: I2C Single Master: peripheral or bit banging? pozz <pozzugno@gmail.com> - 2020-11-20 12:45 +0100
Re: I2C Single Master: peripheral or bit banging? Bernd Linsel <bl1@gmx.com> - 2020-11-20 15:57 +0100
Re: I2C Single Master: peripheral or bit banging? Richard Damon <Richard@Damon-Family.org> - 2020-11-20 08:09 -0500
Re: I2C Single Master: peripheral or bit banging? pozz <pozzugno@gmail.com> - 2020-11-20 15:15 +0100
Re: I2C Single Master: peripheral or bit banging? Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2020-11-20 17:25 +0200
Re: I2C Single Master: peripheral or bit banging? pozz <pozzugno@gmail.com> - 2020-11-20 17:33 +0100
Re: I2C Single Master: peripheral or bit banging? Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2020-11-20 19:39 +0200
Re: I2C Single Master: peripheral or bit banging? Dimiter_Popoff <dp@tgi-sci.com> - 2020-11-20 23:25 +0200
Re: I2C Single Master: peripheral or bit banging? Grant Edwards <invalid@invalid.invalid> - 2020-11-20 23:09 +0000
Re: I2C Single Master: peripheral or bit banging? Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2020-11-21 11:46 +0200
Re: I2C Single Master: peripheral or bit banging? David Brown <david.brown@hesbynett.no> - 2020-11-21 12:06 +0100
Re: I2C Single Master: peripheral or bit banging? pozz <pozzugno@gmail.com> - 2020-11-22 17:48 +0100
Re: I2C Single Master: peripheral or bit banging? David Brown <david.brown@hesbynett.no> - 2020-11-22 19:44 +0100
Re: I2C Single Master: peripheral or bit banging? pozz <pozzugno@gmail.com> - 2020-11-23 08:44 +0100
Re: I2C Single Master: peripheral or bit banging? David Brown <david.brown@hesbynett.no> - 2020-11-23 09:42 +0100
Re: I2C Single Master: peripheral or bit banging? David Brown <david.brown@hesbynett.no> - 2020-11-23 09:44 +0100
Re: I2C Single Master: peripheral or bit banging? Richard Damon <Richard@Damon-Family.org> - 2020-11-23 07:25 -0500
Re: I2C Single Master: peripheral or bit banging? Reinhardt Behm <rbehm@hushmail.com> - 2020-11-24 18:15 +0800
Re: I2C Single Master: peripheral or bit banging? stephen@mpeforth.com (Stephen Pelc) - 2020-11-20 14:53 +0000
Re: I2C Single Master: peripheral or bit banging? John Speth <johnspeth@yahoo.com> - 2020-11-20 06:56 -0800
Re: I2C Single Master: peripheral or bit banging? Michael Kellett <mk@mkesc.co.uk> - 2020-11-21 09:10 +0000
Re: I2C Single Master: peripheral or bit banging? Tauno Voipio <tauno.voipio@notused.fi.invalid> - 2020-11-21 11:48 +0200
Re: I2C Single Master: peripheral or bit banging? pozz <pozzugno@gmail.com> - 2020-11-22 17:35 +0100
Re: I2C Single Master: peripheral or bit banging? Michael Kellett <mk@mkesc.co.uk> - 2020-11-22 20:21 +0000
Re: I2C Single Master: peripheral or bit banging? Mike Perkins <spam@spam.com> - 2020-11-25 17:43 +0000
Re: I2C Single Master: peripheral or bit banging? pozz <pozzugno@gmail.com> - 2020-11-26 08:54 +0100
Re: I2C Single Master: peripheral or bit banging? Mike Perkins <spam@spam.com> - 2020-11-26 14:34 +0000
csiph-web