Tengo algo de experiencia con I²C (TWI) como lo usé antes, pero parece que no puedo resolver este problema en particular. Tengo la intención de comunicar dos CPU a través de I²C. Uno es siempre el amo y el otro es el esclavo. Estoy definiendo el protocolo de comunicación yo mismo, por lo que es algo flexible, pero tengo la intención de que sea lo más eficiente posible (es decir, cuantos menos bytes, mejor).
Quiero que el esclavo configure NACK para ciertos valores; por ejemplo:
MASTER = START + sends SLAVE ADDRESS
SLAVE = sets ACK
MASTER = sends any one "byte" command
SLAVE = sets ACK or NACK depending if "byte" was a valid command or not.
La última declaración es el problema, porque aparentemente yo, como esclavo, tengo que decidirme por ACK o NACK antes de recibir el comando de un "byte"; es decir, en respuesta a TWSR = 0x60 (SLA+W recibido). El problema es que no sé de antemano si el comando será válido o no. Aparentemente, establecer o borrar el bit TWEA solo es efectivo para recibir el siguiente byte.
Por mucho que investigué en los documentos, no puedo encontrar una manera de responder con NACK "sobre la marcha" porque ATMega establece la interrupción DESPUÉS de enviar el ACK (o NACK). TWSR será 0x80 o 0x88, lo que significa "byte recibido, ACK enviado" y "byte recibido, NACK enviado", respectivamente.
Además de agregar bytes de relleno o implementar una biblioteca I²C de bits, ¿hay alguna forma de resolver esto?
El controlador maestro es un NXP LPC2148, mientras que el controlador esclavo es un ATMega1284P.
Gracias.
¡Por favor, no hagas eso! Eso no es para lo que están destinados los I²C ACK/NACK. Se entienden como elementos de protocolo, no como parte de los datos.
Por ejemplo, un NACK recibido al enviar la dirección del dispositivo hará que el controlador del host señale un "Error de direccionamiento", y un NACK recibido durante una transferencia de N bytes hará que el controlador del host señale un "Error de transmisión de datos" al controlador que llama. Es decir, la cantidad de bytes enviados fue incorrecta o la suma de verificación de SMBUS falló.
Durante las transmisiones de lectura, el NACK generalmente indica el final de los datos para recibir.
¿Es eso lo que quieres señalar? ¡Apuesto a que no!
EDITAR: Te doy un ejemplo. Eche un vistazo al puente maestro DS28E17 Onewire a I²C. Es un controlador de host I²C que reside en un bus de un solo cable. Hace toda la comunicación I²C de forma autónoma y no puedes ( no puedes ) recibir ACK/NACK individuales. Le aconsejas a ese chip que escriba una cantidad de bytes y lo hará felizmente. Pero no le dirá si el último bit fue ACK o NACK. Solo puede decirle si hubo un NACK inesperado. Entonces, su esclavo rompe el protocolo y no puede usarse detrás de un DS28E17.
Guillermo Prandi
Guillermo Prandi
Janka
Guillermo Prandi
Janka
Guillermo Prandi