Variaciones de frecuencia de reloj I2C

Estoy usando un periférico I2C en la serie PIC18 que funciona a 100 kHz y he usado resistencias pull up de 4,7 k Ω en el proceso. Luego cargué un código con operación de escritura continua de EEPROM y vi la línea SCL en el osciloscopio. La línea SCL no se queda siempre a 100 kHz. Varía de 100 kHz y algunas veces salta de 24 kHz a 50 kHz y llega hasta 100 kHz... nunca pasa de eso.

¿Qué se debe hacer para que la línea SCL sea estable a 100kHz? ¿Cambiar la resistencia pullup compensará la pérdida?

¿Qué más está haciendo el micro? ¿El I2C está controlado por interrupciones? ¿Hay otras interrupciones que puedan anularlo? Si no es así, ¿hay funciones en curso que podrían causar que la función I2C se retrase (por ejemplo, alguna función que a veces tardará mucho en volver)?
¿Qué periférico I2C? ¿Qué problemas están siendo causados ​​por la "inestabilidad"?
¿Está continuamente escribiendo en la EEPROM? Verifique la hoja de datos de EEPROM y vea que tiene un número limitado de escrituras de por vida. Si lo escribe continuamente, se desgastará rápidamente.
Bueno, el esclavo está simplemente desconectado y verifiqué solo las señales de transmisión de SCL, ya sea que el reloj sea estable o no.
Estoy usando el controlador pic18f26j50.
¿Cómo se mide la frecuencia del reloj? ¿Se promedia la frecuencia medida en varios bytes? ¿O puede ver, en el osciloscopio, que algunos bytes se envían con un reloj a 100 kHz, mientras que otros bytes se transmiten con frecuencias de reloj más bajas?
Sí. Estoy usando el alcance Techtronix. Estoy viendo el pulso en ese instrumento. ¿El estiramiento del reloj causará problemas? En lugar de reducir la velocidad.
Depende de lo que observes. El estiramiento del reloj solo debe retrasar la transmisión del siguiente byte. Pero cada byte debe transmitirse con la frecuencia de reloj normal, por lo que debe observar 100 kHz en ese momento. ¿Tal vez puedas agregar una imagen del alcance para que podamos ver lo que observas?
Ponga algo de retraso después de la inicialización de I2C. especialmente después de asignar el valor de SSPADD.

Respuestas (1)

Se permite el estiramiento del reloj con I2C.

Esta podría ser la razón del comportamiento. ¿Qué sucede cuando transfiere datos a, digamos, 20 kHz? ¿Ve pulsos tan prolongados también o desaparecen?

Bueno, no lo he intentado, solo intenté conectar las resistencias pull up y verifiqué la línea SCL. Tampoco conecté el chip eeprom.
¿Hay algún otro código en ejecución o solo el código I2C? ¿Podría ser que esté enviando algo a UART o esté haciendo algunos cálculos en segundo plano?
No. Solo la escritura I2c está en el flujo
L.Hola... hice algunos experimentos con el osciloscopio y el chip funciona bien en el rango cuando di 20 khz. Veo pequeñas desviaciones entre 19-17 khz en el medio. Cuando di 50 khz... muestra saltos entre 34 khz y 49 khz. Y cuando vuelvo a 100 khz... salta entre 54 y 100 khz.
Bueno, solo un dispositivo (esclavo) está conectado en el bus ahora. ¿Podría ser debido a que el reloj se está estirando?
Póngalo en reinicio, debería ver los resultados inmediatamente. También puede hacer lo siguiente si cree que es su código: alternar un pin inmediatamente antes de comenzar la escritura I2C. Una vez que haya terminado, cambie ese pin nuevamente. Asegúrese de que las interrupciones estén deshabilitadas (excepto las que necesita para I2C, si corresponde).
¿Utiliza el módulo I2C de hardware o una implementación de software?
Es una implementación de hardware.
@ Rookie91 Pregunta relacionada sobre el estiramiento del reloj I2C (con capturas de pantalla del osciloscopio) .
Variaciones de frecuencia de reloj I2C
RespuestasAquíPolítica de privacidad1y, 0v