EmbeddedRelated.com
Forums

Bit-banging I2C

Started by Tim Wescott March 16, 2016
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.
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. -- Rick
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? -- Rick
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.
On Thursday, March 17, 2016 at 2:10:36 AM UTC+2, 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? > >
<snip>
> 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
<snip> 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 individually addressable output latches. A write or read-write in an interrupt can modify the the 'lo' written to the output latch to a 'hi' which ruins the I2C operation. Can be hard to find.
Op 17-Mar-16 om 1:04 AM schreef Hans-Bernhard Br&#4294967295;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. Wouter van Ooijen
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.
On 17/03/16 03:30, Johann Klammer 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. >
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 value (50K - 250K) for an I&sup2;C bus.
On 16/03/16 21:06, 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.
I&sup2;C is /much/ easier than one-wire. One-wire can be a serious pain, as you have to get your timings right to within a few &micro;s - it is hard to mix it with interrupts or other low-jitter events. One-wire has its uses and advantages, but I would not pick it over I&sup2;C. One potential problem that I&sup2;C has that neither one-wire or SPI have, is 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 that I&sup2;C is no longer working. So if you have a reset pin on the I&sup2;C 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.)
> > 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?
Tim Wescott <seemywebsite@myfooter.really> writes:

> Has anyone successfully bit-banged an I2C interface? Any comments on > it's ease or difficulty?
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...