Autor Tema: Analizador de bus I2C  (Leído 6376 veces)

0 Usuarios y 2 Visitantes están viendo este tema.

Desconectado piriots

  • Colaborador
  • PIC24F
  • *****
  • Mensajes: 609
Analizador de bus I2C
« en: 30 de Agosto de 2005, 14:16:00 »
Hola todopic!! El otro dia encontre un circuito muy simple que permite ver los bytes que se mandan por I2C y se me ocurrio la idea que podriamos diseñar un instrumento para poder ver la actividad del bus I2C. Se trataria de capturar las tramas que se mandan por I2C y guardarlas en una eeprom, luego mostrar estos bytes por un LCD y asi poder ver si lo que se esta mandando es realmente lo que queremos o no. Alguien se apuntaria al proyecto??

Salu2

Desconectado RaDoN

  • Moderadores
  • PIC24H
  • *****
  • Mensajes: 1498
RE: Analizador de bus I2C
« Respuesta #1 en: 30 de Agosto de 2005, 15:04:00 »
Me alegra que hayas abierto este hilo piriots, yo me apunto!!Rebotado
Si juegas contra el mejor, pierdes como los demás.

Desconectado piriots

  • Colaborador
  • PIC24F
  • *****
  • Mensajes: 609
RE: Analizador de bus I2C
« Respuesta #2 en: 31 de Agosto de 2005, 06:55:00 »
Para ir empezando con esto me he descargado el pdf que explica el protocolo I2C, son 50 paginas en perfecto ingles que hoy empezaré a estudiar.

Desconectado RaDoN

  • Moderadores
  • PIC24H
  • *****
  • Mensajes: 1498
RE: Analizador de bus I2C
« Respuesta #3 en: 31 de Agosto de 2005, 07:01:00 »
He leido algo cuando trataba con el ASM, no parece complicado el protocolo. Lastima que perdi ese pdf de comunicaciones síncrona con el SPI Llorando
Si juegas contra el mejor, pierdes como los demás.

Desconectado fenix_jn

  • PIC18
  • ****
  • Mensajes: 418
RE: Analizador de bus I2C
« Respuesta #4 en: 31 de Agosto de 2005, 09:35:00 »
Yo tngo las rutinas I2C (envio y recepcion) implementadas via software (para el 16F84 q NO tiene MSSP) pero son largas...

Desconectado piriots

  • Colaborador
  • PIC24F
  • *****
  • Mensajes: 609
RE: Analizador de bus I2C
« Respuesta #5 en: 31 de Agosto de 2005, 10:36:00 »
Son en asm o en C?? Si son en C podrias subirlas y le pegamos una ojeada a ver como son. Si son en asm las puedes subir tambien, ahunque hace tiempo que no toco nada de asm...

Desconectado Algec

  • Colaborador
  • PIC24F
  • *****
  • Mensajes: 974
RE: Analizador de bus I2C
« Respuesta #6 en: 31 de Agosto de 2005, 12:45:00 »
TAmbien me interesa, en C por favor, trataria de colaborar

Desconectado piriots

  • Colaborador
  • PIC24F
  • *****
  • Mensajes: 609
RE: Analizador de bus I2C
« Respuesta #7 en: 31 de Agosto de 2005, 19:28:00 »
Para poder a empezar a discutir sobre el tema explicare como tengo pensado que sea el sistema.

En principio la informacion se representaria en un LCD alfanumerico de 2x16, se podria usar una salida de pwm del pic para controlar la retroiluminacion del lcd, se configuraria con un pequeño menu en el lcd. La informacion a representar seria como dijo fenix_in de la siguiente forma.

I2C: 100Khz 1/20
S_ _ _ _ _ _ _ _A-P A3h

En la primera fila se representaria la frecuencia del bus y la trama que estamos analizando, en este caso la primera de 20.
En la segunda linea apareceria primero, el bit de start (en el caso que haiga), despues el byte a analizar en binario, seguidamente el bit ACK, la condicion de stop en el caso de que haiga, y finalmente el byte a analizar en codigo hexadecimal.  

Para almacenar los byts se usaria una EEPROM externa por ejemplo una 24LC256, alli se guardaria cada byte y la frecuencia a la que se ha enviado.  

El sistema se podria controlar con tres pulsadores,  2 para seleccionar el byte a estudiar, es decir uno para arriba y otro para abajo y un tercero que serviria para borrar todas las tramas almecenadas a la eeprom.

Para medir la frecuencia lo haria de la sigiente forma, usar el timer 1 como contador externo para que cuente los pulsos y hacer que salte la interupcion del timer 0 cada cierto tiempo para poder sacar la frecuencia. Por esto he dicho que la frecuencia tambien se almacenara en la eeprom, si no lo hacemos asi en el momento que dejemos de meter señal la frecuencia seria 0.

Segun las especificaciones del momento el pic deberia de tener por lo menos lo siguiente: 2 timers, una salida de PWM, 3 interrupciones externas, un modulo SSP y suficientes pines para poder controlar la LCD.

Para decidir el micro a utilizar hago las sigientes propuestas: un pic16F876, el inconveniente de usar este pic es que el lcd usa los puertos de interupcion externa. Una solucion seria usar un expansor de I2C PCF8574, por algun lugar he de tener la libreria de control... La otra opcion es usar un PIC16F877. Yo propongo el 16F877 por razones economicas, el PCF8574 en algunas tiendas llega a los 15€...

Menudo tocho!!!!! jajajaj enga a ver que os parece la idea

Desconectado Micom

  • Colaborador
  • PIC24F
  • *****
  • Mensajes: 782
RE: Analizador de bus I2C
« Respuesta #8 en: 01 de Septiembre de 2005, 00:43:00 »
Siguiendo con el tema de las patillas A0, A1, A2,A3 que quedo pendiente con Fenix_in.
Pues te soy sincero que he leido casi todos los data sheets de las memorias EEprom y en ninguna he visto que las patillas A0, A1, A2,A3 se han para cambiar la direccion del esclavo si he leido que se usan para direccionar la memoria mas alla de los 16kbits y que en el  data sheet de  las 24Cxx que van de la C01 a la C16 dice lo siguiente:

Codigo:
8.4 A0, A1, A2
The A0, A1 and A2 pins are not used by the 24XX16.
They may be left floating or tied to either VSS or VCC
.


y tambien dice:

Codigo:
3.6 Device Addressing
A control byte is the first byte received following the
Start condition from the master device (Figure 3-2).
The control byte consists of a four-bit control code.
For the 24XX16, this is set as ‘1010’ binary for read
and write operations. The next three bits of the control
byte are the block-select bits (B2, B1, B0). They are
used by the master device to select which of the eight
256 word-blocks of memory are to be accessed
.

These bits are in effect the three Most Significant bits
of the word address. It should be noted that the
protocol limits the size of the memory to eight blocks
of 256 words, therefore the protocol can support only
one 24XX16 per system.
The last bit of the control byte defines the operation to
be performed. When set to ‘1’, a read operation is
selected. When set to ‘0’, a write operation is selected.
Following the Start condition, the 24XX16 monitors the
SDA bus checking the device type identifier being
transmitted and, upon receiving a ‘1010’ code, the
slave device outputs an Acknowledge signal on the
SDA line. Depending on the state of the R/W bit, the
24XX16 will select a read or write operation


Bueno no se quien tenga la razon si Cekit o la data Sheet
en fin ojala podamos desenmarañar este asunto. Hasta pronto.
El programador GTP USB PLUS es un super programador
GRACIAS dobles amigo SISPIC

Tan solo queda seguir sobreviviendo

Desconectado Micom

  • Colaborador
  • PIC24F
  • *****
  • Mensajes: 782
RE: Analizador de bus I2C
« Respuesta #9 en: 01 de Septiembre de 2005, 01:00:00 »
Algo mas que hay que tener en cuenta es que el analizador del bus I2C tiene que tener una forma de diferenciar componentes conectados, supongamos que un  micro controle con el mismo bus un selector de canales y tambien una memoria, ahora al selector de canales solo le va a enviar puros comando como por ejemplo el comando de subida de canal o el comando de bajada de canal no le manda direcciones de memoria, en cambios a una memoria le manda direcciones de memoria  y datos para guadar en la direccion y tambien le manda una direccion de memoria y lee el dato,  asi que seria necesario que si se comunica con un esclavo memoria que tambien se almacene la direccion que leera o escribira el Micro y porsupuesto tambien el dato.  Hasta pronto.
El programador GTP USB PLUS es un super programador
GRACIAS dobles amigo SISPIC

Tan solo queda seguir sobreviviendo

Desconectado RaDoN

  • Moderadores
  • PIC24H
  • *****
  • Mensajes: 1498
RE: Analizador de bus I2C
« Respuesta #10 en: 01 de Septiembre de 2005, 08:14:00 »
Si el instrumento va analizar bus i2c (supuestamente porque hay algun problema), es un poco ilógico que este use una memoria para almacenar datos mediante este mismo bus loco

Suponiendo que se envia una trama larga de muchos bytes, que no pueden ser representados en pantalla, almacenarlos en la eeprom del pic no os parece? Supongo que sobrará. Y lo del regulador del contraste del LCD automatico... al que le guste vale, pero me parecen "pijadas" innecesarias, yo al menos quiero un instrumento sencillo y economico ¿No creen? Flash
Si juegas contra el mejor, pierdes como los demás.

Desconectado piriots

  • Colaborador
  • PIC24F
  • *****
  • Mensajes: 609
RE: Analizador de bus I2C
« Respuesta #11 en: 01 de Septiembre de 2005, 09:28:00 »
Yo tenia pensado usar un I2C Hardware para detectar las fallas del bus y otro por soft para controlar la eeprom, pero pensandolo mejor los byte a analizar no seran tantos como para llenar la eeprom del pic. Sobre el control de la retroiluminacion del LCD pues es una chorrada como otra, esto ya va a gusto de cada uno. Lo importante ahora es conseguir que el analizador haga su funcion, luego ya se vera si se le meten pijadas. Entre hoy y mañana seguire haciendo pruebas con el frecuencimetro que no creo que sea dificil de hacer.

Salu2
 

Desconectado fenix_jn

  • PIC18
  • ****
  • Mensajes: 418
RE: Analizador de bus I2C
« Respuesta #12 en: 02 de Septiembre de 2005, 09:55:00 »
Micom tienes razon en algo, 24XX16 (y creo q las series superiores a esta) no usa los pines porq ellas no lo permiten, sin embargo, las memorias debajo de ella (24XX08,04,02 y 01) si lo hacen, efectivamente, 24XX16 usa los 3 ultimos bits de seleccion no para seleccionar el chip sino sus bancos internos.

Hasta 24XX02 se usan A2,A1,A0; 04 usa solo A1, A2 y 08 solo usa A2. Creo q con esta nota damos por finalizada la discusion. Los dos tenemos razon pero en aspectos diferentes del mismo tema.

Sin embargo, la inclusion del selector A2, A1, A0 aun debera ser consideraba en el analizador debido a q no siempre estariamos tratando con memorias de 16 Kbits y en la posibilidad de q se encuentren memorias con menor designacion, el instrumento debera ser capaz de manejar incluso esas memorias.

Ahora esta un detalle particular, estamos suponiendo q solo existen memorias en el bus (como tb señala micom), q pasa si hay alguna otra cosa??, creo q la forma seria colocando al instrumento en "solo lectura" es decir, q solo reciba los pulsos o datos q esten el el bus y los presente en el LCD.

Aceca del problema en bus, bueno la idea es que el instrumento sea capaz de detectar el start bit a niveles suficientes para establecer comunicacion, si el start bit nunca llega hay problemas q no solo podrian estar en el bus sino en el micro, en los dispositivos conectados... en fin esa seccion se puede cubrir con un polimetro y conocimientos avanzados de los integrados q se encuentren conectados al bus.

La idea del analizador es efectivamente leer datos desde el bus y presentarlos al LCD (con o sin backlight) pero a la velocidad de comunicacion no habra tiempo de verlo asi q deben ser almacenados en la memoria para luego "estudiarlos".  En otra parte es verdad, los bytes a analizar no seran tantos... pero cuantos son??,  no se sabe, porq dependen del tiempo que invierta el usuario con la punta conectada al bus.

Aparte d eso tenemos la velocidad de transmision, a 100 KHz han pasado 100 bits por cada segundo q este la punta alli, si sacamos la cuenta es 12.5 bytes/segundo suponiendo que el instrumento se keda exactamente un segundo en el bus y q estamos leyendo la trama desde el principio, a 400 KHz temos 50 bytes/segundo (indistintamente sean bits de control, datos o lo q sea, el punto es q llamo "bit" a todas las posibles señales q podrian estar presentes en el bus), asi q no es necesaria una memoria externa SI SE VA A TENR el instrumento conectado por tiempo muy corto y NO se desea toda la trama o un estudio extensivo del bus, para ello podemos usar el EEPROM interna.

Desconectado RaDoN

  • Moderadores
  • PIC24H
  • *****
  • Mensajes: 1498
RE: Analizador de bus I2C
« Respuesta #13 en: 02 de Septiembre de 2005, 10:38:00 »
Si se usa una eeprom externa por bus i2c, tienes que escribir en esta a la velocidad que lees, es decir, por un lado estas leyendo y por el otro grabando (y a la vez recibiendo el nuevo byte que corre por el i2c). O soi yo que no lo entiendo, o así no me parece viable. Llorando
Si juegas contra el mejor, pierdes como los demás.

Desconectado piriots

  • Colaborador
  • PIC24F
  • *****
  • Mensajes: 609
RE: Analizador de bus I2C
« Respuesta #14 en: 02 de Septiembre de 2005, 11:27:00 »
Bueno el frecuencimetro "casi" funciona, es decir que funciona bien hasta los 65kHz, esto no es suficiente ni de coña, yo creo que esto se debe al desbordamiento de la variable que contiene la frecuencia. A ver si alguien que conozca bien como funciona el ccs me lo puede confirmar. Yo se el tamaño de las variables en c++, pero en ccs no lo tengo mu claro... ahi va el codigo. De momento esta hecho para un 16f876 pero tiene que ser para un 16f877, con cambiar el include y poca cosa mas ya funcionara.

Yo opino como tu Radon, a ver si alguien nos explica la forma de poderlo hacer con una eeprom externa si es que se puede.

Codigo:


#include <16f876.h>
#use delay(clock=4000000)
#define use_portb_lcd
#include <lcd.c>
#byte port_a=5
#byte port_b=6
#byte port_c=7
#fuses XT, NOPROTECT, NOPUT, NOWDT, NOBROWNOUT, NOLVP, NOCPD
static float a=0;

#int_timer0
void timer()
{
static byte timer_0_count=0;
if (timer_0_count<1)timer_0_count++;
else
   {
   timer_0_count=0;
   a=((GET_TIMER1()*8)/1000);
   lcd_gotoxy(0,1);
   printf(lcd_putc,"f %03.1f KHz",a);
   a=0;
 
   set_timer1(0);
   }
}
void main()
{
set_tris_a(0x1F);
set_tris_b(0);
set_tris_c(0xFF);
SETUP_TIMER_1(T1_EXTERNAL_SYNC);
set_timer1(0);
setup_timer_0(RTCC_INTERNAL | RTCC_DIV_256); // interrupcion cada 64ms*2=128ms
set_timer0(0);
enable_interrupts(int_timer0);
enable_interrupts(global);
lcd_init();

while(1)
   {
 
   }
}



 

anything