TODOPIC

Microcontroladores PIC => Todo en microcontroladores PIC => Mensaje iniciado por: Nocturno en 10 de Septiembre de 2007, 13:12:31

Título: Luchando contra el ruido POR SOFTWARE
Publicado por: Nocturno en 10 de Septiembre de 2007, 13:12:31
Tras haber leído con detenimiento el contenido del hilo Hablemos del Ruido (http://www.todopic.com.ar/foros/index.php?topic=18106.0) 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 (http://www.micropic.es/index.php?option=com_mambowiki&Itemid=75).



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.
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: Azicuetano 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).


Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: Leon Pic 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.  :-/ :-/
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: micro_cadaver 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.  :-)
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: RedPic 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 (http://picmania.garcia-cuervo.net/Conceptos.php#WatchDogTimer) 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 (http://www.todopic.com.ar/foros/index.php?topic=13694.msg80269#msg80269) 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:

Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: Nocturno en 11 de Septiembre de 2007, 07:21:34
Es lo que tienen las cosas buenas, amigo.
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: aitopes 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!
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: MGLSOFT 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
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: Leon Pic en 11 de Septiembre de 2007, 08:59:50
offtopic para leon_pic:
palabras honestas las tuyas amigo.  :-)

Muchas gracias.

Saludos.  :-/ :-/
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: RedPic 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.

Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: Azicuetano 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.
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: MGLSOFT 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:
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: Azicuetano 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.
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: Nocturno 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.
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: Azicuetano 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.
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: RedPic en 12 de Septiembre de 2007, 17:41:28
En efecto, en todos los PIC's en que he probado esto hasta ahora se dá ese efecto, tras un Reset, MCLR a masa, la RAM queda intacta con todos los valores que tenía anteriormente (16F628, 16F777, 16F876, 18F2550 y 18F4550)

Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: aitopes en 12 de Septiembre de 2007, 17:55:26
Hola amigos!
Es posible que no exista una rutina de "sobreescribir toda la ram con...." cada vez que se hace un RESET, tal como ha comprobado Diego. De hecho, es algo que tomaria algun tiempo hacer....demorando el reinicio del programa.

Esto es algo bastante similar (o al menos yo lo encuentro parecido) a lo que ocurre al eliminar un archivo en DOS : el fichero aparece como borrado, pero solo se elimino su entrada en la FAT, los datos siguen donde estaban, y no se perdio tiempo borrandolos fisicamente.

Esta muy buena la idea de aprovechar esta caracteristica, que seguramente no esta siquiera documentada... :)

Saludos!
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: Azicuetano en 12 de Septiembre de 2007, 19:31:37
En efecto, en todos los PIC's en que he probado esto hasta ahora se dá ese efecto, tras un Reset, MCLR a masa, la RAM queda intacta con todos los valores que tenía anteriormente (16F628, 16F777, 16F876, 18F2550 y 18F4550)

Excelente dato para tenerlo muy en cuenta.


Un saludo desde Alicante.
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: jfh900 en 12 de Septiembre de 2007, 21:10:22
Esta técnica (la recuperación de una máquina despues de un apagado) es algo que se hace desde hace mucho tiempo en los sistemas microprocesados, se conoce como arranque en caliente (se mantienen los datos) o arranque en frio (se inicializa la máquina). Es muy conveniente realizar un checksum de la memoria en el momento del arranque y si los datos no son coherentes realizar una arranque en frio, en caso contrario realizar el arranque en caliente.

Un saludo
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: LABmouse en 12 de Septiembre de 2007, 21:43:15
Yo siempre Uso el WDT, En muchos equipos que diseñaba antes, cualquier problemita en la RED generaba que el PIC se enlocara y saliera de si bucle principal de Funcionamiento. Y si tenia pantalla LCD, salian caracteresa raros y eso. Al final WDT, es la solucion para cuando ocurren ese tipo de cosas.

Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: flacoclau en 12 de Septiembre de 2007, 23:12:02
 Hasta ahora el único problema que tuve con el ruido ha sido en la entrada de un lm35 al ADC del micro con un par de metros de cable mallado, aún así se metía ruido y la lectura en el display era fluctuante, incluso el último dígito variaba tanto que no se podía leer. Esto lo solucioné por soft, no es el método de sacar promedio, es  un poco menos elegante pero mucho más fácil de programar y me ha dado buenos resultados. Es un filtro pasa bajos por soft.
 Lo que hice es tomar el valor mostrado en el display, guardarlo en un registro y compararlo con los valores siguientes que me vá entregando el adc, tengo dos contadores que voy decrementando según sea el valor del adc, un contador para los valores que son mayores y el otro para los menores, si es mayor que el valor del display decremento uno y reseteo el otro, y viceversa.
si alguno de de los contadores llegó a cero es porque hubo 25 mediciones seguidas que fueron mayores, ó 25 mediciones seguidas que fueron menores, eso quiere decir que la variación es real y actualizo el display y aparte trabajo con ese valor nuevo para la toma de deciciones.
 Al valor inicial de los contadores lo elegí en 25 empíricamente, fuí probando lo más conveniente para mi proyecto, ya que un valor mayor me mostraba saltos entre cada temperatura y un valor menor ya no era tan eficaz en el filtrado, osea que aún se veía alguna fluctuación.
espero les sirva y perdón por ser tan extenso.
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: RedPic en 13 de Septiembre de 2007, 01:57:21

Esta muy buena la idea de aprovechar esta caracteristica, que seguramente no esta siquiera documentada... :)


No solo no está documentada sino que me volvió loco hasta que descubrí que valores que yo asumía como ceros tenían un valor distinto tras un reset (Nota importante: ¡Que no implicase un corte total de la alimentación!)

Lo peor eran los flags activados: Mi programa empezaba de nuevo con algun flag a 1, indicador de que algún evento había ocurrido,  cuando era absolutamente falso ya que el evento había ocurrido antes del reset y el programa estaba construido para comenzar suponiendo que todos los flags estaban a cero.

Solución: La primera linea de mi main() comienza siempre con una llamada a una función denonminada on_reset() donde pongo explícitamente los valores que deben tener todas las variables al inicio de la ejecución del programa, sea cual sea el valor que tuviesen anteriormente. Una variable no inicializada en esta sección podría servirme para pasar mensajes desde antes hasta después de un reset (que no sea por corte de alimentacion)

Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: aitopes en 13 de Septiembre de 2007, 07:29:55
Hola Diego!

Si Bill Gates fuese el dueño de Microchip, toma este bug, lo documenta, y lo transforma en una de las ventajas del "nuevo core PIC version xxx.yyy" :) :) :)

Me imagino por las que has pasado.

Saludos!
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: RedPic en 13 de Septiembre de 2007, 09:11:56
Si, Ariel, y especialmente a mi que mis main() son un compendio de flag's en cascada ... imáginate un reset con todos esos flag's  LFADN (Los Flag's Locos Atacan De Nuevo)

Ejemplo de un main() que es puro flag (he quitado lo que cada flag dispara) ...

Código: C++
  1. ///////////////////////////////////////////////////////////////////////////////////////////////////
  2. //
  3. // M A I N
  4. //
  5. ///////////////////////////////////////////////////////////////////////////////////////////////////
  6.  
  7. void main(void){
  8.  
  9.  
  10. main_on_reset:
  11.  
  12.    main_on_reset();
  13.  
  14.    do{
  15.  
  16.       /////////////////////////////////////////////////////////////////////////////////////////////
  17.       //
  18.       // Registra estado de Entradas Digitales
  19.       //
  20.       /////////////////////////////////////////////////////////////////////////////////////////////
  21.  
  22.       task_registry_digital_sensors();
  23.       // Si hay cambio estable en STATUS ...
  24.       if(flag_change_STATUS_stable==1){
  25.          flag_change_STATUS_stable=0;
  26.          ...
  27.       }
  28.       /////////////////////////////////////////////////////////////////////////////////////////////
  29.       //
  30.       // Detecta y Ejecuta la necesidad de Realizar un Reset por Software
  31.       // realizando la secuencia normal implementada en main_on_reset()
  32.       //
  33.       /////////////////////////////////////////////////////////////////////////////////////////////
  34.       if(flag_force_Reset==1){
  35.       ...
  36.       }
  37.       /////////////////////////////////////////////////////////////////////////////////////////////
  38.       //
  39.       // Detecta y Ejecuta la necesidad de Actualizar el Firmware mediante el Bootloader
  40.       // Escribe la marca de EEINT_Device_Status_Firmware en la EEPROM interna y ejecuta el bootloader.
  41.       //
  42.       /////////////////////////////////////////////////////////////////////////////////////////////
  43.       if(flag_force_Boot==1){
  44.        ...
  45.       }
  46.       /////////////////////////////////////////////////////////////////////////////////////////////
  47.       //
  48.       // Detecta necesidad de procesar el buffer USART
  49.       // y lo procesa en la rutina correspondiente.
  50.       //
  51.       /////////////////////////////////////////////////////////////////////////////////////////////
  52.       if(flag_recUSARTComplete==1 or flag_USART_Time_Out_Error==1){
  53.          // Filtra recepcion por canal RS485
  54.          if(flag_RS485_reception_active==1){
  55.             flag_RS485_reception_active=0;
  56.             .....
  57.          }
  58.          else ...
  59.       }
  60.       /////////////////////////////////////////////////////////////////////////////////////////////
  61.       //
  62.       // Detecta necesidad de desactivar alguno de los Relés
  63.       // desactiva el rele y el flag correspondiente.
  64.       //
  65.       /////////////////////////////////////////////////////////////////////////////////////////////
  66.       if(flag_RELAY_1_elapsed==1){
  67.          flag_RELAY_1_elapsed=0;
  68.          ...
  69.       }
  70.       if(flag_RELAY_2_elapsed==1){
  71.          flag_RELAY_2_elapsed=0;
  72.          ...
  73.       }
  74.       /////////////////////////////////////////////////////////////////////////////////////////////
  75.       //
  76.       // Detecta Lectura Completa en HEAD1 o timeout de <XRHEAD,1,...>
  77.       // transmite y/o registra y desactiva el flag
  78.       //
  79.       /////////////////////////////////////////////////////////////////////////////////////////////
  80.       // Si lectura completa de HEAD1
  81.       if(flag_Head1_Read_Complete==1 OR flag_RHEAD1_timeout==1){
  82.          flag_Head1_Read_Complete=0;
  83.          // si no acaba de realizarse una conmutacion set_to_i2c_channel()
  84.          if(flag_after_CD4053_Comnutation==1){
  85.             flag_after_CD4053_Comnutation=0;
  86.             ...
  87.          }
  88.          else{
  89.             // Realizo las tareas necesarias tras una lectura completa de HEAD1.
  90.             ...
  91.          }
  92.       }
  93.       // Si lectura completa de HEAD2
  94.       if(flag_Head2_Read_Complete==1 OR flag_RHEAD2_timeout==1){
  95.          flag_Head2_Read_Complete=0;
  96.          // Realizo las tareas necesarias tras una lectura completa de HEAD2.
  97.          ...
  98.       }
  99.       /////////////////////////////////////////////////////////////////////////////////////////////
  100.       //
  101.       // Detecta timeout por ausencia de respuesta del Server
  102.       //
  103.       /////////////////////////////////////////////////////////////////////////////////////////////
  104.       // No hay <RQUERY> o respuesta <XRQST,1...> para >DQRST,1...>
  105.       if(flag_REQUEST_timeout1==1){
  106.          flag_REQUEST_timeout1=0;
  107.          flag_REQUEST_Pending1=0;
  108.          // No recibo a tiempo <RQUERY> o <XRQST> No hay Polling y estoy en alguno de los modos que lo requieren.
  109.          ...
  110.       }
  111.       // No hay <RQUERY> o respuesta <XRQST,2...> para >DQRST,2...>
  112.       if(flag_REQUEST_timeout2==1){
  113.          flag_REQUEST_timeout2=0;
  114.          flag_REQUEST_Pending2=0;
  115.          // No recibo a tiempo <RQUERY> o <XRQST> No hay Polling y estoy en alguno de los modos que lo requieren.
  116.          ...
  117.       }
  118.       /////////////////////////////////////////////////////////////////////////////////////////////
  119.       //
  120.       // Detecta timeout por ausencia de respuesta del Canal RS485
  121.       //
  122.       /////////////////////////////////////////////////////////////////////////////////////////////
  123.       if(flag_RS485_elapsed==1){
  124.          flag_RS485_elapsed=0;
  125.          ...
  126.       }
  127.       /////////////////////////////////////////////////////////////////////////////////////////////
  128.       //
  129.       // Detecta Segnal de Card Present en Cabezal 1 o Cabezal 2
  130.       // y ...
  131.       //
  132.       /////////////////////////////////////////////////////////////////////////////////////////////
  133.       if(flag_RHEAD1_Card_Present==1 OR flag_RHEAD2_Card_Present==1){
  134.          ...
  135.       }
  136.       /////////////////////////////////////////////////////////////////////////////////////////////
  137.  
  138.  
  139.    }while(1);
  140. }
  141.  
  142.  

P.D. Meguta el GeSHi modelo cpp  :mrgreen:
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: PalitroqueZ en 13 de Septiembre de 2007, 13:35:16
Azicuetano ese programa que colgaste (http://www.todopic.com.ar/foros/index.php?topic=18647.msg130279#msg130279) se asemeja un poco a lo que hacen las bios cuando identifican fallas en la motherboards, el código de pitidos
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: dogflu66 en 13 de Septiembre de 2007, 14:02:27
Aquí dejo algo de mis costumbres ya que no me acuerdo de todas, porque en esto también hay mucho de intuición
De seguro que ya se han hablado de ellas, pero aquí las dejo he iré ampliando según me acuerde de mas detalles.

Mis pequeños trucos básicos para paliar los efectos del ruido:

Hard:
  La fuente de alimentación:
    AC: En la entrada un varistor siempre y su filtro con transformador y condensadores junto con su conexión a tierra.
    DC: Capacidades variadas, 10nF, 100 a 330nF y Electrolítico

  Esquema:
     En el circuito en si, 100pF en las salidas digitales y 1nF en las entradas.
    Condensador de desacople en cada circuito integrado y módulos, 100nF.
    Si la placa no es muy grande un condensador de tántalo de entre 10 y 33uF en una zona central de la placa en la
    alimentación general y si la placa es muy grande varios de 1uF distribuidos según criterio junto con algunos de 10nF   
    y 100nF en la misma línea.
    Si hay módulos exteriores lo mismo condensadores de desacoplo de varios tipos mas uno electrolítico entre 1 y 10uF,
    lo mas cerca del conector que sea posible. Y las capacidades totales puestas en la línea de alimentación de la   
    placa no deben superar entre el 10% y 20% de la capacidad total de la fuente de alimentación. Y tener en cuenta que
    los condensadores solo tienen influencia en una determinada zona de la placa por eso es de colocarlos repartidos 
    amen de varias capacidades antes que una grande.

  PCB:
    Después aplicar el sentido común al ruteado, si una parte de la placa tiene mayor consumo pues reforzar en esa zona
    las capacidades, si se utilizan módulos de protección externos como watchdog (refrescarlo lo menos posible y
    con el tiempo justo y por supuesto no refrescarlo en las interrupciones ya que estas no suelen bloquearse) o supervisor
    de la alimentación, colocar estos circuitos lo mas cerca posible de la zona a escanear, ya que se puede dar el caso
    que se detecten parásitos que puede que el microcontrolador sea inmune a ellos, y si se puede escanear la fuente de
    alimentación que nos servirá para guardar datos con suficiente antelación.
    En el caso de prever interferencias fuera de lo normal, colocar bobinas en serie con la alimentación y con las entradas
    y salidas e incluso utilizar optoacopladores (alimentado el led con una tensión aislada galvanicamente de la de
    nuestra placa).

Soft:
   Hay que intentar trabajar de forma que se pueda dejar rastro de lo que estaba haciendo el programa ya sea con flag,
   variables, datos en la eeprom, etc. Y verificar los flag de los módulos de protección que también son una buena 
   fuente de información para evitar tener que hacer reset absolutos. En las interrupciones cíclicas se puede hacer
   una comprobación de los registros para ver el buen funcionamiento del sistema, y por supuesto intentar verificar todo lo 
   que se escribe siempre que se pueda.
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: aitopes en 13 de Septiembre de 2007, 14:24:18
Maestros, gracias por la guia. Se toma debida nota, se archiva para futuros usos y abusos. ;)

GRACIAS!  :mrgreen:
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: Azicuetano en 13 de Septiembre de 2007, 19:27:16
Ooohhhh !! Con esto se me saltan las lágrimas !!!!

    Si la placa no es muy grande un condensador de tántalo de entre 10 y 33uF en una zona central de la placa en la
    alimentación general y si la placa es muy grande varios de 1uF distribuidos según criterio junto con algunos de 10nF   
    y 100nF en la misma línea.
    Si hay módulos exteriores lo mismo condensadores de desacoplo de varios tipos mas uno electrolítico entre 1 y 10uF,
    lo mas cerca del conector que sea posible. Y las capacidades totales puestas en la línea de alimentación de la  
    placa no deben superar entre el 10% y 20% de la capacidad total de la fuente de alimentación. Y tener en cuenta que
    los condensadores solo tienen influencia en una determinada zona de la placa por eso es de colocarlos repartidos 
    amen de varias capacidades antes que una grande.

 

Jeje... te esperaba porque sabía que de este tema tú sabías mucho (por los post tuyos que he leido en estos 2 años y pico). Thanks.

Azicuetano ese programa que colgaste (http://www.todopic.com.ar/foros/index.php?topic=18647.msg130279#msg130279) se asemeja un poco a lo que hacen las bios cuando identifican fallas en la motherboards, el código de pitidos

Pues ahora que lo dices tienes razón. La pregunta es... cuando el ordenador hace 3 pitiditos intermitentes y rápidos... el problema es de la RAM o de la tarjeta gráfica???  :D  :D  :D Siempre se me olvida  :mrgreen:

Otra cosa que suelo hacer yo (y si la aplicación lo permite) es comprobar que todos los valores que guardo en la eeprom están dentro de un determinado rango (función que siempre llamo 'comprueba_eeprom()' y que tengo en el bucle principal). En el mismo instante que un valor de la eeprom se va de fiesta lo reinicio a su valor por defecto. También suelo intentar hacer el programa de forma que no se quede atontao cuando un valor no es el esperado.


Un saludo desde Alicante.
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: PalitroqueZ en 14 de Septiembre de 2007, 15:58:32
... La pregunta es... cuando el ordenador hace 3 pitiditos intermitentes y rápidos... el problema es de la RAM o de la tarjeta gráfica???  :D  :D  :D Siempre se me olvida  :mrgreen:
...

según en la AMI (http://www.pcguide.com/ts/x/sys/beep/ami.htm) es la RAM.
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: RedPic en 14 de Septiembre de 2007, 16:52:03
Me encanta el tono y el nivel que va alcanzando este hilo.  :mrgreen:
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: LABmouse en 14 de Septiembre de 2007, 21:40:13
Hay algo que se me ha presentado muchas veces y esta es la hora no se como solucionarlo ni por software ni por Hardware.

Cuando almaceno información dentro de la EEPROM interna del PIC, después de algunos RESET, esos valores cambian, no en todas las posiciones, pero si en algunas.

En cambio una EEPROM Externa nunca me ha dado ese problema.
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: Leon Pic en 14 de Septiembre de 2007, 21:46:44
Huyyyyyyyyyyyyy!!!!!!!!!!!

Que buen dato me acabas de dar PICmouse, la verdad es que yo no sabía que de varios reset, la EEMPROM del PIC cambiaban en varios reset, voy a tener que tenerlo en cuenta. ¿Alguién sabe como superar este deperfecto?

Saludos.  :-/ :-/
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: El_Guitre en 14 de Septiembre de 2007, 22:08:30

No solo no está documentada sino que me volvió loco hasta que descubrí que valores que yo asumía como ceros tenían un valor distinto tras un reset (Nota importante: ¡Que no implicase un corte total de la alimentación!)


Una pregunta, respecto al problema este de que algunos flags tenían valores distintos a cero, la directiva del compilador #ZERO_RAM no serviría en este caso para asegurarnos de que esto no pase? Saludos, espectaculares los consejos que estan dando.
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: Nocturno en 15 de Septiembre de 2007, 02:12:54
Pues no tenía ni idea de esa directiva, pero suena muy interesante:

Syntax:
 #zero_ram

Purpose:
 This directive zero's out all of the internal registers that may be used to hold variables before program execution begins.
 
Examples:
 #zero_ram

void main() {

}
 


Compila así:
.................... #zero_ram
0088:  BCF    0C.5
0089:  BCF    0A.3
008A:  GOTO   033

Y en 033 tenía esto:
0033:  MOVF   27,W
0034:  MOVWF  04
0035:  MOVF   28,W
0036:  MOVWF  20
0037:  MOVF   29,W
0038:  MOVWF  21
0039:  MOVF   2A,W
003A:  MOVWF  22
003B:  MOVF   2B,W
003C:  MOVWF  23
003D:  MOVF   2C,W
003E:  MOVWF  24
003F:  MOVF   2D,W
0040:  MOVWF  0A
0041:  SWAPF  26,W
0042:  MOVWF  03
0043:  BCF    03.5
0044:  SWAPF  25,W
0045:  BTFSC  26.1
0046:  BSF    03.5
0047:  RETFIE

No pillo mucho, pero parece que inicializa variables.
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: El_Guitre en 15 de Septiembre de 2007, 04:02:06
Según lo que leo en la ayuda de CCS dice:

"Directiva que pone a cero todos los registros internos que pueden usarse para mantener variables, antes de que comience la ejecución del programa."

Por lo tanto debería poder usarse para poner a 0 las variables en caso de un reseteo accidental. ¿o no?.
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: RedPic en 15 de Septiembre de 2007, 04:52:40
Interesante lo de la #zeroram ¡Habra que investigar su funcionamiento!

Con respecto a la EEPROM voy a implementar un sistema dentro de la rutina de WriteByte con un bucle que escrito en pseudocódigo sería así:

recibo el byte a escribir;
inicializo un contador;
_escribir:
incremento el contador;
si el contador es mayor que numero_maximo_de_reintentos goto _salir_error;
escribo el byte;
leo el byte;
si no es igual al recibido goto _escribir;
goto _salir_ok
_salir_error:
devuelvo -1;
_salir_ok;
devuelvo 0;

Con esto me aseguro que por lo menos he escrito correctamente y que el error no está en el origen, que he escrito mal, sino que el valor ha cambiado a posteriori.

Otra técnica que esta sí que ya utilizo:

El escribir la EEPROM requiere un tiempo que en relación a la velocidad de funcionamiento del PIC es un tiempo realmente largo, del orden de algunos milisegundos, tiene que direccionar, poner el dato, y darle a la EEPROM un pico de tensión para fijarlo y esperar a que se estabilice. Un error muy común es no darle tiempo al PIC a que realice una buena escritura, un valor muy normal que yo utilizaba antes era el de 5 ms colocando un delay_ms(5) tras escribir el byte y siempre me quedaba la duda razonable de si era demasiado corto, o de si estaba desperdiciando tiempo esperando mas de la cuenta.

Ahora he cambiado de estrategia al saber que hay una interrupción que se dispara cuando se ha completado un ciclo correcto de escritura, #int_eeprom. Esta interrupción es absoluta, independiente del tiempo que necesite el PIC para escribir correctamente, se dispara cuando ha terminado y punto. Así que lo que hago es:

Habilito la interrupción int_eeprom
Pongo un flag a 1;
Escribo el byte en la EEPROM;
Espero a que el flag vuelva a 0;
Deshabilito la interrupción int_eeprom
Regreso de  la rutina de escritura de un byte.

En la interrupción int_eeprom pongo el flag a 0;

Con esto me aseguro de que el PIC tiene el tiempo suficiente y necesario para escribir su byte, ni más ni menos tiempo del que realmente necesite.

La implementacion de esto en CCS C es:

Código: C++
  1. #int_eeprom
  2. /** \brief Interrupción por : Fin escritura EEPROM interna.
  3.   *
  4.   */
  5. void interrupt_service_rutine_eeprom(void) {
  6.  
  7.    flag_Writing_INTERNAL_EEPROM=0;
  8.  
  9. }
  10.  
  11. ...
  12.  
  13. void writeByteINTEEPROM(int8 memAddress, int8 data){
  14.  
  15.    flag_Writing_INTERNAL_EEPROM=1;
  16.    enable_interrupts(int_eeprom);
  17.    write_eeprom (memAddress, data);
  18.    while(flag_Writing_INTERNAL_EEPROM==1){/*Wait for write finish*/}
  19.    disable_interrupts(int_eeprom);
  20. }
  21.  
  22.  

A este código es al que le voy a poner lo del principio del post para asegurarme que he escrito correctamente.  :mrgreen:

Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: Leon Pic en 15 de Septiembre de 2007, 06:27:56
En el caso del Pic16f84a, (aún no salí de ese pic  :lol:) hay un bye de un registro que cambia de estado cuando termina la escritura se llama WR que etá en el reistro EECON1 y lo utilizo de la siguiente manera, he aquí un pedazito de una grabación de la eeprom

                MOVLW   H'55'
   MOVWF   EECON2
   MOVLW   H'AA'
   MOVWF   EECON2
   BSF   EECON1,WR
ESPERO   BTFSC   EECON1,WR
   GOTO   ESPERO
   BCF   STATUS,RP0

Saludos.  :-/ :-/
   
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: Azicuetano en 15 de Septiembre de 2007, 11:45:35
Ufff... ya nos metemos en los entrsijos de la programación pura y dura  :D

Cuando yo programaba en asm (que bonitos y duros tiempos aquellos) con mi datasheet en una mano y el teclado en la otra programé todas mis rutinas de grabación y recuperación de la eeprom.

En asm siguiendo el datasheet al pie de la letra tube unos cuantos problemas de basura en eeprom. Les mandé un correo a nuestros queridos señores de Microchip a ver que soluciones me daban y me digeron lo siguiente:

Que al principio de mi función de grabación en eeprom implementara el chequeo de un flag que sólo activaría cada vez que fuera a hacer una grabación en la eeprom (si el programa entraba en la función de grabar accidentalmente, como el flag no estaría activado, no haría ninguna grabación).

Como dicen los compañeros el PIC tarda unos ms en efectuar la grabación en la eeprom y... activa un flag cuando esta se ha completado. Si miramos el datasheet mientras se hace la grabación hay unos instantes en los que se deshabilitan las interrupciones y en los que le metemos un par de tramas al micro de sincronización.

A mi juicio es una operación lenta y que la tenemos que cuidar y mimar todo lo que podamos.

En referencia a lo que comenta PICmouse... yo siempre hago un retardo de 0.5 segundos al principio de todos mis programas (precisamente para evitar que si reseteamos muy rápido el micro y justo al principio del programa tenemos grabaciones en eeprom, no lo interrumpamos y nos la llene de basura). No tengo comprobado que esa sea la razón pero me gusta hacerlo así más que nada para quitarme paranoias. De todas formas, un ruteado que hice una vez y en el que mezclaba lineas de potencia con lineas de control me metía basura en la eeprom que daba gusto (justo en los encendidos). Cambiando el ruteo solucioné ese problema y mi conclusión fué que... cuando un mínimo ruido afecta a nuestro micro lo que primero fastidia es la eeprom.


Un saludo desde Alicante.
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: Nocturno en 15 de Septiembre de 2007, 12:40:44
Que al principio de mi función de grabación en eeprom implementara el chequeo de un flag que sólo activaría cada vez que fuera a hacer una grabación en la eeprom (si el programa entraba en la función de grabar accidentalmente, como el flag no estaría activado, no haría ninguna grabación).
Me apunto esta idea para verificar que las funciones son llamadas siempre desde donde deben. Si utilizamos un flag para cada función y en todas se empieza con un "if (flag)..." estaremos seguro que se ha llegado a ellas de manera correcta.

Y ahora, un aporte de lo más trivial para luchar contra el ruido, pero no por ello menos importante: configurar los TRIS siempre como salidas, excepto en los pines de entrada.

Puede parecer obvio, pero me ha pasado en alguna ocasión que he utilizado un puerto entero para colocar allí los pulsadores o interruptores y por tanto he declarado el TRIS entero a "0b11111111". Luego en la práctica sólo usaba unos cuantos pines y quedaban los demás al aire y oscilando. Eso puede provocar efectos raros en la ejecución del programa, efectos que desaparecen si esos pines están configurados como salidas.
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: RedPic en 15 de Septiembre de 2007, 14:52:42

En referencia a lo que comenta PICmouse... yo siempre hago un retardo de 0.5 segundos al principio de todos mis programas (precisamente para evitar que si reseteamos muy rápido el micro y justo al principio del programa tenemos grabaciones en eeprom, no lo interrumpamos y nos la llene de basura). No tengo comprobado que esa sea la razón pero me gusta hacerlo así más que nada para quitarme paranoias.


Los PIC´s tienen implementado un dispositivo pensado para hacer exactamente esto. El TPWRT o Timer Power Time.

Cuando la alimentación del PIC comienza a crecer de 0 hasta VCC, en el momento de darle corriente o cuando el MCLR después de haber sido tirado a GND comienza a su vez a subir de GND a VCC, está el PIC áun en Reset, hasta alcanzar un nivel determinado de voltaje en el cuál se produce un POR (Power On Reset) que es una señal que indica que el Reset puede ya efectivamente desbloquearse y dejar al PIC correr alegre y jubiloso. En ese momento arranca el oscilador de programa que tras estabilizarse hace que el Reset Interno se desbloquee y comience a funcionar el PIC con nuestro programa.

Pero en este estado pueden producirse aún fluctuaciones de VCC que oscilen alrededor del nivel de disparo de dicho POR por lo que los amables señores de Microchip han implementado aún otro artificio intermedio, entre el POR y el comienzo del funcionamiento del oscilador, que consiste en un Timer que se pone en marcha con dicho POR y que durante su cuenta mantiene aún a GND la señal del Reset, alargando o estirando el tiempo que el Reset se mantiene en GND mientras los voltajes de VCC y/o MCLR alcanzan su nivel óptimo. Cuando completa su cuenta levanta el Reset a VCC y el PIC comienza entonces a correr.

En el PIC 18F4550 que es el que os muestro de ejemplo dicho TPWRT tarda 66 ms como mínimo (mas 2 ms si está activado el PLL) Ved el cronograma de activación de las distintas señales que muestra grafica y claramente como funciona este sistema:

(http://publi.garcia-cuervo.net/Power_Up_Sequence.jpg)

(http://publi.garcia-cuervo.net/Power_Up_Sequence_Times.JPG)

Nota: En CCS C este Timer se activa con el fuse PUT

Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: LABmouse en 15 de Septiembre de 2007, 15:19:14
Si es cierto lo que comentas RedPIC, desde que supe del funcionamiento del PUT, siempre lo habilito.

En lo de la EEPROM interna, que me cambiaba los valores, me sucedia cuando trabajaba en ASM y me sigue sucediendo trabajando en C.

Es mas una vez por semejante problema, recurri a lo indebido, y era usar 3 posiciones de memoria por dato y en las 3 grababa lo mismo, luego cuando necesitaba ese dato, toma las 3 lecturas y las comparaba, la que mas se repetía, ese era el valor correcto. luego regrababa con las 3 posiciones con el correcto.

Yo se, yo se... algo extremo y malo, pero me saco del lio en el que estaba. Yo tengo la costumbre de usar las interrupciones, dan mayor potencia de funcionamiento y evitan bucles cerrados. Por eso no creo que el problema fuera por falta de tiempo de la escritura de la EEPROM. Cuando trabajaba en ASM, siempre esperaba la interrupción por fin de escritura de la EEPROM.

Aunque ahora, siempre que necesito EEPROM, uso una Externa. La interna no me da buena espina.




Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: dogflu66 en 15 de Septiembre de 2007, 22:33:21
Si es cierto lo que comentas RedPIC, desde que supe del funcionamiento del PUT, siempre lo habilito.

En lo de la EEPROM interna, que me cambiaba los valores, me sucedia cuando trabajaba en ASM y me sigue sucediendo trabajando en C.

Es mas una vez por semejante problema, recurri a lo indebido, y era usar 3 posiciones de memoria por dato y en las 3 grababa lo mismo, luego cuando necesitaba ese dato, toma las 3 lecturas y las comparaba, la que mas se repetía, ese era el valor correcto. luego regrababa con las 3 posiciones con el correcto.

Yo se, yo se... algo extremo y malo, pero me saco del lio en el que estaba. Yo tengo la costumbre de usar las interrupciones, dan mayor potencia de funcionamiento y evitan bucles cerrados. Por eso no creo que el problema fuera por falta de tiempo de la escritura de la EEPROM. Cuando trabajaba en ASM, siempre esperaba la interrupción por fin de escritura de la EEPROM.

Aunque ahora, siempre que necesito EEPROM, uso una Externa. La interna no me da buena espina.







Hay circuitos comerciales que dividen la memoria E2Prom en dos partes, una es la pagina de trabajo y la
otra es la imagen de la primera. Siempre se trabaja con la pagina principal, se verifica lo que se escribe,
se dividen las paginas en filas y columnas y se genera un checsun por línea y luego uno general que
es la suma de todos los parciales y si todo esta correcto se actualiza la imagen, este sistema funciona
muy bien cuando se tiene la configuración del programa en E2Prom.
En los arranques siempre se hace un verificado de los checsum de la 1ª pagina.
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: MGLSOFT en 15 de Septiembre de 2007, 23:05:20

Hay circuitos comerciales que dividen la memoria E2Prom en dos partes, una es la pagina de trabajo y la
otra es la imagen de la primera. Siempre se trabaja con la pagina principal, se verifica lo que se escribe,
se dividen las paginas en filas y columnas y se genera un checsun por línea y luego uno general que
es la suma de todos los parciales y si todo esta correcto se actualiza la imagen, este sistema funciona
muy bien cuando se tiene la configuración del programa en E2Prom.
En los arranques siempre se hace un verificado de los checsum de la 1ª pagina.

Puedes dar ejemplos de como aplicar esto??
Es interesante el tema!! :mrgreen:
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: Leon Pic en 16 de Septiembre de 2007, 10:02:03
Me interesa mucho este tema, ya que estoy haciendo una alarma y grabo la clave en la EEPROM, si esta se graba con cualquier valor, no voy a poderr ingresar núnca la clave correcta.

Saludos.  :-/ :-/
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: maunix en 16 de Septiembre de 2007, 16:00:01
Me interesa mucho este tema, ya que estoy haciendo una alarma y grabo la clave en la EEPROM, si esta se graba con cualquier valor, no voy a poderr ingresar núnca la clave correcta.

Saludos.  :-/ :-/

Llego algo tarde al hilo pero bueno, he aqui mi humilde aporte.

Si tienes ese problema, te sugiero si o si, activar el BOR.  Mejoras el filtrado de tu circuito de MCLR.  También que filtres bien la alimentación al PIC.

Por último una técnica muy usada es grabar varias veces el dato con un checksum asociado.  Entonces, al iniciar el programa lees el password #1 con su checksum, si coinciden es porque es un dato bueno, si no coincide, lees el dato #2 con su checksum y así sucesivamente. 

Un buen hardware no borrará tu eeprom.  Si se borra seguido busca solucionar el problema por hardware, y no por software, por software será poco lo que puedas hacer ante un ruido electromagnético pulsante y constante (por citar un ejemplo).

Saludos
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: maunix en 16 de Septiembre de 2007, 16:13:31
Pues no tenía ni idea de esa directiva, pero suena muy interesante:

Syntax:
 #zero_ram

Purpose:
 This directive zero's out all of the internal registers that may be used to hold variables before program execution begins.


El zero_ram o incluir un c18iz.lib en el C18, no hacen más que cumplimentar algo que pide el estandar ANSI C y es el de que se inicialicen todas las variables utilizadas a un estado 0 por defecto.

Esto, sirve en muchos casos donde queremos asegurarnos del correcto funcionamiento de nuestro software y en otros casos, no sirve por tratarse de precisamente, querer tener los datos de "donde estaba" al momento de ocurrir el problema.

En Assembly yo hacia algo muy similar porque sino uno debia inicializar cada memoria que utilizaria, a mano.  Y eso lleva mucho tiempo, codigo, etc.  De esta forma, ponia todo a 0 usando el direccionamiento indirecto y en unas pocas instrucciones inicializaba toda la ram.

Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: jfh900 en 16 de Septiembre de 2007, 16:18:25
Da la impresión de que la EEPROM es algo inestable y que se borra con mucha facilidad. Nada más lejos de la realidad, lo raro es que los adatos estén corruptos y muy dificilmente se borran por ruido. La prueba la tenemos en los propios porgramas almacenados el los pic que duran años y años perfectamente. Yo me inclino a pensar que los problemas con la memoria son debidos a una mala programación. De todas formas con un buen checksum no deberiamos tener más problemas y si los datos guardados no coinciden con los escrito habria que revisar las subrutinas que realizan estas operaciones.

Un saludo
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: maunix en 16 de Septiembre de 2007, 16:47:04
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.

Opino que son raras las aplicaciones que deban correr justo en el punto anterior a donde venian corriendo, ya que si por ejemplo, estamos atendiendo algo importante y se resetea el pic por un BOR, tardará algunos useg o mseg (dependiendo de qué tengamos activado) en volver al lugar donde estaba lo cual en muchos casos sería peor a que directamente reinicie de nuevo.

De todas formas si ese es el caso, sugiero usar memorias externas muy veloces y que tengan posibilidad de 'recordar datos' frente a un reset.   Un ejemplo claro son las memorias ferro magnéticas que se graban en micronésimas de segundo! 

http://www.ramtron.com/doc/AboutFRAM/Technology.asp

Creo que no hay soluciones tan simples y que realmente se complican muchisimo porque también puede darse el caso de que a la mitad de una grabación se corte la alimentación o se resetee el pic.  Si hablamos de una aplicación que corra constantemente entonces estas cosas sí pueden pasar.

Lo ultimo no nos salva de que al reiniciar el software, tener que leer la memoria y verificar que los datos allí incluidos sean correctos, para ello tal vez debamos agregar algun checksum por ejemplo, dentro de la misma memoria que valide los datos. 

Por ello soy de insistir en que si bien por software hay cosas para hacer y tener en cuenta, es por hardware donde reamlente debemos hacer que la cosa funcione y sea confiable.

En lo particular por software me dedico a interpretar y/o determinar las causas de un reset, más que volver a donde estaba.  No siempre es posible y en muchisimos casos es peligroso y hasta puede daniar algo. 



Da la impresión de que la EEPROM es algo inestable y que se borra con mucha facilidad. Nada más lejos de la realidad, lo raro es que los adatos estén corruptos y muy dificilmente se borran por ruido. La prueba la tenemos en los propios porgramas almacenados el los pic que duran años y años perfectamente. Yo me inclino a pensar que los problemas con la memoria son debidos a una mala programación. De todas formas con un buen checksum no deberiamos tener más problemas y si los datos guardados no coinciden con los escrito habria que revisar las subrutinas que realizan estas operaciones.

Un saludo

Las eeprom son mas o mucho más inestables que las FLASH. Si tus programas no hacen uso de la eeprom, allí tienes la respuesta.

Si tus programas sí hacen uso de la eeprom, entonces estamos frente a un hardware bien diseñado para el entorno en el que trabaja.  A veces un hardware bien diseñado para un entorno no lo es bueno para otro que contenga más ruido magnético o un ambiente eléctrico más ruidoso en general.



Aunque ahora, siempre que necesito EEPROM, uso una Externa. La interna no me da buena espina.

Solo a modo de anécdota puedo decir que ambas eeprom son vulnerables a los mismos problemas.  En una oportunidad me pasaba que una aplicación con eeprom externa andaba mal y le echaban la culpa al pic. Bien, como estas cosas son dificiles de demostrar sin datos fehacientes (sino termina siendo la palabra de uno contra el otro por más argumentos que uno esgrima) , me vi forzado a hacer un código dentro de la propia aplicación que verificaba la eeprom del pic y la eeprom externa, a cada rato.  Pasaba que cuando frenaba un motor, se metía un pulso electrico que afectaba a la eeprom externa y no al pic (el cual tenía su hardware más bien diseñado).  Este es un caso en que el problema era la eeprom externa! y le echaban la culpa al pobre PIC.  Solucion? -> les dije que filtren mejor la alimentación de la memoria y santa solución!.


En efecto, en todos los PIC's en que he probado esto hasta ahora se dá ese efecto, tras un Reset, MCLR a masa, la RAM queda intacta con todos los valores que tenía anteriormente (16F628, 16F777, 16F876, 18F2550 y 18F4550)

Creo que se puede agregar que esto funciona y va de la mano de una buena deteccion de la causa del reset :)  Sino, seria altamente peligroso.
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: MGLSOFT en 16 de Septiembre de 2007, 17:09:30
Hola Maunix!!
Creo que estas siendo el unico ganador del campeonato de POSTs, aunque creo que estas corriendo solo!! :mrgreen: :mrgreen:
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: maunix en 16 de Septiembre de 2007, 17:10:42
Mis pequeños trucos básicos para paliar los efectos del ruido:

Hard:
  La fuente de alimentación:
    AC: En la entrada un varistor siempre y su filtro con transformador y condensadores junto con su conexión a tierra.
    DC: Capacidades variadas, 10nF, 100 a 330nF y Electrolítico

Me parece muy útil y valoro el que hayas mencionado, solamente puedo agregar que no me gusta ser amigo de las reglas que nunca se cambien , porque? porque creo que aprendo constantemente.

Hay casos, en que si usamos como fuente de alimentación una fuente switching, poner cualquier capacitancia en paralelo puede hacer oscilar a la fuente.  La fuente de por sí es un sistema de control a lazo cerrado, y si le agregamos capacitores y que hagan entrar en resonancia al lazo se alimentación, podríamos hacerla oscilar lo cual podría hasta dañar el hardware.

A lo que voy , y no quiero corregir a nadie ni mucho menos, solamente opinar desde mi experiencia y es que en estas cuestiones no existen soluciones mágicas que siempre resuelvan el problema, depende de la alimentación, del entorno, de la complejidad , del consumo.

Saludos
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: maunix en 16 de Septiembre de 2007, 17:13:32
Hola Maunix!!
Creo que estas siendo el unico ganador del campeonato de POSTs, aunque creo que estas corriendo solo!! :mrgreen: :mrgreen:

What? si te cuento que se me corta la luz cada 15 minutos me creerias?

PD: no me interesa el número de posts, solamente poner juntos los mensajes que correspondan a un mismo tema, nada más. Alguna vez propuse que se elimine el número de posts ya que genera una competencia innecesaria en la gente que compita por eso (y aclaro que no soy precisamente de los que lo hacen). 

Hay gente que posteó 200 veces y con una claridad inusitada expuso temas impresionantes.  El tener muchos años, como el tener muchos posts, no indican nada.  Hay una frase que contiene mucha sabiduría que dice que una cosa es tener experiencia y otra antigüedad.

saludos

PD: agrupé mis mensajes contiguios en uno solo. 
PD2: EPEC y la re@#$!#$! jajaja.  :mrgreen: :mrgreen:

Nota sobre PD2: EPEC o Empresa Provincial de Energía de Córdoba.
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: dogflu66 en 16 de Septiembre de 2007, 18:58:17

Hay circuitos comerciales que dividen la memoria E2Prom en dos partes, una es la pagina de trabajo y la
otra es la imagen de la primera. Siempre se trabaja con la pagina principal, se verifica lo que se escribe,
se dividen las paginas en filas y columnas y se genera un checsun por línea y luego uno general que
es la suma de todos los parciales y si todo esta correcto se actualiza la imagen, este sistema funciona
muy bien cuando se tiene la configuración del programa en E2Prom.
En los arranques siempre se hace un verificado de los checsum de la 1ª pagina.

Puedes dar ejemplos de como aplicar esto??
Es interesante el tema!! :mrgreen:

Por desgracia no tengo nada que pueda publicar sobre este tema...
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: Nocturno en 17 de Septiembre de 2007, 01:45:11
Joe, Maunix, tu teclado sí que está bien diseñado contra el ruido...  :mrgreen:
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: aitopes en 17 de Septiembre de 2007, 07:59:36
PD2: EPEC y la re@#$!#$! jajaja.  :mrgreen: :mrgreen:
Nota sobre PD2: EPEC o Empresa Provincial de Energía de Córdoba.

Te compadezco. La semana pasada instalaron un generador en mi ciudad (para evitar los cortes en el verano), y como va a sobrar energia, la distribuyen a otra ciudad. Tengo la suerte de vivir por donde pasa la nueva linea que debieron "reforzar", asi que me he pasado toda una semana son energia de 8 a 13.

Realmente, no nos damos cuenta de lo dependientes que somo de la electricidad!!! No soldador, no PDF, no TV, no DVD, no foro, no programar.....y no ruido electrico :)

Menos mal que mi soft de diseño de circuitos corre sobre un cuaderno cuadriculado, si no no se que hubiese hecho :) :) :) :)

Saludos!
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: maunix en 17 de Septiembre de 2007, 08:30:16
Joe, Maunix, tu teclado sí que está bien diseñado contra el ruido...  :mrgreen:

jiji. Ultimamente ando con muchas cosas y la verdad "se extraña" no tener tiempo para el foro y solo quise aportar un granito de arena al respecto de mi experiencia, esperando sean bien tomados como puntos de vista y no como juicios categóricos de mi parte.  :) :)


PD2: EPEC y la re@#$!#$! jajaja.  :mrgreen: :mrgreen:
Nota sobre PD2: EPEC o Empresa Provincial de Energía de Córdoba.

Te compadezco. La semana pasada instalaron un generador en mi ciudad (para evitar los cortes en el verano), y como va a sobrar energia, la distribuyen a otra ciudad. Tengo la suerte de vivir por donde pasa la nueva linea que debieron "reforzar", asi que me he pasado toda una semana son energia de 8 a 13.

Realmente, no nos damos cuenta de lo dependientes que somo de la electricidad!!! No soldador, no PDF, no TV, no DVD, no foro, no programar.....y no ruido electrico :)

Jaja, tal cual.  Mi señora no había terminado de ver una película que teníamos en DVD y para ver los últimos 45 minutos estuvo casi 2 horas!!  Ni te puedo explicar la cantidad de |@#~|@#~|@ que decía jajaja.

También se me quemó una lámpara de bajo consumo, de tantos picos de tensión se terminó dañando (y estas si que no son baratas que digamos...  :5] :5] :5] :5] )

Menos mal que mi soft de diseño de circuitos corre sobre un cuaderno cuadriculado, si no no se que hubiese hecho :) :) :) :)

Jiji, ese si que es inmune al ruido eléctrico aunque puede no serlo al ruido de la humedad o de que Santino lo agarre para jugar.  :D :D

Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: aitopes en 17 de Septiembre de 2007, 08:36:55
Citar
Jiji, ese si que es inmune al ruido eléctrico aunque puede no serlo al ruido de la humedad o de que Santino lo agarre para jugar.

No habia pensado en eso!!!!!!!!! Ya me voy a la fotocopiadora a hacer un "backup"!! :) :) :)
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: maunix en 17 de Septiembre de 2007, 13:00:47
Citar
Jiji, ese si que es inmune al ruido eléctrico aunque puede no serlo al ruido de la humedad o de que Santino lo agarre para jugar.

No habia pensado en eso!!!!!!!!! Ya me voy a la fotocopiadora a hacer un "backup"!! :) :) :)

Jiji, mi tía aún se acuerda de su carpeta de trabajos prácticos para una matería que tuvo que rendir en la facultad, la cual tenía 'hermosos decorados' hechos por su sobrino (leáse yo) en varios colores a la edad 3 o 4 años  :D :D
El profesor le dijo ¿señorita ud tiene hijos? ... mi tía respondió algo así como "no, ¿por?" , Profesor: "porque supongo que ud no ha hecho estos hermosos gráficos a color"

Morajela , nunca dejes algo importante de papel cerca de los chicos  :mrgreen: :mrgreen:
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: PalitroqueZ en 25 de Octubre de 2007, 18:18:17
respecto a la mención de #zero_ram e inicialización de variables.

una anecdota: resulta que en un programa necesitaba que mis variables estuviesen en cero al inicio de la ejecución, me dió bastante trabajo pensar donde estaba el problema, porque el programa daba resultados extraños y a la final se me ocurrió "limpiar" dichos registros y se arregló todo. Ahora tengo pendiente inicializar las variables a cero al inicio.

por cierto en C se usa el calificador static

un ejemplo en asm de una variable global con/sin static (listado generado por el ccs):

Código: C
  1. .................... static int pepe;
  2. 0010:  CLRF   20
  3. .................... int papa;
  4. .................... int luis;
  5. .................... static int jose;
  6. 0011:  CLRF   23
  7.  
  8.  

Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: RedPic en 26 de Octubre de 2007, 02:33:51
Veo, Pedro, que el static del CCS fuerza el Clear File de la posición de memoria. Muy interesante. Yo ya me he acostumbrado a cualificar todas las variables Globales como static.
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: RedPic en 26 de Octubre de 2007, 04:12:22
Ahhhh ... ¡qué bien me ha venido tu comentario sobre los static, Pedro!

Tengo varios bufferes de caracteres, algunos hasta de 128 bytes, que inicializaba con su correspondiente bucle for al comenzar main().

Pero todos estaban declarados como static, por lo que además de mi bucle y antes de él tenía todo una retahíla de ...

Código: ASM
  1. 60EE:  CLRF   1F
  2. 60F0:  CLRF   20
  3. 60F2:  CLRF   21
  4. 60F4:  CLRF   22
  5. 60F6:  CLRF   23
  6. 60F8:  CLRF   24
  7. 60FA:  CLRF   25
  8. 60FC:  CLRF   26
  9. 60FE:  CLRF   27
  10. 6100:  CLRF   28
  11. 6102:  CLRF   29
  12. 6104:  CLRF   2A
  13. 6106:  CLRF   2B
  14. 6108:  CLRF   2C
  15. 610A:  CLRF   2D
  16. 610C:  CLRF   2E
  17. 610E:  CLRF   2F
  18. 6110:  CLRF   30
  19. 6112:  CLRF   31
  20. 6114:  CLRF   32
  21. 6116:  CLRF   33
  22. 6118:  CLRF   34
  23. 611A:  CLRF   35
  24. 611C:  CLRF   36
  25. 611E:  CLRF   37
  26. 6120:  CLRF   38
  27. 6122:  CLRF   39
  28. 6124:  CLRF   3A
  29. 6126:  CLRF   3B
  30. 6128:  CLRF   3C
  31. 612A:  CLRF   3D
  32. 612C:  CLRF   3E
  33. 612E:  CLRF   3F
  34. 6130:  CLRF   40
  35. 6132:  CLRF   41
  36. 6134:  CLRF   42
  37. 6136:  CLRF   43
  38. 6138:  CLRF   44
  39. 613A:  CLRF   45
  40. 613C:  CLRF   46
  41. 613E:  CLRF   47
  42. ...
  43.  


Les he quitado el static y dejado mis bucles de inicialización, que realmente es un único bucle en una única función a la que le paso como parámetros el puntero al primer elemento del buffer y el número de bytes que aloja.

El resultado ha sido espectacular, mi programa ha mermado, se ha acortado, en 1144 bytes de ROM.  :mrgreen: :mrgreen: :mrgreen:

Me encanta aprender cosas nuevas (que si además me sirven pues mejor).

Muchas gracias.
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: Nocturno en 26 de Octubre de 2007, 04:31:46
¿Quién sabe?, lo mismo eso con el nivel 11 de optimización te lo hace el compilador automáticamente ;-)
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: RedPic en 26 de Octubre de 2007, 05:14:18
No tienes tú guasa, ni ná. Ja, ja, ja  :D :D :D
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: visenri en 28 de Octubre de 2007, 13:19:22
Hola, nocturno y cia, este es mi primer mensaje en este foro y he pensado que podía aportar algo a este post.

Alimentación:

Sobre el tema de ruido en la alimentación, no hay demasiado misterio, siempre filtro la alimentación con condensadores de 100n cerca de cada integrado digital y hasta el momento 0 problemas.

Asimismo siempre es aconsejable al hace el rutado de la placa separar la pistas por las que circule potencia de las que sean para la lógica, cada una por su lado, así evitamos que haya caidas de tensión que afecten a la lógica.

También es importante evitar un rutado largo en la masa que va a los condensadores del cristal del pic (por experiencia se que puede provocar efectos indeseados en el oscilador).

En los accionamientos de relés y motores colocar siempre los correspondientes diodos, y si son de alterna los varistores adecuados o un par de diodos zéner en serie y al revés (una vez por culpa de un abrepuertas de alterna mal filtrado el PC saltaba a donde le daba la gana, fue poner el varistor y desaparecer el problema, los picos de tensión al desconectar radiaban al espacio tal interferencia que era capaz de actúar sobre el PIC).

Entradas y salidas:

Yo no uso filtrado casi nunca ni en salidas ni en entradas digitales, lo que hago es siempre (siempre que esa entrada dependa de un pulsador, o una señal externa al circuito) filtrar por software mediante contadores el estado de las entradas digitales, de forma que sea inmune a rebotes rápidos.

En las entradas analógicas uso un promediado emulando una red RC:
 Valor = Valor + (Valor_act - Valor)/K
con algún truco matemático para hacerlo rápido con enteros y no perder resolución.
El valor valor de la frecuencia de filtrado depende de la frecuencia con la que se llame a la función y de la constante K.

Puede que si sea necesario filtrar la entrada analógica si pueden presentarse problemas de aliasing debido a que la frecuencia de variacion de la entrada supere a la mitad que la de muestreo.

Eeprom:

Sobre lo de la Eeprom nunca he tenido problemas (aunque tampoco he usado mucho), pero los problemas que ha tenido la gente normalmente se deben a usar PIC16F84 sin circuito de reset, y es que estos pic no tienen BOD, es decir si  baja un poco la tensión y vuelve a subir ni se enteran, pero puede provocar efectos inesperados en el chip, yo usaba un circuito específico para el reset conectado a la patilla MCLR, pero ahora uso el PIC16F628A en donde usaba el PIC16F84, ya que es más barato y lleva muchas más cosas, entre ellas el BOD.

Cuelgues:

Sobre lo de que el programa se quede colgado, se que debería usar más el WDT, pero no suelo tener necesidad porque siempre hago los programas con un programa ciclico que ejecuta una máquina de estados en vez de esperar a que terminen eventos fijos para continuar, es menos legible pero mucho más potente, seguro y eficiente.

Por ejemplo, casi nunca uso transmisión y recepcion serie sin interrupciones, uso un buffer que lleno en el programa cíclico cuando quiero enviar algo (cosa que finaliza instantáneamente) y que se envia al ritmo serie con la interrupción.
Igual para la recepción, los datos se llenan en otro buffer en la interrupción serie y en el programa cíclico se comprueba si ha llegado un dato nuevo, cuando se tiene una trama completa o se dispara un timeout (por pérdida de datos), se ejecutan las acciones adecuadas.

Lo que quiero decir es que el programa cíclico nunca para, de forma que no hay cuelgue nunca, normalmente el programa cíclico se ejecuta en un tiempo relativamente corto, dependiendo de lo complejo de la aplicación, desde unos pocos us hasta varios ms.

Inicialización de variables:
Uso el compilador de C de Hi-tech y creo que por defecto inicializa toda la ram a 0.

Aún así suelo asegurarme de inicializar todo al inicio, a mi cuando me enseñarón C me dijeron que no puedes dar por sentado el valor de nada si no se lo asignas expresamente. ¿Es verdad que el ansi C obliga a inicializar las variables a 0 como ha dicho alguien?, yo diría que no a menos que se indique en la declaración:

Int Ic = 0;

Vaya tocho para ser el primer mensaje  :D.
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: RedPic en 28 de Octubre de 2007, 14:51:19
Buen tocho y muy buenas las ideas que contiene.

Sé bienvenido a este nuestro, tu, Foro, amigo visenri. Que seas feliz en él y nosotros contigo.

Con respecto a tu post comentarte que yo tampoco pongo nunca el WD hasta estar absolutamente seguro, en lo posible que todo es relativo, así que tras algunos meses con el firmware funcionando correctamente activo un WD relativamente largo, de un par de segundos y pongo un único restart_wachtimer() en el bucle main(). A modo de "para por si acaso"  :mrgreen:
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: jfh900 en 28 de Octubre de 2007, 14:57:37
Hola visenri, antes de nada bienvenido al foro. Gracias por tu aporte, es muy interesante y se viene a sumar a las experiencias de otros foreros. Poco a poco se van conformando las puntos esenciales para eliminar el ruido. Respecto de tu post que es muy completo, solo comentarte dos cosas que creo son de interés: la primera es que las entradas digitales se deben de filtrar con un filtro paso bajo, sobre todo si se esta en un ambiente ruidoso y la longitud de los cables del actuador es grande. La segunda es que los programas muchas veces se pueden bloquear por ruidos entre otras causas y originar un bucle en le que se queden cerrados, independientemente a como lo hayas programado, es por ello que el wachdog es conveniente ponerlo y así estar a cubierto de estas posibles contingencias.

Un saludo y de nuevo bienvenido.

PD.: Se me ha adelantado el amigo Diego.
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: maunix en 14 de Noviembre de 2007, 09:10:57
Visenri bienvenido al foro, siempre es bueno que la gente aporte conocimiento y aquí no se compite por mucho o por poco, sino por contribuir al conocimiento global del grupo.


En cuanto a lo estrictamente técnico, yo no dejaría tan de lado lo de la alimentación, es más te diría que 'depende' del tipo de aplicación que construyas.  Si hablas de un prototipo de laboratorio es una cosa, pero si hablamos de una placa que irá colocada en un tablero eléctrico junto a contactores, relés de estado sólido, etc, entonces los ruidos eléctricos y magnéticos son importantes y no se van con un simple capacitor.

El filtrado de entradas por software funciona cuando el ruido es eléctrico de cierto nivel pero un opto aisla no solo ruido eléctrico (de hecho el fotodiodo actúa como un pasabajo) sino que nos da un margen de aislación de unos cuantas decenas/centenas/millares de voltios.

Para una entrada analógica la sensibilidad es aún mayor y los cuidados también mayores porque no solo que hay que filtrar sino que hay que tener velocidad de respuesta.

En cuanto a la eeprom, las de los pics no son mejores que cualquier otra eeprom y por ende sufren de los mismos problemas.  Tal vez las has usado poco.  A mi los problemas me aparecieron con un cliente con un board no diseñado por mí, el ruido provenía de las conexiones, al encender el sistema el sobrepico de la fuente borraba las eeprom.  Por ello nuevamente filtrar la alimentación y MCLR son muy buena idea.

Lo del WDT coincido en que no hay que ser un maniático en su uso, sobre todo en el laboratorio pero sí hay que usarlo si se quiere mandar un equipo 'fuera'.  El software es determinístico (podemos prever su funcionamiento al 100%), el harware no y por ende el WDT a mi modo de verlo debiera estar siempre habilitado al mandar un equipo para alguna parte.

Nuevamente bienvenido y espero tengas una larga vida y aportes en el foro, verás que acá encontrarás solo amigos y no enemigos.  :) :)
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: Enigma en 28 de Diciembre de 2007, 04:35:05
Hola que tal, estuve revisando esto porque la verdad tengo un problema igualito a este... Hice está rutina, pues la encontre en el CCS y bueno el WDT no se me desborda y la verdad no se porque, ya he leido y he hecho de todo... Ya no se que hacer... otra cosa es que cada vez que enciendo el circuito pues me aparece el reset por causa del PUT siempre, y no se quita!!! que creen que sea esto...??? AYUDA!!! POR FAVOR, ya me estoy arrancando los cabellos por causa de esto... aquí está el codigo si lo quieren revisar... Por cierto estoy trabajando en C del CCS con el 18F4550...

#include <18f4550.h>
#fuses XT,WDT,NOPROTECT,NOCPD,LVP,VREGEN,NOPBADEN,INTRC_IO,MCLR,BROWNOUT_SW,BORV20
#use fast_io (A)
#use fast_io (B)
#use fast_io (C)
#use fast_io (D)
#use delay(clock=4000000,restart_wdt)
#byte RCON=0xFD0
#bit SBOREN=RCON.6
#bit IPEN=RCON.7
#bit POR=RCON.1
#bit TO=RCON.3                                      // Bit de la bandera del Perro Guardian
#bit BOR=RCON.0                                     // Bit de la bandera del Brown Out Reset

void main(void)
{
SBOREN=1;
IPEN=0;
set_tris_b (0x0F);                                  // Configura puerto b como entrada y salida
         set_tris_d (0x00);                         // Configura puerto d como salida
         set_tris_a (0xF0);                         // Configura los pines RA6 - RA4 como entradas y RA3 - RA0 como salidas
         set_tris_c (0x00);                         // Configura puerto c como salida
         output_c (0x00);                           // Limpio el puerto C
         output_b (0x00);                           // Limpio el puerto B
         output_d (0x00);                           // Limpio el puerto d
         output_a (0x00);                           // Limpio el puerto A

         output_c(0x01);

switch(restart_cause())
   {
      case WDT_TIMEOUT:
      {
         output_d(0x73);
         break;
      }

      case NORMAL_POWER_UP:
      {
         output_d(0x01);
         break;
      }
      case MCLR_FROM_RUN:
       {
         output_d(0x39);
         break;
       }

      case BROWNOUT_RESTART:
       {
         output_d(0xFC);
         break;
       }
   }
   if(restart_cause()==12)
   {
       output_d(0x72);
   }
   setup_wdt(WDT_ON);
   while(TRUE)
   {
      restart_wdt();
   }

}

Atte: Enigma... La llanerita de Guayana :?
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: Nocturno en 28 de Diciembre de 2007, 04:42:34
Si pones esto es materialmente imposible que desborde el perro:

   while(TRUE)
   {
      restart_wdt();
   }

Estás continuamente refrescándolo.
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: RedPic en 28 de Diciembre de 2007, 08:33:06
Como dijo Jack el Destripador: ¡Vayamos por partes¡!

Solo con los fuses tenemos para escribir una novela.

#fuses XT, WDT, NOPROTECT, NOCPD, LVP, VREGEN, NOPBADEN, INTRC_IO, MCLR, BROWNOUT_SW, BORV20

LVP es mas peligroso que un tigre en tu dormitorio. En cuanto detecte 5V entra en modo programación. Usa NOLVP salvo que estés programando a bajo voltaje.

WDT sin Postscaler hace que el Reset por desbordamiento sea realmente rápido, quita WDT y empieza por WDT512 o WDT1024, después puedes ir disminuyendo el postscaler hasta que veas donde ocupas mas tiempo. Yo acostumbro a ponerlo muuuuy largo el tiempo del guardián y después lo ajusto a tiempo máximo de mi rutina mas larga (sin reestablecer el contador del Watch Dog).

Tienes también los fuses BROWNOUT_SW y BORV20. El primero anula al segundo y sirve para que tu mismo programa realice on-line el control del BOR.  Utiliza solo una combinación del estilo BROWNOUT,BORV43

INTRC_IO y XT son mutuamente excluyentes. O XT para un Cristal Externo menor o igual a 4 Mhz ó INTRC_IO para el oscilador interno pero no los dos al mismo tiempo.

VREGEN Activa el regulador de voltaje para el USB, si no estas usando el USB no te hace falta (Sobre todo si no tiene puesto el condensador en VUSB, patilla 18 del 18F4550, que le hace falta para realizar dicha regulación)

Conclusión: Pon unos fuses del estilo que te propongo mas abajo y prueba ...

#fuses XT, WDT512, NOPROTECT, NOCPD, NOLVP, NOPBADEN, MCLR, BROWNOUT, BORV43, NODEBUG

Y sobre todo Datasheet, mucho Datasheet.  :mrgreen:



Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: MGLSOFT en 28 de Diciembre de 2007, 11:19:15
AllDatasheet !!! :D :D :D
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: Enigma en 28 de Diciembre de 2007, 12:34:20
Hola muchachos, Gracias, muchas gracias por su gentil colaboración.... Lo del perro Guardian me ha funcionado muy bien.... Y no crean que no he leido el datasheet, si lo he leido, pero probablemnte he tenido una mala interpretación del mismo... he aquí mis explicaciones de algunas de mis acciones:

Cita de: Nocturno
Si pones esto es materialmente imposible que desborde el perro:

   while(TRUE)
   {
      restart_wdt();
   }

Estás continuamente refrescándolo.

Aqí si me hice un nudo... lo quite y me funciono el perro a los 2:12seg, es el tiempo al que lo queria muy bien... pero, el restart_WDT(), lo coloque porque en la ayuda del CCS, me dice que hay que restaurarlo...miren

"Restarts the watchdog timer.  If the watchdog timer is enabled, this must be called periodically to prevent the processor from resetting. 
The watchdog timer is used to cause a hardware reset if the software appears to be stuck.
The timer must be enabled, the timeout time set and software must periodically restart the timer."...

Se me contradicen las ideas...  :?


Cita de: REDPIC
WDT sin Postscaler hace que el Reset por desbordamiento sea realmente rápido, quita WDT y empieza por WDT512 o WDT1024, después puedes ir disminuyendo el postscaler hasta que veas donde ocupas mas tiempo. Yo acostumbro a ponerlo muuuuy largo el tiempo del guardián y después lo ajusto a tiempo máximo de mi rutina mas larga (sin reestablecer el contador del Watch Dog).

Jejeje, el tiempo en que se me desborda aquí solito es el perfecto, 2min con 12seg.... Pero gracias a tu valioso a porte ya se me desborda fino!! jejeje :-)

Cita de: REDPIC
Tienes también los fuses BROWNOUT_SW y BORV20. El primero anula al segundo y sirve para que tu mismo programa realice on-line el control del BOR.  Utiliza solo una combinación del estilo BROWNOUT,BORV43

jejeje aquí fue por que me confundi de combinación.... jejeje ahorita es que me vengo a dar cuenta! rayos! Gracias por la observación amigo!!!

Ahora el set de preguntas.... (es que soy nueva, y pues bueno el datasheet ayuda, pero hay muchas cosas que me dejan así :shock:)

1.) El LVP: Umm.... Bueno, este, estuve buscando en internet lo que significa esto... y sólo me dice que sirve para programar varios pics al mismo tiempo.... Hay un concepto mejor que este... :(... Que es Modo programación, y disculpen mi ignorancia.... :(

2.) Porque el circuito cuando lo enciendo me indica siempre un reset por POWER UP Timer....???

3.) BROWNOUT_RESTART: esto es el BOR??

4.) ¿Cómo devuelvo una respuesta de reseteo por el POR?, no hay un caso para el...? o sólo pregunto por el bit del mismo???

Hasta ahora estás son las preguntas.... jijijii
 :mrgreen:


Atte: Enigma... La llanerita de Guayana :?

Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: Nocturno en 28 de Diciembre de 2007, 13:21:39
Lo de restaurar el wdt dependerá de lo que tú quieras. Si quieres restaurarlo, porque no quieres provocar un reset en tu micro, tendrás que poner restart_wdt.
Si lo que quieres es precisamente provocar un reset, no lo pongas y verás como el perro le da un meneo a tu micro y lo hace arrancar de nuevo.
Te dije que lo quitaras porque precísamente estabas buscando que el perro reseteara a tu micro. Lo habitual es dejarlo puesto en el bucle principal de tu programa.

El LVP, como te dice Diego, permite meter el micro en modo programación de bajo voltaje. Eso permite utilizar un programador que no levante 13V para reprogramar al micro.

Si no quieres que te marque el PowerUp Timer al arrancar, desactiva el fuse PUT con NOPUT.

El Brownout provoca un reset del micro cuando la tensión cae por debajo de determinado nivel, evitando que el micro se comporte como si hubiera bebido demasiado.

No entiendo tu pregunta acerca de "Devolver una respuesta por POR"
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: Cryn en 28 de Diciembre de 2007, 13:27:20
aca algo mas sobre lo mismo, jeje :mrgreen:, esque me ganaron :D

1) el LVP significa Low Voltage Programing, lo que quiere decir que si tu programador trabaja con bajo voltaje para la programacion, esto en VPP si no me equivoco que normalmente se programa con 12V, en bajo voltaje programa a 5V. osea depende de tu programador, la mayoria son normalitos, asi que debes usar NOLVP en el fuse, o que programador usas, para grabar el programa al micro??

2) si no me equivoco, el PUT hace que el micro se resetee cuando recien adqueira el nivel de voltaje necesario (transcurrido un pequeño tiempo), tambien es un Fuse, que va PUT ó NOPUT

3) Si

4) esta no me la se :(, o talvez no la entendi muy bien :mrgreen:

haber si ahora va mejor el asunto, y si me equivoqeu en algo que me corrijan los maestros :mrgreen:
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: Enigma en 28 de Diciembre de 2007, 14:00:51
Hola Muchachos, bueno primero que nada, Cryn no es más de lo mismo, todo aporte es bueno... al menos para mi :-)...

Cita de: NOCTURNO
Si lo que quieres es precisamente provocar un reset, no lo pongas y verás como el perro le da un meneo a tu micro y lo hace arrancar de nuevo.

Aja, aquí, se supone que despues de un reset, el micro deberia empezar a hacer todo de nuevo cierto.... por teoria y por lo que me dices.... Pues bueno, el programa hace todo lo contrario, apaga todo el circuito y lo deja estático... :( Por ejemplo cuando se ddesborda el perro, o.k, me aparece la P (el valor que yo queria mandar cuando sucediese este evento), pero luego cuando hago un reset por MCLR, pues me sigue apareciendo la P del WDT y no la C de Clear que le digo que aparezca cuando se da este evento...

Cita de: NOCTURNO
Si no quieres que te marque el PowerUp Timer al arrancar, desactiva el fuse PUT con NOPUT.

Pero es que precisamente quiero que me muestre está causa de reset, pero cuando suceda... No todo el tiempo.... O es que el PUT está todo el tiempo...? :?

Cita de: ENIGMA
4.) ¿Cómo devuelvo una respuesta de reseteo por el POR?, no hay un caso para el...? o sólo pregunto por el bit del mismo???

Jejeje a lo mejor no me explique bien :mrgreen:... Lo que quiero decir con esto es que como hago para que el micro detecte está causa del reset... Así como hay
case WDT_TIMEOUT:
case MCLR_FROM_RUN:
case BROWNOUT_RESTART:.... No hay un Case para el POR(Power ON Reset)

Cita de: CRYN
la mayoria son normalitos, asi que debes usar NOLVP en el fuse, o que programador usas, para grabar el programa al micro??

Bueno el programa quemador que uso es winpic800 y el quemador que uso quema el pic a 5V....

Atte: Enigma... La llanerita de Guayana :(

Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: jeremylf en 06 de Enero de 2008, 23:08:25
Cita de: ENIGMA
Jejeje a lo mejor no me explique bien :mrgreen:... Lo que quiero decir con esto es que como hago para que el micro detecte está causa del reset... Así como hay
case WDT_TIMEOUT:
case MCLR_FROM_RUN:
case BROWNOUT_RESTART:.... No hay un Case para el POR(Power ON Reset)
Creo q es el NORMAL_POWER_UP, no estoy seguro. Depende tambien del pic; mira en su archivo .h (Almenos el pic12f683 lo tiene).


salu2 8)
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: blackcat en 15 de Marzo de 2008, 04:59:47
Bueno  ... quizá mi pregunta este más desviada del tema ... pues todos hablan del WDT y el BOR ... mi inquietud es la siguiente ... resulta que en un proyecto de la universidad tuve que usar el archiconocido sensor de distancias SRF08 ... utilicé este sensor para un experimento de control en donde el profesor me dejó como tarea implementar un Ball&Beam ... este es el famoso experimento de inestabilidad de una barra y una bola en donde la idea del control es centrar la bola en la barra inclinando de un lado al otro la barra, el centro de esta barra esta unido al eje de un motor ....

Pues bien ... este sensor SRF08 fue mi pesadilla pues medía bien la posición de la bola, sin embargo, era demasiado ruidoso. Si la bola estaba centrada en 50cm las mediciones del sensor eran: 50, 51, 49, 47, 52 .... y de vez en cuando una medición incorrecta y absurda como 255, en sí, este es un tipo de ruido digital!!! .. Aunque la bola llegaba a centrarse este ruido hacia que la barra vibrara mucho. Mi solución de principiante fue usar controles en donde la acción derivativa no estuviera directamente asociada al sensor, y tambien atenué con algunos filtros IIR.

Sin embargo, mi profesor me recomendó usar un tipo de filtro llamado filtro Kalman o de Kalman .. no sé ... a su explicación me dijo que este filtro es "inteligente" ... uno le da condiciones iniciales y el filtro "aprende" el comportamiento de la señal haciendo que el ruido se atenúe considerablemente ...

Nunca lo implementé pues ya no me daba la cabeza pa' tanta cosa ...  pero me quedó la inquietud ... si alguien ha hecho algo similar o sabe de eso me gustaría oir la experiencia ...

Saludos!




Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: RedPic en 15 de Marzo de 2008, 06:52:42
Me encanta tu pregunta, amigo Blackcat, y no porque tenga una respuesta, que no la tengo, sino porque para gente como yo , sin preparación académica, preguntas como la tuya nos hacen darnos cuenta de lo poco que sabemos y del montón de cosas que podríamos y deberíamos aprender.

Hablas de filtros IIR que tampoco conozco y de otros de denominación incierta que además son "inteligentes". Yo, en mi desconocimiento no he pasado de promediar medidas para quedarme con valores medios ... no se siquiera como se llamará esto que hago ...

Por eso me uno a la pregunta del amigo Blackcat y ruego a los amigos "estudiados" que hagan el favor de iluminarnos con su sapiencia y buen hacer.  :mrgreen:
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: MGLSOFT en 15 de Marzo de 2008, 10:01:00
Bueno  ... quizá mi pregunta este más desviada del tema ... pues todos hablan del WDT y el BOR ... mi inquietud es la siguiente ... resulta que en un proyecto de la universidad tuve que usar el archiconocido sensor de distancias SRF08 ... utilicé este sensor para un experimento de control en donde el profesor me dejó como tarea implementar un Ball&Beam ... este es el famoso experimento de inestabilidad de una barra y una bola en donde la idea del control es centrar la bola en la barra inclinando de un lado al otro la barra, el centro de esta barra esta unido al eje de un motor ....

Pues bien ... este sensor SRF08 fue mi pesadilla pues medía bien la posición de la bola, sin embargo, era demasiado ruidoso. Si la bola estaba centrada en 50cm las mediciones del sensor eran: 50, 51, 49, 47, 52 .... y de vez en cuando una medición incorrecta y absurda como 255, en sí, este es un tipo de ruido digital!!! .. Aunque la bola llegaba a centrarse este ruido hacia que la barra vibrara mucho. Mi solución de principiante fue usar controles en donde la acción derivativa no estuviera directamente asociada al sensor, y tambien atenué con algunos filtros IIR.

Sin embargo, mi profesor me recomendó usar un tipo de filtro llamado filtro Kalman o de Kalman .. no sé ... a su explicación me dijo que este filtro es "inteligente" ... uno le da condiciones iniciales y el filtro "aprende" el comportamiento de la señal haciendo que el ruido se atenúe considerablemente ...

Nunca lo implementé pues ya no me daba la cabeza pa' tanta cosa ...  pero me quedó la inquietud ... si alguien ha hecho algo similar o sabe de eso me gustaría oir la experiencia ...

Saludos!





Yo tambien como Diego, pertenezco a la gama de los "No Ilustrados", mis conocimientos son escasos respecto a la electronica y al control.
Pero si he leido un ensayo de un participante de AADECA (Asociacion Argentina De Control Automatico) donde habla de la utilizacion del filtro de Kalman o Kaltman (no se como se escribe) para implementarlo en el control automatico de calderas.
Veo si te lo ubico a ver si te sirve... :mrgreen:
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: MGLSOFT en 15 de Marzo de 2008, 10:07:38
Bueno, mezcle las cosas.
El cuadernillo practico se llama:

Citar
C.P. Nº 14 El Predictor De Smith y El Filtro De Kalman: Ejemplos De Predicción Y Estimación
Serie 1 - Instrumentación en Separadores de Ensayo

Si te interesa lo escaneo y lo pongo para leer... :mrgreen:
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: RedPic en 15 de Marzo de 2008, 10:08:59
Filtro de Kalman (http://es.wikipedia.org/wiki/Filtro_de_Kalman) para estimar el estado oculto (no medible) de un sistema dinámico lineal ...

Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: Modulay en 15 de Marzo de 2008, 10:48:58
Parece un método de esos unipaso.
Matemática de la fea,aunque si no reuerdo mal,teniendo todos los datos,el cálculo se efectuaba en un solo paso
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: Azicuetano en 15 de Marzo de 2008, 11:04:08
Es la primera vez que escucho hablar del Sr. Kalman.

En un proyecto que hice el año pasado obtenía una respuesta muy similar a la tuya. El pic detectaba lo siguente:

123, 123, 124, 122, 124, 123, 123, ... ..., 122, 255, 123, 122, ... ... 122, 123, 123, ...

Al final (el tiempo premiaba y lo tenía que entregar con urgencia) utlicé mis cutres artimañas para salvar al sistema.

Hice una función que se encargaba de ver la diferencia entre medidas (con cierto margen de seguridad) y cuando detectaba algún valor fuera de lo común, símplemente hacía caso omiso del mismo.

Veré a ver que se cuenta Mr. Kalman  :D


Un saludo desde Alicante.
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: jfh900 en 15 de Marzo de 2008, 11:06:24
El filtro de Kalman es un filtro adaptativo. Compara el valor estimado con el valor real y así adapta sus constantes para predecir el próximo valor. Tiene unas funciones de predicción y otras funciones de actualización.

Yo, en mi desconocimiento no he pasado de promediar medidas para quedarme con valores medios ... no se siquiera como se llamará esto que hago ...

Es un filtro de media. Si los valores del ruido son muy grandes, se puede utilizar mejor un filtro de mediana.

Un saludo
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: Modulay en 15 de Marzo de 2008, 11:08:17
¿A ,B y C son residuos,Jesus?
¿dependen del sistema?
En la wiki no dice nada
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: Modulay en 15 de Marzo de 2008, 11:10:49
matrices...a saber que matrices son esas  :?
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: blackcat en 15 de Marzo de 2008, 22:53:21
Bueno ... la curiosidad me mato .. por ahi me encontré varias implementaciones en MATLAB  ... uno con matemática fea y otro mas simple ... el problema es que los dos filtros tiene como parámetros la varianza Q y R .... ahora no la conozco de mi señal (SRF08) ... sigo igual de perdido!

Bueno, mezcle las cosas.
El cuadernillo practico se llama:

Citar
C.P. Nº 14 El Predictor De Smith y El Filtro De Kalman: Ejemplos De Predicción Y Estimación
Serie 1 - Instrumentación en Separadores de Ensayo

Si te interesa lo escaneo y lo pongo para leer... :mrgreen:

Si no fuera mucha molestia ...

Saludos!
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: Modulay en 15 de Marzo de 2008, 23:06:31
Se supone que la covarianza es parámetro de una señal aleatoria,o sea,ruido...no le veo sentido usar una caracterización estadística para una señal que no lo sea.
Como en las fórmulas de Kalman,seguramente debas tener por ahí en la caracterización del filtro algún tipo de señal ruido y de ahí que se usen covarianzas,medianas y demás
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: enero0022 en 17 de Marzo de 2008, 23:31:16
Tras haber leído con detenimiento el contenido del hilo Hablemos del Ruido (http://www.todopic.com.ar/foros/index.php?topic=18106.0) 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 (http://www.micropic.es/index.php?option=com_mambowiki&Itemid=75).



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.

En estos dias he tenido muchos problemas de ruido en una tarjeta que elabore para una maquina en la empresa que trabajo, por el molesto ruido, por lo tanto me he dedicado a investigar sobre el tema del ruido, por lo cual me encontre con un convertidor dc,dc de 24 volts a 5 volts que reduce demasiado el nivel de ruido, cabe mencionar que la tarjeta la elabore en una tarjeta perforada que tiene mucha similitud con un protoboard creo que el problema esta ahi quisiera saber si alguien me puede orientar sobre las caracteristicas de la misma tarjeta, volviendo al tema del convertidor dc,dc les envio el numero por si alguien le interesa, cabe mencionar que el costo es un poco elevado por eso quisiera que alguien me orientara sobre el detalle de la tarjeta perforada tipo protoboard, el numero del convertidor es el siguiente: ten5-2411
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: Azicuetano en 08 de Julio de 2008, 19:35:40
MMMmmmhhhh... caviar del bueno...

Es de obligada lectura, pero, si estamos un poco perros (gandules, vagos) como mínimo leer desde la página 28 hasta la 34.

http://www.freescale.com/files/microcontrollers/doc/app_note/AN2764.pdf?fsrch=1

Con este documento se confirman muchas teorías. Si yo le hubiera hincado el diente a esto hace unos años...  :D  :D  :D cuantos dolores de cabeza me habría ahorrado  :mrgreen:

Espero que disfruteis con esto tanto como lo he hecho yo.


Un saludo desde Alicante.
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: copper en 23 de Marzo de 2009, 04:15:26
MUY muy interesante foro
Estuve leyendo todos los apartados, en estos momentos me encuentro desarrollando un proyecto en una empresa acerca de una automztizacion de control de calidad de cajas de baterias, bueno relatare un poco acerca de lo que se esta haciendo.
La parte de control fue disenada con un pic 16f877 tengo 6 entradas al pic , 4 salidas , y un lcd.
 La idea es que en la fabrica tienen un dispositivo que al colocar la caja sobre una parte metalica y la caja esta defectuosa se produce una rayo de unos 10Kv y se enciende un foco como alarma para identificar el problema.
Ahora si viene el problema la parte de control resiente los efectos cuando esa maquina esta en funcionamiento, he intenantado los capacitores de desacoplo, he pues mi circuito en caja metalica la tierra de mi circuito se ha aislado de la tierra donde se descarga el rayo, he blindado los cables que salen del exterior he puesto optoacopladores  con buffer 74ls245 para inmunizar el ruido pero no he tenido exito  :(  pero leyendo esto de eliminar ruido con software  he visto una buena alternativa espero y me puedan orientar para que mi sistema no se colapse tambien sucede que mi lcd bum se distorciona y se ponen letras que no de donde salen de antemano muchas gracias       
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: Azicuetano en 23 de Marzo de 2009, 04:34:00
Hola copper!

Yo pondría un par de condensadores de desacoplo en las patillas del PIC, uno de 220nF y otro de electrolítico de 10uF.

Otra cosa muy importante y con la que los amigos te pueden ayudar mucho es viendo el diseño de tu PCB. Si pudieras poner unas imágenes de la cara TOP y BOT sería genial.

Un saludo y no te preocupes que en unos días vencerás al ruido  :mrgreen:


Un saludo desde Alicante.
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: Gonzalo_BlackHawk en 23 de Marzo de 2009, 14:33:29
MMMmmmhhhh... caviar del bueno...

Es de obligada lectura, pero, si estamos un poco perros (gandules, vagos) como mínimo leer desde la página 28 hasta la 34.

http://www.freescale.com/files/microcontrollers/doc/app_note/AN2764.pdf?fsrch=1

Azicuetano, si te tuviera cerca te daría un beso en la frente  :mrgreen:, es una de las mejores app notes que he leido en mi vida. Cada una de las 60 paginas valen la pena. Estoy casi seguro que hay mas de estas dando vueltas por las paginas de los fabricantes. Aca dejo algunas que tambien podrian ser interesantes:

Freescale AN2321 - Designing for board level electromagnetic compatibility (http://www.freescale.com/files/microcontrollers/doc/app_note/AN2321.pdf)

Circuit Cellar: I/O for embedded controllers - Parte 1 (http://www.eckhard-gosch.de/download/digio.pdf)

Circuit Cellar: I/O for embedded controllers - Parte 2 (http://i.cmpnet.com/chipcenter/circuitcellar/october99/pdf/c109cdpdf.pdf)

PCB design tutorial (http://alternatezone.com/electronics/files/PCBDesignTutorialRevA.pdf)

Microchip - EMC: The art of compatibility (http://ww1.microchip.com/downloads/en/DeviceDoc/EMC%20Newsletter%20Issue%205.pdf)

Bueno, todas estan en inglés, eso sí, me habia olvidado.

Saludos.
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: PalitroqueZ en 24 de Marzo de 2009, 11:38:44
hola gonzalo.

uff si que hay bastante info, en la web de analog se consigue bastante, ellos tienen una sección llamada preguntas raras frecuentes (RAQ)

http://www.analog.com/en/content/RAQ_index/fca.html

Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: copper en 26 de Marzo de 2009, 04:56:39
Gracias por la contestacion pero como ya habia comentado ya trate de colocar esos condesadores de desacoplo y no he tenido exito
todo lo que se refiera a hardware he estado leyendo muchos foros y creo que ya cumpli con lo basico
para eliminar el fastidioso ruido yo creo que el problema lo tengo en el programa ya imprimi todo este foro para leerlo con detinimiento
pero  quisiera que me ayudaran a hacer mas robusto mi programa y combatirlo desde sofware pondre el codigo asi me puedan ayudar o dar algunas sugerencias

PICC

#include <16F877A.h>
#use delay(clock=4000000)
#include <LCD.c>
#fuses XT,NOWDT,NOPROTECT,NOPUT,NOBROWNOUT,NOLVP //ordenes para el programador         

#use  fast_io(B)
#use  fast_io(C)

#use  fast_io(D)

#byte portb = 6
#byte portc = 7


#byte portd = 8

int acumulador_bueno=0 ;
int acumulador_malo=0 ;
int Total_buennomalo=0;

void main()
{

inicio:
   
   
lcd_init();           
port_b_pullups(TRUE);
set_tris_b(0b00111111); // B0-B1-B2-B3-B4-B5-Puertos entrada las demas salidas                       
set_tris_c(0x00);   //todo el puerto c como salida               

 while(1)         // verificar que este en lugar de inicio

{
   output_c(4);
   

   lcd_putc("\f");
   lcd_putc(" *Verificando*  ");
   lcd_putc("\n");
   lcd_putc(" Estado Inicial ");
   delay_ms(100);

    if(input(PIN_B0)!=1)
 
   
      {
           
            output_c(0);
           
            output_high(PIN_C1);
             delay_ms(600);
             output_low(PIN_C1);
         
       
            lcd_putc("\f");
            lcd_putc("    Ok Listo     Estado inicial ");
            lcd_putc("\n");
            lcd_putc("  *Pulse START  ");
           
           
            output_high(PIN_C4);  // abilita escobilla
           
            delay_ms(3000);
           
            break;
      }
     
 
     

}

 while(1)
 {
 
 output_high(PIN_C4);  // mantien la escobilla activada durante todo el proceso
 
 if(   input(PIN_B5)!=1)  // Boton de registro
      {   
     
      lcd_putc("\f");
   
   printf(lcd_putc,"    Registro    Bad  Box=%d      ",acumulador_malo);
   
   lcd_putc("\n");
 
    //linea       ("12345678901234561234567890123456")
   printf(lcd_putc,"Good Box=%d",acumulador_bueno);
   delay_ms(3000);
    //linea       ("12345678901234561234567890123456")
   lcd_putc("\f");
    //linea       ("12345678901234561234567890123456")
   printf(lcd_putc,"      Total            %d       ",Total_buennomalo);
          lcd_putc("\n");
          lcd_putc(" Cajas Checadas ");
       
   
   delay_ms(3000);
     
     
      goto inicio;
     
      }
 
 
 
   if(   input(PIN_B2)!=1)  // Boton de inicio de la prueba
      {   
      output_low(PIN_C1);
     output_high(PIN_C1);
         

          lcd_putc("\f");
          lcd_putc("  VERIFICACION       ESPERE      ");
          lcd_putc("\n");
          lcd_putc("      1-2      ");
         
         
      }
     
   if( input(PIN_B1)!=1)   //Sensor limite 2  cambia de sentido
      {   
          output_low(PIN_C1);
          delay_ms(10);
         
          output_high(PIN_C2);
         
         
          lcd_putc("\f");
        //linea   ("1234567890123456")
          lcd_putc("  VERIFICACION       ESPERE      ");
          lcd_putc("\n");
          lcd_putc("      2-2      ");
       
       
           
         
      }
     
   if(  input(PIN_B3)!=1)  // Entrada del error
      {
     
       delay_ms(100);
          while(1)
         
      {
     
     
          output_c(0);
         
           
         
          lcd_putc("\f");
       
            lcd_putc("    Producto     RETIRE LA CAJA ");
            lcd_putc("\n");
            lcd_putc("   DEFECTUOSO   ");
         
         
       
     
         
         
         output_high(PIN_C3);
       
         delay_ms(500);
         output_low(PIN_C3);
       
       
       
       
        if( input(PIN_B4)!=1)    //  Sale del error para iniciar de nuevo el proceso
        {
        acumulador_malo=acumulador_malo+1;
        Total_buennomalo=Total_buennomalo+1;
       
        goto inicio;
       
        }
         
         
      }
     
      }
     
      if( input(PIN_B0)!=1)
   
      {
            output_c(0); 
            break;
      }
     
 
 }
 acumulador_bueno=acumulador_bueno+1;
 Total_buennomalo=Total_buennomalo+1;
 goto inicio;
 
 
 
 }// parentesis de main



Estuve leyendo algo sobre los flags si pueden unos ejemplos por que a penas ando moviendome en este mundo de los pic
De antemano muchas gracias
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: LABmouse en 23 de Mayo de 2009, 12:28:43
Amigo Ivan, gracias por ese gran documento de Freescale, realmente completo..  :)
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: Azicuetano en 08 de Junio de 2009, 17:22:40
 :mrgreen:

Los documentos de Gonzalo y Mr. Palitroquez también son realmente buenos.
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: MLO__ en 09 de Junio de 2009, 00:29:15
Muy buenos textos ...  :mrgreen:
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: josmaroal en 19 de Junio de 2009, 05:37:19
Hola flacoclau, gracias por tus indicaciones, espero me puedan ayudar con esto de el ruido en las lecturas ADC, estoy haciendo la lectura de 64 potenciometros multiplexados con el 4051,  y en los 8 canales del pic 16F877, he leido en este hilo de algunos filtros usados para evitar la inestabilidad en la lectura, por favor alguien me podria guiar al respecto como obtener el diagrama. Yo nesecito leer a una velocidad aprox de 14 muestras x seg, y los potenciometrso dn una salida de 0 a 5v.
Gracias
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: Desiderium en 02 de Diciembre de 2009, 15:26:57
Hola josmaroal, en sí no sé muy bien a qué filtros te refieres, si vas a hacer lecturas multiplexadas puedes solucionarlo por hardware de manera relativamente sencilla con un filtro RC  (http://www.google.es/search?hl=es&q=filtros+rc&sourceid=navclient-ff&rlz=1B3GGGL_es___MX343&ie=UTF-8), con sus respectivas limitaciones en cuanto a la frecuencia de corte, ya que si quieres un mejor filtro hay que hacer unos cuantos cálculos, o puedes hacer un filtro por software, para esto puedes usar los ya citados por los compañeros, aunque matemáticamente hay formas de obtener la ecuación para los diferentes tipos de filtros, sólo que necesitas saber un poco de sistemas discretos... no es tan complejo sacar la ecuación para el filtro digital, casi casi es formulazo, pero a mejor filtro mayor la complejidad de la ecuación resultante, por eso cuando hablan sobre filtros hablan sobre el orden del filtro (pj. Filtro pasabandas de 5to orden).

Un filtro tan especializado de octavo orden por ejemplo, es para cuando trabajamos con señales de determinada frecuencia, por ejemplo, si nos llega una señal en una frecuencia de 10Khz no queremos saber nada de las otras frecuencias entonces aplicamos un filtro pasabanda de entre 9.8Khz y 10.2Khz, ya dependerá de qué tan marcada quieres que sea tu frecuencia de corte (9.8 y 10.2 Khz) será el orden de tu filtro. Luego depende si lo quieres hacer digital, aplicas un filtro discreto, o si lo quieres hacer por hardware que generalmente aplicas un filtro de tiempo continuo.

Puede creerse que es más embrollo, pero sin duda alguna estos son los filtros que funcionan en equipos industriales y para ello hay que chutarse un par de libros, vale la pena de verdad.

Otra cosa importante que no se ha tratado mucho por lo que he visto es el ruido en la comunicación serial, espero pronto postear un código con protocolo aplicado en C que elimine estos ruidos de comunicación mediante software, si me queda tiempo espero estár posteando por aquí algunas ideas interesantes ya implementadas sobre un sistema que ya aplique. Saludos!
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: pelacable en 16 de Marzo de 2010, 12:54:54
Como dijo Jack el Destripador: ¡Vayamos por partes¡!

Solo con los fuses tenemos para escribir una novela.

#fuses XT, WDT, NOPROTECT, NOCPD, LVP, VREGEN, NOPBADEN, INTRC_IO, MCLR, BROWNOUT_SW, BORV20

LVP es mas peligroso que un tigre en tu dormitorio. En cuanto detecte 5V entra en modo programación. Usa NOLVP salvo que estés programando a bajo voltaje.

WDT sin Postscaler hace que el Reset por desbordamiento sea realmente rápido, quita WDT y empieza por WDT512 o WDT1024, después puedes ir disminuyendo el postscaler hasta que veas donde ocupas mas tiempo. Yo acostumbro a ponerlo muuuuy largo el tiempo del guardián y después lo ajusto a tiempo máximo de mi rutina mas larga (sin reestablecer el contador del Watch Dog).

Tienes también los fuses BROWNOUT_SW y BORV20. El primero anula al segundo y sirve para que tu mismo programa realice on-line el control del BOR.  Utiliza solo una combinación del estilo BROWNOUT,BORV43

INTRC_IO y XT son mutuamente excluyentes. O XT para un Cristal Externo menor o igual a 4 Mhz ó INTRC_IO para el oscilador interno pero no los dos al mismo tiempo.

VREGEN Activa el regulador de voltaje para el USB, si no estas usando el USB no te hace falta (Sobre todo si no tiene puesto el condensador en VUSB, patilla 18 del 18F4550, que le hace falta para realizar dicha regulación)

Conclusión: Pon unos fuses del estilo que te propongo mas abajo y prueba ...

#fuses XT, WDT512, NOPROTECT, NOCPD, NOLVP, NOPBADEN, MCLR, BROWNOUT, BORV43, NODEBUG

Y sobre todo Datasheet, mucho Datasheet.  :mrgreen:





Hola a todos
Este tema está muy bueno :-/
Yo recien estoy empezando a programar seguido, y cuando salté del 16F84 al 16F877A cometí varios errores que pude superar y darme cuenta de lo complicado del tema.
Si a alguno se le borra la eeprom yo les gané a todos :D :D Resulta que por desconocimiento cada vez que programaba con el ic prog. activaba el LVP, los programas funcionaban, pero no podía tocar ningun cable, se volvía inestable, el AD se volvía loco, y si tocaba el encapsulado, se reseteaba.

No entendía el porqué y decidí cambiar el integrado, fué justo ahi que me desperté. El nuevo pic se comportaba de manera muy diferente, cuando lo alimentaba directamente no funcionaba.
Lo leía con el grabador y estaba todo borrado...Otra que solo la EEprom ! a mi  se me borraba todo jejeje Desactivé el LVP y se solucionó todo.

En otra oportunidád el AD era muy inestable, y también tocando el encapsulado se producian interferencias extraordinarias.
No había programado con el LVP y los problemas eran parecidos. Como ví que el encapsulado era tan sensible, decidí colocarle una chapita de bronce por encima y ésta a masa.
Resultó, ahora el AD se había estabilizado y podía medir sin ruido, pero ¿que era lo que producía ese ruido?
El origen del mísmo era la resistencia que puse en el pin 1 MCLR, que era de un valor muy alto y que no polarizaba correctamente.  :mrgreen: estaba marcada como 10 K y tenía 1meghom :shock:

A medida que le bajaba el valor a la resistencia el comportamiento mejoraba, y podía ya sacarle la plaquita de bronce que cubría el PIC.

Hoy si la aplicación que le doy al PIC es en un ambiente ruidoso no dudo en poner un buen plano de masa en el PCB por debajo del micro y si no alcanza le pongo la plaquita por encima,
como la etapa de radio de un sintonizador, al margen de usar los capacitores de .1 uF directamente soldados a las patas. electrolíticos, inductores y demas yerbas

Otro tema que descubrí es que el 16F877 tiene entrada de alimentación por ambos lados del encapsulado, y que se le deben colocar no uno sino 2 capacitores de .1 (uno por cada entrada)

Tanto los PLCs como los equipos industriales de medicion en campo, están provistos de una placa de masa intermedia entre las dos caras de la plaqueta (ésto tiene un nombre que no me acuerdo) Hace las veces de pantalla.

Las fuentes conmutadas son las más sensibles al ruido de Fabrica, en cambio los transformadores que tienen una pantalla de papel metálico muy fino entre primario y secundario, y éste colocado a tierra, dan mejor resultado.
Lo pude comprobar con un variador de velocidad trifásico en el mísmo gabinete

Resumiendo: de mis errores pude aprender algo, y de mis experiencias en ambientes ruidosos
otro tanto.
Quizas le sirba a alguien que recien empieza como yo y no repita mis errores :oops: :oops:

 Si es así me pondré contento :P

Saludos
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: XAVICOROSS en 15 de Noviembre de 2010, 01:13:26
Ahora recién leo todos los mensajes del foro y déjenme decir que estoy aprendiendo mucho.
Hablando de Kalman, una vez utilicé un algoritmo basado en este modelo predictivo, para deshechar valores erroneos
causados por interferencia electromagnética al medir frecuencia y posición angular mediante un sensor VR
(reluctancia variable). Es increíble el resultado, lo recomiento 100%...
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: jeremylf en 21 de Diciembre de 2010, 05:45:24
Muy buenos todos las cosas que se pueden hacer por software.. Yo para estas cosas me inclino mas para el software que para el hardware, pues siempre tengo la intencion de reducir este ultimo por los costos...

Bueno, he tenido el problema de la EEPROM del PIC (18F2550) que se borraba siempre de varias resets y falsos contactos con la fuente principal (12V) ya hacer tiempo... Esto lo arregle con su sistema Brown-Out Reset configurado a 4.2V. Me di cuenta que estas "fluctuaciones" de la EEPROM se generaban a un bajo voltaje. Por otro lado, tambien pongo un delay en el main de 300ms antes de hacer cualquier cosa. Tambien, muy recomendable el WDT si quieres vender el producto ("sacarlo afuera"). Ahora estoy usando un 10F222 a 4Mhz con su WDT a 18MS (el minimo) y todo va bien. Ah y el reset siempre lo pongo al incio del bucle. Y, porsupuesto, nunca poner un refresco de WDT (restart_wdt) en una ISR (interrupcion), pues me a pasado (y varias veces) que el contador de programa se queda en otro lado, mientras que las interrupciones SI siguen ejecutandose, COMPROBADO.

Aparte, para las entradas digitales (aparte de usar pullups interna por lo que comente de reducir los costos de hardware) siempre el delay de 30ms aprox. para saber que no es un ruido. En este caso, ahora ultimo, yo e echo lo mismo pero con un programa ciclico, pues el micro no se queda en un solo lugar esperando que pase este tiempo. Para esto, e echo un contador para que revise un numero X de veces el input()... cada ves que entre por ahi el programa, despues de esto lo considero como no-ruido. Tambien, cuando quiero interpretar ese mismo pin pero en su estado contrario hago lo mismo, si la aplicacion lo requiere.

Finalmente, aun no estoy muy seguro de esto y queria preguntarles a todos... Se que usar el #Fast_IO(X) mejora considerablemtne el consumo de ROM. Pero al hacer esto aique configurar los tris manualmente siquiera una vez en el main. Para cuestiones de ruido, no seria recomendable configurar el tris cada ves que se necesite/use (#STANDARD_IO(X)) ??? No estoy seguro (no lo recuerdo) si fue por esto pero creo haber tenido un problema de desconfiguracion de un tris o algo parecido que lo soluciones aplicando STANDAR_IO.... como digo no estoy seguro pero al interpretarlo parece buena idea para un "porsiacaso se me desconfigura los TRIS cuando configure en el main (se me convierte una salida a entrada o algo parecido); volviendose a reconfigurar automaticamente cuando mi programa lo necesite o use ese pin"... pues tampoco no es que los TRIS se vayan a gastar no?

Ahora, no recuerdo algunos otros trucos pero ahi estaremos.

Un saludo.  
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: jeremylf en 21 de Diciembre de 2010, 06:00:53
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  :-)
No estoy muy deacuerdo con este truquillo Azicuetano, pues (claro que depende de la aplicacion) hacer esto si que cuesta y me refiero al tiempo que desperdicias al poner ese delay para ajustar MAS el WDT. Almenos, en una aplicacion ciclica, como la que comento un post atras, hacer esto no me dejaria hacer esas reviciones. Por el contrario, he oido o leido de mchip ya hace tiempo de una forma para no tener ese tipo de fallas que tenias sin tener que hacerlo asi y es cubriendo toodo lo que no has usado de progrrama con un GOTO creo al incio de tu programa por si el contador de programa se le ocurre saltar por ahi. No recuerdo que nota era y la forma en que se hacia y tampoco lo he echo pero se lee muy interesante implementarlo. Tampoco estoy seguro como se aria eso en CCS, creo q con #ORG o #reserve... bueno.


Salu2
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: setshomaru en 31 de Enero de 2011, 21:36:38
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.


Gracias colega, despues de Dios, me has salvado de ser un desempleado mas, este truco me ayudó a terminar un proyecto en la empresa para la que trabajo y no creo que hubiera sido posible sin esto.

Entrando en el tema creo que lo mas importante es tratar de minimizar el ruido por hardware, y prevenir por software, en mi experiencia, en cada circuito que hago coloco un condensador de 100uF lo mas cercano posible a los pines de alimentacion del pic, casi siempre basta con eso, y claro tener una muy buena fuente. 
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: japifer_22 en 14 de Mayo de 2011, 23:06:23
Hola, bueno este tema que se toca acá es para nunca acabar, y como se han dicho en estas 6 páginas siempre hay algo que aprender, pero como dicen varios, casi siempre el problema de que el pic se quede pegado es por el motivo del ruido, y independiendo de que ruido afecte a nuestro circuito. En fin, yo siempre estoy haciendo cosas y mis PCB, en cuales en varios ocasiones tengo circuitos que tienen que funcionar siempre, ósea los 365 días del año sin descanso. Yo estoy aprendiendo a programar, como se ve en las muchas preguntas que e hecho en el foro, pero siempre me resultan bien los circuito cuando los llevo a la práctica, y es porque:
Como dicen varios separar las pistas de potencia con la de control
También filtrar muy bien la fuente de alimentación, condensadores y bobinas, esto último yo siempre las pongo en conjunto con varistores.
Luego pongo condensadores de 100nf cerca de los CI.
Pero para mí lo más importante es que siempre, pero siempre genero su plano a tierra del circuito y siempre pongo condensadores de filtrado en varias partes que yo creo que son criticas.
En cuanto a los malditos botones, aprendí que esto siempre hace que el pic se cuelgue en algún momento. Pero logre solucionar esto generando un anti-rebote por hard y otro pos soft. Como también que en un pic de los 16F no tengo que generar tantas funciones, ya que este es más propenso a perderse que los de la gama de los 18, y lo digo con fundamento esto último, ya que he probado esto.
Ahora ultimo lo que hago también es poner condensadores en las entradas y salidas del pic, ya que he cambiado mi tecnología de circuito y he emigrado a SMD, y bucha que es grato poder meter todo el circuito que quieras, y que te ocupe tan poco espacio, y sobre todo si ocupas doble faz.
También lo otro es que nunca dejo un pin sin conectar, y en esto ahora estoy aprueba que es mejor si dejarlo a VCC o a GND, pero son pruebas como digo que me tendrán que llevar a alguna conclusión buena, y no duden en que se las are saber.

http://construyasuvideorockola.com/fabricacion_impresos_04.php

A todo esto. Les dejo un video de cómo hacer PCB, y créanme que se logran muy buenos resultado, vean el video, es el método de serigrafía.
Y como acotación en la parte que va la soldadura, le pongo primero estaño liquido, y al horno y después del video y lo ultimo dicho, empiezo a poner los componentes.
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: callecuatro1976 en 28 de Diciembre de 2014, 10:18:34
como hago filtro básico por software para un voltimetro filtro básico por software sumando variables y tomando mediciones me tilde y no se me ocurre , en c por favor
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: MLO__ en 28 de Diciembre de 2014, 17:24:24
Código: C#
  1. //Haz un promedio de las mediciones tomadas ...
  2.  

 :mrgreen: :mrgreen: :mrgreen: :mrgreen:
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: callecuatro1976 en 28 de Diciembre de 2014, 18:24:48
como seria un ejemplo de como armo el programa y como hago la lectura del adc
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: KILLERJC en 28 de Diciembre de 2014, 19:04:15
como seria un ejemplo de como armo el programa y como hago la lectura del adc

Y depende :3 si lo haces con interrupciones, en cada interrupcion sumas el valor del ADC en una variable y luego de una x cantidad de variables dividis. Y ese es tu valor.

Si no lo haces con interrupciones, Hacelo con delays y toma datos a un intervalo regular de tiempo, acordate que mientras estes en un delay no vas a poder hacer nada.

Lo mejor es que tomes una cantidad de datos que sea potencia de 2, asi con simples rotaciones lo dividis (4,8,16) , pero intenta que sea a intervalo regulares de tiempo.

Un ejemplo... si mostras tus datos en un LCD cada 0.5 segundo,  entonces podes tomar datos cada 62.5mS y cuando llegue al 8vo dato ( dividis por 8 y mostras en el LCD )
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: callecuatro1976 en 29 de Diciembre de 2014, 07:42:00
asea que seria
variable 1
delay
variable2
delay
variable3
delay
variable4
1+2+3+4=variable5
variable5=read_adc
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: callecuatro1976 en 29 de Diciembre de 2014, 12:34:39
 while (true)
   {
   set_adc_channel(0);
   delay_us(20);
   for(var1=0;var1<8;var1++)
   {
      volt = read_adc();
      delay_us(20);
   }
   
  var2=var2+volt;
  var1=var1+1;
   valor=volt/8;
   valor=volt*50/1023;
   lcd_gotoxy(2,2);
   printf(lcd_putc,"%04.2f",valor );
   delay_ms(500);
  asi seria el código para el resultado de variables para un voltimetro , me parece que le estoy pifiando
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: KILLERJC en 29 de Diciembre de 2014, 13:46:44
while (true)
   {
   set_adc_channel(0);
   delay_us(20);
   for(var1=0;var1<8;var1++)
   {
      volt = read_adc();
      delay_us(20);
   }
  
  var2=var2+volt;
  var1=var1+1;
   valor=volt/8;
   valor=volt*50/1023;
   lcd_gotoxy(2,2);
   printf(lcd_putc,"%04.2f",valor );
   delay_ms(500);

Si le estas errando xD, algunas cosas, si no fueras a cambiar el canal del A/D y siempre usas el canal 0 sacaria el:

   set_adc_channel(0);
   delay_us(20);

afuera del while. Tambien la variable volt deberia ser de 16bits y la variable valor un float...

Citar
while (true)
   {
   for(var1=0;var1<8;var1++)
   {
      volt += read_adc();
      delay_us(62);
   }
 
   valor = volt / 8; // No se como lo tomara el compilador si es mejor asi o rotarlo 3 posiciones, es decir valor = volt >> 3
   valor = valor * 50 / 1023;
   lcd_gotoxy(2,2);
   printf(lcd_putc,"%04.2f",valor );

Modifique asi no hay no aparece el ultimo delay, para eso hice que la sumatoria de todos los delays de la toma de datos te de 500mS, asi en ningun momento deja de tomar datos (500ms/8 = 62.5mS). Sino estarias tomando datos por un momento y luego nada. Espero que se entienda lo que quise decir. De todas formas cada 500mS aproximadamente el LCD se va a actualizar.

Puse en negrita lo que cambie, o las lineas que cambiaron.
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: callecuatro1976 en 29 de Diciembre de 2014, 16:05:23
se me dispara empezando a contar asendente y no para
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: callecuatro1976 en 29 de Diciembre de 2014, 16:27:58
todo el programa es asi


void main(){
int var1=0;
 float valor=0,volt,valor2,amper;

//Se habilita el A/D y se declara el PORT a usar

 setup_adc_ports(an0_an1_an3);
setup_adc(adc_clock_div_32  );           

 

 
//Se inicia la LCD
   lcd_init();
   lcd_gotoxy(3,1);
   lcd_putc("iniciando");
   delay_ms(2000);
   lcd_gotoxy(7,2);
   lcd_putc("LPK");
   

   delay_ms(500);
   lcd_putc("\f");
   lcd_gotoxy(2,1);
   lcd_putc("Volt     Amper");
      delay_ms(1000);


   
  while (true){
  set_adc_channel(0); 
   delay_us(20);
  {
   for(var1=0;var1<8;var1++)
   {
      volt= read_adc();
      delay_us(62);
   }
 
   valor = volt / 8;
   valor = valor * 50 / 1023;
   lcd_gotoxy(2,2);
   printf(lcd_putc,"%04.2f",valor);
 
   
   set_adc_channel(3); 
   delay_us(20);
   amper = read_adc();
   delay_us(500);
   valor2=amper*18/1023;
   lcd_gotoxy(11,2);
   printf(lcd_putc,"%04.3f",valor2);
   delay_ms(200);
 
   }
   }
}
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: KILLERJC en 29 de Diciembre de 2014, 19:23:49
A mi gusto son muchos delays pero cambiarlo implicaria uso de timers y interrupciones asi que mejor lo dejamos asi xD o es tema para otro dia.

No cambiaste:

Código: [Seleccionar]
volt= read_adc();  
por ( fijate el += )  
Código: [Seleccionar]
volt += read_adc();o que es lo mismo que poner
Código: [Seleccionar]
volt = volt + read_adc();
se me dispara empezando a contar asendente y no para

No me doy cuenta donde estas contando ascendente, el for deberia terminar si o si.
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: callecuatro1976 en 29 de Diciembre de 2014, 20:56:47
Cuando lo simulo en el proteus los volt suben y no paran
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: KILLERJC en 29 de Diciembre de 2014, 21:04:31
Si perdon, antes de entrar al for pone

Citar
volt = 0;

Asi resetea el valor. Cuando comienza a tomar las demas medidas.
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: callecuatro1976 en 30 de Diciembre de 2014, 07:32:30
#include <16f873a.h>
#device adc=10
#fuses NOWDT,BROWNOUT,XT,NOLVP,PUT
#use delay (clock=4m)
#define use_portb_lcd true
#include <lcd.c>


void main(){
int var1=0;
 float valor=0,volt=0,valor2,amper;

//Se habilita el A/D y se declara el PORT a usar

 setup_adc_ports(an0_an1_an3);
setup_adc(adc_clock_div_32  );           

 

 
//Se inicia la LCD
   lcd_init();
   lcd_gotoxy(3,1);
   lcd_putc("iniciando");
   delay_ms(2000);
   lcd_gotoxy(7,2);
   lcd_putc("LPK");
   

   delay_ms(500);
   lcd_putc("\f");
   lcd_gotoxy(2,1);
   lcd_putc("Volt     Amper");
      delay_ms(1000);


   
  while (true){
  set_adc_channel(0); 
   delay_us(20);
  {
   for(var1=0;var1<8;var1++)
   {
      volt=volt+ read_adc();
      delay_us(62);
   
 
   valor = volt / 8;
   
   valor = valor * 50 / 1023;
   lcd_gotoxy(2,2);
   printf(lcd_putc,"%04.2f",valor);
   }
   
   set_adc_channel(3); 
   delay_us(20);
   amper = read_adc();
   delay_us(500);
   valor2=amper*18/1023;
   lcd_gotoxy(11,2);
   printf(lcd_putc,"%04.3f",valor2);
   delay_ms(200);
 
   }
   }
}
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: KILLERJC en 30 de Diciembre de 2014, 11:16:26
Código: [Seleccionar]
#include <16f873a.h>
#device adc=10
#fuses NOWDT,BROWNOUT,XT,NOLVP,PUT
#use delay (clock=4m)
#define use_portb_lcd true
#include <lcd.c>


void main(){
int var1=0;
float valor=0,volt=0,valor2,amper;

//Se habilita el A/D y se declara el PORT a usar

 setup_adc_ports(an0_an1_an3);
setup_adc(adc_clock_div_32  );            

//Se inicia la LCD
   lcd_init();
   lcd_gotoxy(3,1);
   lcd_putc("iniciando");
   delay_ms(2000);
   lcd_gotoxy(7,2);
   lcd_putc("LPK");
  

   delay_ms(500);
   lcd_putc("\f");
   lcd_gotoxy(2,1);
   lcd_putc("Volt     Amper");
      delay_ms(1000);


  
  while (true){
  set_adc_channel(0);  
   delay_us(20);
   volt = 0;     // ACA es donde decia
   for(var1=0;var1<8;var1++)
   {
      volt=volt+ read_adc();
      delay_us(62);
   }
 
   valor = volt / 8;
   valor = valor * 50 / 1023;
   lcd_gotoxy(2,2);
   printf(lcd_putc,"%04.2f",valor);
  
  
   set_adc_channel(3);  
   delay_us(20);
   amper = read_adc();
   delay_us(500);
   valor2=amper*18/1023;
   lcd_gotoxy(11,2);
   printf(lcd_putc,"%04.3f",valor2);
   delay_ms(200);
  
   }
}

Asi cada ves que comienza a hacer le promedio de las medidas comienza de 0 y no del valor que habia dejado antes ( del ultimo promedio ) que era el problema que tenias vos.
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: callecuatro1976 en 30 de Diciembre de 2014, 11:33:45
si funciona bastante bien ahora como puedo hacer que se vea mejor en. el lcd se ven los últimos dígitos muy movedizos se puede hacer que se vea como el tester bien quietos
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: KILLERJC en 30 de Diciembre de 2014, 12:09:27
Aca entramos en un problema si tenes muchos digitos luego de la coma va a variar siempre y mas si la señal de entrada varia por un ripple etc.

Quedan 2 formas:



Pero si aun asi tenes problema ya veria de hacer algo en hardware y no en software.
Por que si varia tanto la entrada no tiene sentido el sacar un promedio. Y convendria mas tomar un valor cada mucho tiempo aunque no sea lo correcto.
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: callecuatro1976 en 30 de Diciembre de 2014, 13:56:51
me sirvió mucho tu ayuda gracias
Título: Re: Luchando contra el ruido POR SOFTWARE
Publicado por: yenz en 04 de Marzo de 2015, 14:24:39
Esta técnica (la recuperación de una máquina despues de un apagado) es algo que se hace desde hace mucho tiempo en los sistemas microprocesados, se conoce como arranque en caliente (se mantienen los datos) o arranque en frio (se inicializa la máquina). Es muy conveniente realizar un checksum de la memoria en el momento del arranque y si los datos no son coherentes realizar una arranque en frio, en caso contrario realizar el arranque en caliente.

Un saludo
Título: Re:Luchando contra el ruido POR SOFTWARE
Publicado por: Loudness en 07 de Noviembre de 2015, 01:21:11
Veo que este tema lleva mucho tiempo sin moverse, pero voy a escribir aqui antes de abrir un nuevo tema.

El caso es que es un tema muy interesante y el hilo es muy completo. Con mi nivel, la mayoria de los mensajes no les llego a entender del todo, pero me esta sirviendo para tener una referencia y saber por donde empezar.

Y es que en este hilo o en otros parecidos, se habla de como luchar contra el ruido, pero, a mi nivel todavia no entiendo muy bien como identificar si lo que esta afectando a mi PIC es ruido o mas bien otra causa (un fallo de programa, p.e.). Y, si de verdad es ruido, como saber exactamente por donde le esta entrando para saber la medida adecuada a tomar?/

Me explico con un ejemplo mas o menos real: disenas un circuito, funciona bien, tomas las medidas anti-ruido "estandar" (una buena fuente, condensadores de desacoplo, anti-rebote para los pulsadores....), "sacas fuera" unos 200, y esos 200 funcionan sin problemas en diferentes lugares durante meses. Pero, mira por donde, al hacer funcionar el cirucito 201 en cierto sitio, a los pocos minutos de funcionamiento las letras del LCD empiezan a bailar. Reseteas y lo mismo una y otra vez. "Esto tiene que ser fallo del programa, vete y arreglalo"... Despues de 200 circuitos sin ningun fallo, que el 201 tenga un fallo de programa no me lo llego a creer del todo. "Esto tiene que ser ruido" pienso y es hay donde viene el tema. Si me piden que explique por donde entra el ruido, que tengo que hacer?.

Me imagino que ir con un osciloscopio y medir la onda de la fuente de 5V....pero aunque mire la onda como puedo saber si el ruido es de verdad el casuante del problema? Y si la fuente no tiene ruido, por donde sigo la medicion?. Por la entradas del PIC?...

Me he alargado y no se si explicado bien el problema....


Título: Re:Luchando contra el ruido POR SOFTWARE
Publicado por: KILLERJC en 07 de Noviembre de 2015, 01:52:03
El ruido creo que es lo peor que uno se puede enfrentar.
El dificil de quitarlo. Y ahi ruidos que son imposibles de quitarlos, como el ruido termico

¿ Por donde puede ingresar ? Por todos lados. Por radiacion, por conduccion, etc.

Podes tener el mismo PCB con fuente en un lado u otro, pero tal ves ese lugar numero 201, tiene un equipo que no cumple con las especificaciones y envia armonicos a la "red" y al aire ( a la alimentacion ) y eso termine ingresando a tu PIC por tu fuente.

Tambien puede ser que tengas un cable que pase por lugares donde existen cambios en los campos magneticos y eso genera una corriente en tu cable. Supongamos un boton y que pase por las alimentaciones de unos contactores o salidas a motores.

Pero tambien puede ser que la misma PCB sus caminos terminen siendo una especie de antena. Y captando las EMI transmitidas en el aire.
La ultima es que afecte al PIC directamente, tal ves en los pines del oscilador, o tal ves el PIC en si.

Hay varios problemas que el software no te lo va a solucionar, puede ser algunas cosas, pero otras no.
Y la solucion mas simple es... una jaula de faraday. Sino podrias optar por una PCB de 4 capas asi tenes capas de GND que te sirvan como pantalla a los ruidos. al menos de radiacion.
Ponerle el anillo de guarda al cristal si es que usas. Y una jaula de faraday depende del material/frecuencia y intensidad de la onda. Segun eso va a tner un mayor/menor factor de absorcion el material ( Busca penetracion de onda electromagnetica )

Ver el ruido para mi me parece que es muy complejo. Al menos yo no se como lograrlo, por que a veces es un ruido en modo comun, y no veas cambios.
Con respecto a tu pregunta sobre si es el programa o no, es bastante simple de ver. Si de las 200 todas funcionan bien (y durante meses), quiere decir que el programa esta funcionando, pero esa 201 no funciona correctamente (y me refiero a 3 problemas por dia un suponer ), podrias reemplazar la placa (si tenes 201, tenes 202), de esa forma si sigue el problema saber que es ruido, y la otra es intentar determinar por donde viene el ruido. Si ocurre un problema cuando se activa algo en especial ( como un motor ) o no hay nada evidente.

Creo que finalmente es poner y probar , poner y probar. Lo mismo ocurre con el layout del PCB
Título: Re:Luchando contra el ruido POR SOFTWARE
Publicado por: Loudness en 07 de Noviembre de 2015, 02:17:31
Gracias por la rapida respuesta.

La placa 201 la voy a sustituir por la 202 esta semana. Pero, como dije antes, no me acabo de creer que sea problema de software asi que me llevare el osciloscopio, aunque, segun tu explicacion creo que no va a valer de mucho....

Si el problema es ruido y va a ser dificil quitarlo, se me ocurre (como solucion de emergencia) un programa con un temporizador para que resetee la pantalla LCD, por ejemplo, 10 veces por segundo. Aunque las letras se vuelvan locas, pienso que el reseteo de la pantalla pueda "ocultar" el error y darme algo de tiempo hasta encontrar una solucion mas real.

Lo malo de esto es que, si reseteo la pantalla tantas veces, las letras van a parecer como intermitentes.....

Creo que estoy despedido jejeje  :lol:
Título: Re:Luchando contra el ruido POR SOFTWARE
Publicado por: KILLERJC en 07 de Noviembre de 2015, 02:31:51
Ahora que nombras LCD, no recuerdo que persona tenia unos problemas parecidos y que por suerte tenia otro LCD igual. El LCD le fallaba en cierto tiempo. Primero pense que era un tema de tiempos, pero no era asi ya que le funcionaba bien y luego no. Esto fue aca en el foro y termino con esa solucion.

Asi que proba primero con otra placa.
Sino buscate algun metal ( una lata de gaseosa - como para probar ) y trata de crearte una jaula , soldandolo a GND y tratando obviamente que no toque nada mas. Si ya ahi no funciona empeza a mirar el tema de cuando es que grafica cosas raras / si se activa algo o no.

Mas no te puedo decir, ya que va a depender de donde este el circuito, el layout del circuito, las maquinas alrededor, cada situacion es particular.

PD: Sobre verlo en el osciloscopio no dije que sea inutil, sino mas bien complejo, por que todo depende de la naturaleza del ruido. Podes estar todo el dia ahi y nada. y en un momento vino la señora de casa, encendio su magnifico secador de pelo, y tenes tu ruido. Lo cual no hablamos si esto ocurre ocasionalmente, o continuamente apenas se usa el LCD.
Título: Re:Luchando contra el ruido POR SOFTWARE
Publicado por: Loudness en 07 de Noviembre de 2015, 03:27:58
Gracias de nuevo.

No se me habia ocurrido que fuera el LCD :shock:. Creo que tengo uno asi que lo llevare y lo probare. Y si no va empezare con la jaula puesta a tierra.

El PIC se alimenta de una fuente regulada de DC5V que a su vez se alimenta de una red AC200V 60z. Me han dicho que lleve algun filtro EMC(?) para poner en la linea de 200V, que puede funcionar si el ruido viene de alli.

En cuanto a lo del oscilocopio, lo siento, no me exprese bien. Habia entendido tu explicacion pero como es un viaje de casi 5 horas en tren hasta el "problema" pense que mejor no llevarlo para evitar equipaje, pero no creo que sea inutil. Me disculpo.

El miercoles me voy y lo vere "in situ". Cuando tenga algun resultado lo escribire en este hilo. A lo mejor le puede servir a alguien.

Título: Re:Luchando contra el ruido POR SOFTWARE
Publicado por: KILLERJC en 07 de Noviembre de 2015, 11:30:38
No te diria que te lleves una bateria por que es algo "complejo" de llevar y asi evitar el ruido de fuente, pero podrias verlo en el osciloscopio, siempre y cuando no sea un ruido en modo comun, ya que si es un ruido en modo comun entre GND y VCC no vas a ver nada nuevamente.

Tambien va a depender bastante de las fuente que sea. Switching o de transformador, si es switching considero mas facil que pase ruido de alta frecuencia, mientras que una fuente a transformador lo veo mas complejo que suceda. Ya que el transformador de 50/60Hz prefiere mas estas frecuencias que no unas altas.

Y no queda otra que ir al lugar, cambiar la placa, y si es ruido, ver donde esta posicionada, ver si el problema aparece cuando se enciende algun elemento y el cable pasa por ahi cerca o si no hay cable que pase cerca entonces es por radiacion. Si el LCD esta conectado por cables intenta cables mas cortos. Tal ves el ruido este entrando por ahi. Probaria de ponerle pull-ups a las entradas, podrias ver el caracter extraño que aparece y que relacion tiene con el que deberia aparecer. En fin es todo lo que se me ocurre para probar. Y que probaria yo al menos.

Asi que espero hasta el miercoles para que lo veas y espero que le logres encontrar solucion.
Título: Re:Luchando contra el ruido POR SOFTWARE
Publicado por: Loudness en 07 de Noviembre de 2015, 23:33:22
El problema del LCD no es que aparezcan caracteres extranos. Mas en detalle, el problema es la posicion donde salen.

Me explico: El circuito es bastante simple. Coje una senal de 0-5V por la entrada analogica, calcula el nivel de la senal(0~100%), y saca el resultado por un LCD de 16x2. El mensaje que sale es "OUTPUT:____100%" por la linea 1 del LCD y "WORKING_________"por la linea 2. Tambien tiene 3 botones para actuar sobre reles de DC5V y segun la accion saca un mensaje en la pantalla.

El problema es que el mensaje de output, tiene que salir la primera letra "O" en la posicion 1 de la primera linea. Pero cuando pasan varios minutos, la letra empieza a salir por la posicion 2, es decir, se corre un sitio hacia la derecha de tal manera que el resto del mensaje tambien se corre. Enseguida se pasa a la posicion 3 y a la 4 y asi una por una hacia la derecha. Mientras por la parte izquierda empieza a aparecer la parte del mensaje que se va borrando por la derecha.....

RESUMIENDO: se ha convertido en un cartel de letras giratorias cuando realmente deberian quedarse quietas. Pero, realmente las letras siguen saliendo bien, sin fallo "OUTPUT:".

En esta situacion, actuando sobre los botones, los reles se mueven bien, asi que el programa en realidad sigue funcionando.

Por eso pense que una solucion de emergencia seria el reseteo de la pantalla cada cierto tiempo. No soluciona el problema pero puede valer de momento?.

El PIC se comunica con el LCD por un cable flat de 300mm. Esta suelto sin tocar con otros cables del circuito. Tambien tengo intencion de cambiarlo junto al LCD pero no se si podre conseguir otro mas corto. Vere que puedo hacer.

En cuanto a la fuente, es de switching y tambien llevare una de repuesto. Aunque, si el ruido la esta afectando, sin encontrar la causa y cambiar la fuente no va a valer de mucho?


Título: Re:Luchando contra el ruido POR SOFTWARE
Publicado por: KILLERJC en 08 de Noviembre de 2015, 00:19:11
Ah.. entonces el problema no es que termina haciendo cualquier cosa, sino que es un error que se repite continuamente. Y el mismo error.

Y ahi si pienso que puede ser posible un problema de soft, el tema es que si me decis que las demas placas sometidas a la misma operacion ( es decir si estan siempre alimentado o se corta la alimentacion, etc ) funcionan perfectamente entonces no puedo decir eso, y me pareceria descabellado. Pero que justamente tengas un problema asi tan especifico y se repita en serio parece eso. probaria con una placa que funciona, probala antes de llevarla y que tenga el mismo ritmo de funcionamiento que la otra, y observa si presenta el mismo problema. Si ya reemplazas alla y sigue entonces si puedo pensar en ruido.
Título: Re:Luchando contra el ruido POR SOFTWARE
Publicado por: Loudness en 08 de Noviembre de 2015, 00:58:00
Totalmente de acuerdo. Por eso, la primera persona que vio el problema enseguida me dijo "Problema de software".

El numero exacto son 214 maquinas con la misma placa. Algunas solo funcionan unas horas al dia y otras estan conectadas las 24 horas.
Algunas estan en ambientes con ruido moderado pero, aun asi, es la primera vez que sale este mismo problema.

Por eso, no niego la posibilidad de un error del software, mas todavia cuando soy un novato en esto del PIC.
Pero todavia me resisto a aceptarla hasta que no cambie el circuito y lo compruebe por mi mismo.

Por otra parte, espero que no sea problema de software porque sino ya me veo viajando meses para actualizar todas las 213 placas restantes....
Título: Re:Luchando contra el ruido POR SOFTWARE
Publicado por: KILLERJC en 08 de Noviembre de 2015, 01:17:57
Citar
Por otra parte, espero que no sea problema de software porque sino ya me veo viajando meses para actualizar todas las 213 placas restantes....

Seria un dolor terrible hacerlo. Asi que esperemos que sea solo un caso aislado.
Respecto a tus otras preguntas no las respondi por que cambio enteramente el panorama cuando me explicaste bien cual era el mal funcionamiento del LCD. Tanto que descartaria el ruido.
Por que es algo que:

- se repite ( el mismo error, otro error NO aparece ), si fuera un ruido que entra y modifica un bit de uno de los comandos (que modifique la direccion o realize un shift), se podria esperar que tambien pueda llegar a modificar cualquier letra enviada, pero esto no ocurre. tambien seria muy raro que unicamente afecte a un dato en particular
- acumulativo ( pasa a la 2, luego a la 3 etc) , esto quiere decir que hay una variable involucrada, ya que hay una "memoria". Supongo que tendras algo como lcd_xy(3,1); Linea 3 , posicion 1. si hay una variable tanto que lo pasas por ahi o que se maneja adentro, que se modifique en otro lado

Esto suponiendo que unicamente lo que se dezplaza es la palabra "output:___00%" y nada mas.
Asi que solo me queda que lleves un LCD + una placa, y con suerte si se arregla o es el LCD o es la Placa, si no se arregla entonces seria un problema de soft nomas creeria yo.
Título: Re:Luchando contra el ruido POR SOFTWARE
Publicado por: Loudness en 08 de Noviembre de 2015, 01:47:46
Huummmmm....  :?

Despues de leer tu explicacion me estoy empezando a convencer de que si puede ser un error de software.

La rutina para ir a la primera posicion de la linea1 del LCD, seria algo asi (en ensamblador):

; LCD_Linea1             
;   movlw   b'10000000'       
;   bcf           LCD_PinRS      
;   movwf   LCD_GuardaDato      
;   call           LCD_EscribeLCD      
;   swapf   LCD_GuardaDato,W   
;   call           LCD_EscribeLCD      
;   btfss           LCD_PinRS      
;   call           Retardo_2ms      
;   call           Retardo_50micros
;   return   
;LCD_EscribeLCD
;   andlw   b'11110000'      
;   movwf   LCD_Dato      
;   movf           LCD_BusDatos,W      
;   andlw   b'00001111'      
;   iorwf           LCD_Dato,F      
;   banksel     TRISD      
;   movf           TRISD,W      
;       banksel   PORTD
;   movwf   LCD_GuardaTRISD
;       banksel   TRISD
;   movlw   b'00001111'      
;   andwf   PORTD,F         
;   clrf           STATUS      
;   movf           LCD_Dato,W      
;   movwf   LCD_BusDatos      
;   bsf           LCD_PinEnable      
;   nop
;   bcf           LCD_PinEnable      
;   banksel   PORTD
;   movf           LCD_GuardaTRISD,W   
;       banksel   TRISD
;   movwf   TRISD         
;   clrf           STATUS      
;   return

Esta rutina esta cogida de un libro pero la que utilizo se parece mucho. El caso es que, tambien la utilizo en otros proyectos (en laboratorio) y no he tenido especial problema con ella.

Como lo ves?.

Título: Re:Luchando contra el ruido POR SOFTWARE
Publicado por: KILLERJC en 08 de Noviembre de 2015, 03:04:31
No veo demasiados problemas, lo que si no me gusta como se maneja el TRIS, mas cuando se estaria usando demoras y no lecturas desde el LCD para pasar al siguiente dato.

- Siempre deberias llamar a la funcion LCD_Linea1 con el banco 0.

- Tambien Podrias eliminar la parte de los TRIS. Ya que si te molestas para tomar el dato del puerto para no modificar las demas salidas. Es decir esto:

Código: ASM
  1.         movf    LCD_BusDatos,W          ; Tomo el port, le hago una AND con 0x0F y una OR con el dato guardado
  2.         andlw   b'00001111'      
  3.         iorwf   LCD_Dato,F              ; Asi no cambio ls demas bits, LCD_Dato es el valor a poner en el puerto

Asi solo modificarias las salida superior. Entonces cuando haces un

Código: ASM
  1.         banksel TRISD
  2.         movlw   b'00001111'             ; Nuevamente gracias al TRISD anterior toma los TRIS y solo
  3.         andwf   PORTD,F                 ; deja la parte alta como salida
(Solo notar que ese PORTD no es un PORTD sino que accederia a TRISD)
Cuando lo pones como entrada perdes totalmente los valores que tenias ahi. No se si va a afectar esto o no, pero si la parte baja de ese puerto el LCD lo usa, entonces puede que tengas unos errores ahi.

- Tenes una instruccion sin sentido:

   btfss   LCD_PinRS   

Pero que no va a afectar en tu programa.
Es lo unico que se me ocurre que pueda ocurrir ahi, y que pueda ser un problema de bancos.
Título: Re:Luchando contra el ruido POR SOFTWARE
Publicado por: Loudness en 08 de Noviembre de 2015, 09:59:55
Pues parece que van saliendo problemas de software :oops:

La funcion de LCD_Linea1 la llamo siempre desde el banco 0, por ahi creo que no va a tener problema, pero el TRISD ya es diferente...

Mi placa se conecta al LCD utilizando RD4~RD7 como bus de datos (4bits).
El pin E va al RD2, el RS va al RD0 y el Pin R/W va al RD1. En efecto, la parte baja del TRISD la utilizo para el control del LCD. :shock:

Escuchando tu explicacion esto puede dar problemas.
Pero, precisamente para no alterar el puerto D pense que funcionaba esta parte:

;       movf           TRISD,W     
;       banksel       PORTD
;       movwf        LCD_GuardaTRISD

conservando el dato en un registro (LCD_GuardaTRISD), para al final de la rutina volver a restaurarlo;

;       movf           LCD_GuardaTRISD,W   
;       banksel       TRISD
;       movwf        TRISD     

Pense que de esta manera el TRISD del principio de la rutina y al final de la misma no ha variado y no provocaria problemas?   
Como he dicho todavia soy novato en esto y noto algo raro pero no acabo de ver el error...


- Tenes una instruccion sin sentido:

   btfss   LCD_PinRS   


Cierto, esta instruccion no tiene sentido y esta utlizando linea de codigo sin sentido. Borrada.
Título: Re:Luchando contra el ruido POR SOFTWARE
Publicado por: KILLERJC en 08 de Noviembre de 2015, 10:24:12
Yo tengo mis ciertas dudas, pero voy a intentar explicar como creo yo que funcionaria. Voy a hacer un ejemplo

PORTD = 0b0100 1010
TRISD = 0b0000 0000

Vos guardas el PORTD y cambias los bits de datos

PORTD = 0b0100 1010
Guardado = 0b1100 1010
TRISD = 0b0000 0000

Luego cambias el TRISD a entrada y escribis el PORTD

TRISD = 0b0000 1111
Escribo el PORTD
PORTD = 0x1100 xxxx

Esas x es por que no puedo modificarlas (son entradas, el valor depende del pin), ya que esos valores dependen exclusivamente de la entrada , y ahora estan flotando, no estan ni a 0 ni a 1.  A no ser que tengas un pull-up / pull-down externo O tal ves lo posea el puerto. Supongamos que el puerto tiene pull-up activado, como esos pines son entradas al LCD, el LCD no va a presentar tension alli, tendrias un 1.

PORTD = 0b1100 1111           // Lo tuyo mas lo leido por ser entradas
Ahora vuelvo el TRISD como estaba antes
TRISD = 0b0000 0000

Y PORTD como queda? queda con los valores que grabaste antes ? con los valores guardados ? o queda con los valores de la entrada? Creo que esta ultima suposicion seria para mi la correcta. Ya que la entrada afecta al PORTD. Quedandote al final.

PORTD = 0b1100 1111

Ese es el unico error que suponia.  La unica forma de haber realizado lo que hiciste es por si tenia que leer el LCD, lo que no creo que hagas por que usas un delay para esperar que termine de procesarse la instruccion o dato. Ni estas leyendo una entrada. Por eso pense que eso esta demas.
Si no lo ponias era algo tan simple como esto:

PORTD = 0b0100 1010  //Original
TRISD = 0b0000 0000  // Original
-------
Guardado = 0b1100 1010  // AND + OR, solo cambian el nibble superior
-------
PORTD = 0b1100 1010  // Paso al PORTD

Los bits de control no varian para nada y se cambio el valor de PORTD sin problemas.
Título: Re:Luchando contra el ruido POR SOFTWARE
Publicado por: Loudness en 08 de Noviembre de 2015, 21:36:10
Hummm, creo que empiezo a ver lo que quieres decir.

Como ya te escrito todavia no soy mas que un novato y mirando mi codigo seguro que hay mas sitios que un profesional escribiria de otra manera.
Poco a poco ire estudiando y repasando, no solo esta parte, sino el codigo en general.

De todas maneras, y a riesgo de ponerme pesado, si el problema saliera de esta secuencia, porque se descubre ahora?
No tendria que salir mucho antes?. Sigo pensando que hay otro factor que hace fallar al PIC.....

El miercoles cuando vaya espero llegar a alguna conclusion


Título: Re:Luchando contra el ruido POR SOFTWARE
Publicado por: KILLERJC en 08 de Noviembre de 2015, 23:23:19
Si y es lo raro, puede llegar a ser la placa, o tal ves el LCD. Realmente puede ser algo unico a eso. Yo te comento el posible error, deberia haber podido simularlo para ver si exactamente lo que comento ocurre. Tambien depende de que si tu programa a medida que pasa el tiempo tal ves modifica algo sin querer. Todo es posible xD
Título: Re:Luchando contra el ruido POR SOFTWARE
Publicado por: Loudness en 13 de Noviembre de 2015, 00:37:14
Bueno, pues encontre el problema y no era el ruido.

Llegue ante la placa del problema. El ambiente no era, para nada, ruidoso. He estado en sitios mucho peores que este.
Encendi la maquina y sin pasar 5 minutos las letras empezaron a moverse y a cambiar (algo diferente de lo que me habian explicado por telefono).
Lo probe varias veces y siempre salia el mismo problema cambiando los tiempos: a veces unos 5 minutos otras unos 3 y a veces mas de 7 u 8 minutos. Lo
del tiempo al que salia el fallo no era fijo.

Medi con el tester y luego con el oscilo la entrada de 5V. Limpia.
Cambie el cable entre el LCD y la placa por uno mas corto. Sigue saliendo el problema.
Cambie el LCD.....y se arreglo!!!. Estuvo mas de 40 minutos sin salir el fallo.
Volvi a conectar el LCD sospechoso y zas!. A los pocos minutos salio el mismo problema.

Cambie el LCD y despues de comprobar otra vez que no salia el fallo durante mas de 1 hora, me volvi.

Al llegar al laboratorio y probar el LCD ni siquiera sale nada desde el principio. Esta totalmente muerto.

Ahora me preocupa como se ha estropeado el LCD (se prueban todos los montajes antes de salir al cliente y este no tenia problema) pero, de momento, creo que puedo respirar durante un tiempo.

Gracias por la ayuda y los consejos. He aprendido bastante.

Título: Re:Luchando contra el ruido POR SOFTWARE
Publicado por: KILLERJC en 13 de Noviembre de 2015, 01:11:41
Bueno por lo menos era eso, asi que te salvaste xD..
Título: Re:Luchando contra el ruido POR SOFTWARE
Publicado por: bluesboy en 01 de Diciembre de 2015, 10:16:00
Les cuento, tal vez a alguno le sirva. Si es redundante o no sirve, le dejo al moderador la posibilidad de borrarlo o lo que le parezca.
Debo contarles del hardware primero.
Mucha de esta info esta en un link que saque de esta web que pueden buscar en google: pongan Ruidos MCUs. RECOMIENDO FUERTEMENTE LEERLO.
Hay extras de mi parte.

La mayoría de los problemas que tengo en mis aplicaciones son por bajas de tensión. El equipo, con su pic, esta siendo usado para automatizar o controlar alguna máquina y en gral esas máquinas tienen motores.
Algunos de mis clientes tienen instalaciones no calculadas, con lo cual, cuando sus motores se encienden, su cableado funciona como una gran resistencia, bajando la tensión, y dependiendo de como sea ese bajón, el equipo actua raro. Muy, pero muy pocas veces se resetea, les diria que me paso una vez sola, pero si pasa que actua erráticamente, por ej si esta contando piezas, cuenta una de mas.
Otras veces, usan motores de carbones. Una fuente de ruido perfecta, una porquería.

Bue, que hago: Por hard, una fuente lo mas filtrada posible. Viniendo desde la alterna:  fusible, varistor, filtro con dos capacitores 0,047uF y dos choque rf de 1 mHy, trafo, después del trafo capacitor de filtro 2200uF, luego 100 nF, luego choque rf 1mHy, capacitor 1500uF, regulador con 0,33uf entre In y masa y 0,1uf entre out y masa (ambos soldados directamente en las patas del regulador).
Si la aplicaión es crítica, por ej a veces tengo que contar tiempos con precisión, después del regulador y antes de alimentar al micro pongo un capacitor de 1 F (un faradio).
Entre las patas del micro, entre V+ y masa, un capacitor de bypas, en mi caso, como manejo 4 Mhz habitualmente, uso un capacitor de 33 nF, Todos los capacitores son muticapa.
Y todo esto con una salida a un borne para poner masa a tierra (una puesta a tierra como corresponde. Exclusiva, no quiero fallas de otras máquinas dañando mis equipos). Cuando hay mucho ruido, blindo todo y a masa).
Tengan en cuenta usar placas de fibra de vidrio si usan frecuencias de mas de 4 Mhz.

Por soft, como mis problemas son por baja tensión, picos de baja tensión, tengo un transistor polarizado de forma tal que cuando la tensión baja a 4V, la de alimentación, le manda un 1 a una patita del micro y eso hace que grabe todos los estados que me interesan en la eeprom. Entonces, cuando arranca el programa, lee esos estados y vuelve a empezar. Si al transistor se le da un buen ¨zapatazo¨ de corriente (sin quemarlo, pero sin escatimar) tiene velocidades de 100 Mhz, y eso usando uno común, BC327 o 337.
Para evitar que grabe datos sin sentido cuando se apaga la máquina, hay que poner un boton de ¨puesta a cero¨ para incializar. También se puede hacer que esto se haga solo con una mezacla de soft y hard. Depende del presupuesto del cliente.
Es molesto, pero es lo único que me ha servido para evitar el problema de los cortes de luz.

En otras ocasiones, para evitar ruido, si me da la velocidad, hago demoras en las entradas de los sensores, de forma tal que el dato entregado por el sensor este siendo ¨sensado¨ durante x cantidad de tiempo. Si el tiempo esta ok, entonces ese dato vale, sino, es ruido.
Un capacitor en la entrada de sensores en ambientes ruidosos colabora mucho.

Saludos.
Título: Re:Luchando contra el ruido POR SOFTWARE
Publicado por: bluesboy en 01 de Diciembre de 2015, 10:44:15
Me acordé de algo que tal vez pueda servir.
Antés, usaba relés para encender y apagar cargas en 220V, y aunque les agregaba una red snuber, igual metían ruido.
Lo solucione usando: Para continua, transistores.
                                   Para alterna, optotriac + triac y de ahí (fusible mediante) a la bobina de un contactor.

Se acabaron los ruidos por prender y apagar cosas.
Saludos.
Título: Re:Luchando contra el ruido POR SOFTWARE
Publicado por: proteus en 24 de Marzo de 2016, 03:14:26
Hola, muy interesante el hilo, Yo considero que lo principal es eliminar el ruido desde la fuente de este (voy a buscar información para compartir), para mí, el 99% de los problemas de ruido radican en el hardware, si allí no se ha solucionado, será practicamente imposible hacerlo por software.

Algo que acostumbro a hacer, es usar el WDT, pero cambio los tiempos de acuerdo a los procesos que se ejecutan, por ejemplo:

 setup_wdt(WDT_ON);
 setup_wdt(WDT_64S);      //~64 s reset
 do
 {
  printf("AT+CREG?");
  putc(0x0D); 
  Fin_comando=0;
  while(Fin_comando==0);
  procesa_comando();
 }while(Resp!=3);
 restart_wdt();
 setup_wdt(WDT_4S);      //~4 s reset
 restart_wdt();
 do
 {
  printf("AT");
  putc(0x0D); 
  Fin_comando=0;
  while(Fin_comando==0);
  procesa_comando();
 }while(Resp!=2);
 setup_wdt(WDT_OFF);
 printf("ATD>AD1;");
 putc(0x0D);
 do
 {
  Fin_comando=0;
  while(Fin_comando==0);
  procesa_comando();
 }while(Resp!=2);

Esto es una parte de un código para realizar una comunicación con un modem GPRS y hacer una llamada  :mrgreen:

En otros casos, además de esto, he colocado contadores dentro del proceso, así, en caso de que la rutina se haya realizado muchas veces, se sale de allí y regresa a un punto de control.

Como estoy con el PC recien formateado, debo buscar todo en el disco con la copia de seguridad, pero quedo pendiente de subir la información y de colocar el código que explique el segundo truco.

Gracias a todos!