Datos raros I2C y salida/entrada de reloj

Hola, estoy tratando de comunicar que está usando SMBus. Entonces, cuando intento enviar datos que eran 0x0D y la dirección del dispositivo era 0x16. Veo algo así en la línea de datos:

ASD

Y así es como se ve el pin de mi reloj (SCL):

SCL

Entonces mis preguntas son:

  1. ¿Son normales estos datos y las señales del reloj? Sé que los datos no son normales porque no puedo transmitir el mensaje, pero ¿qué pasa con la señal del reloj?
  2. Entonces, los datos se ven como 1 1 1 1 1 1 .... 1 1, ¿es porque no puedo reconocer ACK/NACK del esclavo, sigue enviando los datos una y otra vez? O tal vez algo más detrás de esta extraña señal de datos.
  3. Usé resistencias pull up de 20 K para SDA y SCL para 5 V Vdd. (Para SMBus, creo que debería haber usado 15 k ohm.) ¿Puede ser esa la razón? ¿O alguna otra idea que cause esto? Gracias de antemano

En la ficha técnica de la batería que trato de comunicar, dice:

Para resistencias pull up

Así que pensé que podría usar 20 k ohmios como resistencias pull-up (para ser honesto, no pude entender realmente lo que dicen en el documento).

Y así es como se ven juntas las señales SCL/SDA

Señal SCL/SDA

Este es el esquema del circuito (uso RB1 y RB2 para la comunicación SMBus).

Esquemático

Este es el diagrama de pines de la batería. Me estoy comunicando con la primera sección, PINS 1-4:

CONFIGURACIÓN

Eso no parece una señal de reloj normal o una señal de datos, pero no tengo idea de qué podría estar causándolo.
Eso no me parece normal, ¿qué frecuencia estás tratando de ejecutar?
¿Qué dispositivos intentan comunicarse (números de pieza)?
Estoy usando PIC18F26K83 e intento comunicarme con una batería inteligente. Bueno, la frecuencia debería haber sido de 62,5 kHz, pero como se puede ver, la frecuencia también está mal. Pero no me importó porque en las especificaciones de SMBus está escrito que el rango de frecuencia permitido está entre 10 Khz y 100 Khz.
¿Está todo en la misma placa y usando el mismo suministro/tierra? ¿Puedes agregar un esquema?
Sí, todo está en el mismo tablero, agregaré un esquema aquí
Use 2 entradas en su 'alcance. SCL en uno, SDA en el otro. Acérquese a solo 1 o 2 pulsos de reloj para que podamos ver cómo SDA y SCL se relacionan entre sí.
@brhans lo agregó, pero no estoy seguro si está en la forma que solicitó
Sí, eso es lo que estaba buscando. Pero se ve tan extraño (para un bus I2C) que no es de mucha ayuda para diagnosticar el problema... Sospecho que hay algo mal con la forma en que está configurando o controlando el puerto periférico I2C en su PIC.
@Justin agregué el esquema, perdón por la demora
¿Está el circuito de control de la batería en el mismo suministro/tierra que el PIC?
@Justin mm no, solo conecto las líneas SCL y SDA de la batería a las líneas SDA y SCL del PIC. Entonces solo 2 conexiones por cable.
@GünkutAğabeyoğlu - Ese podría ser tu problema. I2C en realidad requiere una conexión a tierra común, por lo que en realidad es un bus de 3 cables. Lo publicaré como respuesta.
Sí, podría ser el problema. ¡Nunca lo pensé bien!

Respuestas (3)

El bus I2C en realidad no requiere 2 cables, sino 3: SCL, SDA y tierra . Por lo general, solo se asume porque I2C está destinado a la comunicación en la misma placa. Si realmente solo está conectando SCL y SDA desde su PIC a su batería, y no hay una conexión a tierra común entre ellos, es posible que vea algo como esto.

La tierra de su PIC debe estar conectada a la tierra del circuito de monitoreo de la batería. No es necesariamente la conexión a tierra real de la batería; pueden proporcionar un pin de tierra separado destinado a la comunicación. ¿Cuál es el pinout de su batería inteligente?

Es algo como esto, y solo conecté Reloj (PIN 1-4) y Datos (PIN 1-4). Así que estoy agregando la imagen a la publicación principal.

Ninguna forma de onda parece normal para una transmisión SMBus. En una situación ideal de transmisión de la forma de onda del reloj durante el período de transacción, debería tener un ciclo de trabajo aproximado del 50%.

Dudo que las resistencias pullup sean el problema, pero me gustaría comentar que tratar de usar resistencias en el rango de 15K a 20K es muy poco convencional. Las aplicaciones SMBus del mundo real utilizan resistencias pull-up en el rango de 2,2 K a 4,7 K.

Será difícil sugerir más pasos de depuración porque no sé cómo está generando su tráfico (bloqueo de IP de SMBus o bit-banged). También se desconocen factores como las conexiones de pines de MCU, las configuraciones de pines, los controladores aplicados o incluso los traductores de nivel.

En el datasheet de la batería que trato de comunicar dice algo así: ah entonces no puedo poner una imagen aquí, la agregaré a mi publicación.

Estaba tratando de hacer una referencia cruzada de su imagen con algunas capturas que he guardado para juzgar la base de tiempo y cómo debería verse.

Creo que lo que sucede a 100us/div es que se ven inicios repetidos que no se reconocen. Además, su tiempo de subida parece horrible, intente dominadas más pequeñas.

Aquí hay una captura a 50us y me imagino que 100us se vuelve una resolución bastante pobre pero aún así puede mostrar el 50% de servicio en el reloj.

capturaTampoco importa la medición de frecuencia de 66,7 kHz, no calcula bien las cosas en una captura como esta, el bus era de 100 kHz.

Entonces, seguí enviando estos datos porque no pude obtener respuesta, ¿verdad? Pero no se parece a mis datos que trato de enviar ni a la dirección del valor del esclavo
Sí, me gustaría ver una dirección allí. ¿Cómo se implementa el maestro, podría ser un error? Mi captura es de cuando perseguí un error de bus que pensé que era eléctrico pero resultó ser un maestro que estaba mal implementado y, a veces, enviaba basura.
Datos raros I2C y salida/entrada de reloj
RespuestasAquíPolítica de privacidad1y, 0v