Analizando el Protocolo

Estoy tratando de entender un protocolo (que se muestra en la figura 1) Figura 1. Por ahora, he entendido que los datos se transfieren en un reloj alto a bajo. como se muestra en la figura. y la sincronización es para cada 8 bits.

Pero luego hay otro dato en la línea de datos, como se muestra en la figura 2 Figura 2, que está cambiando en la parte baja del reloj. Esto no sucede en una instancia en particular, sino en algún momento en el 3.°, 4.°, 8.° bit, etc. con respecto a la sincronización. Además, estos datos son diferentes cada vez.

Después de esto, los datos se transfieren en cada reloj de menor a mayor, aún con sincronización de 8 bits (Figura 3). Entonces, estoy pensando que esto puede ser una especie de cambio de dirección de los datos del ciclo de lectura a escritura (o viceversa).ingrese la descripción de la imagen aquí

Alguien me puede ayudar a entender esto.

Editar: probablemente sea un chip de memoria, canon está utilizando en el protocolo los chips de impresora (Impresora iP7230) para comunicar los niveles de la impresora.

Vi esto hace unos días, pensé que podía probar esto. http://www.instructables.com/id/Reverse-Engineering-to-Emulate-Ink-Cartridges-for-/

Solo quería que me indicaran qué tipo de protocolo puede ser.

Probablemente valga la pena agregar un poco de información sobre qué es el dispositivo. ¿Supongo que no es la salida de un módulo de RF?
No, no lo es y he editado la pregunta en consecuencia.
Usted dice que probablemente sea un chip de memoria, pero debe ser más explícito: ¿dónde lo midió y en qué producto?
No tengo idea, está en el cartucho del chip de la impresora y no tiene ninguna etiqueta. El modelo de impresora es canon ip7230 y tomó estos datos del chip mientras se comunicaba con la impresora.
Creo que no será un simple chip de memoria, será un chip patentado desarrollado para hacerles la vida difícil a los ingenieros inversos, de modo que tengan que comprar sus cartuchos de impresora Canon para que puedan recuperar la pérdida que sufrieron al vender la impresora. Probablemente tendrá que ver cómo varían los datos con las condiciones del cartucho (ya que la tinta se agota) y resolverlo de la manera más difícil.
Gracias @RedGrittyBrick por recordárnoslo y sí, sé el punto de todo eso, pero por ahora estoy atascado en la segunda imagen que publiqué. Resto, puedo hacer un bit bang usando algún controlador después de comprender los datos del chip y su dirección. Pero, por ahora, la segunda imagen me está dando un problema, porque no tiene estructura ni simetría. Solo espero que alguien haya visto algún tipo similar de cambio de pulsos, pueda arrojar algo de luz.
Tal vez alguien que haya visto algo similar pueda responder, mientras tanto, si aún no lo ha visto, puede disfrutar de la ingeniería inversa de la interfaz LCD del iPod Nano 6.
Las áreas de datos que cambian rápidamente son probablemente solo un período de alta impedancia, una brecha entre escribir (¿un comando de lectura?) y obtener una respuesta.
Sí, ya lo había intentado de esta manera, es decir, ignorándolo. Parece funcionar sin ningún problema por ahora. Gracias

Respuestas (2)

Sugeriría simplemente romper el protocolo. Mi interpretación de las imágenes mostradas es:

Figura 1: Esto muestra el protocolo con un bit de sincronización y un reloj. Se envía un nuevo bit en cada pendiente descendente del reloj. (Como usted mismo ha descubierto)

Figura 2: El cambio rápido del carril de datos puede ser solo algo de ruido. Tal vez este sea el final de los datos enviados desde la impresora al cartucho.

Figura 3: Esta podría ser la respuesta del cartucho. Se tarda mucho más en enviar sus bits después del reloj. Probablemente su controlador sea mucho más lento que el de la impresora. (Esto es solo una especulación por ahora, pero podría tener sentido ya que la impresora probablemente solicite datos del cartucho y no viceversa)

Sugeriría conectar un microcontrolador a las líneas y monitorear las solicitudes y respuestas que se envían. Esto ayudaría a apoyar la teoría. Y al final tal vez puedas replicarlo. Incluso sin conocer el protocolo.

Lo siento, por responder tarde, ya que @apalopohaba sugirió que probablemente sea un período de alta impedancia, y los datos también tenían sentido con esto. Aunque perdí interés en este tiempo atrás y comencé algo más, un amigo mío analizó esto un poco más y también llegó a una conclusión similar.

Por lo general, cualquier protocolo es síncrono (señal de reloj separada) o asíncrono (los datos en sí tienen algún tipo de sincronización y el reloj está integrado).

Lo extraño de este protocolo es que la señal SYNC está en un período más bajo que el reloj, lo que significa que si el receptor usa el reloj para muestrear SYNC, nunca notará que la sincronización está cambiando. Solo puedo suponer que SYNC se usa como un reinicio asíncrono para que el receptor reinicie el conteo de bits (mal diseño, en mi humilde opinión).

En la figura 2, ve datos en un período aún más bajo. SI esto no es un problema de muestreo (ruido, mala conexión, etc.), me inclino a creer que en realidad no tiene reloj o que le falta una señal:

  • SYNC: es en realidad sincronización de fotogramas, especifica el inicio de un fotograma/bloque (fragmento de palabras).
  • CLK: en realidad es sincronización de palabras, especifica el comienzo de una palabra
  • DATOS - Son datos @ ~32MHz.

Sin embargo, esto es muy poco probable, de lo contrario significa que tiene muchos unos y ceros aquí.

Lo siento, por llegar tarde, ya que @apalopohaba sugirió que probablemente sea un período de alta impedancia, y los datos también tenían sentido con esto. Aunque perdí interés en este tiempo atrás y comencé algo más, un amigo mío analizó esto un poco más y también llegó a una conclusión similar.
Analizando el Protocolo
RespuestasAquíPolítica de privacidad1y, 0v