On 07/06/22 10:52, David Brown wrote:> On 06/07/2022 10:27, Stephen Pelc wrote: >> 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. It >> is excellent for master devices, but writing the slave software is >> much more >> complex to cover all cases. >> > > A key problem for I²C is the multi-drop nature of the lines. The edges > themselves are not the big problem, it is the weak pull-up that leaves > the lines very susceptible to noise and interference. SPI has edges, as > do most protocols with a clock signal, but there the master drives high > and low, giving a far more "solid" line. > > I²C can be fine in simple cases, but there are several less-used > features that complicate it, especially when used together. That > includes multi-master, clock stretching, 10-bit addressing, and newer > faster speeds. Good luck trying to make a microcontroller slave that > works with all of that! > > There is also the possibility of bus hang and invalid states. This can > hit you during development - if you stop your microcontroller and > restart it (perhaps with a new program version) in the middle of an I²C > transaction, you can leave the slaves stuck - they may need a reset or > power-cycle to recover.The original Iic from Philips was for consumer equipment and has worked well for that sort of application, but it's not robust enough for professional work imho. I would never use it unless an io device needed it, such early Teletext devices. As you say spi is a far better sorted design... Chris
I2C Communication between two Microcontrollers
Started by ●July 5, 2022
Reply by ●July 7, 20222022-07-07
Reply by ●July 7, 20222022-07-07
On 7/7/2022 19:19, chris wrote:> On 07/06/22 10:52, David Brown wrote: >> On 06/07/2022 10:27, Stephen Pelc wrote: >>> 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. It >>> is excellent for master devices, but writing the slave software is >>> much more >>> complex to cover all cases. >>> >> >> A key problem for I²C is the multi-drop nature of the lines. The edges >> themselves are not the big problem, it is the weak pull-up that leaves >> the lines very susceptible to noise and interference. SPI has edges, as >> do most protocols with a clock signal, but there the master drives high >> and low, giving a far more "solid" line. >> >> I²C can be fine in simple cases, but there are several less-used >> features that complicate it, especially when used together. That >> includes multi-master, clock stretching, 10-bit addressing, and newer >> faster speeds. Good luck trying to make a microcontroller slave that >> works with all of that! >> >> There is also the possibility of bus hang and invalid states. This can >> hit you during development - if you stop your microcontroller and >> restart it (perhaps with a new program version) in the middle of an I²C >> transaction, you can leave the slaves stuck - they may need a reset or >> power-cycle to recover. > > The original Iic from Philips was for consumer equipment and has > worked well for that sort of application, but it's not robust enough > for professional work imho. I would never use it unless an io > device needed it, such early Teletext devices. As you say spi > is a far better sorted design... > > ChrisI basically agree but things are not that bad as long as one does not push things too far. For me the worst part has been dealing with in-built I2C controllers, used two and both worked but each took me *days* to defeat - unlike the first time I used I2C some decades ago, bitbanging it from a HC11, which took me only an hour or two. Never used an MCU as an I2C slave yet, may do so soon but who knows. The peripherals I have used - some eeprom, RTC, ADC and perhaps some I can't think of now have all behaved; of course one has to deal with hanged bus situations, I have not seen a part which needs repower to get fixed (must have been lucky I guess). I have managed to upset the bus, being open drain, routing it too close to a flyback convertor switch, the latter doing 100V excursions "pretty fast" (tens of ns for the 100V I think). Changing the pullups on the I2c from 2k to 1k fixed that (still not that much of "too close", some luck again :). ====================================================== Dimiter Popoff, TGI http://www.tgi-sci.com ====================================================== http://www.flickr.com/photos/didi_tgi/
Reply by ●July 8, 20222022-07-08
On 7/7/22 12:49 PM, Dimiter_Popoff wrote:> On 7/7/2022 19:19, chris wrote: >> On 07/06/22 10:52, David Brown wrote: >>> On 06/07/2022 10:27, Stephen Pelc wrote: >>>> 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. It >>>> is excellent for master devices, but writing the slave software is >>>> much more >>>> complex to cover all cases. >>>> >>> >>> A key problem for I²C is the multi-drop nature of the lines. The edges >>> themselves are not the big problem, it is the weak pull-up that leaves >>> the lines very susceptible to noise and interference. SPI has edges, as >>> do most protocols with a clock signal, but there the master drives high >>> and low, giving a far more "solid" line. >>> >>> I²C can be fine in simple cases, but there are several less-used >>> features that complicate it, especially when used together. That >>> includes multi-master, clock stretching, 10-bit addressing, and newer >>> faster speeds. Good luck trying to make a microcontroller slave that >>> works with all of that! >>> >>> There is also the possibility of bus hang and invalid states. This can >>> hit you during development - if you stop your microcontroller and >>> restart it (perhaps with a new program version) in the middle of an I²C >>> transaction, you can leave the slaves stuck - they may need a reset or >>> power-cycle to recover. >> >> The original Iic from Philips was for consumer equipment and has >> worked well for that sort of application, but it's not robust enough >> for professional work imho. I would never use it unless an io >> device needed it, such early Teletext devices. As you say spi >> is a far better sorted design... >> >> Chris > > I basically agree but things are not that bad as long as one > does not push things too far. For me the worst part has been dealing > with in-built I2C controllers, used two and both worked but each > took me *days* to defeat - unlike the first time I used I2C > some decades ago, bitbanging it from a HC11, which took me > only an hour or two. Never used an MCU as an I2C slave yet, may > do so soon but who knows. > The peripherals I have used - some eeprom, RTC, ADC and perhaps > some I can't think of now have all behaved; of course one has to > deal with hanged bus situations, I have not seen a part which > needs repower to get fixed (must have been lucky I guess). > I have managed to upset the bus, being open drain, routing it > too close to a flyback convertor switch, the latter doing 100V > excursions "pretty fast" (tens of ns for the 100V I think). > Changing the pullups on the I2c from 2k to 1k fixed that > (still not that much of "too close", some luck again :). > > ====================================================== > Dimiter Popoff, TGI http://www.tgi-sci.com > ====================================================== > http://www.flickr.com/photos/didi_tgi/My experience is that to handle a "stuck" I2C bus, sometimes you need to be able to turn "off" the I2C controller and manually "bit-bang" up to (generally) 8 I2C clock pulses, until the slave that is stuck lets go of the I2C Data line, then you can force a START-STOP code (by pulling the data line low then high with the clock high) to get the bus into a usable state. If that doesn't work, then you have a non-conforming device. I do remember one time working with a slave that if you addressed it too soon after power up, it would go into clock streach mode (pulling down the clock) but never leave that mode. For that case the only option was to power down that device, and then power it back up and wait long enough.
Reply by ●August 5, 20222022-08-05
On 08/07/2022 04:22, Richard Damon wrote:> On 7/7/22 12:49 PM, Dimiter_Popoff wrote: >> On 7/7/2022 19:19, chris wrote: >>> On 07/06/22 10:52, David Brown wrote: >>>> On 06/07/2022 10:27, Stephen Pelc wrote: >>>>> 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. It >>>>> is excellent for master devices, but writing the slave software is >>>>> much more >>>>> complex to cover all cases. >>>>> >>>> >>>> A key problem for I²C is the multi-drop nature of the lines. The edges >>>> themselves are not the big problem, it is the weak pull-up that leaves >>>> the lines very susceptible to noise and interference. SPI has edges, as >>>> do most protocols with a clock signal, but there the master drives high >>>> and low, giving a far more "solid" line. >>>> >>>> I²C can be fine in simple cases, but there are several less-used >>>> features that complicate it, especially when used together. That >>>> includes multi-master, clock stretching, 10-bit addressing, and newer >>>> faster speeds. Good luck trying to make a microcontroller slave that >>>> works with all of that! >>>> >>>> There is also the possibility of bus hang and invalid states. This can >>>> hit you during development - if you stop your microcontroller and >>>> restart it (perhaps with a new program version) in the middle of an I²C >>>> transaction, you can leave the slaves stuck - they may need a reset or >>>> power-cycle to recover. >>> >>> The original Iic from Philips was for consumer equipment and has >>> worked well for that sort of application, but it's not robust enough >>> for professional work imho. I would never use it unless an io >>> device needed it, such early Teletext devices. As you say spi >>> is a far better sorted design... >>> >>> Chris >> >> I basically agree but things are not that bad as long as one >> does not push things too far. For me the worst part has been dealing >> with in-built I2C controllers, used two and both worked but each >> took me *days* to defeat - unlike the first time I used I2C >> some decades ago, bitbanging it from a HC11, which took me >> only an hour or two. Never used an MCU as an I2C slave yet, may >> do so soon but who knows. >> The peripherals I have used - some eeprom, RTC, ADC and perhaps >> some I can't think of now have all behaved; of course one has to >> deal with hanged bus situations, I have not seen a part which >> needs repower to get fixed (must have been lucky I guess). >> I have managed to upset the bus, being open drain, routing it >> too close to a flyback convertor switch, the latter doing 100V >> excursions "pretty fast" (tens of ns for the 100V I think). >> Changing the pullups on the I2c from 2k to 1k fixed that >> (still not that much of "too close", some luck again :). >> >> ====================================================== >> Dimiter Popoff, TGI http://www.tgi-sci.com >> ====================================================== >> http://www.flickr.com/photos/didi_tgi/ > > My experience is that to handle a "stuck" I2C bus, sometimes you need to > be able to turn "off" the I2C controller and manually "bit-bang" up to > (generally) 8 I2C clock pulses, until the slave that is stuck lets go of > the I2C Data line, then you can force a START-STOP code (by pulling the > data line low then high with the clock high) to get the bus into a > usable state.Isn't that why SMBus was invented? -- Mike Perkins Video Solutions Ltd www.videosolutions.ltd.uk
Reply by ●August 5, 20222022-08-05
On 8/5/22 5:07 PM, Mike Perkins wrote:> On 08/07/2022 04:22, Richard Damon wrote: >> >> My experience is that to handle a "stuck" I2C bus, sometimes you need >> to be able to turn "off" the I2C controller and manually "bit-bang" up >> to (generally) 8 I2C clock pulses, until the slave that is stuck lets >> go of the I2C Data line, then you can force a START-STOP code (by >> pulling the data line low then high with the clock high) to get the >> bus into a usable state. > Isn't that why SMBus was invented? >That handles it, but only if ALL your devices support it. The "Stuck Device" might be a device that doesn't support SMB bus, and might not normally need to, because it is just a simple slave that never clock streaches, so shouldn't be able to have a problem on a working bus. The issue can happen if the controller get aborted mid-read-transfer, so the slave is driving the data bus (low) so a master can't assert a Start or Stop to reset the devices.
