Cómo configurar NACK justo después del byte actual en TWI (ATMega8)

1

Tengo algo de experiencia con I²C (TWI) como la he usado 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. Yo mismo estoy definiendo el protocolo de comunicación, así que es algo flexible, pero pretendo que sea lo más eficiente posible (es decir, cuantos menos bytes, mejor).

Quiero que el esclavo establezca 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, como el esclavo, tengo que decidir 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 que se reciba el siguiente byte.

Por mucho que haya investigado 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.

Aparte de agregar bytes de relleno o de implementar una biblioteca I²C de bit banging, ¿hay alguna manera de resolver esto?

El controlador maestro es un NXP LPC2148, mientras que el controlador esclavo es un ATMega1284P.

Gracias.

    
pregunta Guillermo Prandi

1 respuesta

1

Por favor no hagas eso! Eso no es para lo que I²C ACK / NACK está destinado. 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 la señal del controlador principal sea un "Error de direccionamiento", y un NACK recibido durante una transferencia de N bytes hará que la señal del controlador principal sea un "Error de transmisión de datos" al conductor de llamadas Es decir, la cantidad de bytes enviados fue incorrecta o la suma de comprobación SMBUS falló.

Durante las transmisiones de lectura, el NACK generalmente denota el final de los datos a recibir.

¿Es eso lo que quieres señalar? ¡Apuesto que no!

EDITAR: Te doy un ejemplo. Por favor, eche un vistazo al DS28E17 Onewire al puente maestro I²C. Es un controlador de host I²C que reside en un bus onewire. Realiza todas las comunicaciones I²C de forma autónoma y usted no puede ( no puede ) recibir ACK / NACK individuales. Aconsejas a ese chip que escriba un número de bytes y lo hará felizmente. Pero no te dirá si el último bit fue ACK o NACK. Solo puede decirte si hubo un NACK inesperado. Por lo tanto, su esclavo rompe el protocolo y no se puede usar detrás de un DS28E17.

    
respondido por el Janka

Lea otras preguntas en las etiquetas