Problemas con i2c 18f4550 [II] ccs 4.023

[manex_1987]

Buenas

Abro un nuevo hilo porque he pasado a una nueva fase. Con la ayuda del osciloscopio digital de la universidad (un promax de 150mhz chulisimo, lastima que no tuviera cable usb para mostraros las formas de onda del cacharro) he desvelado algunas incognitas.

Código: [Seleccionar]

#include <18f4550.h>
#use delay(clock=20000000)
#fuses HS,NOWDT,PUT
#use i2c(master,sda=PIN_D3,scl=PIN_D2)

int q;

void main()
{
   while(1)
   {
      i2c_start();
      i2c_write(0xa0);
      i2c_write(0x00);
      i2c_write(0xaa);
      i2c_stop();

      delay_us(100);

      i2c_start();
      i2c_write(0xa0);
      i2c_write(0x00);
      i2c_start();
      i2c_write(0xa1);
      q=i2c_read();
      i2c_stop();
   }
}
El codigo del ISR del slave... en su expresion mas basica, el soft del slave se basa en esto en un 99%. Yo creo que es necesario que veais este codigo para conocer la respuesta del i2c esclavo.

Código: [Seleccionar]


#INT_SSP
void ssp_interupt ()
{
   BYTE incoming, state;
   output_a(0xFF);
   
   

   state = i2c_isr_state();

   if(state < 0x80)                     //Master is sending data
   {
      incoming = i2c_read();
      if(state == 1)                     //First received byte is address
         address = incoming;
      if(state == 2)                     //Second received byte is data
         buffer[address] = incoming;
   }
   if(state == 0x80)                     //Master is requesting data
   {
      i2c_write(buffer[address]);
   }
}

Bien, visto asi, lo pongo a "hablar" con un 18f2550 a 48mhz, y total, que SDA y SCL estan a nivel bajo todo el rato. Probemos con este codigo:

Código: [Seleccionar]

#include <18f4550.h>
#use delay(clock=20000000)
#fuses HS,NOWDT,PUT
#use i2c(master,sda=PIN_D3,scl=PIN_D2)

int q;

void main()
{
   while(1)
   {
      i2c_start();
      i2c_write(0xa0);
      i2c_write(0x00);
      i2c_write(0xaa);
      i2c_stop();

      delay_us(100);

      i2c_start();
      i2c_write(0xa0);
      i2c_write(0x00);
      i2c_stop();  //AÑADO ESTO Y ELIMINO (TACHO) LO SIGUIENTE

      ****i2c_start();
      ****i2c_write(0xa1);
      ****q=i2c_read();
      ****i2c_stop();
   }
}

Vamos, que elimino el restart y la rutina de lectura. Voilá! El osciloscopio muestra vida. Con las comodidades del osciloscopio digital, logro observar toda la onda que se "trae entre manos" durante todo el programa. En los pines SDA y SCL, claro.
En fin... las ondas son correctas. Clock bien, se ven los start y los stop, los bytes son mandados correctamente, y hay ACK del esclavo. Vamos, que todo va bien. Pero cuando añado ese fragmento de codigo (ver diferencia entre el primer codigo y el segundo), todo se va al garete. No lo entiendo.

Alguien puede arrojar luz? Seguire aportando mas pistas, no pienso dejar de asistir a la universidad a trastear usando el osciloscopio este.

Un saludo!

[vszener]

No creo que el protocolo i2c te deje empezar una trama si antes no la paras, es decir, supongo que es normal, que la siguiente porción de código no te funcione:

Código: C

1. i2c_start();
2.       i2c_write(0xa0);
3.       i2c_write(0x00);
4.       i2c_write(0xaa);
5.       i2c_stop();
6.  
7.       delay_us(100);
8.  
9.       i2c_start();
10.       i2c_write(0xa0);
11.       i2c_write(0x00);
12.       i2c_start();
13.       i2c_write(0xa1);
14.       q=i2c_read();
15.       i2c_stop();

Como bien has realizado en el segundo código, paras la trama y despues la inicoas d enuevo

Suerte!!!

[manex_1987]

Esa porcion de codigo es completamente legal, pues el compilador CCS interpreta un "start" despues de otro "start" como un RESTART, algo necesario en la rutina de lectura. Ahora bien, puestos a pensar mal... no sera que el ccs se pasa de largo esa "asuncion"????

[pikman]

mANEX, te paso un dato, algun problema hay con el I2C en la 4.023, compile un codigo que quedo fucionando perfectamente en la version 3.190, simplemente es un 16F628 que lee y escribe una memoria 24C256 Y HACE LO QUE SE LE ANTOJA, para sacarme las dudas migre a mi placa de desarrollo y probe con un 16F877 por hardware y lo mismo no anda, cambie a un 18F452 y nada, tanto el 16F877 como el 18F452 fueron probados por soft y por hard, lo extraño es que con una aplicacion reciente si funciona por hardware, no pude descubrir porque.

Compile con la 3.249 y anda bien en todos lados, algo hay, cambie velocidad, cristales etc, mi conclusion es que pruebes con una version 3, pues evidentemente hay problemas graves con la version 4, pues cada vez que sale una nueva version reportan bugs que realmente no me parece que deberian estar, ademas de que te pueden volver loco.