Experiencia con I2C en proteus, 3 PIC, 1 Master 2 Slaves

[alcubo01]

 Hola, quiero dejar constancia de los problemas que he tenido a la hora de montar un bus I2C en proteus por si son de utilidad para alguien.

 Para la simulación he usado: Proteus 7.6 SP0
 Para la compilación del código: PICC 4.093


 Las pruebas que he hecho son:

 1- Montar el bus con 2 x 16f876a, 1 Master + 1 Slave.

      + Pruebas satisfactorias lectura / escritura correctas


 2- 3 x 16f876a, 1 Master + 2 Slaves. Usé el mismo código en los dos Slaves (cambiando la dirección I2C).

      + Si durante la ejecución el Master se comunica "sólo" con Slave_1 puede leer / escribir correctamente

      + Si durante la ejecución el Master se comunica "sólo" con Slave_2 puede leer / escribir correctamente

      + Si durante la ejecución el master comienza a comunicarse con un Slave y luego pasa a comunicarse con el otro,
         la comunicación con el primero será correcta pero en cuanto comienza a comunicarse con el segundo todo falla,
         el bus se queda bloqueado. Los slaves no reciben ninguna interrupción I2C. En este punto se hace imposible reestablecer
         la comunicación con nadie.

         Al estar en esta situación de bloqueo y mirar con el osciloscopio se ve que cuando el master hace STOP las lineas SDA
         y SCL pasan a nivel alto y al hacer START pasan a nivel bajo. Todo parece estar igual que al comienzo de la simulación,
         sin embargo al intentar comunicarnos con un Slave para lectura/escritura, este no recibe la interrupción.


 3- Montar el bus con 2 x 18f2550, 1 Master + 1 Slave.

      + Pruebas satisfactorias lectura / escritura correctas


 4- 3 x 18f2550, 1 Master + 2 Slaves. Usé el mismo código en los dos Slaves (cambiando la dirección I2C).

      + Obtuve los mismos resultados que con 3 x 18f876a



      Un saludo, Alberto

[Suky]

Que se bloquee el bus es correcto, cuando inicias una comunicación la terminas  Sino ese Start que colocas en el medio se toma como un re-start que confunde al dispositivo con el cual ya has establecido comunicación.


Saludos!

[alcubo01]

 En el código que estoy ejecutando, hago un par de lecturas seguidas, una a Slave_1 y la otra a Slave_2.

 Cada lectura empieza con Start y termina con Stop. Entre medio de las dos operaciones (stop de la primera y start de la segunda), dejo transcurrir unos 100ms.

 
  El código de lectura que ejecuta el Master para cada Slave es el siguiente:

   

Código: [Seleccionar]


   i2c_start ();            // inicio del protocolo I2C

   i2c_write (0x61);    // Direccion de Slave + Read

   /*

   i2c_write (x);       Direccion de memoria que queremos leer. Por simplicidad para las pruebas,
                              el codigo del cliente no lo espera y devuelve siempre el mismo valor
   */

   result = i2c_read();    // Leemos el dato

   i2c_stop ();               // Paramos la comunicacion con el esclavo

   delay_ms(100);

   printf("\r\n 2_A Result[%d] = %d \r\n",x,result);     // Para Debug

   


   El codigo que ejecuta el Slave es el siguiente:

Código: [Seleccionar]


  #INT_SSP
void ssp_interupt ()
{

    state = i2c_isr_state();   //Leemos el estado


    if(state < 0x80)                     //El master nos envia datos
    {
         incoming = i2c_read();

         if(state == 1)                      //Llega una direccion
              address = incoming;

         else if(state == 2)                   //Llega un dato
             buffer[address] = incoming;
   }


   if(state == 0x80)                     //El Master pide un dato
   {
      i2c_write(buffer[address]);  //Enviamos el dato

      incoming = i2c_read();   //Lectura necesaria, sino se queda bloqueado el Master
   }

}


   
   Lo que me parece muy extraño es que el problema sólo existe al cambiar el Slave, si continuo haciendo operaciones sobre el mismo (aunque los dos estén conectados al bus), todo va bien.

   El tema de la lectura en el Slave después del write también me mosquea...   


 Un saludo
 

         

[karpegui]

 Te cuento mi experiencia con una version anterior del Proteus. Tratando de comunicar un master con varios slaves descubri que los slaves respondian a todas las direcciones I2C por lo que se producian errores en la comunicacion. Antes de seguir comprueba en el ejemplo que tienes con un solo esclavo que cuando intentas escribir en el con distintas direcciones solo responde a la que tu le has programado.

PD En el montaje real funcionaba correctamente, asi que no te fies tanto del Proteus

[alcubo01]

 Lo acabo de probar y los esclavos sólo responden a su dirección.

 Tiene pinta de que acabaré depurando el código en la protoboard...

[calornat10]

alcubo01, consulta:

La prueba en el protoboard te funcionó? era un problema de simulación en proteus??

Tengo el mismo problema.

Gracias.

[daverzo]

alcubo01, consulta:

La prueba en el protoboard te funcionó? era un problema de simulación en proteus??

Tengo el mismo problema.

Gracias.

Ya hable con alcubo01 y me informa que funciono en protoboard aunque no en simulacion 

[ComePic]

      + Si durante la ejecución el master comienza a comunicarse con un Slave y luego pasa a comunicarse con el otro,
         la comunicación con el primero será correcta pero en cuanto comienza a comunicarse con el segundo todo falla,
         el bus se queda bloqueado. Los slaves no reciben ninguna interrupción I2C. En este punto se hace imposible reestablecer
         la comunicación con nadie.
 

Hola alcubo01

Yo también tuve el mismo problema, pero después de una larga espera el problema ya fue solucionado.

Al parecer el i2c debugger de proteus era el que presentaba el problema y no los pic ni el compilador por supuesto.
El problema lo estuve viviendo hasta la versión 7.10 de proteus. Ahora tengo instalada la versión 8.0 SP0 y esta versión
ya no presenta este problema.

Se puede simular perfectamente, sin embargo en esta nueva entrega de proteus el cambio
es bastante grande y con respecto a simulación quedo con un problema. La simulación desde el archivo .cof para hacer
ejecución paso a paso no responde.

Unas por otras .... pero es algo que seguramente lo resuelven rápido.

Saludos.