# Is it possible to use 400 kHz I2C buses with a 32 kHz slave?

I am going to use a 400 kHz I2C bus, but I want to talk to a slave MCU, a PIC16F690 (datasheet), running at 32 kHz. Is it possible to do this? I think so, because the master does the clocking, but are there any unforeseen problems that might occur? (e.g. MCU can't load data into RAM quick enough.)

read the data sheet to determine if the slave's MSSP can support the speed your interested in.

If you need extra time to copy the data out of the receiving register use clock stretching, again read the data sheet for the slave for proper usage.

EDIT: from the datasheet for that part, 400khz requires minimum device speed of 10Mhz, 100khz requires 1.5Mhz.

• Clock stretching would be absolutely required in some form; IIC takes 9 clocks/byte, so 400 KHz IIC byte rate would be 45 Kbyte/sec, even if the processor blindly read the I2C data register at 32 KHz cycle after cycle, one might slip through. – Nick T Nov 11 '10 at 6:35

Mark's "look at the datasheet" is the right answer.

You tend to find that a synchronous digital part like a microcontroller samples all its inputs via registers which are clocked from the main clock (or a clock divided from the main clock). So even things which feel like they are 'clocks' in their own right often have upper frequency limits which are imposed by the CPU's clock.

But, even if the I2C slave logic does have a clock domain of its own, truly clocked by SCL, then the way that domain is connected to the CPU's clock domain will impose some restrictions on the relative frequencies of the two sections of logic.

This is just unfortunate stuff which comes up in synchronous logic design. If you ever do FPGA design, you have to deal with it endlessly.

The datasheet makes it sound like the I2C operates asynchronously, as it apparently can run while sleeping (no clock to peripheral). Though it might take a few cycles to determine if it was addressed and if it should send an ACK.

### 13.6 Slave Mode

While in Slave mode, the external clock is supplied by the external clock source on the SCK pin. This external clock must meet the minimum high and low times as specified in the electrical specifications.

While in Sleep mode, the slave can transmit/receive data. When a byte is received, the device will wake-up from Sleep.

The electrical specifications don't mention if they are for just master or both it and slave modes; the 10 MHz for 400 kHz and 1.5 MHz for 100 kHz are comments on the bit-hold time parameter.

If you want to run with wildly disparate clocks, SPI might be a better bet, as you generally have direct control of the shift register clock.

• Its the time to ack that is critical, the address has to be shifted out of the receive register, compared to the slave address register and then an ack or nack generated. The ack is checked by the master on the 9th clock so the shift+comparison+ack set has to take place in < 1 I2C clock cycle, which would be much faster than the system clock in this example. – Mark Nov 11 '10 at 0:11
• @Mark: If the PIC's I2C implementation is any good, it should be able to hold SCK low for however long it takes to generate the ACK or NAK. – supercat Sep 8 '11 at 22:09

A small amount of asynchronous logic will allow an I2C slave, no matter how slow its synchronous logic runs, to share a bus with devices running much faster. Such a device will have to throttle the speed of other devices for the first word of any transaction (while it checks to see if it's being addressed) but the protocol would still work. If a transaction is meant for someone else, the slow device could drop out after the address byte, letting the faster devices communicate full-speed among themselves..

A little more asynchronous logic would allow an I2C slave to receive a byte of data without delaying the master until the ack/nak was required. A little more logic still would allow the slave to ignore (without making the bus wait for the CPU to generate a NAK) any transactions whose first byte or two bytes don't match a particular pattern. Obviously any communications destined for the slow device will have to be transmitted at a speed it can handle, but it may be desirable to allow faster devices to use the bus full-speed without any delay being introduced by a device that won't be interested in the communication anyway.

Unfortunately, at least some I2C implementations, like those in the PSOC, will choke if I2C data is exchanged too fast relative to the CPU clock speed (a problem when running a PSOC at reduced speed to save power). I'm not sure about the PIC.

Apart from the other answers, which are more about the electrical/logical interface, how about the I2C-processor interafce?

A PIC runs 1 instruction every 4 clock cycles, so at 32 kHz you get 8 KIPS. I am not sure how many clock cycles I2C needs to get a byte over the bus, but 10 is a good order-of-manitude guess. At 400 kHz that would mean 40 kbyte/s, so you could get 5 bytes stuffed down your throat for every instruction your poor PIC executes! So without serious clock strectching you won't stand a chance.

You say "runs a 32kHz". You you mean that, or do you just want to use a 32 kHz crystal? If the latter, you can run some PICs (but not this one) at a higher CPU clock frequency by (temporarily) switching to the internal 8 MHz oscillator.