Cómo configurar NACK en un PEC incorrecto en TWI utilizado para SMBUS (ATMega8) [duplicado]

1

Quiero implementar el protocolo SMBUS en mi dispositivo AVR (ATMega1284P), que tendrá el rol de esclavo. Necesito admitir la función PEC (código de error del paquete), lo que significa que el dispositivo maestro (que no es mío) enviará un byte de "suma de comprobación" después del último byte de su comando, al que debo responder con ACK o NACK Dependiendo de su validez.

Tengo algo de experiencia con I²C / SMBUS / TWI como la he usado antes, pero parece que no puedo resolver este problema en particular. Aparentemente, con la implementación TWI de AVR necesito decidir por ACK o NACK en el byte recibido anterior al valor PEC; es decir, en respuesta a un TWSR anterior = 0x80 (se han recibido datos). El problema es que no sé de antemano si el PEC que recibiré a continuación será válido o no. Aparentemente, establecer o borrar el bit TWEA solo es efectivo para recibir el siguiente byte. Ejemplo:

1 - ME     = Prepare for TWI slave operation; set address and ACK
2 - MASTER = Writes SLA+W (gets ACK from step #1)
3 - ME     = INT with TWSR 0x60; Sets ACK/NACK for next byte (ACK)
4 - MASTER = Sends Byte (gets ACK/NACK from step #3)
5 - ME     = INT with TWSR 0x80; Sets ACK/NACK for next byte (ACK)
6 - MASTER = Sends Byte (gets ACK/NACK from step #5)
7 - ME     = INT with TWSR 0x80; Sets ACK/NACK for next byte (ACK)
8 - MASTER = Sends PEC Byte (gets ACK/NACK from step #7)
9 - ME     = INT with TWSR 0x80 (PEC); too late to ACK/NACK PEC value!

Como puede ver, debo decidir por ACK / NACK en el paso # 9, ¡pero el maestro ya tiene un ACK establecido en el paso # 7!

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 implementar una biblioteca de SMBUS que golpea los bits, ¿hay alguna manera de resolver esto?

Gracias.

    
pregunta Guillermo Prandi

1 respuesta

0

Este es el principal problema al intentar hacer un esclavo SMBUS con PEC en el software. Y, de hecho, se menciona en las normas, así como una de las razones por las que la PEC no es obligatoria, pero se sugiere enérgicamente.

Eso significa que un maestro puede no suponer, según las mejores prácticas sugeridas en la norma, que un esclavo que envía un ACK en el último byte en realidad indicó que el PEC se codificó correctamente. Lo único obligatorio es que si se envía un PEC y no es válido, los datos deben descartarse.

La única forma confiable de hacer PEC y NACK como quiera es si tiene soporte de hardware para CRC8-CCITT (el polinomio de PEC es el poli del CCITT) o SMBUS, o preferiblemente ambos.

Su MCU elegida no se puede hacer para hacer hardware I2C y también le permite decidir el bit ACK en el último minuto. Eso no es algo que la gente quiera poner en cada microcontrolador. En 9 de 10 casos, el hecho de que el esclavo espere que otro byte sea suficiente para ACK. O posiblemente 99 de cada 100 incluso.

Podría piratearlo con hardware para poder "NACK" justo a tiempo con un pin de IO adicional, pero eso significaría que necesita hacer que su CRC sea muy eficiente, o llegará demasiado tarde.

    
respondido por el Asmyldof

Lea otras preguntas en las etiquetas