Aqui os dejo un ejemplo BASICo que permite distinguir el proceso de guardado y lectura de data de una eeprom(en este caso la CLASICA 24c32A) en forma I2C, usando el excelente comando BUSIN y BUSOUT.
-------------------------------------------------------------------------------------------------------------------
DEVICE 16F628A
CONFIG INTRC_OSC_NOCLKOUT,WDT_OFF,PWRTE_ON,CP_OFF,BODEN_OFF,LVP_OFF,MCLRE_OFF
ALL_DIGITAL ON
PORTB_PULLUPS ON
DECLARE LCD_DTPIN PORTA.0
DECLARE LCD_ENPIN PORTB.3
DECLARE LCD_RSPIN PORTA.4
DECLARE SDA_PIN PORTB.0
DECLARE SCL_PIN PORTB.1
DIM DIRECCION AS WORD "IMPORTANTE QUE SEA WORD, YA QUE SE USA
"UNA VARIABLE TIPO STRING
DIM VAR1[16] AS BYTE
DIM VAR2[16] AS BYTE
CLS
CLEAR DIRECCION
STR VAR1="TODOPIC TU FORO!"
PRINT "SALVANDO EN ROM" "COMPROBACION VISUAL DE ESCRITURA
BUSOUT %10100000,DIRECCION,[STR VAR1]
DELAYMS 500
CLEAR DIRECCION
CLS
PRINT "LECTURA DE ROM" "COMPROBACION VISUAL DE LECTURA
BUSIN %10100001,DIRECCION,[STR VAR2]
DELAYMS 500
CLS
PRINT STR VAR2 "IMPRESION DE DATOS,FORMATO TEXTO
DELAYMS 500
END
---------------------------------------------------------------------------------------------------------
Claro que esta es solo una forma de hacerlo, hay procesos mas metodicos usando los mismos comandos y a traves de los cuales se puede comprobar el correcto grabado y lectura de cada dato de la eeprom. Como anote en el comentario de la variable DIRECCION.. esta es importante definirla dependiendo de lo que se vaya a guardar(variable dato) ya que si hubiesemos usado una variable byte, no hubiera trabajado adecuedamente dicho proceso.
El Codigo de control o señalizacion ACK, depende de cada dispositivo y su lectura individual de DS, asi como la recomendacion de guardar dicha informacion en multiplos(cuando gravamos casi toda la eeprom con informacion) de 8 ya que en muchos casos es guardado en sectores desiguales produciendo errores(informacion basura) tanto de escritura como de lectura, practicamente es el mismo cuidado que hay que tener como cuando hacemos las declaracions de nuestras variables.(ya que se recomienda primero delcarar variables que soporten mayor contenido"floats" y luego las de menor contenido"bits", para evitar el mismo tiempo de problema de acomodo de informacion.) claro que con un codigo de comprobacion puede ayudarnos a evitar este proceso de optimizacion de codigo, sacrificando mas memoria al usar MAS CODIGO para dicha comprobacion.
Salu2 panas
