Autor Tema: Luchando contra el ruido POR SOFTWARE  (Leído 54633 veces)

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

Desconectado Nocturno

  • Administrador
  • DsPIC33
  • *******
  • Mensajes: 17506
    • MicroPIC
Luchando contra el ruido POR SOFTWARE
« en: 10 de Septiembre de 2007, 13:12:31 »
Tras haber leído con detenimiento el contenido del hilo Hablemos del Ruido y después de haber analizado y entendido los famosos “checkpoints” de Azicuetano, he llegado a la conclusión de que es de vital importancia luchar contra el ruido haciendo un buen diseño de nuestros circuitos y aplicando todas las técnicas posibles en el HARDWARE, pero no es menos importante implementar una serie de protecciones en el SOFTWARE que lo hagan robusto, fuerte e inexpugnable.

Al abrir este hilo pretendo que los que tenéis experiencia en el tema nos contéis cuáles son esos truquillos que cada uno utiliza, con la intención de que aquí vayan saliendo todos ellos y podamos consultarlos en cualquier momento.

Mi experiencia en la lucha contra el ruido es corta, pero para no empezar el hilo sin aportar alguna medida antirruido, hablaré del archiconocido Watchdog. En vez de contarlo yo, os pego el artículo que he extraido de la WikiPIC.



Watchdog
El Watchdog, o "perro guardian" es un concepto de protección usado para volver a reiniciar el programa cuando éste "se pierde" o realiza una acción no prevista.

Es un dispositivo que resetea al micro cada intervalo de tiempo, salvo que el programa le ponga el contador a 0. De esta manera, si el programa se queda colgado en algún sitio, y no refresca al Watchdog, él se encargará de resetear al micro y evitar el cuelgue.

No es extraño que en microelectrónica se den circunstancias de hardware o firmware no previstas por el diseñador en las que un microprocesador se quede en un estado indeterminado del que le sea imposible salir sin una ayuda externa.

El Watchdog lo que hace fundamentalmente es resetear el micro tras un periodo de tiempo determinado. Su funcionamiento es similar a la Interrupción por Desbordamiento de un Timer, que se produce cuando un Timer que es incrementado continuamente pasa de su valor máximo al mínimo para comenzar de nuevo a contar.
En el caso del Watchdog en lugar de saltar una interrupción se genera un reset automático en el momento de producirse dicho desbordamiento.

Pero evidentemente en condiciones normales, nuestro micro funcionando correctamente, no debería producirse dicho reset automático.

Para evitar que el reset se dispare es para lo que aplicamos el restart_wdt(); o sea que "restauramos" el timer del Watchdog, o lo que es lo mismo: lo volvemos a poner a 0 "a mano" y vuelve de nuevo a iniciar su cuenta para acercarse al abismo y amenazarnos con resetear el micro si antes no lo "restauramos" de nuevo.

Un ejemplo tonto:
Configuramos nuestro Watchdog para que salte cada 5 ms, por ejemplo.
Entramos en una rutina que espera a que le lleguen una docena de caracteres vía RS232, y cada vez que le llega uno hace un restart_wdt().
Al recibir el doceavo carácter sale de la rutina y continua su ejecución normal.
Por manos del demonio se nos escapa el hacha que con la que estábamos haciendo juegos malabares y corta accidentalmente el cable de la RS232, justo cuando el PIC había recibido el carácter número 11 de los 12 que esperaba.
Por lo tanto nuestro programa se queda esperando un carácter que nunca le va a llegar, al menos durante el tiempo en que tardemos en sustituir el cable accidentado.

¿Y qué ocurre entonces con el resto de del programa que debía estar funcionando? pues que todo está detenido indefinidamente
.
Pero, para eso está el Watchdog. Como restaurábamos el contador cada vez que recibíamos un carácter y estos iban llegando, uno a uno en su cadencia natural, el Watchdog no se desbordaba y todo iba bien. Pero tras recibir nuestro 11 carácter y quedarse esperando el 12 nadie ha restaurado el Watchdog por lo que este camina, paso a paso, tick a tick, hasta el temible desbordamiento ... y éste se produce indefectiblemente 5 ms después de haber recibido el onceavo carácter.

El PIC se resetea y todo vuelve a comenzar de nuevo.

Si hemos sido lo suficientemente inteligentes como para escribir un 1 en la EEPROM al iniciar la recepción de los susodichos 12 bytes, y teníamos previsto escribir un 0 en la EEPROM en el mismo sitio para indicar que la última recepción de 12 bytes fue un completo éxito tendremos disponible un indicador veraz y seguro de que al reiniciarse nuestro PIC sabremos fehacientemente que la última recepción fue bien o por el contrario se convirtió en un completo, total y rotundo fracaso y, por lo menos, nos tomaremos con precaución el asunto de la RS232.

Nuestro programa podrá seguir su curso evitando los terrenos pantanosos y habilitando los medios para solventar los problemas que nos hemos encontrado.
Un saludo desde Sevilla, España.
Visita MicroPIC                                                                                        ɔ!doɹɔ!ɯ ɐʇ!s!ʌ

Desconectado Azicuetano

  • Moderadores
  • PIC24H
  • *****
  • Mensajes: 1020
    • Aplicaciones Electrónicas en Alicante.
Re: Luchando contra el ruido POR SOFTWARE
« Respuesta #1 en: 10 de Septiembre de 2007, 19:39:33 »
Este hilo empieza con una buena explicación jeje. Todos los libros que hablan de microcontroladores tendrían que empezar así el tema del watchdog.

Recupero un post que escribí hace un tiempo y que más o menos creo que se podría poner aquí:

---------------------------------------------------------------------------------------------------------------------------------------------

A mi me gusta refrescar el watchdog en el bucle principal (y si es posible sólo una vez) y no recomiendo el refresco en las interrupciones.

Lo que hago es seleccionar un determinado tiempo en el watchdog y pongo un refresco en el bucle principal. Si el micro se está reseteando continuamente lo que hago es aumentar el tiempo del watcdog hasta que el equipo me funciona bien (o viceversa).

Además de todo esto también me gusta hacer lo siguiente:

Si pasamos por el bucle principal cada 10 ms (aproximadamente) configuro el wdt con 18ms y en el bucle principal (si la aplicación me lo permite) hago un retardo de unos 6 o 7 ms para que mi bucle principal tenga una duración de 17 ms (más o menos). Lo que consigo así es ajustar al máximo el wdt. Parece una tontería pero... por no ajustar bien el wdt en varias ocasiones que he tenido problemas de ruido y el wdt no me los ha solventado (porque se me ha refrescado aún sufriendo un salto el contador de programa).

---------------------------------------------------------------------------------------------------------------------------------------------

Esto que comenté hace ya un tiempo lo continuo haciendo. Tengo comprobado que si sufres ruido la ejecución normal del programa (el contador de programa)  salta a donde le da la real gana. Si no se ajusta bien el tiempo del WDT se puede dar el caso que, aún saltando a cualquier otra función, al WDT no le de tiempo a desbordarse y no te resetea la aplicación (la consecuencia es evidente, el programa se cuelga jeje).

Este es el truquillo que yo tengo para el WDT. Estoy de acuerdo que quizás es demasiado extremista mi postura, pero bueno, como no cuesta nada hacerlo y tengo comprobado que se pueden sufrir cuelgues si no lo ajustas bien... por eso lo hago  :-)


Un saludo desde Alicante.

PD: Me gustaría saber hasta que punto es importante soldar la carcasa metálica del cristal de cuarzo a la masa del circuito. Recuerdo que Maunix una vez lo comentó y desde entonces estoy con la mosca detras de la oreja jeje. Si alguien tiene alguna experiencia en este tema le agradecería su comentario (bueno... se lo agraceríamos todos yo incluido jeje).


« Última modificación: 10 de Septiembre de 2007, 19:43:00 por Azicuetano »

Desconectado Leon Pic

  • Colaborador
  • DsPIC30
  • *****
  • Mensajes: 3473
    • Mensajes de la Virgen María
Re: Luchando contra el ruido POR SOFTWARE
« Respuesta #2 en: 10 de Septiembre de 2007, 19:46:03 »
Hola. Me interesa mucho este post. Estuve tambien en el tema de hablemos de ruido que es muy bueno. Mi experiencia con los ruidos son un desastre vamos 1000000000000000000000000000 a 0. Me las tiene por el piso el condenado ruido, estoy en un proyecto que no puedo concluir por el ruido, lo he montado en un protorboard y la verdad que no lo puedo hacer andar. Hise un tema por el protorboard y me an aconsejao que utilice el proteus, pues bien, lo estoy haciendo y no lo puedo hacer porque baje una versión demo y resulta que no anda para trajar con los pic (ya es demasiado que no te lo deja grabar, tengo que dejar prendida la PC para trabajar al otro día y todo porque el software es muy caro) Por lo tanto me voy a arriesgar en armar la placa y probarlo (para mi es arriesgado ya que no dispongo de mucha plata)

Con el tema del software proteus, estoy averiguando precio (no lo quiero robar, lean mas abajo de mi post). El que vende en latinoamérica es Brasil, por lo que estoy esperando un precio por el profesional, voy a averiguar cuanto sale comprarlo por cantidad, todo aquel interesado que lo quiera comprar conmigo, que se contacte conmigo. Una vez que tenga un precio, voy a armar un nuevo tema para juntar compañero para comprar licencias.

Saludos.  :-/ :-/
Jesús dijo, yo soy el CAMINO, la VERDAD y la VIDA, nadie llega al PADRE si no es por mi.

-Mi propio Foro de Meteorología
www.meteorologiafacil.com.ar/foros/index.php

Desconectado micro_cadaver

  • Colaborador
  • PIC24H
  • *****
  • Mensajes: 2102
    • blog microembebidos
Re: Luchando contra el ruido POR SOFTWARE
« Respuesta #3 en: 11 de Septiembre de 2007, 03:43:32 »
excelente post, yo tambien uso el WDT combinándolo con la eeprom, pero no sabia lo del ruido y los saltos del PClath, tampoco lo del xtal soldado a tierra.

offtopic para leon_pic:
palabras honestas las tuyas amigo.  :-)
a cosechar!!!... :P
pic32... ahi voy....
aguante el micro 16f84  !!!!

visita mi pagina: http://www.microembebidos.wordpress.com

Desconectado RedPic

  • Administrador
  • DsPIC33
  • *******
  • Mensajes: 5416
    • Picmania by Redraven
Re: Luchando contra el ruido POR SOFTWARE
« Respuesta #4 en: 11 de Septiembre de 2007, 06:28:36 »
Ja, ja, ja  :D :D :D

Ese artículo de la Wikipic se parece mucho al artículo Conceptos y Explicaciones: El WatchDog en PicManía que a su vez también se parece mucho al anterior Post de este foro Contador con timer0 en los Pic 18 escrito por mí el día de mi cumpleaños del año pasado.

Hay que ver las vueltas que dá un artículo.  :mrgreen:

Contra la estupidez los propios dioses luchan en vano. Schiller
Mi Güeb : Picmania

Desconectado Nocturno

  • Administrador
  • DsPIC33
  • *******
  • Mensajes: 17506
    • MicroPIC
Re: Luchando contra el ruido POR SOFTWARE
« Respuesta #5 en: 11 de Septiembre de 2007, 07:21:34 »
Es lo que tienen las cosas buenas, amigo.
Un saludo desde Sevilla, España.
Visita MicroPIC                                                                                        ɔ!doɹɔ!ɯ ɐʇ!s!ʌ

Desconectado aitopes

  • Moderadores
  • DsPIC33
  • *****
  • Mensajes: 5102
    • uControl
Re: Luchando contra el ruido POR SOFTWARE
« Respuesta #6 en: 11 de Septiembre de 2007, 07:26:34 »
Buenismo el tema. Por lo visto hay mucho para hacer desde el lado del software para evitar el desastre.

Citar
Ese artículo de la Wikipic se parece mucho al artículo Conceptos y Explicaciones: El WatchDog en PicManía que a su vez también se parece mucho al anterior Post de este foro Contador con timer0 en los Pic 18 escrito por mí el día de mi cumpleaños del año pasado.

Pues....si alguien busca 100 años de perdón, ya sabe que hacer!!!!!!!!!! Yo estoy tentado. ;)
Saludos!
Si cualquier habilidad que aprende un niño será obsoleta antes de que la use, entonces, ¿qué es lo que tiene que aprender? La respuesta es obvia:
La única habilidad competitiva a largo plazo es la habilidad para aprender
“. Seymour Papert

Desconectado MGLSOFT

  • Moderador Local
  • DsPIC33
  • *****
  • Mensajes: 7791
Re: Luchando contra el ruido POR SOFTWARE
« Respuesta #7 en: 11 de Septiembre de 2007, 08:23:16 »
Hey Manolo, tanto RON te esta afectando la personalidad !! :mrgreen: :mrgreen:
Realmente creo que ese tipo de notas es para copiarlas, adelante Ariel!! :lol: :lol:
Y a felicitar al autor del Alzheimer, que parece que anda recuperandose !!! :D :D :D :D
Todos los dias aprendo algo nuevo, el ultimo día de mi vida aprenderé a morir....
Mi Abuelo.

Desconectado Leon Pic

  • Colaborador
  • DsPIC30
  • *****
  • Mensajes: 3473
    • Mensajes de la Virgen María
Re: Luchando contra el ruido POR SOFTWARE
« Respuesta #8 en: 11 de Septiembre de 2007, 08:59:50 »
offtopic para leon_pic:
palabras honestas las tuyas amigo.  :-)

Muchas gracias.

Saludos.  :-/ :-/
Jesús dijo, yo soy el CAMINO, la VERDAD y la VIDA, nadie llega al PADRE si no es por mi.

-Mi propio Foro de Meteorología
www.meteorologiafacil.com.ar/foros/index.php

Desconectado RedPic

  • Administrador
  • DsPIC33
  • *******
  • Mensajes: 5416
    • Picmania by Redraven
Re: Luchando contra el ruido POR SOFTWARE
« Respuesta #9 en: 11 de Septiembre de 2007, 09:56:37 »
En el mismo orden de lo iniciado por Manolo voy a estudiar en breve y después "articulear" en este mismo hilo la combinación mágica de los POR & BOR resets.

Como adelanto solo deciros que el uno, POR (Timer Power On Reset) hace que el reset se desenclave pasado un tiempo programable después de haber alcanzado el nivel optimo de hacerlo. Esto nos ayuda a esperar lo suficiente a que todo nuestro PIC esté estabilizado antes de empezar a ejecutar nuestro firmware. Y el otro, BOR (Brown-Out Reset(, mete en un reset automático al PIC cuando se detecta una caída de la alimentación programable.

La combinación de ambos nos dará seguridad de que el PIC no va a intentar realizar nada mientras esta cayendo la tensión de alimentación, al punto que que empiece a caer el PIC entrará en reset, funcionará el BOR, y si es un pico de caída no va a salir del reset hasta un tiempo después, por lo que si nos fluctúa la tensión seguirá disparándose el BOR hasta que tras el POR suficiente quede todo estabilizado y el PIC comience de nuevo a funcionar.

Esta combinación le viene de maravillas a la EEPROM, por ejemplo.

Contra la estupidez los propios dioses luchan en vano. Schiller
Mi Güeb : Picmania

Desconectado Azicuetano

  • Moderadores
  • PIC24H
  • *****
  • Mensajes: 1020
    • Aplicaciones Electrónicas en Alicante.
Re: Luchando contra el ruido POR SOFTWARE
« Respuesta #10 en: 11 de Septiembre de 2007, 10:25:35 »
Esto se pone calentito!

Esta noche cuento yo mi truco del "restart_cause()" (me lo piiidoooo  :D)

A mi me encanta  :mrgreen:


Un saludo desde Alicante.

Desconectado MGLSOFT

  • Moderador Local
  • DsPIC33
  • *****
  • Mensajes: 7791
Re: Luchando contra el ruido POR SOFTWARE
« Respuesta #11 en: 11 de Septiembre de 2007, 11:07:36 »
En el mismo orden de lo iniciado por Manolo voy a estudiar en breve y después "articulear" en este mismo hilo la combinación mágica de los POR & BOR resets.

Como adelanto solo deciros que el uno, POR (Timer Power On Reset) hace que el reset se desenclave pasado un tiempo programable después de haber alcanzado el nivel optimo de hacerlo. Esto nos ayuda a esperar lo suficiente a que todo nuestro PIC esté estabilizado antes de empezar a ejecutar nuestro firmware. Y el otro, BOR (Brown-Out Reset(, mete en un reset automático al PIC cuando se detecta una caída de la alimentación programable.

La combinación de ambos nos dará seguridad de que el PIC no va a intentar realizar nada mientras esta cayendo la tensión de alimentación, al punto que que empiece a caer el PIC entrará en reset, funcionará el BOR, y si es un pico de caída no va a salir del reset hasta un tiempo después, por lo que si nos fluctúa la tensión seguirá disparándose el BOR hasta que tras el POR suficiente quede todo estabilizado y el PIC comience de nuevo a funcionar.

Esta combinación le viene de maravillas a la EEPROM, por ejemplo.



Hablando de la EEPROM, como utilizar estos bits para detectar con tiempo el momento de grabar un dato que no queremos que se pierda, pero que esta en Ram ??
 :shock: :shock:
Todos los dias aprendo algo nuevo, el ultimo día de mi vida aprenderé a morir....
Mi Abuelo.

Desconectado Azicuetano

  • Moderadores
  • PIC24H
  • *****
  • Mensajes: 1020
    • Aplicaciones Electrónicas en Alicante.
Re: Luchando contra el ruido POR SOFTWARE
« Respuesta #12 en: 11 de Septiembre de 2007, 19:56:19 »
Bueno, voy con el 'restart_cause()' de mis amores.

Con esta función podemos saber cual fue la causa del reinicio del PIC.

Para que la utilizo? Pues... si nuestro hardware se resetea por causa mayor podemos hacer que el usuario ni se entere del cuelgue.

En que tipos de hard-software se puede utilizar esto?? Pues vamos con un ejemplo:

Imaginemos que tenemos una PBA que cada vez que se enciende el usuario la tiene que activar dándole a un pulsador. Si el equipo se cuelga por la noche, estará sin funcionar un buen número de horas. Sin embargo, si al principio de nuestro main somos capaces de saber que fué lo que pasó (por que se reseteó) podremos hacer que el equipo continue funcionando como si nada.

Evidentemente he puesto el ejemplo más tonto, pero, imaginaros que cuando se enciende la pba hace un pitido, o... espera iniciar algún evento que en ese momento no se puede hacer por lo que sea.

El caso es que se puede utilizar casi siempre y... es un buen método para que nadie se de cuenta de nuestra ineptitud (o de la suya propia) :D

Un ejemplo puede ser este. La pba siempre hace un pitido cuando se enciende y muestra por unos displays la versión del soft que tiene grabado. A continuación solo detectaremos cuando la PBA se reinicia por un fallo en la alimentación 'BROWNOUT_RESTART' y lo que haremos es omitir ese pitido inicial y que nos muestre la versión. Aunque el usuario estñe encima de la pba no se dará ni cuenta que se ha reseteado por un fallo en la alimenteción.  :mrgreen:

Código: [Seleccionar]
switch(restart_cause())
{

case WDT_FROM_SLEEP:

mostrar_version(); // VERSION

BIP();

case WDT_TIMEOUT:

mostrar_version(); // VERSION

BIP();

case MCLR_FROM_SLEEP:

mostrar_version(); // VERSION

BIP();

case MCLR_FROM_RUN:

mostrar_version(); // VERSION

BIP();

case NORMAL_POWER_UP:

mostrar_version(); // VERSION

BIP();

case BROWNOUT_RESTART:       // Aqui se mete casi siempre que sufre ruido la pba
                             // Reiniciamos la pba pero sin que el usuario se de cuenta
// output_high(PIN_C0);      // por eso ni encendemos leds, ni versión, ni pitamos ni nada.
// output_high(PIN_C1);
// output_high(PIN_C2);
// output_high(PIN_C3);


}


Un saludo desde Alicante.
« Última modificación: 04 de Enero de 2009, 14:34:50 por Azicuetano »

Desconectado Nocturno

  • Administrador
  • DsPIC33
  • *******
  • Mensajes: 17506
    • MicroPIC
Re: Luchando contra el ruido POR SOFTWARE
« Respuesta #13 en: 12 de Septiembre de 2007, 01:01:59 »
Llevando tu método al límite, Iván, si nuestro programa está basado en una máquina de estados, incluso podríamos ir al estado que estaba activo durante el Reset, ¿verdad?
Según tengo entendido la RAM permanece con los mismos valores, por lo que quizás se podría conseguir una transparencia total para el usuario.
Un saludo desde Sevilla, España.
Visita MicroPIC                                                                                        ɔ!doɹɔ!ɯ ɐʇ!s!ʌ

Desconectado Azicuetano

  • Moderadores
  • PIC24H
  • *****
  • Mensajes: 1020
    • Aplicaciones Electrónicas en Alicante.
Re: Luchando contra el ruido POR SOFTWARE
« Respuesta #14 en: 12 de Septiembre de 2007, 04:42:21 »
Yo diría que si.

Creo recordar que Diego escribió algo al respecto de la RAM y de su capacidad para no borrar los datos frente a un reseteo (no se si todas las familias de PIC´s lo permiten).

El caso es que, de la forma que tú dices, la transparencia sería total  :mrgreen: a mi juicio sería una muy buena combinación.


Un saludo desde Alicante.


 

anything