I2C PIC16F88 Esclavo No Funciona

[DominusDRR]

Pues con buenas y malas noticias

La buena es que ahora se que sucede con la comunicacion, he simulado en Proteus, y no se obtiene nunca el reconocimiento (ack), por ello la interrupcion salta pero no obtiene respuesta confirmatoria del esclavo, por ello, no hace nada de nada.

Para comprobar que lo estaba haciendo correcto en proteus, he simulado tambien, un programa que tengo mas que probado (esta operando en varias maquinas) y en ese, si que obtengo la respuesta del esclavo sin problema.

Ahora el tema sera, porque no reconoce su direccion el esclavo.

Adjunto imagen de la simulacion, donde se aprecia en el paquete que devuelve, el NACK

Seguimos avanzando.

  - Tienes que ingresar para ver archivos adjuntos -

Pregunta

¿No deberías hacer esto en el lado del esclavo?

Código: C

1. if(state==0) //Address match received with R/W bit clear, perform i2c_read( ) to read the I2C address.
2. {
3.       i2c_read();
4. }

[thegame]

Que tal Compañero Dominus

Lo de la direccion esta correcto, me refiero a que el esclavo deberia mandar un Ack cuando la direccion enviada por el maestro coincide con la suya, y no lo hace con la direccion 0x99, porque?, desconozco, la he cambiado a 0x50, y ahora si me envia el ack de que reconoce que es a el al que se le habla

despues de eso, seguia sin obtener ese bit de ack cuando enviaba datos, es decir, enviada direccion y respondia ACK, seguido de ello, mandaba un dato, y obtenia un NACK, entonces, hice lo que dices, pongo el i2c_read() despues de obtener estate ==0, pero seguia igual, reconocia la direccion pero no el dato.

de tantos post que he leido, recorde un compañero que mencionaba que el tuvo que probar con diferentes frecuencias en el slave, hasta donde observo que no tenia problemas, yo creo que se debe al timing que el protocolo debe tener asi que lo e intentado y al parecer, al menos en la simulacion, ahora si responde en ambos casos, direccion y dato, la he cambiado de 4Mhz a 8Mhz y como veras en la imagen, ya se ven los bits de ACK

Aun me falta probar en fisico, como te comente, no soy muy fan de proteus aunque hoy me ha sido de mucha ayuda

cuando tenga resultados del funcionamiento en fisico te comento.

Saludos y mil gracias por la ayuda

[DominusDRR]

Pregunta

¿No deberías hacer esto en el lado del esclavo?

Código: C

1. if(state==0) //Address match received with R/W bit clear, perform i2c_read( ) to read the I2C address.
2. {
3.       i2c_read();
4. }

Yo decía del i2c_read porque según entiendo (tal vez mal) i2c_read genera un ACK y tal vez por eso el esclavo no lo genera (mirar imagen)

[DominusDRR]

¿Y estás depurando tu código sin los delays?

Entre retardo y retardo es posible que se te pierda algo que envía el esclavo.

Pienso yo que deberías quitarlos.

[thegame]

es correcto retire los delays, y modifique la rutina de recepcion en la interrupcion del esclavo, y cambie de frecuencia a 8 Mhz y  ahi, al menos en la simulacion trabaja ya como deberia

la condicion que regresa i2c_read, por default genera el ACK, y si lo hace bien con las modificaciones mencionadas

ya solo me falta probar en fisico

saludos

[DominusDRR]

es correcto retire los delays, y modifique la rutina de recepcion en la interrupcion del esclavo, y cambie de frecuencia a 8 Mhz y  ahi, al menos en la simulacion trabaja ya como deberia

la condicion que regresa i2c_read, por default genera el ACK, y si lo hace bien con las modificaciones mencionadas

ya solo me falta probar en fisico

saludos

Con el osciloscopio deberías observar que frecuencia tenía el reloj antes y luego de la mejora, para determinar si cambia con lo que dices.<

Si no se mantiene en 100 Hkz, implica que el compilador tiene algún problema.

[remi04]

Haz una cosa.

  Lee el registro SSPxM (la x sustituye el número de módulo que usas), y saca su valor con un printf.   Esto es para ver cómo la directiva te está configurando el origen del reloj del módulo SSPx

  Por otro lado, si puedes pon la configuración de todos los registros del oscilador que estás usando.

  Hay ocasiones en las que al pic no le resulta posible bajar a 100 khz, especialmente cuando se usan los PLL y te acaba trabajando a 250 u otra frecuencia distinta de la que esperabas.

  También puedes medirla con el osciloscopio en el pin clk.

  Saludos 

[thegame]

Que tal remi04

Desgraciadamente no cuento con osciloscopio para medir la frecuencia en el pin clk

creo que el tema de la velocidad del bus pudiese afectar en el lado del esclavo, hare lo que me indicas y les publico el resultado.

por lo pronto, decir que, en fisico, ya no obtengo el 0xFF en el maestro como inicialmente, ahora es un espantoso 0x00 siempre 

sigue sin funcionar en fisico, en la simulacion, agregue el PIC maestro, y o sorpresa, no hace nada de nada, pense que ahi tendria buenos resultados, pero no es asi, el I2C debug, me muestra cosas ilegibles, adjunto la imagen

sigo tratando de resolverlo con el 16F88, pero creo que ya ire pensando en una alternativa, aunque me resisto a dejarme vencer por el problema.

Saludos y gracias por los consejos y ayuda

 

fallo_3_comunicacion_errores.jpg
(67.5 kB, 726x333 - visto 319 veces)

[thegame]

Mi problema me parece que no es en la velocidad de comunicacion a 100Khz

Creo que mi problema esta en la rutina de lectura desde el maestro, y por ende, la funcion en el esclavo, me explico

He probado una rutina simple de escritura, solo escritura, y he puesto el siguiente codigo en el esclavo:

Código: [Seleccionar]

//Interrupcion por recepcion de I2C
#INT_SSP
void recepcion_i2c(void)
{
   dato=i2c_read(sensor);
   
   if(dato==0x50)
   {
      dato=' ';
   }
   else if(dato=='A')
   {
      output_high(PIN_A1);
   }
}

Y desde el maestro, he mandado hacer lo siguiente:

Código: [Seleccionar]

            i2c_start(i2c_maestro);       //Inicio comunicacion
            ack2=i2c_write(i2c_maestro,0x50);  //Escribo direccion del esclavo
            if(ack2==0) //Si el bit de reconocimiento es valido
            {
               i2c_write(i2c_maestro,'A');     //Escribo el caracter a enviar al esclavo
            }
            i2c_stop();

Y funciona de maravilla, en fisico, sin problema

El maestro a 20Mhz, y el esclavo a 16Mhz, a 8Mhz y a 4Mhz, a la que ponga, funciona esta rutina

Entonces, mi bus I2C si que funciona, pero no estoy leyendo como debe ser, mi problema es la bendita lectura     

[thegame]

SOLUCIONADO 

Me ha costado un poco, pero como he aprendido, he combinado lo que ya sabia hacer, con lo aprendido, se los comparto.

En el esclavo, he puesto lo siguiente:

La directiva de configuracion del I2C para el esclavo queda asi

Código: [Seleccionar]

#use i2c(SLAVE,SCL=PIN_B4,SDA=PIN_B1,ADDRESS=0x50,SLOW=100000,STREAM=sensor)
y el codigo en la rutina de interrupcion la he echo de la siguiente manera

Código: [Seleccionar]

//Interrupcion por recepcion de I2C
#INT_SSP
void recepcion_i2c(void)
{
   state=i2c_isr_state(sensor); 
   
   if(state<0x80)
   {
      dato=i2c_read();
      if(dato==0x50)
      {
         dato=' ';
         escritura=1;
      }
      else if(escritura==1)
      {
         address=dato;
         dato=' ';
         escritura=0;
      }
     
      if(dato==0x51)
      {
         dato=' ';
         lectura=1;
      }
   }
   else if(state>=0x80)
   {
      i2c_write_slave(buffer[address]);
      dato=' ';
      lectura=0;
   }
}

En el maestro, la directiba para el I2C queda asi

Código: [Seleccionar]

#use i2c(MASTER,SCL=PIN_C3,SDA=PIN_C4,SLOW=100000,FORCE_HW,STREAM=i2c_maestro)
y la solicitud de datos o lectura la hago asi:

Código: [Seleccionar]

            i2c_start(i2c_maestro);       //Inicio comunicacion
           
            ack2=i2c_write(i2c_maestro,0x50);  //Escribo direccion del esclavo
           
            if(ack2==0)
            {
               i2c_write(i2c_maestro,0);     //Escribo la posicion quw quiero leer del esclavo
            }
           
            i2c_start(i2c_maestro);       //Reinicio el protocolo
           
            ack2=i2c_write(i2c_maestro,0x51);  //Escribo direccion del esclavo + 1 (para lectura)
           
            if(ack2==0)
            {
               dato=i2c_read(i2c_maestro,0); //Leo la posicion previamente enviada
            }
            i2c_stop();                   //Detengo la comunicacion

Los PIC quedan operando uno a 20Mhz (maestro 18F46K22) y otro a 16Mhz (esclavo 16F88)

Lo he probado en fisico, y funciona bien 

Ojala a alguien le sirva esta experiencia, si algo no esta claro, con gusto lo aclaramos

Saludos y muchas gracias compañeros

P.D.: Si algun moderador me hiciera favor de agregar en el titulo del post el [SOLUCIONADO] se lo agradecere mucho

[DominusDRR]

SOLUCIONADO 

Me ha costado un poco, pero como he aprendido, he combinado lo que ya sabia hacer, con lo aprendido, se los comparto.

En el esclavo, he puesto lo siguiente:

La directiva de configuracion del I2C para el esclavo queda asi

Código: [Seleccionar]

#use i2c(SLAVE,SCL=PIN_B4,SDA=PIN_B1,ADDRESS=0x50,SLOW=100000,STREAM=sensor)
y el codigo en la rutina de interrupcion la he echo de la siguiente manera

Código: [Seleccionar]

//Interrupcion por recepcion de I2C
#INT_SSP
void recepcion_i2c(void)
{
   state=i2c_isr_state(sensor); 
   
   if(state<0x80)
   {
      dato=i2c_read();
      if(dato==0x50)
      {
         dato=' ';
         escritura=1;
      }
      else if(escritura==1)
      {
         address=dato;
         dato=' ';
         escritura=0;
      }
     
      if(dato==0x51)
      {
         dato=' ';
         lectura=1;
      }
   }
   else if(state>=0x80)
   {
      i2c_write_slave(buffer[address]);
      dato=' ';
      lectura=0;
   }
}

En el maestro, la directiba para el I2C queda asi

Código: [Seleccionar]

#use i2c(MASTER,SCL=PIN_C3,SDA=PIN_C4,SLOW=100000,FORCE_HW,STREAM=i2c_maestro)
y la solicitud de datos o lectura la hago asi:

Código: [Seleccionar]

            i2c_start(i2c_maestro);       //Inicio comunicacion
           
            ack2=i2c_write(i2c_maestro,0x50);  //Escribo direccion del esclavo
           
            if(ack2==0)
            {
               i2c_write(i2c_maestro,0);     //Escribo la posicion quw quiero leer del esclavo
            }
           
            i2c_start(i2c_maestro);       //Reinicio el protocolo
           
            ack2=i2c_write(i2c_maestro,0x51);  //Escribo direccion del esclavo + 1 (para lectura)
           
            if(ack2==0)
            {
               dato=i2c_read(i2c_maestro,0); //Leo la posicion previamente enviada
            }
            i2c_stop();                   //Detengo la comunicacion

Los PIC quedan operando uno a 20Mhz (maestro 18F46K22) y otro a 16Mhz (esclavo 16F88)

Lo he probado en fisico, y funciona bien 

Ojala a alguien le sirva esta experiencia, si algo no esta claro, con gusto lo aclaramos

Saludos y muchas gracias compañeros

P.D.: Si algun moderador me hiciera favor de agregar en el titulo del post el [SOLUCIONADO] se lo agradecere mucho

Una pregunta

¿Y qué mismo fue el problema? No lo capto aún.

[thegame]

Que tal Dominus, te enlisto los dos cambios que resolvieron el problema

1.- En principio la direccion que configure en el esclavo no la tomaba (0x99), nunca respondia, la cambie (0x50) y empezo a responder

2.- Cambie la rutina de recepcion en el esclavo, la que muestro, porque no enviaba el dato correcto, me mandaba un 0x00 siempre

en general son los dos cambios importantes que hice, aunado a esto, probe el cambio de cristales a diferentes frecuencias, cambie la estructura de la directiva de I2C, los delays, la frecuencia del bus, etc etc

Pero en realidad, con los dos primeros puntos trabaja sin problema.

Saludos

[DominusDRR]

Que tal Dominus, te enlisto los dos cambios que resolvieron el problema

1.- En principio la direccion que configure en el esclavo no la tomaba (0x99), nunca respondia, la cambie (0x50) y empezo a responder

2.- Cambie la rutina de recepcion en el esclavo, la que muestro, porque no enviaba el dato correcto, me mandaba un 0x00 siempre

en general son los dos cambios importantes que hice, aunado a esto, probe el cambio de cristales a diferentes frecuencias, cambie la estructura de la directiva de I2C, los delays, la frecuencia del bus, etc etc

Pero en realidad, con los dos primeros puntos trabaja sin problema.

Saludos

Bueno tener presente para la próxima.

Sólo con un analizador lógico que muestre las formas de onda (o un osciloscopio) se podría determinar que pasaba cuando la dirección era 0x99

[thegame]

Si tienes toda la razon, ya estoy por comprarme uno, es como bien se dijo, indispensable cuando se trabaja constantemente con estos sistemas.

Muchas gracias Dominus y compañeros

Saludos