AVR Freaks

Thanks for the feedback. I should have explained the reason for my question (since the answer may already be known). I have a board that was designed for SPI, but needs to use I2C for a newer version of the slave. The MCU is an AT90USB162, so I2C would be done in software.

Everything is pin compatible because the I2C pins on the new chip are in the same spots as MISO and SCLK on the old chip. But unfortunately the re-purposed SPI lines do not have pull-up resistors on the pcb.

I realize I2C is an open-drain circuit, so I'm wondering if I can make it work using the AVR's internal pull-ups. The main problem I see is the intermediate state when switching from output-low to input with pullup (or visa-versa).

During that transition the MCU would be set to output-high while the slave could be input-low (for just a few cycles). What I don't know is if that is enough for "bad things" to happen. I don't believe it would be a timing issue, but it might be an electrical (short) issue.

Anyone tried this before?

Looking at Peter Fleury's I2C code, there is definitely a possibility of a transitional output-high connected to slave input-low. It can happen if the slave adds wait states like in the code below at the end of a write

Assuming the rcall i2c_delay_T2 and release SCL can't be reversed, I either hack my boards or determine that the AVR and slave can handle a few cycles of an output-high to input-low connection.

Well, in this specific case I'm hoping that it "should" have an external pullup not "must".

I sent an email to the vendor of the slave IC asking if their device ever does clock stretching. If not, then I actually don't see any problems using internal pullups. In the two (very short) race conditions where the slave will pull SDA low, the master can "release" SDA through the floating state.

In fact if the slave never pulls the clock, the master could just drive SCL high and low directly. Sure its a hack, but I can't see why it wouldn't work in this special case.

The IO pull-up are between 20-50 kΩ on the AT90USB162, but this definitely isn't for production. As I mentioned, this it to make use of already some prototype boards.

I haven't heard back from SiLabs (makers of the slave chip), but I went ahead and gave it a try. So far all is working! The devices are talking and no smoke has escaped.

Hmm thanks for the feedback, but I don't think it matters if you check the previous state or not. Without a external pullups, there is no way to transition from output-low to input-pullup without going through a middle state. You can chose if you want that middle state to be input-floating (as you have done) or out-high. Either middle state could cause problems. With Input-float on the clock, for example, it could go high and low on you due to noise. And the problem with out-high is obvious if the slave is pulling low.

Checking the previous state doesn't matter. What matters is the order you assign values to PORTx and DDRx. If you removed all those "if( DDR_x)" checks from your code, the electric signals would be the same, you're just avoid setting the register to the values they already have. But that is basically a nop anyway.

Ok, here is everything I have gathered in case someone else wants to try this. I can't promise it will work for you, but it works for my devices.

1. Assume the slave does not perform clock stretching. If it does, you may need another approach (probably external pull-ups).

2. Always transition the clock through output-high since the slave's clock pin should just be reading the value (hi-z). You could probably just drive the clock output-low and output-high directly, but I decided to use output-low and input-pullup with and output-high intermediate step. Using an input-floating intermediate step seems like a bad choice for SCL since it could allow the clock line to fluctuate randomly (false pulses).

3. When the master is writing data (aka the clock is low), transition the data line through output-high also. Again the assumption is that the slave is reading the line with a hi-z input. You could go through input-float instead since the slave shouldn't notice fluctuations while the clock is low, but it seemed sloppier to me.

4. There are two cases where the slave can drive SDA low. When it acks a byte sent by the master and when it is writing data. In these two places when the master transitions the SDA line to input-pullup, it should go through the input-floating intermediate state. Using an input-high intermediate step seems like a bad choice here since it could connect input-high on the master to output-low on the slave.

Perhaps it would be simpler if the data line always used the input-float intermediate state. Then you don't need to make any special distinction for point #4, and just always do the following:

But I haven't tried that yet since I'm transitioning SDA through {1,1} except for the cases mentioned in point #4 above.

I looked at the signals in a scope and all look good. So clean, in fact, that I wanted to see how fast I could push it before things started to go bad. The slave device is rated at max 400kHz. Some interesting results:

The initial clock target was 100kHz but the actual clock was was 80kHz since the delay loop in Peter's code doesn't account for the time spent in surrounding code.

When the data-line is transitions through input-float {0, 0} before reads, the highest possible speed is about 200kHz. If I change the data line to transition through output-high {1,1} before reads, the highest speed before errors is about 222kHz. With a weak 20-50k pullup, that makes sense since SDA is sure to be high when it is engaged.

In the scope I observed that the slave device always writes during the rising edge of the clock, so it should be very safe (in this specific case) to transition through output-high since SDA will long since have made it to input-pullup by the time the clock rises.

So I'm going to always use the {1,1} transition, and to be safe adjusting the delay to produce about ~100kHz clock. David what was that you were saying about time spent on this thread :)

Edit: Here is my final transition diagram. Basically always going through output-high.

The system clock is 8MHz.

As you said, the limiting factor is during reads when SDA is simply left as input-pullup from the MCU side. Since it is relying entirely on the pullup, its a lot slower to transition high. I could inject an output-high in there the help, but since its running fine at 100kHz I'm going to call it good enough.

Actually I think the slave may be holding the line low between clock cycles or doing something else that resists the pullup. Because during reads the raise time seems to fill the low cycle not matter what the frequency is (within the range I'm testing). Then there is a final jump up just as the clock goes high.

The rise and fall times for the "assisted" pullups are < 10ns. Its pushing 3us with just the pullup alone at 100kHz (but I as I said I think this is being effected by something).

Also I'm pretty sure all reads are supposed to happen while SCL is high.

Anyway... long enough spent on this. Its working and I'll add pullups to the next hardware rev. Thanks for all the input.