Publicado por: Elena2000 en 17 de Septiembre de 2003, 11:06:00
Prometí ordenar lo de mi alarma y ponerlo en el foro, así que empiezo YA, porque veo que se me van pasando los días...... y a pesar de que hoy no luzco precisamente la mejor de mis sonrisas, creo que el contaros cómo llevo mi proyecto me animará, así que allá voy:
1. COMPONENTES DEL SISTEMA
La alarma está compuesta por un núcleo microcontrolador basado en un PIC16F84A con todas sus entradas y salidas aisladas del circuito exterior. Un circuito receptor se encarga de recibir la señal emitida del mando a distancia para armar y desarmar la alarma.
Las entradas que recibe la alarma provienen de las puertas, maletero, capó del motor, ignición de la llave de contacto y mando a distancia; las salidas sobre las que actúa son la señal acústica (sirena), señal luminosa (intermitentes), indicador interior (LED), contacto y cierre centralizado (abrir/cerrar puertas).
Sigo en el próximo mensaje..... (esto lo he aprendido de Marmatar... jeje)
besotes
Elena
Publicado por: Elena2000 en 17 de Septiembre de 2003, 11:11:00
Sigo....
2. FUNCIONAMIENTO
2.1. Estado inicial
Se define esta situación como aquella en la que el sistema (bien sea el coche o la alarma) se conectan a la tensión de batería, tras la primera instalación, revisión de batería, mantenimiento, etc.
En este estado la alarma encenderá el indicador interior durante un segundo para verificar su correcto funcionamiento y al cabo de este tiempo abrirá el cierre centralizado; en determinadas circunstancias y vehículos, la reconexión de la batería origina cierres inesperados de las puertas.
La alarma entonces pasará al estado de desarmada.
..... un poco de jaleo ... ya... pero debe ser así...
2.2. Estado de alarma desarmada
Se define este estado como aquel en el que la alarma se activa ante variaciones del estado de las entradas, a excepción del mando a distancia.
En este estado todas las salidas permanecen en reposo (desactivadas).
De este estado la alarma pasa al estado de armada cuando se activa la entrada del mando a distancia, exceptuando las siguientes condiciones:
- Señal de ignición activa: en esta condición bajo ningún concepto se pasará al estado de alarma armada, ya que el coche puede estar en marcha. El indicador interior permanecerá encendido mientras esté pulsado el mando a distancia. La alarma no podrá pasar al estado de armada mientras esté pulsado el mando a distancia aunque de desactive la señal de ignición; será necesario volver a pulsar de nuevo el mando a distancia.
2.3. Transición de estado de alarma desarmada a alarma armada
... Mejor sigo mañana..... vale? que si no os vais a aburrir enseguida de mi....
Besotes, chicos
Elena
Publicado por: marmatar en 17 de Septiembre de 2003, 12:40:00
Como primera medida quiero decirte que es imposible aburrirse de ti... tu explicación consisa y ordenada de la funcionamiento de la alarma es muy bueno, ni que te dedicaras a la documentación de proyectos...
Si no fuera que tengo demasiados proyectos en danza, y por lo que ya he dicho alguna vez "el que mucho abarca poco aprieta"... dejaré éste para otro momento, además no tengo auto
... salvo que me lo coloque en la chaqueta para que no me la roben cuando viajo a casa...jeje.En realidad quería pasar a derte mi apoyo por aquí... un beso grande... y adelante.
marmatar
Publicado por: Elena2000 en 19 de Septiembre de 2003, 04:21:00
Os sigo contando el funcionamiento de la alarma. Me quedé en la transición de desarmada a armada.
2.3. Transición de estado de alarma desarmada a alarma armada
Como ya dije anteriormente, será condición indispensable para pasar a estado armada que la ignición esté desactiva. La transición de estado se hará tal y como sigue:
1.- Se cerrará el cierre centralizado.
2.- Se iniciará una temporización de treinta segundos antes de pasar al estado de alarma armada. Si durante estos treinta segundos alguna puerta, maletero o capó está abierto, el temporizador seguirá contando y el indicador interior parpadeará de manera rápida (250 milisegundos) para indicar dicha circunstancia; si transcurridos los treinta segundos permaneciera en esta situación, la alarma pasará al estado de alarma disparada. Si ninguna puerta, maletero o capó se encuentra abierta o, si estando abiertas, se cierran dentro del periodo de temporización, el indicador interior permanecerá permanentemente encendido hasta el cambio de estado a armada.
3.- Transcurridos los treinta segundos, se pasa al estado de armada.
Si durante el periodo de treinta segundos se recibe señal del mando a distancia se pasará al estado de alarma desarmada.
2.4. Estado de alarma armada
Se define este estado como aquel en el que la alarma pasará a alarma disparada en el caso de que se detecte la activación de las entradas correspondientes a puertas, maletero, capó o ignición.
Durante este estado el indicador interior parpadeará a modo de baliza (1 segundo apagado, 250 milisegundos encendido).
Las entradas de capó, maletero e ignición hacen disparar la alarma instantáneamente (sin retraso); sin embargo, la señal de puerta disparará la alarma transcurridos cinco segundos para permitir su desconexión mediante el interruptor oculto si fuere necesario (pérdida o deterioro del mando, que el mando esté en el bolso pero lo buscas, lo buscas, lo buscas,..... el bolso parece un enorme pozo sin fondo.. no lo encuentras... ahhhh! esas cosillas que pueden suceder, etc.).
Vale, luego sigo
Besotes!
Elena
Publicado por: pikman en 20 de Septiembre de 2003, 21:05:00
un saludo
Ariel
Publicado por: Elena2000 en 23 de Septiembre de 2003, 04:23:00
Os cuento cómo he hecho lo del mando a distancia...
Ariel y Jorge (también tú me has preguntando sobre esto), me parece que la idea de Ariel es mucho más sofisticada que la mía... la verdad es que si lo pienso bien, lo que he hecho es algo "chapuza", pero funciona, y es mucho más sencillo... Verás, conéctate a la página:
www.cebek.com
de aquí compré un emisor y un receptor (TL-11 y TL-60, si buscas por códigos los encontrarás rápido). Busca también el C-0504.
Yo lo que he hecho en mi alarma es desmontar el circuito híbrido de recepción (que es la madre del cordero.....
) del circuito TL-60 y he montado el resto de la circuitería para dar la señal del PIC. Proximamente pondré en el foro este circuito (cuando lo ponga en limpio en el Proteus, y actualize la versión, por cierto!). Besotes, chicos
Elena
Publicado por: doppel en 24 de Septiembre de 2003, 20:18:00
besos!
Publicado por: Elena2000 en 25 de Septiembre de 2003, 10:19:00
Más cositas de la alarma:
2.5. Estado de alarma disparada
Se define este estado como aquel en el que alguna entrada (puertas, capó, maletero o ignición) ha sido activada durante el estado de alarma armada.
En este estado la señal acústica será activada, la señal luminosa será activada de forma parpadeante (0,5 segundos ON y 0,5 segundos OFF) y activará la señal de contacto (el contacto se controla mediante un contacto NC de la alarma; por tanto la activación de esta señal interrumpirá el circuito).
La alarma estará disparada por cada entrada durante tres minutos (la señal acústica será intermitente a intervalos de treinta segundos, y la señal de contacto quedará activada hasta que la alarma sea desarmada por el mando a distancia). Transcurrido este tiempo la alarma pasará a modo de armada pero la entrada que la hizo disparar será inhabilitada hasta la próxima vez que la alarma sea armada de nuevo.
El indicador interior parpadeará según la siguiente tabla para indicar qué evento le hizo disparar:
Indicación del LED Señal de disparo
o-x-o-x-o-1seg Puertas
o-x-o-x-o-x-o-1seg Ignición
o-x-o-x-o-x-o-x-o-1seg Maletero y/o capó
Las x son retardos de 250 ms
Las o indican el led encendido durante otro 250 ms
Si fue más de un evento el que hizo disparar la alarma, el indicador luminoso parpadeará para indicar de forma secuencial todos aquellos eventos que la hicieron disparar.
La alarma sólo podrá salir del estado de disparo transcurridos los tres minutos o si se recibe la señal del mando a distancia. La desaparición de la señal de disparo no implicará la salida del estado de disparo.
To be continued...
Elena
Publicado por: Abago en 26 de Noviembre de 2003, 18:47:00
Una preguntita....
Como has hecho para gestión de tiempos en la alarma???
estoy haciendo un proyecto, y me encuentro con el problema de que no se como hacer la gestión del tiempo en la lectura de unos pines
La idea es leer un pin del pic, que me indique que tengo que leer otras entradas
lo que quiero es leer el estado de unos pines mientras que
el temporizador esté activo.
pero sin dejar de correr el programa...
te dejo el link del otro post que dejé en el foro, que creo que está mejor explicado....
http://miarroba.com/foros/ver.php?temaid=1252514&foroid=8826
Muchas gracias de antemano
Publicado por: Elena2000 en 28 de Noviembre de 2003, 14:05:00
Perdona que haya tardado tanto en responderte. Verás, yo utilizo la interrupción por desbordamiento del TMR0 para llevar el control de los tiempos.
De todas formas, espera un poquito, voy a echar un ojo al link que has puesto con la otra explicación a ver si veo alguna forma concreta de ayudarte en un problemilla, vale?
besotes
Elena
Publicado por: Abago en 28 de Noviembre de 2003, 22:59:00
por ajemplo, leemos los estados un sensor de golpes, un sensor de puerta, y un sensor de grua.
para el sensor de golpes, pondrémos un tiempo de inactividad de 2 minutos.
para el sensor de grua, 10 minutos
y para el sensor de puerta, 15 minutos...
Es algo asi, mi idea, pero acepto sugerencias...
Tnks
--
Abago
Publicado por: Elena2000 en 01 de Diciembre de 2003, 05:40:00
A ver, basándome en lo que yo he hecho en mi alarma, te cuento como tendrías que adaptarlo a la tuya.
Si quieres monitorizar tres sensores, conecta cada señal de los sensores a los pines de interrupción por cambio de estado del PIC (depende de qué pic estés usando, por ejemplo el 16F84 son RB4:RB7). Cuando tengas condición de alarma, deshabilita las interrupciones para estos pines e inicia la rutina del contador. Cuando llegues al tiempo de inactividad, vuelves a habilitar las interrupciones de estos sensores (y apagas la sirena), y ya está.
Para controlar el tiempo de inactividad utiliza el TMR0, con 1:256 de prescaler (supongo que tu cristal es 4MHz). El desbordamiento de este registro provocará una interrupción que hará incrementar el tiempo de un contador y enviará un flag al control principal de tu programa, de forma que tu controles cuando tienes que habilitar los sensores o esperar hasta que acabe de contar esos minutos..
Dime si te aclaras, vale?
Besotes
Elena
Publicado por: Abago en 01 de Diciembre de 2003, 17:11:00
he utilizado el pin rb0 para detectar interrupción, y armar/desarmar la alarma...
(no tenia idea de que se le podia asignar interrupción a otros pines, pero me puede ser de utilidad..)
Lo hice medianta una variable, que cambia el estado de 0 a 1
una vez que esta variable, se pone a 1, el programa entra en un bucle que checkea los estados de rb1, rb2, rb3...
Hago un chequeo constante para que cree una variable que incrementa
si rb1 = 1 variable = variable + 1
si rb2 = 1 variable = variable + 2
si rb3 = 1 variable = variable + 4
dependiendo del valor de la variable despues de el checkeo, procedo con lo que quiero que la alarma haga...
viendo la idea que me das, que utilizar la interrupción para cada uno de los pines, creo que se simplifica mi proyecto... Pero ...
COMO LO HAS HECHO???
a ver si es posible que me pongas por aqui un ejemplo de como hacerlo....
testear la interrupción de 4 pines, y testear el tiempo con la interrupción por timer0
la detección de la interrupción de cada pin, se hace por independiente???
o detecta interrupción general, y en el handle, discriminamos por que pin ha entrado la interrupción????
Me he quedado un poco perdido con el tema, pero con un poquito de ayuda, creo que lo solucionaré rápidamente...
Muchas gracias por tu ayuda y tu apollo....
--
Atentamente
abago
Publicado por: Elena2000 en 02 de Diciembre de 2003, 04:46:00
(te pongo fragmentos de mi código que tenmgo implementado para mi alarma):
; Declaración de entradas
; RB0 = Conexión de la alarma a través del cierre centralizado.
; Flanco de subida: ARMADA
; RB4 = puertas abiertas, 1 abierta, 0 cerrada
; RB5 = capó abierto, 1 abierto, 0 cerrado
; RB6 = maletero, 1 abierto, 0 cerrado
; RB7 = 1 ignición on, 0 ignición off (activa por nivel bajo)
INTCON EQU 0X0B ;registro para interrupciones
TMR0_OPT EQU 0x81
;Origen del programa
org 0
goto INICIO
org 4 ;vector de interrupciones
goto INTER
org 5 ;salta el vector de
;interrupción
;****ESTADO INICIAL****
bsf PORTA,0 ;encender led durante 1s call DELAY1 ;1 sg de temporizacion
bsf PORTA,3 ;abrir puertas bcf PORTA,0 ;apagar led
call DELAY1 ;1 s de temporizacion
bcf PORTA,3 ;liberar abrir puertas
movlw 0x98 ;activar las interrupciones
;se activan 10011000
;bit 7: GIE, permiso global
; de interrup.
;bit 4: INT externa (RB0)
;bit 3: cambio de estado
;en RB4:RB7
movwf INTCON
; VALE, ahora ocurre una situación de alarma: SE PRODUCE
;UNA INTERRUPCION: y entonces el programa salta a la
;rutina de interrupciones:
INTER btfss INTCON,0
;explora el bit 0 si hay interrupcion por cambio de estado de RB4..RB7 (los sensores)
goto CAUSA0
;fue RB0 -- el control de l mando a distancia para armar/desarmar: NO SUENA LA SIRENA
goto CAUSA1
;fue RB4..RB7: ALGUN SENSOR SE ACTIVÓ: ALARMA!!!!!
Bueno, y ya pones en la rutinas lo que quieres que haga en un caso u otro, ¿lo entiendes?
Pues ya me dirás.
Besotes
Elena
Publicado por: Abago en 02 de Diciembre de 2003, 08:16:00
Estaba desarrollando el proyecto en PBP, y el ensamblador, colapso mi cerebro, pero seguro que enseguida le voy cojiendo el hilo.
el pic que en pricipio, estoy utilizando es el 16f84, pero como el pbp, ocupa tanta memoria, creo que es posible que en algun momento tenga que migrarlo al 16f876, o similares...
Creo que al integrar datos en asm, es posible que me entre en el 16f84
-----------------------------------------
INTER btfss INTCON,0
;explora el bit 0 si hay interrupcion por cambio de estado de RB4..RB7 (los sensores)
goto CAUSA0
;fue RB0 -- el control de l mando a distancia para armar/desarmar: NO SUENA LA SIRENA
goto CAUSA1
;fue RB4..RB7: ALGUN SENSOR SE ACTIVÓ: ALARMA!!!!!
-----------------------------------------
leemos el bit 0 del INTCON (RBIF)
como discriminamos por que pin ha entrado la interrupcion???
si rb0 - armamos/desarmamos
si timer0 - decrementamos los contadores de inhabilitación.
si rb4-rb7 detectamos por que pin entro la interrupcion...
y dependiendo de que pin se ha usado, hacemos sonar la sirena durante un tiempo diferente.
Muchas gracias por tu ayuda....
Publicado por: Abago en 02 de Diciembre de 2003, 18:41:00
Ejemplo de programa que discrimina el pin activo, y realiza na secuencia de intermitencia en un led...
El led parpadea con distinta frecuencia dependiendo del pin pulsado.
-----------------------------------------------
LIST p=16c84
#include <c:mplabp16c84.inc>
__CONFIG 11H
CONSTANT LED=0 ; PORTA pin for LED
CONSTANT CH3=7 ; CH3 corresponds to PORTB.7
CONSTANT CH2=6
CONSTANT CH1=5
CONSTANT CH0=4 ; CH0 corresponds to PORTB.4
CONSTANT VARS=0CH
LOOP1 EQU VARS+0 ; outter timing loop
LOOP2 EQU VARS+1 ; inner timing loop
LED_CNT EQU VARS+2 ; times LED is winked
ORIGINAL EQU VARS+3
NEW EQU VARS+4
CHANGE EQU VARS+5
N EQU VARS+6
ORG 000H
CLRWDT
GOTO TOP
ORG 004H
GOTO WAKE_UP
TOP:
BCF OPTION_REG, 7 ; enable internal pullups
BSF STATUS, RP0
MOVLW 0F0H ; RB.7 - RB.4 are inputs
MOVWF TRISB
BCF STATUS, RP1
BTFSS STATUS, NOT_TO ; not a watch dog timer reset
GOTO TOP_1
; sample PORTB before going to sleep
MOVF PORTB, W ; fetch the current state
MOVWF ORIGINAL ; current state in high nibble
TOP_1:
BSF INTCON, GIE ; enable general interupts
BSF INTCON, RBIE ; enable interrupt on change
L1:
SLEEP
NOP
GOTO L1
WAKE_UP: ; interrupt service routine
MOVF PORTB, W ; sample changed state of pins
MOVWF NEW ; this will become the new original
XORWF ORIGINAL, W
MOVWF CHANGE ; 1"s now in high nibble now identifies
; the bit that has changed
CLRF N ; set index to 0
BTFSC CHANGE, CH0
GOTO BLINK
INCF N, F ; N=1
BTFSC CHANGE, CH1
GOTO BLINK
INCF N, F ; N=2
BTFSC CHANGE, CH2
GOTO BLINK
INCF N, F
GOTO BLINK
BLINK: ; N is either 0, 1, 2 or 3 corresponding to the channel
; this is now mapped into a delay
CALL DELAY_LOOKUP
MOVWF LOOP1 ; save the delay in LOOP1
GOTO BLINK_AT_SPEED
DELAY_LOOKUP: ; map N into 100, 150, 200 or 250 msecs
MOVF N, W
ADDWF PCL, F
DT .100, .150, .200, .250
BLINK_AT_SPEED:
MOVLW .10
MOVWF LED_CNT
L2:
BSF PORTA, LED
CALL DELAY
CALL DELAY
BCF PORTA, LED
CALL DELAY
CALL DELAY
DECFSZ LED_CNT, F
GOTO L2
MOVF NEW, W
MOVWF ORIGINAL ; new original states
BCF INTCON, RBIF ; clear interrupt flag
RETFIE
DELAY:
L3:
MOVLW .110
MOVLW LOOP2
L4:
CLRWDT
NOP
NOP
NOP
NOP
NOP
NOP
DECFSZ LOOP2, F
GOTO L4
DECFSZ LOOP1, F
GOTO L3
RETURN
END
Publicado por: Abago en 02 de Diciembre de 2003, 18:45:00
como habilitar el timer0
y discriminar la interrupción del mismo en el codigo que he puesto en el anterior post???
la idea es que podamos discriminar entre la interrupción por rb0
rb4..rb7
y el overflow del timer....
todo en uno..
tendremos interrupción por 6 estador....
rb0 - armado/desarmado de la alarma
rb4..rb7 - estado de los sensores de la alarma
timer0 - contador de tiempo
con poco mas la alarma está casi hecha...
Bueno, lo que queda, no es poco, pero ya he avanzado MUCHO....
Gracias de antemano.
--
Aténtamente
Abago
Publicado por: Abago en 08 de Diciembre de 2003, 18:43:00
Ya he encontrado como hacer tambien lo que te pregunto en el anterior post....
Pero tengo una dudilla....
A ver... el programa principal de la alarma, lo estoy desarrollando en PBP...
Y el handler de interrupción, lo voy a hacer el ASM...
En el handler, discrimino entre interrupción por RB0, RB4..7, O timer.
hay alguna forma de inhibir las interrupciones por RB4..7 de una manera independiente???
me gustaría poder leer los estados por separado:
RB0: armar desarmar
RB4: Puerta
RB5: golpe
RB6: grua
RB7: PANICO
a ver, si se queda una puerta habierta, o el coche, es montado en una grua....
los pines RB4 o RB6, se pondrán en estado alto, y generaran una interrupción constante no????
la idea, es poder inhibir la interrupción de estos pines por un tiempo determinado, que calcularé con la interrupción por timer...
No se si me he explicado....
Muchas gracias por todo tu apollo...
Publicado por: ejmc en 08 de Diciembre de 2003, 21:06:00
INTCON[3]=0 " desabilita la interrupcion por cambio de estado
Hera eso lo que preguntabas no?
Ahora como haces eso de atender distintas interrupciones. Vas habilitando las que necesites segun el lugar del programa donde te encuentres. En PBP se puede definir una sola etiqueta de interrupcion no, en ASM se puede definir mas de una?
Saludos
Publicado por: Elena2000 en 16 de Septiembre de 2004, 02:36:00
Anda, dime una cosa, ¿en qué lenguaje de programación estás haciendo tu programa de la alarma?
Publicado por: eduardo.gonzalez en 06 de Octubre de 2004, 10:34:00
Mi nombre es Eduardo, soy nuevo en la lista y estuve trabajando con Pics desde hace un año mas o menos, ahora me largué con el proyecto de una alarma para autos la cual quedó funcionando perfectamente, hasta que la puse en un auto, y resultó ser un verdadero desastre, la alarma se reseteaba a la menor perturbación, por ejemplo chispas de un rele que comandaba una bocina, al cual le puse un apaga-chispas (serie 100ohms & 0.1uf) y ni hablar de poner el motor en marcha.
En la alimentación filtros de todos colores, diodos rápidos, capacitores, reguladores,etc.
Es decir todo como manda la ley y algo mas.
El equipo está funcionando con un 16F84A con cristal de 4Mhz.
Lo más extraño de todo es que después reemplacé mi alarma por una de primera marca bajo las mismas condiciones, la única diferencia era que esta tenía un 16C61, y esta no se reseteó en ninguna oportunidad.
¿Dónde creen ustedes que puede estar el problema?
¿Es normal que sea tan inestable el 16F84?
¿Tendrá mas estabilidad un OTP?
Desde yá agradezco su ayuda.
Saludos. Edu.
Publicado por: Elena2000 en 07 de Octubre de 2004, 10:01:00
Realmente me extraña lo que nos cuentas, sobretodo sabiendo la cantidad de filtros, sistemas antichispas,etc que le pusiste a tu cacharrito. Pero no me entero... ¿dices que reemplazaste tu alarmita made in casa por una comercial y que todo iba de perlas, y que la única diferencia era el microprocesador? pues... no se si te entendí mal, pero no creo que esa fuera la única diferencia.. Si tenías problamas de chispas y reseteos por perturbaciones, seguro que el pic no tenía nada que ver en eso, eso es más bien debido a componentes pasivos, relés, falsos contactos, etc, los típico fallos que te vuelven loco... porque son muy difíciles de detectar...
Yo nunca he utilizado el 16C61, pero te puedo asegurar que no tiene porqué ser más estable o menos estable que el 16F84. Si están bien aislados de ruidos y el programa que le cargas al micro contempla todos los posibles casos de activación/desactivación, y tienes depurados los rebotes, etc... no tendrías que encontrar diferencia entre un pic u otro. ¿Me explico?
No se, yo por mi experiencia se que las señales que encuentras en el coche, a veces son poco fiables; por ejemplo recuerdo que me dio mucha lata encontrar la forma de detectar con seguridad que se había abierto una puerta...
Anda, si quieres que entremos a trapo con tu circuito, ponlo en la parte del foro técnico, por ejemplo, y seguro que ratreando las pistas encontramos el dichoso misterio... Si quieres de paso mirar el código de la alarma, ponlo por aquí y te doy mi opinión.
Vale? ya nos contarás.
inestable el 16F84? ¿Tendrá mas estabilidad un OTP? Desde yá agradezco su ayuda. Saludos. Edu.
Publicado por: eduardo.gonzalez en 08 de Octubre de 2004, 05:59:00
Antes que nada quiero aclarar que mi alarma no es ningún cacharrito!!!(No me enojé...es una broma)
El circuito es básicamente el que estoy adjuntando, sin el UM3750 puesto que la señal de la radio la mando directamente al Pic a travez de un divisor resistivo, mas los filtros que le agregué cuando empecé con este problema.
Con respecto al programa ¿Existe alguna instrucción o método de programación que pueda resetear al micro?
Estoy armando un simulador que meta todos los ruidos que mete un encendido de auto, así puedo seguir experimentando en el laboratorio, sin tener que recurrir al vehículo, espero poder tener novedades para el martes.
Gracias por los datos que me diste y si alguien tiene alguna sugerencia será binvenida.
Saludos. Edu.
PD.: El circuito no lo puedo enviar dice:
"Lo sentimos, no hay suficiente espacio disponible para subir el adjunto".
El que quiera/pueda se lo envío por mail directo.
Un abrazo.
Publicado por: Elena2000 en 08 de Octubre de 2004, 06:08:00
En cuanto al circuito de tu "cacharrito", jejejeje, si quieres mándamelo a un privado, y trataré de ponerlo en el almacén del foro para que los demás tambien lo puedan ver. vale?
Publicado por: endiefi en 23 de Octubre de 2004, 05:58:00
gracias de antemano
Publicado por: Elena2000 en 25 de Octubre de 2004, 05:20:00
Pues mi respuesta es que me parece estupendo lo que propones. Haz una cosita antes de empezar; echa un vistazo a conciencia en el foro porque hay referencias de gente que ha añadido el tema del envío del sms al móvil desde la alarma del coche. Te lo comento para ver cómo lo hicieron los demás y así te puedes orientar.
En cuanto a la alarma "básica", sin sms al móvil, con cuatro sensores, temporizaciones, etc, yo tengo mucha versiones hechas en ensamblador, pero echa un ojo a los mensajes de Abago, porque este nene hizo modificaciones y un código espectacular en asm. Lo encontrarás en los mensajes de este tema.
Al final, emigré del asm y me lié a hacer una nueva versión en basic, y aún estoy trabajando en ella (aunque tengo muy poquito tiempo y no avanzo..
Pero si te animas con el C, genial! me gustaría probar con el c a mi también, así que si no te importa, me voy a subir a tu chepa y lo podemos ir tanteando, vale?
Publicado por: cucaracha en 25 de Octubre de 2004, 12:09:00
Ahora pueden incluir esto a sus alarmas de coche, para los de versión aviso por SMS.
Si... te da el aviso de robo y ahora además puedes localizar su posición aproximada...
Miren:
http://www.msn.es/moviles/localizar/default.asp?id=1
Saludos!!
Publicado por: MGLSOFT en 25 de Octubre de 2004, 14:59:00
Publicado por: Nocturno en 25 de Octubre de 2004, 16:16:00
http://www.gpsworldpager.com/wpager1.html
Seguro que os gusta, sobre todo a tí Marcos.
Publicado por: gauchosuizo en 26 de Octubre de 2004, 02:44:00
@Eduardo Gonzales
para mi tiene mucho que ver el Layout, como lo has hecho? Que tipos de filtros has hecho a la entrada? Seria bueno ver el circuito.
Aloha
Publicado por: eduardo.gonzalez en 26 de Octubre de 2004, 16:40:00
Quería comentarles que el problema original de la alarma resultó ser un error de diseño del impreso, el mismo lo explico en el informe que adjunto.
GRACIAS A TODOS POR LA AYUDA!!!
Ahora, me encuentro abocado a la tarea de migrar mi programa de 16F84 a 16C71 con la finalidad de abaratar el proyecto, y por otro lado el distribuidor me informó que se dejaron de importar a argentina los 16F84.
Por lo que estuve leyendo las direcciones de memoria son las mismas, con lo que me parece que será una tarea sencilla.
Saludos cordiales, Eduardo.
PD.: No puedo adjuntar el PDF, asi es que copio solamente el texto a continuación, falta un grafico donde se muestra claramente la pista que causó el problema.
Interferencias en Alarma basada en 16f84
La falla se produjo en una alarma antirrobo para vehículos basada en un 16F84, la cual dentro del laboratorio,y alimentada con una fuente normal, funcionaba perfectamente, luego al instalarla en un vehículo se observa que el microcontrolador se resetea a la menor perturbación, como por ejemplo: al accionar la bocina, o con el motor en marcha, precisamente en este estado es que queda constantemente reseteandose el micro.
La falla radicaba en el diseño del PCB, el cual se realizó en material fenólico, y con el criterio de engrosar cuanto se pudiera cualquier pista sin importar las separaciones mínimas entre ellas, el efecto mas nocivo de todo esto lo produjo una pista de unos 2mm de ancho y unos 50mm de largo, la cual pasaba muy cerca de la
bornera general (adjunto gráfico), al retirar la citada pista se solucionó completamente el problema.
Publicado por: endiefi en 27 de Octubre de 2004, 14:28:00
Este es el codigo de la alarma en C. Es muy basica y la iré ampliando a medida que avance con el proyecto (acepto propuestas). La alarma esta hecha con un PIC16F876 y he añadido un Led, un pulsador, un zumbador, etc
#include <pic1684.h>
void main (void)
{
TRISA=0x00;
TRISB=0X11;
INTEDG=0; //flanco descendente RB0/INT
GIE=INTE=1; //habilita interrupcion
RA3=0;
while(1);
}
void interrupt conmuta_RA3 (void)
{
if (INTF) //señalizador de estado RB0/INT
{
RA0=!RA0;
INTF=0;
}
}
void interrupt sensores (void)
{
if (RBIF) //señalizador de estado RB0/INT
{
RA0=!RA0; //Led
RB4=!RB4; //Rele
RA5=!RA5; //Zumbador
RBIF=0;
}
}
Como veis es muy sencilla y todavia no he añadido el modulo que envia el SMS al movil. Espero vuestras opiniones.
Un saludo
Publicado por: ErYeZuZ en 28 de Octubre de 2004, 06:27:00
el proyecto es el siguiente
http://perso.wanadoo.es/luism..serrano
Como podeis ver no tiene un sistema de encendido y apagado determinado si no que hay que desenchufar los cable, de mano con un interruptor en el reset se arreglaria, mi intencion es q se pueda activar y desactivar con una llamada desde un movil q este en la agenda, luego necesitaria modificar el Hex para obtener una o varias salida a nivel alto intermitentes una vez pasase el retraso (cuando se manda el sms)y que se mantuviesen asi hasta el reseteo de la alarma, yo tengo mas conocimientos de electronica q de programacion, veo que en este foro hay verdaderos masters y que modificar el hex de luis serrano no os sera muy dificil si alguien me ayuda yo me comprometo a remodelar el apartado de hardware,os digo lo que tenia pensao de mano yo todo lo iva a hacer electronicamente sin tocar el codigo ya q en estos momento no se, ponerle un sistema q cuando mande el sms encienda las luces intermitentes y claxon intermitentemente cada 2 segundos hasta q se reinicie la alrma tambien estoy estudiando q corte la corriente al encendido y/o bomba gasolina, electricamente lleva mucho mas tiempo q si se programa el pic con la salida intermitente para eso se inventaron.
A parte de esto ya os comentare dudas ya que tengo que aprobar automatismos micro8082 y automata programable omron en diciembre y en estos momentos no tengo ni idea un saludo espero noticias vuestras
Bueno resumiendo:
Mi proposito es:
1º una alarma q se active/desactive bien por una clavija especial dentro del coche o mediante llamada perdida desde una numero configurado en la agenda.
2º con sensor de apertura de puertas moviemiento, etc
3º q cuando un sensor salta tarde unos 5 o 10 segundos en actuar (asi tendremos tiempo a desactivarla si somos nosotros los q abrimos las puertas.
4 q cuando actue despues de esa cuenta mande un sms a un numero de movil configurable, y active la iluminaciony claxon del conhce interumpidamente, hasta q se desactive la alarma.
LOS APARTADOS 2º Y 3º LOS TENGO LA ACTIVACION DESACTIVACION MEDIANTE CLAVIJA TAMBIEN, LO DE QUE MANDE SMS TAMBIEN ESTA, ME FALTA EL RESTO.
Publicado por: ErYeZuZ en 28 de Octubre de 2004, 08:58:00
Publicado por: ErYeZuZ en 28 de Octubre de 2004, 08:59:00
http://inicia.es/de/pmaicas/goofy/algsmgps.htm
Publicado por: Elena2000 en 29 de Octubre de 2004, 07:43:00
endiefi, este finde voy a completar tu código C con mis rutinas, vale? y el lunes te lo pongo por aquí. Lo he estado mirando y tiene muy buena pinta! Cuando le pongas el módulo gsm va a estar de lujo (y si le añades un link a MARTA, se de uno por aquí que te lo va a agradecer mucho. jeje.)
ErYeZuZ. La página que has apuntado es muy muy buena!! ¿eres tú el autor de ese proyecto? el goofy este es bueno de verdad. Y qué parte vas a sustituir de software para implementarla en hardware. Es que no te cosco bien, perdona..
Anda, cuéntame un poquito mejor a ver si te puedo ayudar en condiciones, pliss.
Publicado por: ErYeZuZ en 29 de Octubre de 2004, 08:23:00
pero la de goffy esta completa hay no habria q modificar nada solo hacer el programa para el pic, que me dices me modificas el hex de la de luis.. y si eso una vez acabada esta nos metemos con el hex de la de goofy, yo en estos momentos programacion 0 soy electronico y me queda un mes pal examen 8081 y omron
Publicado por: ErYeZuZ en 29 de Octubre de 2004, 08:25:00
Publicado por: ErYeZuZ en 02 de Noviembre de 2004, 17:18:00
Publicado por: Elena2000 en 03 de Noviembre de 2004, 02:54:00
Publicado por: ErYeZuZ en 03 de Noviembre de 2004, 10:11:00
2 Segundos 0V
Creo que es facil no?, solo necesitariamos encontrar la rutina de envio de sms y añadirle q active las salidas a nivel alto, todavia estoy un poco pez en esto.
Nada no puedo subir me dice q no hay espacio, ultimamente el foro va un poco espeso, a veces me da error y me manda a miarroba, lo intentare mas tarde
Publicado por: endiefi en 03 de Noviembre de 2004, 10:18:00
Pocher, he hecho los siguientes cambios en mi alarma:
#include <pic1687x.h>
#define LED1 RC2
#define LED2 RC3
#define ZUMB RA4
#define RELE RA5
unsigned int cent;
void main (void)
{
unsigned char nvuelta;
TRISA=0x00; //PORTA salida
TRISC=0x00; //PORTC salida
TRISB=0xFF; //PORTB entrada
PORTA=0x00; //
PORTC=0x0C; //LED1+LED2
OPTION=0xD7;
INTCON=0xb8;
TMR0=0xd9;
do
{
nvuelta=0;
do
{
cent=0;
LED1=1;
LED2=0;
while (cent<50); //0"5 seg
cent=0;
LED1=0;
LED2=1;
while (cent<50); //0"5 seg
nvuelta++;
}
while(nvuelta<10); //10 seg
}
while(1);
}
void interrupt centesimas (void)
{
if (T0IF)
{
TMR0=0xd9;
cent++;
T0IF=0;
}
if (RBIF)
{
LED1=LED2=RELE=ZUMB=1;
RBIF=0;
}
}
Al compilar con MPLAB no me da ningun error. Lo unico q no cumple el tiempo q yo le indico ( 0"5 segundos).
Elena me parece muy buena idea q completes este codigo
De momento voy a probar en el laboratorio si funciona y despues ya a por el modulo GSM.
Un saludo
Publicado por: pocher en 03 de Noviembre de 2004, 13:04:00
La verdad y no es por desmoralizar, pero el programa, no tiene muy buena pinta. En fin lo importante es que te funcione.
La función void interrupt centesimas (void) no la va a hacer nunca, ya que para que se dispare una determinada interrupción hay que poner delante del nombre de la función #INT_RB o #INT_RTCC (es la del TMR0). La tendrías que poner dentro de while(1) y así no necesitarás las directivas anteriores.
Te recomiendo que te leas un poco más el manual, ya que por desconocimiento de este lo estas intentando hacer en ensamblador, pero así también puede salir, por supuesto.
Un saludo
Publicado por: endiefi en 05 de Noviembre de 2004, 12:19:00
Hasta pronto.
Publicado por: Elena2000 en 08 de Noviembre de 2004, 02:55:00
ErYeZuz, oyez, que entre los ficheros que me has enviado a hotmail, resulta que el archivo con el asm de la alarma tenía tamaño 0 pelotero, o sea que no había na de na.. Bueno, me he bajado el hex de la página del serrano y lo he desensamblado yo pispa, con una herramienta muy chula que puso todopic en el almacén del assembler. Bueno, tío.... es la madre del cordero entender el asm de marras, porque vienen todas las directrices con las direcciones de memoria de la flash a pelo, así que me va a llevar algún rato más traducir este asm a un asm más apañao. También lo estoy simulando, para meter los retardos. Mientras tanto, ¿por qué no te pones a buscar la rutina que nos hace falta, la del envío del mensaje al móvil? lo otro es una tontería y se hace en un momento. Anda, a ver si la encuentras por ahí.
Endifi, como ya te dije, estoy toqueteando tu código para adaptarlo a mi alarma. Lo pondré aquí en cuanto lo acabe, y así Pocher de paso me lo echas un ojo, valeee?
Publicado por: pocher en 08 de Noviembre de 2004, 05:54:00
No sé porqué pensé que lo estabas haciendo con CCS.
Vale Elena, intentaré ayudar en lo que pueda.
Publicado por: Elena2000 en 08 de Noviembre de 2004, 07:52:00
Pues muchas gracias, Pocher.
Publicado por: ErYeZuZ en 08 de Noviembre de 2004, 16:55:00
Publicado por: siliconbyte en 26 de Marzo de 2005, 18:16:00
inicio
uno movlw .100 cargo w
movwf reg0 llevo a registro reg0
dos btfss ptoa,0 leo puerto
goto uno si hay 1 salto sino cargo con 100
decfsz reg0,f descuento el registro
goto dos me fijo si sige un 1
listo ok
ya filtre todo ruido porque no es un ruido es verdadero.
esta pequeña rutina es una rutina pasajera porque yo puedo leer varios puertos realizando saltos de lectura ,si yo quisiera utilizar el mismo pic como decodificador
como si fuese un um o un decodificador de 24bits o mas no abria problemas
pero no olviden que decodificar no es sencillo porque en rf hay muchos ruidos y cuando el sistema esta dentro de un auto mas aun ,pero este es un derecho de reserva .
solamente les digo que para leer un codigo en rf este se realiza midiendo el bit start y luego este se debe auto ajustar para poder pegar los saltos de lectura
luego debo leer al menos 3 veces para saber que es verdadero y no un dato falso.
busquen en la pagina de holtek.
chau
Publicado por: ulysse en 10 de Enero de 2006, 21:13:00
Llevo mucho tiempo sin pasarme por el foro porque entre los estudios y más cosa no he tenido tiempo para nada.
Elena, lo de la alarma está parado o va para adelante? he leido varios temas pero no has llegado a subir esquemitas, código... verdad? me gustaría echarle un vistazo.
Lo que estoy más frito es en el tema de los sensores, has llegado a comprar alguno? Pásame toda la información que tengas sobre estos para ir haciendome una idea del funcionamiento y ... del precio.
Estoy interesado en montar una alarmita para mi coche, para no dejar de lado la electrónica y seguir haciendo algunas cosas. En mi caso le introduciría un móvil y creo que el mando por RF no (ya me la pegué una vez con los módulos de Aurel, no conseguí hacerlos funcionar). Pero en el caso del móvil ya he hecho otro proyecto y me ha funcionado bien.
Alguna cosa más que he pensado sería en meterle un LCD y un teclado para programar la alarma y más cosas que se puedan ocurrir.
Saludos.
Publicado por: pardaleplus+ en 18 de Abril de 2006, 00:34:05
Mi meil es paradaleplus@yahoo.com