EmbeddedRelated.com
Forums

Bit-banging I2C

Started by Tim Wescott March 16, 2016
On 3/16/2016 4:04 PM, Tim Wescott wrote:
> On Wed, 16 Mar 2016 15:51:25 -0400, rickman wrote: > >> On 3/16/2016 2:49 PM, 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. >> >> Do you have a free interrupt for the clock pin and do you have a free >> timer? I bet you can map the state machine for I2C to those two things >> rather than polling the interface. That said, I haven't done it. I >> have done this for a UART receiver. Rather than sample at each clock >> interval I use an interrupt on input transitions (no noise in the line >> obviously) and measure the position with the timer. Easy to figure how >> how many bits from the last transition. >> >> I2C starts with a high to low on the data line while the clock is high >> and the end condition is a lot to high on the data while the clock is >> high. Otherwise all data transitions are while the clock is low. So on >> the end of a message you will need to poll or something to find the end >> condition. Otherwise, interrupt on the falling edge of the clock when >> you are waiting for the start condition, on the rising edge of the clock >> when expecting data, sample the data and Bob's your uncle. >> >> I guess I'm assuming you are implementing the slave. I think the master >> is easier and can be driven completely from a timer interrupt unless you >> want to implement clock stretching. > > 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.
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. -- Rick
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. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
On Wed, 16 Mar 2016 16:08:06 -0400, rickman wrote:

> On 3/16/2016 4:04 PM, Tim Wescott wrote: >> On Wed, 16 Mar 2016 15:51:25 -0400, rickman wrote: >> >>> On 3/16/2016 2:49 PM, 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. >>> >>> Do you have a free interrupt for the clock pin and do you have a free >>> timer? I bet you can map the state machine for I2C to those two >>> things rather than polling the interface. That said, I haven't done >>> it. I have done this for a UART receiver. Rather than sample at each >>> clock interval I use an interrupt on input transitions (no noise in >>> the line obviously) and measure the position with the timer. Easy to >>> figure how how many bits from the last transition. >>> >>> I2C starts with a high to low on the data line while the clock is high >>> and the end condition is a lot to high on the data while the clock is >>> high. Otherwise all data transitions are while the clock is low. So >>> on the end of a message you will need to poll or something to find the >>> end condition. Otherwise, interrupt on the falling edge of the clock >>> when you are waiting for the start condition, on the rising edge of >>> the clock when expecting data, sample the data and Bob's your uncle. >>> >>> I guess I'm assuming you are implementing the slave. I think the >>> master is easier and can be driven completely from a timer interrupt >>> unless you want to implement clock stretching. >> >> 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. > > 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. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
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. -- Grant Edwards grant.b.edwards Yow! If I felt any more at SOPHISTICATED I would DIE gmail.com of EMBARRASSMENT!
On Wed, 16 Mar 2016 20:11:14 +0000, 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. > > 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.
Thank you for that reminder, Grant. SPI is looking more attractive, if I can find a suitable chip with such an interface. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
On 16/03/16 20:06, Grant Edwards wrote:
> On 2016-03-16, Tim Wescott <seemywebsite@myfooter.really> wrote: > >> Has anyone successfully bit-banged an I2C interface? > > Several times. Sometimes it's easier to bit-bang it than it is to > figure out how to get a broken I2C controller to work right. [Not to > mention any names <cough-Samsung-cough>] >
I agree (I won't mention any names, because I can't remember which microcontroller it was). Bit-banging a master I&#4294967295;C is pretty simple. Just make sure you have a delay routine that really does delay as you want (reading from a hardware timer of some sort is usually reliable).
>> Any comments on it's ease or difficulty? > > It can be pretty easy. > > If you're doing it on bare metal with predictable timing for delay > loops and without interrupts, and you don't try to implement > clock-stretching, it's quite easy.
It is easier if you don't have to implement clock stretching - few simple peripherals need use clock stretching.
> > For the data signal you need both an input pin and an open-collector > output pin. If you can read back the electrical level on an > open-collector output pin (as opposed to the output latch value), then > that's all you need for data. > > If you're not doing clock-stretching, then all you need for the clock > is a generic output pin (doesn't need to be open-collector, and you > don't need to read it). If do you want to impliment clock-stetching, > then the clock signal has the same requirements as the data signal. > > If you want to try to use some sort of interrupt-driven counter/timer > output or waveform generator peripheral, then it may take a bit more > work. But, if you want predictable timing in an interrupt-driven > multi-threaded environment that's probably what you'd need. >
On 16.3.2016 &#1075;. 22:02, Tim Wescott wrote:
> On Wed, 16 Mar 2016 21:03:01 +0200, Dimiter_Popoff wrote: > >> On 16.3.2016 &#1075;. 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. >
Hi Tim, I put my old source (last modified Sep 2000....) at http://tgi-sci.com/src/nmi2c.sa Just "as is", should give you an idea about the complexity of what you are after. Dimiter ------------------------------------------------------ Dimiter Popoff, TGI http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/
Den onsdag den 16. marts 2016 kl. 21.11.18 UTC+1 skrev 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. >
you don't _need_ open-collector, you can just set the pin to low and switch the pin between input and output -Lasse
Den onsdag den 16. marts 2016 kl. 21.08.20 UTC+1 skrev rickman:
> On 3/16/2016 4:04 PM, Tim Wescott wrote: > > On Wed, 16 Mar 2016 15:51:25 -0400, rickman wrote: > > > >> On 3/16/2016 2:49 PM, 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. > >> > >> Do you have a free interrupt for the clock pin and do you have a free > >> timer? I bet you can map the state machine for I2C to those two things > >> rather than polling the interface. That said, I haven't done it. I > >> have done this for a UART receiver. Rather than sample at each clock > >> interval I use an interrupt on input transitions (no noise in the line > >> obviously) and measure the position with the timer. Easy to figure how > >> how many bits from the last transition. > >> > >> I2C starts with a high to low on the data line while the clock is high > >> and the end condition is a lot to high on the data while the clock is > >> high. Otherwise all data transitions are while the clock is low. So on > >> the end of a message you will need to poll or something to find the end > >> condition. Otherwise, interrupt on the falling edge of the clock when > >> you are waiting for the start condition, on the rising edge of the clock > >> when expecting data, sample the data and Bob's your uncle. > >> > >> I guess I'm assuming you are implementing the slave. I think the master > >> is easier and can be driven completely from a timer interrupt unless you > >> want to implement clock stretching. > > > > 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. > > 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. >
the physical part is simple but there is not really a standard and there is lots of stuff that you almost have to bit bang because the "naive" 8 bits serial doesn't cut it, e.g. weird number of bits, clock phase changing between read and write parts of serial stream, delays need in weird places, data lines doubling as busy signals etc. -Lasse
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