Retraso I2C necesario y c18

Estoy usando I2C y anteriormente publiqué dudas sobre I2C aquí. Estoy usando controladores PIC y usando su compilador C18. Usé sus bibliotecas para crear una función para escribir datos en EEPROM a través de I2C, y cuando verifiqué las líneas SCL, fluctuaron.

Creé una función para escribir en EEPROM, pero me perdí los retrasos, ya que la hoja de datos dice "se requiere un retraso mínimo de 5 ms para cada operación de escritura en I2C".

Confío en que está causando los problemas. El problema es que SCL no se queda en 100kHz y fluctúa entre 54kHz y 100kHz pero nunca más allá. ¿Se debe a que el byte de control, la dirección y los datos se envían a lo largo de la función?

float ee_write_float(unsigned char ee_addr, float f)
{
     void i2c_init(); //initialize I2c
     unsigned char *p = (unsigned char *)&f;
     unsigned char  i;

   for (i = sizeof f; i != 0; --i)
   {
      EEByteWrite(EE_I2C_ADDR, ee_addr++, *p++);
   }

}

¿Qué tan importante es el dela para las operaciones de escritura I2C?

¿Puede ser esa la causa del problema?

¿Debo poner un retraso después de la función EEByteWrite para compensar?

Nota: el SCL se vuelve algo estable después de que la tasa de baudios se reduce a 20kHz y luego fluctúa entre 17kHz y 19kHz. Sería muy feliz si descubriera alguna causa razonable para solucionar este problema ... o cualquier sugerencia valiosa será bienvenida de todo corazón.

Tengo que preguntarle si sabe que se especifica un retraso de 5 mS en la hoja de datos, ¿por qué no intentarlo? Es un retraso bastante largo y en este momento probablemente esté intentando escribir mil veces más rápido de lo permitido.
Bueno, estoy tratando de escribir a 100 kbps... pero la línea scl cuando se observó en el alcance mostró... fluctuaciones y nunca se mantuvo constante a 100 kbps cuando ejecuto la función anterior en main().
Podría ser el estiramiento del reloj como se propone en una respuesta sobre la otra pregunta (no sé mucho sobre eso), pero eventualmente necesitará el retraso de 5 mS para que funcione de manera confiable. Siempre puede usar un disparador en el osciloscopio para capturar el reloj de 100 kbps incluso con el retraso. ¿Cómo estás midiendo la frecuencia? Tal vez sea solo fluctuación entre los bytes que se transfieren.
Sí, estoy usando el botón disparador en el osciloscopio. Bueno, la frecuencia simplemente se muestra... debajo del osciloscopio. OK... Así que puede ser un jitter entre bytes. Bueno, lo he puesto en for loop... continuamente.
¿Puede publicar la fuente de EEByteWrite () y tal vez un seguimiento del alcance de los autobuses?
Está interpretando las cosas para llegar al problema de que su reloj I2C es inestable. Hasta donde yo sé, la estabilidad del reloj no está garantizada bajo el estándar I2C. ¿Cuál es el verdadero problema? ¿Comunicación poco confiable?

Respuestas (1)

En I2C, el reloj solo cambia según sea necesario para transmitir o recibir datos. No hay necesidad de una señal de reloj continua, por lo que se debe esperar una variación en la frecuencia observada. La especificación de 100 kHz es la frecuencia de reloj máxima en lugar de la frecuencia de reloj promedio o continua.

Las memorias no volátiles como Flash y EEPROM necesitan un período de tiempo relativamente largo para escribir datos en la memoria, y 5 ms suena bien. No debe intentar ejecutar varias operaciones de escritura sin permitir este retraso entre ellas. Debido a esto, posiblemente no pueda ejecutar más de 200 operaciones de escritura por segundo y permitir 5 ms por operación.

Una vez que tenga todo funcionando correctamente, debe esperar ver una ráfaga de pulsos de reloj de 100 kHz cada 5 ms aproximadamente.

Retraso I2C necesario y c18
RespuestasAquíPolítica de privacidad1y, 0v