Voy a utilizar un bus I2C de 400 kHz, pero quiero hablar con una MCU esclava, una PIC16F690 ( hoja de datos ), funcionando a 32 kHz. ¿Es posible hacer esto? Creo que sí, porque el maestro hace la sincronización, pero ¿hay algún problema imprevisto que pueda ocurrir? (Por ejemplo, MCU no puede cargar datos en la RAM lo suficientemente rápido).
lea la hoja de datos para determinar si el MSSP del esclavo puede soportar la velocidad que le interesa.
Si necesita tiempo adicional para copiar los datos del registro de recepción, use el estiramiento del reloj, nuevamente lea la hoja de datos del esclavo para un uso adecuado.
EDITAR: de la hoja de datos para esa parte, 400khz requiere una velocidad mínima del dispositivo de 10Mhz, 100khz requiere 1.5Mhz.
La "respuesta a la hoja de datos" de Mark es la respuesta correcta.
Tiendes a encontrar que una parte digital síncrona como un microcontrolador muestrea todas sus entradas a través de registros que están sincronizados desde el reloj principal (o un reloj dividido desde el reloj principal). Así que incluso las cosas que se sienten como si fueran "relojes" por derecho propio a menudo tienen límites de frecuencia superiores que impone el reloj de la CPU.
Pero, incluso si la lógica del esclavo I2C tiene un dominio de reloj propio, verdaderamente sincronizado por SCL, entonces la forma en que ese dominio está conectado al dominio de reloj de la CPU impondrá algunas restricciones en las frecuencias relativas de las dos secciones de lógica.
Esto es algo desafortunado que aparece en el diseño de lógica síncrona. Si alguna vez hace un diseño de FPGA, tendrá que lidiar con él sin cesar.
La hoja de datos hace que parezca que el I2C funciona de forma asíncrona, ya que aparentemente puede ejecutarse mientras se está durmiendo (sin reloj en el periférico). Aunque puede tomar algunos ciclos determinar si se trató y si debería enviar un ACK.
13.6 Modo esclavo
Mientras se encuentra en modo esclavo, el reloj externo es suministrado por la fuente del reloj externo en el pin SCK. Este reloj externo debe cumplir con los tiempos máximos máximos y mínimos especificados en las especificaciones eléctricas.
Mientras está en modo de suspensión, el esclavo puede transmitir / recibir datos. Cuando se recibe un byte, el dispositivo se activará desde el modo de suspensión.
Las especificaciones eléctricas no mencionan si son solo para modo maestro o ambos modos esclavo y esclavo; Los 10 MHz para 400 kHz y 1.5 MHz para 100 kHz son comentarios sobre el parámetro de tiempo de retención de bits.
Si quieres correr con relojes muy dispares, SPI podría ser una mejor apuesta, ya que generalmente tienes el control directo del reloj del registro de desplazamiento.
Una pequeña cantidad de lógica asíncrona permitirá que un esclavo I2C, sin importar qué tan lenta se ejecute su lógica síncrona, comparta un bus con dispositivos que se ejecutan mucho más rápido. Dicho dispositivo tendrá que acelerar la velocidad de otros dispositivos para la primera palabra de cualquier transacción (mientras verifica si se está abordando) pero el protocolo aún funcionaría. Si una transacción está destinada a otra persona, el dispositivo lento podría interrumpirse después del byte de la dirección, permitiendo que los dispositivos más rápidos se comuniquen a toda velocidad entre ellos ...
Un poco más de lógica asíncrona permitiría a un esclavo I2C recibir un byte de datos sin retrasar el maestro hasta que se requiera el ack / nak. Un poco más de lógica aún permitiría al esclavo ignorar (sin hacer que el bus espere a que la CPU genere un NAK) cualquier transacción cuyo primer byte o dos bytes no coincida con un patrón en particular. Obviamente, cualquier comunicación destinada al dispositivo lento tendrá que transmitirse a una velocidad que pueda manejar, pero puede ser conveniente permitir que los dispositivos más rápidos utilicen el bus a toda velocidad sin que se introduzca ningún retraso por parte de un dispositivo que no esté interesado. En la comunicación de todos modos.
Desafortunadamente, al menos algunas implementaciones de I2C, como las del PSOC, se ahogarán si los datos de I2C se intercambian demasiado rápido en relación con la velocidad de reloj de la CPU (un problema al ejecutar un PSOC a velocidad reducida para ahorrar energía). No estoy seguro sobre el PIC.
Aparte de las otras respuestas, que son más acerca de la interfaz eléctrica / lógica, ¿qué hay sobre la interfaz del procesador I2C?
Un PIC ejecuta 1 instrucción cada 4 ciclos de reloj, por lo que a 32 kHz obtiene 8 KIPS. No estoy seguro de cuántos ciclos de reloj necesita I2C para obtener un byte sobre el bus, pero 10 es una buena suposición de orden de la manidad. A 400 kHz, eso significaría 40 kbyte / s, por lo que podría obtener 5 bytes embutidos por cada instrucción que ejecuta su pobre PIC. Así que, sin un reloj serio no tendrás ninguna posibilidad.
Dices "corre a 32kHz". ¿Quieres decir eso, o simplemente quieres usar un cristal de 32 kHz? Si es lo último, puede ejecutar algunos PIC (pero no este) a una frecuencia de reloj de CPU más alta cambiando (temporalmente) al oscilador interno de 8 MHz.
Lea otras preguntas en las etiquetas microcontroller i2c