Publicado por: piriots en 30 de Agosto de 2005, 14:16:00
Salu2
Publicado por: RaDoN en 30 de Agosto de 2005, 15:04:00
Publicado por: piriots en 31 de Agosto de 2005, 06:55:00
Publicado por: RaDoN en 31 de Agosto de 2005, 07:01:00
Publicado por: fenix_jn en 31 de Agosto de 2005, 09:35:00
Publicado por: piriots en 31 de Agosto de 2005, 10:36:00
Publicado por: Algec en 31 de Agosto de 2005, 12:45:00
Publicado por: piriots en 31 de Agosto de 2005, 19:28:00
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
Publicado por: Micom en 01 de Septiembre de 2005, 00:43:00
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.
Publicado por: Micom en 01 de Septiembre de 2005, 01:00:00
Publicado por: RaDoN en 01 de Septiembre de 2005, 08:14:00
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?
Publicado por: piriots en 01 de Septiembre de 2005, 09:28:00
Salu2
Publicado por: fenix_jn en 02 de Septiembre de 2005, 09:55:00
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.
Publicado por: RaDoN en 02 de Septiembre de 2005, 10:38:00
Publicado por: piriots en 02 de Septiembre de 2005, 11:27:00
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)
{
}
}
Publicado por: fenix_jn en 02 de Septiembre de 2005, 14:14:00
Publicado por: Nocturno en 03 de Septiembre de 2005, 00:04:00
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);
Publicado por: fenix_jn en 03 de Septiembre de 2005, 07:58:00
Publicado por: piriots en 03 de Septiembre de 2005, 08:10:00
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
Publicado por: piriots en 05 de Septiembre de 2005, 14:48:00
Salu2
Publicado por: fenix_jn en 05 de Septiembre de 2005, 22:18:00
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
Publicado por: piriots en 08 de Septiembre de 2005, 15:05:00
. 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???
Publicado por: RaDoN en 08 de Septiembre de 2005, 15:30:00
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.
Publicado por: piriots en 08 de Septiembre de 2005, 15:52:00
Salu2
Publicado por: RaDoN en 09 de Septiembre de 2005, 04:32:00
, 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 ...?
Publicado por: RaDoN en 11 de Septiembre de 2005, 19:01:00
Publicado por: piriots en 12 de Septiembre de 2005, 08:46:00
Salu2
Publicado por: fenix_jn en 12 de Septiembre de 2005, 23:02:00
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)