Bit-banging I2C

On Wed, 16 Mar 2016 13:49:00 -0500, Tim Wescott wrote:

> Has anyone successfully bit-banged an I2C interface?  Any comments on
> it's ease or difficulty?
> 
> I've used I2C with processors that have built-in hardware, I've sat next
> to a guy who's bit-banged it, but I've never bit-banged it myself.
> 
> I ask as a circuit designer who's going to design in an I2C chip to be
> presented to a software engineer with a smile and a "here, this ought to
> be easy!"  I want to know whether I'll be honest or not.


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.

http://www.nxp.com/documents/user_manual/UM10204.pdf

BTW, SMB is defined by Intel.

Regards,
Allan

On 2016-03-17, Wouter van Ooijen <wouter@voti.nl> wrote:
> Op 17-Mar-16 om 1:04 AM schreef Hans-Bernhard Br&ouml;ker:
>> Am 17.03.2016 um 00:04 schrieb Wouter van Ooijen:
>>> Op 16-Mar-16 om 9:11 PM schreef Grant Edwards:
>>
>>>> Just make sure the I2C clock/data are connected to MCU pins that can
>>>> be configured as open-collector (or open-drain), that there is a
>>>> footprint for an external pull-up resistor on each, and that the
>>>> software can read the electrical level (0/1) for each those signals.
>> [...]
>>>> On _some_ MCUs that means the clock and data signals each have to be
>>>> connected to both an open-collector output pin and to an input pin.
>>
>>> For my curiosity, could you specify a uC for which that is true? I
>>> haven't seen one yet.
>>
>> Interesting.  I originally saw only ones like that.
>>
>> Basically, if your MCU has pairs of "port data registers" (PDR) and
>> "data direction registers" (DDR), odds are that a PDR is (or used to be,
>> in its original versions) a single register which on Read delivers
>> either the port's designated output vale, or the actual input, depending
>> on whether the DDR configure the port as an output or input.
>
> 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.

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

-- 
Grant Edwards               grant.b.edwards        Yow! But was he mature
                                  at               enough last night at the
                              gmail.com            lesbian masquerade?

On 2016-03-17, Johann Klammer <klammerj@NOSPAM.a1.net> wrote:
> On 03/16/2016 09:09 PM, Tim Wescott wrote:
>> 
>> I failed to mention: I'm hoping that the circuit design part of it will 
>> just be attaching a couple of free microprocessor pins to pins on the 
>> slave device.

> 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. 

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

-- 
Grant Edwards               grant.b.edwards        Yow! Are we live or on
                                  at               tape?
                              gmail.com            

Am 17.03.2016 um 08:40 schrieb Wouter van Ooijen:
> Op 17-Mar-16 om 1:04 AM schreef Hans-Bernhard Br�ker:

>> Basically, if your MCU has pairs of "port data registers" (PDR) and
>> "data direction registers" (DDR), odds are that a PDR is (or used to be,
>> in its original versions) a single register which on Read delivers
>> either the port's designated output vale, or the actual input, depending
>> on whether the DDR configure the port as an output or input.
>
> 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.

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.


>Master is what I'm looking at.  Just need an MCU to talk to a slave 
>device.
>

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 http://www.EmbeddedRelated.com

On Thu, 17 Mar 2016 08:52:32 +0100, David Brown wrote:

> On 17/03/16 03:46, rickman wrote:
>> On 3/16/2016 7:47 PM, Tim Wescott wrote:
>>> On Wed, 16 Mar 2016 19:12:28 -0400, rickman wrote:
>>>>
>>>> lol
>>>
>>> It _is_ a laugh, but when I'm in a larger team it can also be useful. 
>>> "I know this is possible to do, can you please figure it out" may get
>>> no traction at all with someone where a "lookee, this here (Verilog,
>>> circuit, C++ object, hunk of metal, etc.) does just what we need, and
>>> ain't it purdy?" will get an instant response.
>>>
>>> One does have to tread a fine line sometimes -- I'm generally looking
>>> for "oh my lord, please let me do that!" rather than "oh, that looks
>>> great! let's run with it!"  I will admit that people who know me do
>>> learn that a seemingly innocuous offer to step outside of my specialty
>>> and help them with theirs is a threat, not a joke.
>> 
>> It's late and I'm not able to translate all that.  But if you are
>> looking for any advice or help, I'm happy to offer both.
>> 
>> 
> It's early here, and I can't figure out what he is saying either.  Tim
> usually makes a lot of sense in his posts, but I think this is one of
> those times where tone of voice is needed.  Maybe it will be clearer
> after a coffee or two.  In the meantime, I'll go back to the technical
> help.

In some areas I'm an expert.  In other areas, I'm just competent enough 
to show that something is possible.  Generally my demonstrations in those 
areas are technically competent enough to show that yes, it is possible, 
yet still scary enough to galvanize the _real_ experts.

And sometimes, I milk that.

-- 
www.wescottdesign.com

On Wed, 16 Mar 2016 20:18:28 -0700, Paul Rubin wrote:

> Tim Wescott <seemywebsite@myfooter.really> writes:
>> I'm looking for a suitable analog chip (battery gas gauge) to drop on a
>> board.  By far and away it seems that I2C is the preferred interface
>> out there in the market.
> 
> 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.

Theoretically, yes.

-- 
www.wescottdesign.com

On Wed, 16 Mar 2016 22:51:37 -0400, rickman wrote:

> On 3/16/2016 7:51 PM, Tim Wescott wrote:
>> On Wed, 16 Mar 2016 19:11:12 -0400, rickman wrote:
>>
>>> On 3/16/2016 4:10 PM, Tim Wescott wrote:
>>>> On Wed, 16 Mar 2016 16:08:06 -0400, rickman wrote:
>>>>
>>>>> On 3/16/2016 4:04 PM, Tim Wescott wrote:
>>>>>>
>>>>>> Mostly I want to make sure I'm not painting the guy into a corner.
>>>>>
>>>>> Why not SPI?  I can't recall people having much trouble with SPI on
>>>>> a dumb device.  At least not if it is design ok.  I mean the
>>>>> interface is pretty durn simple.
>>>>
>>>> At the moment I haven't found a suitable chip with an SPI interface.
>>>> If there is one, I may choose it.
>>>
>>> I'm confused now.  I thought you were building the interface into the
>>> analog chip you were designing.  Are you saying you can't find a
>>> suitable MCU with SPI?  Or are you saying you are using an I2C
>>> interface slave chip and using the I/Os to control your chip?
>>
>> I'm looking for a suitable analog chip (battery gas gauge) to drop on a
>> board.  By far and away it seems that I2C is the preferred interface
>> out there in the market.
> 
> 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?

Yes, more or less.



-- 
www.wescottdesign.com

On Thu, 17 Mar 2016 07:06:27 +1100, Clifford Heath wrote:

> On 17/03/16 05:49, Tim Wescott wrote:
>> Has anyone successfully bit-banged an I2C interface?  Any comments on
>> it's ease or difficulty?
>>
>> I've used I2C with processors that have built-in hardware, I've sat
>> next to a guy who's bit-banged it, but I've never bit-banged it myself.
>>
>> I ask as a circuit designer who's going to design in an I2C chip to be
>> presented to a software engineer with a smile and a "here, this ought
>> to be easy!"  I want to know whether I'll be honest or not.
> 
> Not I2C, but I've bitbanged One-Wire, including enumeration (though not
> high-speed), in an MSP430. I assume this relates to your battery gauge
> question? If so, I'd think One-Wire was preferable - only one pin to
> diddle.
> 
> However, to get bit timings right, the important question is whether you
> can afford to stop the world while doing a data transfer. Trying to
> interrupt for each bit transition might be too hard. I guess you
> wouldn't need to read the gas gauge very often - perhaps you can pick a
> time when you can lock out all other interrupts?

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

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

On Thu, 17 Mar 2016 15:08:36 -0500, Tim Wescott
<seemywebsite@myfooter.really> wrote:

>On Thu, 17 Mar 2016 07:06:27 +1100, Clifford Heath wrote:
>
>> On 17/03/16 05:49, Tim Wescott wrote:
>>> Has anyone successfully bit-banged an I2C interface?  Any comments on
>>> it's ease or difficulty?
>>>
>>> I've used I2C with processors that have built-in hardware, I've sat
>>> next to a guy who's bit-banged it, but I've never bit-banged it myself.
>>>
>>> I ask as a circuit designer who's going to design in an I2C chip to be
>>> presented to a software engineer with a smile and a "here, this ought
>>> to be easy!"  I want to know whether I'll be honest or not.
>> 
>> Not I2C, but I've bitbanged One-Wire, including enumeration (though not
>> high-speed), in an MSP430. I assume this relates to your battery gauge
>> question? If so, I'd think One-Wire was preferable - only one pin to
>> diddle.
>> 
>> However, to get bit timings right, the important question is whether you
>> can afford to stop the world while doing a data transfer. Trying to
>> interrupt for each bit transition might be too hard. I guess you
>> wouldn't need to read the gas gauge very often - perhaps you can pick a
>> time when you can lock out all other interrupts?
>
>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