Bit-banging I2C

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:

formatting link

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
Reply to
Les Cargill
Loading thread data ...

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.

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

--
Les Cargill
Reply to
Les Cargill

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.

Reply to
Johann Klammer

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
Reply to
rickman

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.

Reply to
Paul Rubin

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.

Reply to
Rocky

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

Reply to
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

Reply to
David Brown

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

Reply to
David Brown

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

Reply to
Anssi Saari

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.

formatting link

BTW, SMB is defined by Intel.

Regards, Allan

Reply to
Allan Herriman

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 
 Click to see the full signature
Reply to
Grant Edwards

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? 
 Click to see the full signature
Reply to
Grant Edwards

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.

Reply to
Hans-Bernhard Bröker

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

formatting link

Reply to
antedeluvian

Theoretically, yes.

--
www.wescottdesign.com
Reply to
Tim Wescott

Yes, more or less.

--
www.wescottdesign.com
Reply to
Tim Wescott

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 
 Click to see the full signature
Reply to
Tim Wescott

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

CHeers

Reply to
Martin Riddle

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

--

Rick
Reply to
rickman

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.