Actualmente estoy trabajando en un proyecto I2C EEPROM usando bit-banging para manejar las líneas SDA y SCL.
Mi función de lectura funciona bien, pero cada vez que escribo cualquier byte con un "1" inicial, siempre leo FF; incluso si el byte ha sido programado con algo más antes. Liderando "0" es perfecto. No es mi rutina de lectura; Como puedo ver en el alcance, devuelve FF.
Estoy buscando sugerencias sobre por qué esto podría ser. ¿Hay alguna obvia que pueda pasar por alto que pueda causar el problema? [No puedo publicar el código - empresa confidencial ... :(]
Cada forma de onda que miro cumple exactamente con las especificaciones. Estoy desacoplando la EEPROM. Mis pull ups son 2.2k, así que dentro de las especificaciones. Estoy registrando a unos 500 Hz en este prototipo. El chip está enviando ACK a cada uno de mis bytes, por lo que los reconoce. Pero simplemente no funciona ...
Estoy usando un Microchip 24LC256 .
Algoritmo de escritura simplificado para un byte:
wait
SDA low
SCL low
wait
for each bit
if bit is set: SDA high
if bit is unset: SDA low
wait
SCL high
wait
wait
SCL low
wait
wait
SDA high
SCL high
wait
wait
check ACK status
SDA low
SCL low
wait
return ACK status
Algoritmo de lectura simplificado para un byte:
wait
SCL low
SDA high
for each bit (8 bits)
SCL high
wait
wait
SCL low
wait
check and store received bit
wait
do a NACK or ACK depending on if it is the last byte
Respuestas:
Estás leyendo los datos después de que el reloj vuelva a estar bajo. Tendrás que hacer eso entre hacer que el reloj sea alto y hacerlo bajo. Una vez que el reloj está bajo, el esclavo puede cambiar la línea de datos, no mientras esté alto.
Entonces leer debería ser así:
fuente
El problema al final resultó ser que estaba enviando inadvertidamente una condición de DETENCIÓN en algunas condiciones debido a la sincronización. Dejé de usar el alcance y saqué el analizador lógico, y pude solucionar el problema en 15 minutos, ya que resaltaba la PARADA que no debería haber estado allí. Elegiré a quién dar la recompensa en función de la respuesta más útil. Gracias por todas las soluciones.
fuente
OK, su alcance demuestra que el primer byte que ingresa al PIC es malo, por lo que no es la función de lectura del PIC.
¿Verificó que el tiempo de escritura es correcto en el extremo receptor?
¿Esto falla en los dos modos a continuación?
La especificación muestra "El bit más significativo (MSB) 'b7' se envía primero" Esto también es coincidente cuando b7 = 1 que el byte completo se vuelve a leer como FF. Por lo tanto, no se escribe y solo se borra (condición de falla) cuando b7 = 1, o se lee incorrectamente como FF independientemente del contenido anterior. Dado que cada escritura es un borrado amplio de bytes antes de la escritura, ¿podría ser una mala escritura o una mala lectura o la sincronización del primer byte es diferente?
Sugerencia: Verifique la señal PTC durante una escritura / lectura para garantizar el funcionamiento normal.
Existe la opción de usar un reloj externo para cronometrar la duración de un ciclo E / W usando PTC. ¿Has intentado usar esto?
Tiempo de ciclo tE / W
¿Pasa este criterio?
fuente
Parece que podría ser un par de cosas:
0xFF
. El pin podría dejarse como una salida que conduce el autobús mientras lee.0xFF
s (y lo más probable es que devuelva lo mismo, ya que probablemente sea un comando / condición no válida).fuente
0xFF
s? Vea mis ediciones arriba también.Envié esto como un comentario arriba, pero mi confianza en la respuesta ha crecido silenciosamente en los profundos recovecos de mi mente, así que lo estoy promoviendo para una respuesta.
Tengo el presentimiento de que esto es casi seguro que es un error de software de bajo nivel relacionado con la firma de algunas variables. En su código para cada bit, ¿está inadvertidamente extendiendo la señal con una operación de cambio a la derecha? Si es así, su líder finalmente lo dejará con un 0xFF después de 7 operaciones de turno.
Steven aludió a esto en un comentario, pero ¿ha sido testigo de la santidad de sus operaciones de escritura en un osciloscopio, o solo presume que funcionan en función de que la mitad de las lecturas se vean bien? Si no ha intentado mirar la operación de escritura del valor 0xAA, puede ser una buena idea intentarlo.
Si puede proporcionar el código real de su bucle interno y las declaraciones de variables asociadas, podríamos detectar un error.
fuente