Bit-banging I2C

He's on the master, so he and the software guy need to basically make sure* that the line is clear before writing. Collisions can latch

*a response receive timeout needs to be longer than a word by some safety factor to be named later.

Or just switch the output to an input for a short while.

You'll want IO pins that you can use as open collector, preferrably with an integrated pull up. Schmitt triggered inputs are also a good idea. If your uC can do that, it should work well.

Oh, that's totally different. So your concern is how much work it will be for someone else who will have to drive it from an unknown MCU?

I wonder if you could do the whole thing in software without a separate chip. Use analog uC pins to monitor the battery voltage and current, and integrate as you go along.

For I2C there are only minimum times specified, so interrupts don't impact on the protocol. One issue I have had is RMW on devices that do not have in dividually addressable output latches. A write or read-write in an interrup t can modify the the 'lo' written to the output latch to a 'hi' which ruins the I2C operation. Can be hard to find.

But how is that a problem for I2C? To make a pin high, you make it input, and then you can read its (external) value/level.

Wouter van Ooijen

If you can't make the pins open connector on the microcontroller, you can do it with a diode and an external pull-up resistor per pin.

And if it is a simple slave that doesn't do clock stretching, you can do fine with a pin that you change modes between push-pull and input, along with a pull-up (external or internal). A typical microcontroller GPIO has an IN, an OUT, and a DIR bit per pin. Instead of thinking of the pin as an output and controlling the OUT bit, keep the OUT bit at 0 and control the DIR bit - set to 1 to drive a 0 on the bus, and set to 0 to let the bus be pulled high.

Schmitt triggers are always nice, but are unlikely to be needed on a short local bus.

Internal pullups /might/ be good enough, but they are often too high

mix it with interrupts or other low-jitter events. One-wire has its

that you can get a bus-hang if the protocol is interrupted, where a slave has been selected but the transaction is not complete and you can't finish it properly. Typically this happens if you get an unexpected reset in the middle of a transaction - I have seen it a few times during development when I stop the debugger, re-start, and find

slaves, attach it! (Many slave devices are so low power that you could use an MCU GPIO pin as the power line to the slaves, giving an easy reset.)

I think I did as a student but it's been a while and it was a very small part actually in an electronics lab course. It may be some code was given as help though so didn't have to do it from scratch. The specific assignment was to read a temperature sensor and display the value on an LCD.

A colleague of mine did this a year or two ago, due to a HW bug on a board where clock and data lines were switched. The CPU's I2C hardware wasn't flexible enough to handle that so he configured the pins as GPIOs and banged away. It didn't take him more than a day as I recall.

Somewhat amusingly, I think the CPU was a HC12 both of these times, just about 20 years apart...

I've bit-banged it in C and assembler, master and slave, on 8051 at the low end to PPC at the high end. (I've also done it in FPGA, but that's not relevant here.)

It's fairly straightforward and easy to get right if you follow the spec. to the letter.

Things to look out for:

- do you need PMB, SMB or just I2C? SMB(/PMB) has some timeouts that I2C doesn't have (I2C can go to DC; SMB can't), resulting in a different state machine in the controller. You mentioned a battery gauge, which might imply PMB.

- do you have a single master, or are there multiple masters on the same bus?

- If multi-master, does the master need to include slave functionality (so the other master can talk to it)?

- do you need clock stretching on SCL?

- do you need "standard", "fast", "fast+" or "high" speed mode? This has implications for the pullups and the types of I/O that you can use (e.g. HS mode has a switchable current source pullup rather than a resistor on SCL). I'm guessing "standard" mode will be fine.

- I2C uses input glitch filters. Your microcontroller GPIOs won't have these, but it probably won't matter as the software sampling will be relatively slow (if you think you've seen an input transition, read it again to make sure it's in the state you think it's in). Be careful if using edge triggered interrupts though. I2C isn't terminated, and the SI is often bad if there are many slaves (with reflections causing multiple transitions).

Things in your favour:

You already know how to use a 'scope or logic analyser. You'll need to use one to verify the various delays. During development it's helpful to use a spare GPIO or two to indicate timings or states that can't be observed from probing SDA and SCL.

I2C is reasonably well defined. You can almost write code just from looking at the specification. It's best to ignore any online guides you may find and just stick to the spec.

BTW, SMB is defined by Intel.

Regards, Allan

Yes, that would usually work (assuming the pin is bidirectional).

In my experience, the integrated pullups are usually too weak for decent data rates.

Am 17.03.2016 um 08:40 schrieb Wouter van Ooijen:

That might well depend on the previous output value still being present after the port has been switched from output to input and back to output, or a write to a PDR while it's configured for input making any difference. I don't remember having seen either assertion in datasheets.

There are many app notes from reputable sources on bit-banging I2C. Just Google "app note bit bang i2c". You will find Microchip, ST, Maxim and Intel just to name a few.

One comment (as a cautionary note) from an NXP data sheet "Any processor can ?bit bang? the I2C-bus using 2 bits of GPIO, one for the data and one for the clock, if it is the only master on the bus and needs to send only simple commands. The PCF8584 or PCA9564 is required when full multiple master compliance with the I2C specification is required."

--------------------------------------- Posted through

Theoretically, yes.

Yes, more or less.

Their complaint is having to stop the world to do a data transfer. Given what they're doing it's exceedingly inconvenient.

You might want to check the nxp SPI-to-I2C bridges. would get around the timing issues.

CHeers

A teacher in high school would never let us answer that way. "Which is it, more or less?"