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

0 Usuarios y 1 Visitante están viendo este tema.

Desconectado fenix_jn

  • PIC18
  • ****
  • Mensajes: 418
RE: Analizador de bus I2C
« Respuesta #15 en: 02 de Septiembre de 2005, 14:14:00 »
Bueno en teoria seria cosa de enviar la data por otro pin, pero la cuestion es q eso solo funciona a 100 Khz porq a 400 Khz no habria mucho tiempo para generar el tren de pulsos para grabar en la otra memoria... no se si usando la EEPROM interna del PIC podamos resolver eso, no recuerdo cuanto era el tiempo de espera para grabar en esa memoria (1 mS???) pero si es asi creo q vamos a tner un problema con la velocidad

Desconectado Nocturno

  • Administrador
  • DsPIC33
  • *******
  • Mensajes: 18286
    • MicroPIC
RE: Analizador de bus I2C
« Respuesta #16 en: 03 de Septiembre de 2005, 00:04:00 »
Como la variable la tienes declarada como Float, no deberías tener problemas para almacenar una cifra superior, sin embargo, creo que tendrías menos problemas usando el int32.

De todas formas, si haces algunos cambios en tu fórmula, también debería funcionar con Float. Si quieres, prueba haciendo esto:

a=(((float)GET_TIMER1()*8.0)/1000.0);

Desconectado fenix_jn

  • PIC18
  • ****
  • Mensajes: 418
RE: Analizador de bus I2C
« Respuesta #17 en: 03 de Septiembre de 2005, 07:58:00 »
Estaba pensando... q tal si ponemos el # de muestras fijas?? del tamaño de la RAM sobrante? con eso el dato recibido en el bus solo habria q moverlo usando el FSR y INDO y no tendriamos q darnos mala vida con las EEPROM ni con el tiempo interno ni nada d eso, solo usemos la RAM sobrante del programa como buffer y ya, lo q podemos hacer es incluir una funcion q LUEGO guarde los datos en la eeprom si se desea.

Desconectado piriots

  • Colaborador
  • PIC24F
  • *****
  • Mensajes: 609
RE: Analizador de bus I2C
« Respuesta #18 en: 03 de Septiembre de 2005, 08:10:00 »
Muchas gracias Nocturno he puesto la formula com indicas y ya funciona. Pero con eso a mi no me basta.... Podrias explicarme el porque de poner ese float a la formula?

Ahora me las piro a una casa de Montaña un par de dias hasta el lunes por la noche no volvere por aqui.

Salu2

Desconectado piriots

  • Colaborador
  • PIC24F
  • *****
  • Mensajes: 609
RE: Analizador de bus I2C
« Respuesta #19 en: 05 de Septiembre de 2005, 14:48:00 »
Buenas!! ya vuelvo a estar por aqui. Gracias de nuevo por la explicacion Nocturno. A ver los registros FSR y INDO son para el direccionamiento indirecto?? He estado mirando el datasheet del 16f877 y no explica casi nada de esto. Para poder trabajar en c con estos registros habria que definirlos. A ver fenix si puedes explicar mejor tu idea porque yo de asm hace mas de un año que no toco nada, y trabajando en c al final te olvidas del todo de como trabaja internamente el micro, a parte que lo que hice en asm fueron cositas mu simples...

Salu2

Desconectado fenix_jn

  • PIC18
  • ****
  • Mensajes: 418
RE: Analizador de bus I2C
« Respuesta #20 en: 05 de Septiembre de 2005, 22:18:00 »
A ver, ok funciona asi, supongamos que limitamos la memoria a 30 datos, la idea es q cada vez q un dato sea recibido, sea enviado a una posicion "buffer" de RAM, el programa kedaria de esta forma (mas o menos)

Codigo:

indf   equ   00h ;IND0
fsr   equ   04h ;FSR
txbf_0   equ   10h ;Direccion ilustrativa de principio de buffer
txbf_29   equ   2Eh ;Ultima posicion de memoria (para 30 datos I2C)

incio
;rutina de inicializacion y preparacion de puertos y otras configuraciones

rcv_dt
;receptor de datos

;Esta rutina seria la encargada de recibir los datos y colocarlos en el buffer usando direccionamiento
;indirecto, usando este metodo, el proceso es muy rapido.
save_ram   movlw   txbf_0      ;Apunta a la 1ra posicion de RAMbuffer
      movwf   fsr
nx_dt      call   rcv_dt      ;Lee el bus
      movf   rxdata, w   ;Carga los datos en el buffer
      movwf   indf      ;y los envia a la direccion apuntada por el FSR
      incf   fsr, f      ;Verifica limite
      movf   fsr, w
      xorlw   txbf_29+1   ;Verifica si completo los 30 datos
      btfss   status, z
      goto   nx_dt      ;NO: Continua con la sig lectura
      return         ;SI: Termina el programa



Ahora, este codigo tiene como condicion q se deben recibir los 30 datos, una buena idea seria hacer "pooling" al registro q maneja el stop bit, al recibirlo entonces se saldria de la rutina y se iria a otra para mostrar los datos o para guardar los datos en la memoria serial

Desconectado piriots

  • Colaborador
  • PIC24F
  • *****
  • Mensajes: 609
RE: Analizador de bus I2C
« Respuesta #21 en: 08 de Septiembre de 2005, 15:05:00 »
IEeeeeeeeeeeeah!!! donde esta el post???? Aqui falta un post!!!!!!Ardiendo loco. Bueno supongo que algun error de mi@ habra acabado con el..... Volvere a escribirlo...

Bueno, almacenar los datos es simple, se haria un buffer de x posiciones, tantas como quepan en la ram sobrabte del pic o algunas menos, esto en c se hace un array de x elementos y solucionado. Para saber cuando hay que parar de escribir se miraria el ultimo elemento del array y si es distindo de 0 es que ya estan todos escritos, este seria el momento de guardar los datos en la eeprom si se desea.

Habria que detectar las condiciones de start, stop, y el bit de ACK. Para detectar estas condiciones no se si seria factible hacerlo de esta forma.

Habria que usar el modulo ssp del pic con su correspondiente interrupcion. Al entrar en la interrupcion se tendria que mirar el valor de los siguientes bits:

el bit 3 del registro SSPSTAT que corresponde a la concidion de start, el bit 5 del mismo registro que pertenece al bit de stop, el bit 6 del registro SSPCON2 que se pone a 1 cuando el master recive el bit de ack del slave. Supongo que para acceder a estos registros en c se tendrian definir previamente.

Hasta aqui es correcto??

La forma de captar el byte a almacenar no la tengo nada clara, se tendria que configurar el pic en modo maestro en recepcion. Otra cosa seria hacer que despues de recivir el byte no mande señal de ack para que no afectara a la comunicacion del circuito a analizar. Como seria la forma correcta de captar el byte a analizar???

Desconectado RaDoN

  • Moderadores
  • PIC24H
  • *****
  • Mensajes: 1498
RE: Analizador de bus I2C
« Respuesta #22 en: 08 de Septiembre de 2005, 15:30:00 »
¿Estamos hablando de registros? ¿Pero no sera en C? para detectar los bits de start y salida, estos tiene una particularidad, y se puede hacer usando cualquier linea del pic, una para SDA y otra para SCL.

La condición de inicio, es que mientras SCL este en alto, en SDA haya un flanco descencendente (de 1 a 0 vamos).

La condicion de de fín, es que mientras SCL este en alto, haya un flanco ascendente (de 0 a 1).

Se podría hacer, introduciendo la señal de SCL (el reloj) en una pata con interrupción externa, asi cuando se produzca, pasamos a testar el dato/bit/condición de SDA.

¿Que os parece?

Edito: añado, otra condicion del bus I2C, es que cuando se recibe los datos (bytes) no puede cambiar el estado de SCL (no haya transiciones), si no estariamos antes una condicion de inicio/fin y no recibiria el dato.
Si juegas contra el mejor, pierdes como los demás.

Desconectado piriots

  • Colaborador
  • PIC24F
  • *****
  • Mensajes: 609
RE: Analizador de bus I2C
« Respuesta #23 en: 08 de Septiembre de 2005, 15:52:00 »
Como bien dices sera en c , yo decia de definir estos registros y mirarlos porque si el pic puede detectar las condiciones de start, stop y el bit de ack por hard nos ahorrabamos de hacerlo por soft, ahunque no seria complicado hacerlo como dices tu.

Salu2

Desconectado RaDoN

  • Moderadores
  • PIC24H
  • *****
  • Mensajes: 1498
RE: Analizador de bus I2C
« Respuesta #24 en: 09 de Septiembre de 2005, 04:32:00 »
Si tienes razón, pero si suponemos que activamos este modulo, para que tire del hard, ten en cuenta que este aparto en la red i2c no debe ser ni un maestro (no va generar la señal de reloj), ni un esclavo (al que darle una dirección para que "se cosque"Giño, es un elemento para analizar, y debe ser "invisible para la red i2c".

Yo creo que es necesario hacer la rutina por soft, para que evalue lo que pasa en las 2 lineas.

¿O me equiboco ...? Angelito
Si juegas contra el mejor, pierdes como los demás.

Desconectado RaDoN

  • Moderadores
  • PIC24H
  • *****
  • Mensajes: 1498
RE: Analizador de bus I2C
« Respuesta #25 en: 11 de Septiembre de 2005, 19:01:00 »
¿Que pasó? ¿Esto sigue adelante? RollEyes
Si juegas contra el mejor, pierdes como los demás.

Desconectado piriots

  • Colaborador
  • PIC24F
  • *****
  • Mensajes: 609
RE: Analizador de bus I2C
« Respuesta #26 en: 12 de Septiembre de 2005, 08:46:00 »
Si si , tranquilo que el proyecto me interesa hacerlo, creo que es un instrumento que puede ser muy util, el problema que tengo es que hasta finales de noviembre salgo de casa a las 8 de la mañana y no vuelvo hasta las 10 de la noche...  Estoy mu jodido de tiempo!! pero poco a poco a ratitos ire haciendo, siempre teniendo en cuenta que el proyecto de fin de ciclo tiene prioridad...

Salu2

Desconectado fenix_jn

  • PIC18
  • ****
  • Mensajes: 418
RE: Analizador de bus I2C
« Respuesta #27 en: 12 de Septiembre de 2005, 23:02:00 »
Ok y en q lenguaje va esto?? en ASM puedo trabajar con lo dl FSR y el INDO (de hecho, el ejemplo de arriba es una de las rutinas q iria dentro  del programa)

rcv_dt debera contener un detector de stop bit y una rutina de timeout (sobretiempo) para detectar caidas en el bus (y el PIC no se nos kede en un ciclo perpetuo esperando por el pulso de CLK) y a mi rutina de buffer (save_ram) habria q ponerle un handler de errores,  o sea un registro dond se le diga q el dato q reciba no es un dato sino un error (como una linea D/E: data/error code, solo q en vez de un bit sera un registro completo q hara q la rutina haga algo en caso de error particular como mostrar el tipo de error en pantalla y autoguardar los datos cargados en el buffer si es q los hay)

Estaba pensando, si colocaramos un regulador de tension o algun tipo de aislant en la entrada podemos trabajar con RS232 y RS485 y generar el mismo concepto de almacenar datos para posterior analisis, preseleccionando el protocolo via hardware (usando interruptores o un menu en el LCD)... claro ya esto es pedirle mucho a un 16F84 (mas q todo por lo de la memoria ROM y RAM)


 

anything