I2C Single Master: peripheral or bit banging?

Jitter should not be a problem, but I have known slave devices go to sleep after a few ms of inactivity on the bus.

I've seen many bit banged attempts using processor loops for delays. Then something changes (compiler upgrade, faster clock, whatever) and then it all goes wrong.

MK

Reply to
Michael Kellett
Loading thread data ...

Yes, but it's not simple. As described in AN686, I2C EEPROMs doesn't have a reset, so it's impossible for the MCU to reset the EEPROM at startup. The only solution is to introduce dedicated hw to remove and reapply power supply.

This is the main reason I now prefer to use SPI EEPROM (when possible), because slave-select signal of the SPI bus restart automatically the transaction.

Reply to
pozz

I too prefer SPI - it is often simpler and can be much faster.

However, if it is possible for your power supply to glitch and reset the MCU, without being turned off properly (and therefore reseting your eeprom), you have a definite hardware problem on the board. (Of course, boards vary in how much effort and money you are willing to spend to get stability, and how unstable a supply you might have.)

Reply to
David Brown

I hit "send" before I included a final point - the "dedicated hardware to remove the power supply to the eeprom" is usually just a GPIO pin from the microcontroller. Often a GPIO pin can easily supply the current needed for a low power device like an eeprom, so that you don't need anything else.

Reply to
David Brown

One thing to note about the I2C bus protocol, is that a High to Low transition of the SDA line when SCL is high (a Start Bit) is supposed to 'Reset' the communication channel of every device on the bus and put it in the mode to compare the next 8 bits as a Device Address.

Thus, if at the 'random' reset, no device is driving the SDA line high, then as soon as the master starts a new cycle, everything is back in sync.

It is possible, that a device is either doing an ACK or a Read Cycle at the point of reset, holding SDA low. The master just needs to cycle SCL until SDA goes high by completing that ack or read cycle. The Read might need up to 8 clocks. One we have SDA and SCL high, we can generate the Start to get everyone listening.

Devices should not be holding SCL low for extended periods, so that shouldn't be a problem (or is a problem of a different nature if you do have an oddball infinite bus extender).

Reply to
Richard Damon

Also a sequence of >= 10 clock pulses is supposed to get devices into normal function.

Unfortunately not all devices have read this spec.

I had one (LM75) which could be driven reproducible into a non-responding mode by a short glitch on data or clock. The only way to recover was a power cycle.

Reply to
Reinhardt Behm

I don't have much experience in these micros, mainly ST ARM devices. But single master applications can be very reliable, as long as you check all the status bits. Some examples only look for patterns that could leave a hanging peripheral.

This is where I diverge. I would not choose to use I2C in a multi-master system.

I2C was always intended to be used on a single PCB, without long wires attracting EM noise.

Not all manufacturers say this. The trick is to detect an error condition, clear the error and if necessary reset the peripheral.

Nothing wrong with bit-banging.

There is no drawback, apart from difficult to debug and a high MCU utilisation. At least I2C is meant to be static, unlike SMB.

--
Mike Perkins 
Video Solutions Ltd 
 Click to see the full signature
Reply to
Mike Perkins

Il 25/11/2020 18:43, Mike Perkins ha scritto: > On 20/11/2020 08:43:32, pozz wrote: >> I hate I2C for several reasons. It's only two-wires bus, but for this >> reason it is insidious. >> >> I usually use hw peripherals when they are available, because it's >> much more efficient and smart and because it's the only possibility in >> many cases. >> Actually we have MCUs with abundant UARTs, timers and so on, so >> there's no real story: choose a suitable MCU and use that damn >> peripheral. >> So I usually start using I2C peripherals available in MCUs, but I >> found many issues. >> >> I have experience with AVR8 and SAMC21 by Atmel/Microchip. In both >> cases the I2C peripheral is much more complex than UART or similar >> serial lines. I2C Single Master, that is the most frequent situation, >> is very simple, > > I don't have much experience in these micros, mainly ST ARM devices. But > single master applications can be very reliable, as long as you check > all the status bits. Some examples only look for patterns that could > leave a hanging peripheral. > >> but I2C Multi Master introduces many critical situations. >> I2C peripherals usually promise to be compatible with multi-master, so >> their internal state machine is somewhat complex... and often there's >> some bug or situations that aren't expected that leave the code stucks >> at some point. > > This is where I diverge. I would not choose to use I2C in a multi-master > system. Me too. It was only to just say the peripheral inside new MCUs are compatible with I2C Multi-Master, so they are complex state-machine (see arbitration lost).

Reply to
pozz

Are you certain that the main event interrupt isn't being called repeatedly? Because not all the conditions that cause the interrupt have been serviced?

I'm more familiar with the ST ARM range and generally haven't seen a hang condition that can't be assessed by looking at the status registers. I obviously accept that other MCUs may behave differently.

I'm currently using FreeRTOS, and with a transmission complete semaphore, so implementing a short timeout becomes an easy matter. Also useful for repeating the I2C transmission in a failed NAK case.

--
Mike Perkins 
Video Solutions Ltd 
 Click to see the full signature
Reply to
Mike Perkins

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.