Bit-banging I2C

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?

-- 

Rick

On 3/16/2016 4:08 PM, Tim Wescott wrote:
> On Wed, 16 Mar 2016 16:06:01 -0400, rickman wrote:
>
>> On 3/16/2016 4:02 PM, Tim Wescott wrote:
>>> On Wed, 16 Mar 2016 21:03:01 +0200, Dimiter_Popoff wrote:
>>>
>>>> On 16.3.2016 г. 20: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.
>>>>>
>>>>>
>>>> Master only I2C bitbanging is quite easy, I did it in a couple of
>>>> hours when I did it first some 15 years ago (on a HC11....).
>>>> Cost me a lot longer in more recent years to grasp some pervert logic
>>>> behind some in-built I2C controllers (two of them, both wasted me at
>>>> least a day each IIRC).
>>>>
>>>> Slave mode will probably be somewhat more complex and you will hit
>>>> some MCU speed imposed restrictions.
>>>
>>> Master is what I'm looking at.  Just need an MCU to talk to a slave
>>> device.
>>
>> I have trouble remembering who posted what.  Did you say previously that
>> you aren't as good with the digital stuff as you are with the analog?
>> Would you care for any help designing the I2C interface?  I'm pretty
>> free at this point.
>
> I can do stuff at that level equally well in analog and digital.
>
> It's efficient design of fast FPGA stuff that I can't do.  Basically I
> can write Verilog (or VHDL) code that's good enough to prove that
> something can be done, yet still atrocious enough to provoke someone like
> you to say "here, Tim, let me do that for you...".

lol

-- 

Rick

On 2016-03-16, Wouter van Ooijen <wouter@voti.nl> wrote:
> Op 16-Mar-16 om 9:11 PM schreef Grant Edwards:
>> On 2016-03-16, Tim Wescott <seemywebsite@myfooter.really> wrote:
>>
>>> I'm dropping a slave chip onto the board and telling the software guy
>>> "look what I've done for you!".
>>>
>>> Mostly I want to make sure I'm not painting the guy into a corner.
>>
>> 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.
>>
>> That means that if the software outputs '1' on both those pins, and
>> somebody else is pulling them low, the software needs to be able to
>> read those pins and see that they're low -- as opposed to just reading
>> back the '1' value that was written to the output latches for those
>> pins.
>>
>> 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.

I have vague memories that some old Intel uControllers acted like
that. I can't think of anything I've used in the past 10-15 years
where it was a problem, but it can't hurt to check on it before you
lay out a board. :)

-- 
Grant

On Wed, 16 Mar 2016 19:12:28 -0400, rickman wrote:

> On 3/16/2016 4:08 PM, Tim Wescott wrote:
>> On Wed, 16 Mar 2016 16:06:01 -0400, rickman wrote:
>>
>>> On 3/16/2016 4:02 PM, Tim Wescott wrote:
>>>> On Wed, 16 Mar 2016 21:03:01 +0200, Dimiter_Popoff wrote:
>>>>
>>>>> On 16.3.2016 г. 20: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.
>>>>>>
>>>>>>
>>>>> Master only I2C bitbanging is quite easy, I did it in a couple of
>>>>> hours when I did it first some 15 years ago (on a HC11....).
>>>>> Cost me a lot longer in more recent years to grasp some pervert
>>>>> logic behind some in-built I2C controllers (two of them, both wasted
>>>>> me at least a day each IIRC).
>>>>>
>>>>> Slave mode will probably be somewhat more complex and you will hit
>>>>> some MCU speed imposed restrictions.
>>>>
>>>> Master is what I'm looking at.  Just need an MCU to talk to a slave
>>>> device.
>>>
>>> I have trouble remembering who posted what.  Did you say previously
>>> that you aren't as good with the digital stuff as you are with the
>>> analog? Would you care for any help designing the I2C interface?  I'm
>>> pretty free at this point.
>>
>> I can do stuff at that level equally well in analog and digital.
>>
>> It's efficient design of fast FPGA stuff that I can't do.  Basically I
>> can write Verilog (or VHDL) code that's good enough to prove that
>> something can be done, yet still atrocious enough to provoke someone
>> like you to say "here, Tim, let me do that for you...".
> 
> 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.

-- 

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

On Thu, 17 Mar 2016 00:04:36 +0100, Wouter van Ooijen wrote:

> Op 16-Mar-16 om 9:11 PM schreef Grant Edwards:
>> On 2016-03-16, Tim Wescott <seemywebsite@myfooter.really> wrote:
>>
>>> I'm dropping a slave chip onto the board and telling the software guy
>>> "look what I've done for you!".
>>>
>>> Mostly I want to make sure I'm not painting the guy into a corner.
>>
>> 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.
>>
>> That means that if the software outputs '1' on both those pins, and
>> somebody else is pulling them low, the software needs to be able to
>> read those pins and see that they're low -- as opposed to just reading
>> back the '1' value that was written to the output latches for those
>> pins.
>>
>> 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.
> 
> Wouter van Ooijen

Kinda what Grant said -- I haven't seen any lately (the one we're using 
on this project isn't one), but I dimly recall it being an issue with 
something in my past.

It's just the general rule of don't trust the manufacturer to not screw 
you over...

-- 

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

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.

-- 

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

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


Yes. So far, some A/Ds, a T1 framer, other stuff I've forgotten.

Bit banged with what? If it's Linux, and you're just spawning a thread 
and using usleep() for timing, expect ... many opportunities for 
difficulty.

Curiously, learning the Windows multimedia timers ( or whatever they're
called these days ) is pretty easy and the jitter doesn't
seem bad at all. Of course there's no PIO, so it's moot.

If you have good hardware timers and can do the bit transitions in the
ISR ( or at least FIFO it on behalf of middleware to be
named later) , fate smiles on you.

If it's a PIC and you can count down timers properly, happiness reigns.
Fs for an unladen PIC can be in the 10^6 samples/sec or more range.

I'd at least not consider the hardware done until I'd used an otherwise
unladen PIC that could demo the SPI interface to be correct.

Also maybe this:
http://www.totalphase.com/products/beagle-i2cspi/

The Bus pirate and a couple of other like things may also
work there, but I'm deliriously happy with everything I've
ever gotten from Total Phase including support.

-- 
Les Cargill

Tim Wescott wrote:
> On Wed, 16 Mar 2016 16:06:01 -0400, rickman wrote:
>
>> On 3/16/2016 4:02 PM, Tim Wescott wrote:
>>> On Wed, 16 Mar 2016 21:03:01 +0200, Dimiter_Popoff wrote:
>>>
>>>> On 16.3.2016 г. 20: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.
>>>>>
>>>>>
>>>> Master only I2C bitbanging is quite easy, I did it in a couple of
>>>> hours when I did it first some 15 years ago (on a HC11....).
>>>> Cost me a lot longer in more recent years to grasp some pervert logic
>>>> behind some in-built I2C controllers (two of them, both wasted me at
>>>> least a day each IIRC).
>>>>
>>>> Slave mode will probably be somewhat more complex and you will hit
>>>> some MCU speed imposed restrictions.
>>>
>>> Master is what I'm looking at.  Just need an MCU to talk to a slave
>>> device.
>>
>> I have trouble remembering who posted what.  Did you say previously that
>> you aren't as good with the digital stuff as you are with the analog?
>> Would you care for any help designing the I2C interface?  I'm pretty
>> free at this point.
>
> 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 may be disappointed then.

-- 
Les Cargill

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.

This gradually improved over the last 10 years or so, as MCU designers 
began to make MCU pins cleverer with each generation, at the expense of 
making them more complex to handle.  Nowadays a single port pin may 
require more than 10 registers to be configured to operate it (turn off 
"higher" peripherals using the same pin or configure the crossbar to map 
pin to I/O, port direction, digital vs. analog, input amplifier enable, 
hi/lo thresholds, filters, output drive strength, pull-up, pull-down, 
configure clock and power supply to the relevant sub-sections of the 
MCU, ...)

Grant Edwards wrote:
> On 2016-03-16, Tim Wescott <seemywebsite@myfooter.really> wrote:
>
>> I'm dropping a slave chip onto the board and telling the software guy
>> "look what I've done for you!".
>>
>> Mostly I want to make sure I'm not painting the guy into a corner.
>
> 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.
>
> That means that if the software outputs '1' on both those pins, and
> somebody else is pulling them low, the software needs to be able to
> read those pins and see that they're low -- as opposed to just reading
> back the '1' value that was written to the output latches for those
> pins.
>

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
12c right up.

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

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

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

-- 
Les Cargill