Resumen: Sospecho que el nuevo I 2 C no se acerca lo suficiente al original, y al menos un I 2 La secuencia C se muestra en el "trazado de trabajo", que puede ser difícil de reproducir para usted.
Detalles:
Suponiendo que la diferencia no dependa de una señal distinta de la I 2 Líneas C [...]
¿Qué me falta?
Las capturas del analizador lógico son muy útiles, gracias. Junto con la otra información, creo que tenemos un buen "sospechoso".
Hay diferencias obvias de tiempo en mi solicitud frente a la de ellos, pero no estoy seguro de que sean significativas.
Apuesto a que las diferencias de tiempo son significativo, sobre todo porque:
La comunicación con el 24C16WI es exitosa
Así que usando su propia I 2 C Master, puede comunicarse con el estándar I 2 C (esa EEPROM). Como has dicho, el problema es intentar obtener una respuesta del PIC, y como has señalado en un comentario posterior, ese PIC no tiene un módulo I2C incorporado:
He leído la hoja de datos del dispositivo esclavo (PIC12F509) pero no he visto una implementación de hardware I2C. Sólo puedo suponer que están golpeando bits.
Sí, he visto otros dispositivos PIC (sin I 2 C) programado como I 2 C, que tenían importantes restricciones de tiempo en su I 2 Comportamiento C.
Observo que hay un mayor retraso en la secuencia de inicio
Exactamente. No he medido con el software Saleae, pero "a ojo" hay aproximadamente 0,8 ms de retardo entre la I 2 C y la primera conmutación de la señal SCL en el trabajando rastro, y no hay tal retraso en el fallando rastro.
Ese retraso no es típico I 2 C, pero sospecho que es necesario para que el firmware del PIC (desconocido) reconozca la I 2 C (por ejemplo, tal vez tenga que despertarse del sueño, utilizando la función "wake on change" del PIC GPIO, cuando la señal SDA cambia como parte de la I 2 C Condición de inicio).
Si yo estuviera en su situación, empezaría con una hipótesis que todo del original I 2 La sincronización de C es importante (no sólo la velocidad del reloj SCL, donde ya es similar a la velocidad original) y tratar de duplicar la sincronización original y el comportamiento completamente . Después de todo, esa secuencia original funciona :-)
Hay otras partes inusuales en el "trabajo" que 2 Transacción C:
-
En el byte de dirección, parece haber un pequeño retraso entre el reloj para el bit 8 y el reloj para el (9º) bit ACK/NACK. De nuevo, ese retardo (que no existe en tu traza "fallida") podría ser requerido por el firmware del PIC.
-
En el siguiente byte, veo sólo 8 pulsos de reloj y no los 9 pulsos esperados, lo que explica el comentario del software Saleae sobre "Missing ACK/NACK". De nuevo, este (anormal) I 2 C para que coincida con las expectativas del firmware del PIC, pero es probable que sea difícil o imposible de reproducir, utilizando la I 2 Código de controlador / biblioteca C, ya que esto normalmente generaría los 9 pulsos de reloj normales.
No estoy seguro de cómo producir eso con el controlador ASF I2C de Atmel.
No he utilizado ese controlador. Puedes investigar si puedes insertar un retardo después de enviar la I 2 C Condición de inicio, antes de enviar la dirección del dispositivo. Esto es independiente del pulso de reloj "Missing ACK/NACK" (que puede tiene que faltar!) cuando el Maestro transmitió el segundo byte en la "traza de trabajo".
Por lo tanto, es posible que no puedas utilizar ese controlador "tal cual", y en su lugar tengas que escribir tu propio código de bajo nivel ("controlador"), que te da más control. Si todo lo demás falla para darle la cantidad necesaria de control de temporización y pulso de reloj, puede que tenga que hacer un bit-bang en las señales SDA y SCL del Maestro para algunas o todas las señales I 2 Secuencias del protocolo C que necesitas.
