Summary: Sospecho que el nuevo tiempo I 2 C no está lo suficientemente cerca del original, y al menos uno "anormal" I 2 La secuencia C se muestra en la "traza de trabajo", que puede ser difícil de reproducir.
Detalles :
Suponiendo que la diferencia no se basa en una señal distinta de las líneas I 2 C
[...]
¿Qué me estoy perdiendo?
Las capturas del analizador lógico son muy útiles, gracias. Junto con la otra información, creo que tenemos un buen "sospechoso".
Hay diferencias de tiempo obvias en mi solicitud frente a las suyas, pero no estoy seguro de que sean significativas.
Apuesto a que las diferencias de tiempo son significativas, especialmente desde:
La comunicación con el 24C16WI es exitosa
Entonces, utilizando su propio I 2 C Master, puede comunicarse con el dispositivo estándar I 2 C (esa EEPROM). Como usted dijo, el problema es tratar de obtener una respuesta del PIC, y como señaló en un comentario posterior, ese PIC no tiene un módulo I2C incorporado:
Leí la hoja de datos del dispositivo esclavo (PIC12F509) pero no vi una implementación de hardware I2C. Solo puedo asumir que están golpeando.
¡Sí! He visto otros dispositivos PIC (sin un módulo interno I 2 C) programados como I 2 C esclavos, que tenían restricciones de tiempo significativas en su I 2 C comportamiento.
Observo que hay un retraso mayor en la secuencia de inicio
Exactamente. No he medido utilizando el software Saleae, pero "a simple vista" hay aproximadamente un retraso de 0,8 ms entre la condición de inicio I 2 C y el primer conmutador de la señal SCL en el que funciona trace, y no hay tal retraso en el error trace
.
Ese retraso no es el comportamiento típico de I 2 C, pero sospecho que es necesario que el firmware PIC (desconocido) reconozca la condición de inicio C 2 (por ejemplo, tal vez tenga que activarse desde el estado de reposo, utilizando la función "despertar al cambiar" de PIC GPIO, cuando la señal SDA cambia como parte de la condición de inicio I 2 C).
Si estuviera en su situación, comenzaría con la hipótesis de que todos del I 2 C original es importante (no solo la velocidad del reloj de SCL, donde ya eres similar a la velocidad original) e intenta duplicar el tiempo original y el comportamiento completamente . Después de todo, esa secuencia original funciona :-)
Hay otras partes inusuales en la transacción "en funcionamiento" I 2 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. Una vez más, ese retraso (que no existe en su seguimiento "fallido") puede ser requerido por el firmware del PIC.
-
En el siguiente byte, veo solo 8 pulsos de reloj, no los 9 pulsos esperados, lo que explica el comentario del software Saleae sobre "Falta ACK / NACK". De nuevo, este comportamiento (anormal) I 2 C puede ser necesario para que coincida con las expectativas del firmware del PIC, pero es probable que sea difícil o imposible de reproducir, usando I 2 Código de controlador / biblioteca C, ya que esto generaría normalmente los 9 pulsos de reloj normales.
No estoy seguro de cómo producir eso con el controlador Atmel ASF I2C.
No he usado ese controlador. Puede investigar si puede insertar un retraso después de enviar la condición I 2 C Start, antes de enviar la dirección del dispositivo. Eso está separado del pulso de reloj "Falta ACK / NACK" (¡que podría faltar!) Cuando el Maestro transmitió el segundo byte en la "traza de trabajo".
Por lo tanto, es posible que no pueda usar ese controlador "tal como está" y, en cambio, tal vez deba escribir su propio código de bajo nivel ("controlador"), que le brinda más control. Si todo lo demás no puede proporcionarle la cantidad necesaria de tiempo y control del pulso del reloj, es posible que tenga que hacer bit-bang para que el SDA y SCL del Maestro se señalen para algunas o todas las secuencias del protocolo I 2 C necesita.
