Cómo garantizar la integridad de los datos cuando se utiliza I2C con un PIC

Navega tus respuestas
2

Cuando el dispositivo maestro transfiere una parte de los datos, el esclavo responderá una vez que el esclavo haya recibido los datos. Por lo tanto, no es posible garantizar la integridad de los datos solo mediante el sondeo ACK.

Implementé una función C: 

unsigned char i2c_write_byte(unsigned char s);

Aquí estoy devolviendo el bit ACKSTAT. Entonces, si no hay un ACK enviado por el esclavo, intentaré enviar los datos nuevamente usando: 

while(!i2c_write_byte(data));

Sé que el noveno reloj es para ACK, pero qué pasa si no hay un ACK enviado por el dispositivo esclavo. Entonces debería detectarse como NACK, lo que significa que el esclavo no logró un SDA bajo, que es el esclavo que nunca recibió datos transferidos.

Entonces, en esta ocasión, ¿debo enviar datos nuevamente o enviarlos después de un reinicio?

Solo puedo pensar en volver a enviar datos para solucionar el problema de NACK y aún no puedo resolver el error ocurrido en los datos mientras estaba en una transferencia.

Entonces, ¿cómo garantizar la integridad de los datos en I2C?

    
pregunta longtengaa

2 respuestas

3

Si tiene problemas graves de integridad de datos con su bus IIC, primero debe consultar el hardware para ver por qué los datos se corrompen. En un sistema adecuadamente diseñado, los NACK no deberían ocurrir de manera específica para que el esclavo indique que no puede tomar más datos. NACK a un byte de dirección significa que has enviado la dirección incorrecta. Eso no debería suceder a menos que esté sondeando deliberadamente para ver qué direcciones están disponibles. NACK a un byte de datos donde NACK no se usa para indicar que el esclavo no puede tomar más es un error de firmware o debido a un ruido excesivo en la línea SCL.

Tenga en cuenta que ACK no significa que se haya recibido un byte correctamente. Aparte del byte de dirección, solo significa que el reloj se recibió correctamente. NACK es bastante inútil para comprobar si hay daños en los datos, ya que cuando recibes NACK debido al ruido del bus, tienes problemas de sistema mucho más grandes.

NACK inesperado significa que algo salió mal, pero realmente no sabes qué. Es mejor abortar todo el mensaje porque no sabes cuán confundido está el esclavo en ese momento. Haz una parada, luego un comienzo antes del siguiente mensaje. Eso debería restablecer la capa de protocolo de bajo nivel de todos los esclavos. Quizás pueda volver a intentar el mensaje una o dos veces, pero lo más probable es que tenga un problema de nivel superior que, por lo tanto, debe ser tratado por niveles más altos de firmware.

    
respondido por el Olin Lathrop
2

Además de la respuesta de Olin:

Es posible que desee ver algunos protocolos que usan I2C como su base, como SMBus (o PMBus):

  • Estos protocolos introducen una suma de comprobación de error de paquete (PEC), que es una verificación de CRC de todo el mensaje. El esclavo transmitirá su PEC computado y el maestro calculará el suyo propio. Si coinciden, no te preocupes. De lo contrario, descarte los datos y vuelva a intentar la transacción desde la parte superior.

  • Estos protocolos establecen un límite superior de tiempo de espera para el estiramiento del reloj, lo que obliga al hardware I2C a restablecerse si la transacción demora demasiado. Pure I2C puede tener alargamiento indefinido del reloj.

Además, no tengas miedo de golpear el autobús tan fuerte como puedas como prueba de conflicto. Solía confiar en los maestros I2C (iPort y Aardvark) disponibles para caracterizar el rendimiento de nuestros productos en el banco, pero rápidamente descubrí que eran incapaces de ejercer el bus lo suficientemente rápido para descubrir problemas de firmware como condiciones de carrera o abrumadoras. del mecanismo de programación de tareas. Terminé escribiendo mi propio maestro de bus en C / inline assembly (usando un dsPIC a 50 MIPS) específicamente para ejercer la interfaz I2C / PMBus tan rápido como el esclavo lo permitiría con latencia trivial. Wow, encontré problemas :)

    
respondido por el Adam Lawrence

Lea otras preguntas en las etiquetas

Usando BRAM en lugar de SRAM en Virtex-5 FPGA Cables blindados y trenzados