entendiendo los sitemas de proteccion de los pics

[JBQ]

Hola groundman, que significa "currao"? es un elogio o un peyorativo?.

[groundman]

que es un peyorativo?
en españa el curro es el trabajo.que la verdad no hay mucho con la crisis.currao es que te lo has trabajado.

saludos.

[JBQ]

ah, bueno, de todas maneras gracias por la explicación. Entonces sigamos curreando, que todavía hay más por aprender e investigar....  saludos y chao.

[groundman]

pues bien.ya que hemos empezado a ablar sobre el WATCHDOG,quiero proseguir.

estoy empezando a usar este dispositivo interno.y me estan surgiendo una serie de problemas al implementarlo en el codigo  asm.

el principal problema que se me plantea es naturalmente de que el simulador se resetea continuamente.cosa muy normal ya que el WDT se desborda por no
poner un clrwdt estrategicamente en las lineas del codigo.

una de las primeras cosas que he hecho es poner un BREAKPOIN antes del programa principal,es decir en la parte del codigo donde solo se va a pasar una sola vez.
a no ser que el programa se reinicie.
de esta forma el programa se parara cuando se produzca el desbordamiento del WATCHDOG.esto lo hago porque no se donde esta la opcion en el simulador;
para que el programa se pare nada mas se produzca el reset por WDT.

otra cosa que he aprendido es tener mucho cuidado con los subprogramas que usen retardos.la mayoria de los reseteos se producen en estos.por no poner
un clrwdt adecuadamente.

otro problema esta en los bucles donde se espera a que se produzca un evento.

ejem.


btfss   REGISTRO,X      
goto   $-1

deberiamos poner:

clrwdt
btfss   REGISTRO,X      
goto   $-2

a no ser que sepamos que el evento va a producirse antes de que se desborde el WDT.

usando la opcion de solo activar el WDT descartamos el uso del prescaler para el WDT.y asi poder aprobecharlo para el TMR0.
y con 18ms tenemos un tiempo que nos da mas precision a la hora de reiniciar el pic por un bloqueo de este.

con lo que he expuesto invito a la gente a exponer su experiencia en el tema.y quizas podamos aprender un poco mas sobre este sistema de proteccion.

[Suky]

En creación de demoras, el programa que se presenta aquí tiene incluido el clrwdt entre sus lineas. 


Saludos!

[groundman]

muy bueno.si señor.ya nunca dejare de usarlo.

referente a las precauciones que hay que tomar respecto al uso del WDT.tengo entendido que no es aconsejable este llegue a reiniciarse dentro de un programa
que esta atendiendo a una interrupcion.
esto es cierto?

y tambien es desaconsejable usrar clrwdt dentro de la interrupcion?

que cosas raras pude llegar ha hacer un pic para que no siga su ejecucion normal,y se quede en un bucle infinito ?
podria llegar a darse la casualidad de que este entre en un bucle infinito donde se borra constantemente el WDT.y el pic no se reinicie?
y me refiero a un bucle por fallo.no porque este esperando un evento.

[Leon Pic]

Otra cosa muy importante acerca del perro guardián, es que no se trata de poner clrwdt en partes del programa para que el mismo no se resetee, sino que hay que armar el firmware de una manera que, al cabo de un reset, el CP pueda retomar en una rutina segura.

La función principal del perro guardián, es la de desbloquear al CP cuando este queda en un bucle infinito y no hay nada que lo haga salir. Esto se puede dar por la espera de un evento externo que por una causa, jamás llegará.

Por lo tanto, el firmware tiene que tener las siguientes "propiedades":

1. Ser multitarea, para que en el caso de un reset, el CP siga con otra función.
2. Que sea capaz de retomar a una parte del programa seguro para que pueda hacer otra función. En caso de necesitar un evento externo que jamás llega, volverá al reset y comenzará de nuevo.

No obstante, la función de multitarea, va a prevenir que el CP deje de hacer otras funciones necesarias. Supongamos que tiene que hacer 6 tareas diferentes, de las cuales 1 necesitará un evento externo y el dispositivo que entrega el dato está apagado. Cuando se produzca el reset, el CP tiene que ser capaz de seguir con las 5 tareas restantes. No importa si para cumplir las tareas restantes, tenga que resetearse una 10 veces (por poner un ejemplo) pero tiene que ser capaz de hacerlas.

[groundman]

no se si te entiendo muy bien.

te refieres a que testeemos los bit del registro STATUS ligados al WDT,para comprovar si se ha produciodo un desbordamiento del WDT.y guardarlos en la memoria para obrar en consecuencia al fallo?

si es asi me parece una buena idea.para que el programa prosiguiera en otro subprograma y este no quede siempre bloqueado.
esto seria util si por ejemplo quisieramos visualizar en una lcd.diferentes lecturas y que si por algun motivo el pic se reiniciara un numero determinado de veces,apareciera un mensage de error.

pero si el problema fuera por una interferencia,que no tubiera que ver con el circuito que maneja.
creo que daria igual tener esta precaucion.ya que el pic seguiria reiniciandose por bloqueo.

supongo que todo depende de en que parte del codigo se bloquee.y como se bloquee.
no es lo mismo que se quede pillado en una instruccion,a que el PC de un salto indeterminado de instrucciones y no se ejecuten
algunas instruciones.


entonces el programa no seguiria su correcto curso.y no hace falta que se reiniciase .porque podria haberse dado el caso de que hubiera  pasado por un clrwdt.

supongo que prevenir el comportamiento del pic ante este tipo de fallos no es algo sencillo.

por ejemplo.estoy realizando un programa para regular la intensidad de una lampara de 220v de filamento.en este tipo de lamparas no suelen producirse
interferencias mas alla que la propia conmutacion del triac.pero estas interferencias si se producen al regular las lampara de bajo consumo.ya que internamente
estas trabajan con alto voltage.
las interferencias se suelen producir durante su ajuste.y mas comunmente cuando su iluminacion es menor.

hasta ahora tengo el programa bastante trabajado y me da menos problemas.ya que durante su regulacion,voy grabando en la eepronm de datos interna
el valor de esta.y si se reinicia,se toma el ultimo valor guardado.

pero que pasaria si la interferencia fuera tal que no diera tiempo ni ha guardar el valor en la eeprom.
pues que ya no me serviria ningun tipo de proteccion por sofware.y tendria que aislar el pic de la corriente de la red electrica.

[Leon Pic]

Para mi, el wdt no está pensado para el ruido eléctrico porque es como dices tu, si salta a otra parte del programa debido a interferencias, tarde o temprano pasará por un clrfwdt y jamás se reseteará. También está la posibilidad de que no pase por un clrfwdt y se resetee el pic.

te refieres a que testeemos los bit del registro STATUS ligados al WDT,para comprovar si se ha produciodo un desbordamiento del WDT.y guardarlos en la memoria para obrar en consecuencia al fallo?

Si eso mismo. Chequear el bit TO del registro Status para ver si se reseteo el pic por el WDT. Esto es obvio que hay que hacerlo al principio del programa.

[JBQ]

Hola a todos, de nuevo por estos lares. Respecto a...

y tambien es desaconsejable usrar clrwdt dentro de la interrupcion?

no lo creo, ya que esta instrucción no tiene ningún otro efecto mas que el de resetear la cuenta del WDT y los bit TO y PD.

Si eso mismo. Chequear el bit TO del registro Status para ver si se reseteo el pic por el WDT. Esto es obvio que hay que hacerlo al principio del programa.

Eso es correcto, si su usa el WDT, pero no debemos de olvidar también de volver a configurar los registros del microcontrolador, ya que algunos de estos cambian sus valores luego de haberse dado el reseteo por WDT.

pero que pasaria si la interferencia fuera tal que no diera tiempo ni ha guardar el valor en la eeprom.
pues que ya no me serviria ningun tipo de proteccion por sofware.y tendria que aislar el pic de la corriente de la red electrica.

Si bien es cierto que el bit TO nos indica si ocurrió un reset por WDT o no, también están los bits POR y BOR, que creo también pueden ayudar en estos casos.
De todas maneras, es necesario evitar estos tipos de interferencias con filtros, reguladores, etc. 

un saludo a todos y chao.

[groundman]

   
Eso es correcto, si su usa el WDT, pero no debemos de olvidar también de volver a configurar los registros del microcontrolador, ya que algunos de estos cambian sus valores luego de haberse dado el reseteo por WDT.

esto que acabas de decir esta muy bien.no habia caido en eso.pero a que registros te refieres?

el reseteo del pic hace que se vuelvan a configurar todos los registros de nuevo.a no ser que no queramos hacerlo, testando el bit
del suceso de desbordamiento del WDT.pero no creo que esto sea muy recomendable.
el guardar datos en la eeprom de datos.es una opcion si nos interesa dejar funcionando al circuito tal y como estaba funcinando la ultima vez.o almenos salvar datos que se estaban procesando.
aunque esto se hace con los registros de proposito general.y no se debe usar mucho.por el desgaste de la eeprom.

pero claro.todo depende del tipo de programa que estemos realizando.

lo que quiero decir es que no podemos estar guardando por ejemplo un registro que va a estar constantemente variando sus datos.
ya que quemariamos la eeprom de datos.

en este programa que estoy realizando.guardo el valor de regulacion,estado de la lampara on/off y la lampara que estaba encendida.
estos datos puede que se guarden 20 veces al dia.mas o menos.depende si es un salon.un dormitorio o un pasillo.este ultimo si que puede
que se guarde mas veces.

asi que si tenemos una media de 1.000.000 de grabaciones maximo que admite estas eeprom.tenemos 1.000.000/20=136 años de uso del pic.
y si puera el pasillo con una media de 100 pulsaciones diarias.tendriamos 27 años.

ahora.si guardamos un dato que se va a estar actualizando cada segundo.tendriamos 277 horas de funcionamiento.

por eso si pudieras exponer a que registros te refieres.seria de mucha utilidad.

[JBQ]

el reseteo del pic hace que se vuelvan a configurar todos los registros de nuevo.a no ser que no queramos hacerlo, testando el bit
del suceso de desbordamiento del WDT.pero no creo que esto sea muy recomendable.
el guardar datos en la eeprom de datos.es una opcion si nos interesa dejar funcionando al circuito tal y como estaba funcinando la ultima vez.o almenos salvar datos que se estaban procesando.
aunque esto se hace con los registros de proposito general.y no se debe usar mucho.por el desgaste de la eeprom.

Disculpa pero no entendi nada de lo que quiciste decir aqui.
********************************************

Respecto a los registros que se alteran al producirse el reset, sea por WDT o por cualquier otra fuente de los servicios de reset del microcontrolador, puedes darle un vistazo al datasheet respectivo del micro en particular a usar. Por ejemplo, para los archiconocidos PIC16F877A y PIC16F628A los puedes encontrar en las tablas 14.6 y 14.7 respectivamente. suerte con tu programa.

[Leon Pic]

No estoy seguro lo que voy a decir, pero en caso de un reset producido por el WDT, solo algunos registros son afectados.

[mtristan]

.

No estoy seguro lo que voy a decir, pero en caso de un reset producido por el WDT, solo algunos registros son afectados

Me tomo el atrevimiento de contradecirte. Según el datasheet del 16F628A las condiciones de los registros luego de un reset por WDT son las mismas que un reset por activación del pin MCLR.
Este hilo está interesantísimo   

[Leon Pic]

.

No estoy seguro lo que voy a decir, pero en caso de un reset producido por el WDT, solo algunos registros son afectados

Me tomo el atrevimiento de contradecirte. Según el datasheet del 16F628A las condiciones de los registros luego de un reset por WDT son las mismas que un reset por activación del pin MCLR.
Este hilo está interesantísimo   

¿Me puedes indicar dónde dice eso? Porque es justamente lo que ando buscando y no lo encuentro.