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

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

Desconectado LABmouse

  • Moderadores
  • DsPIC30
  • *****
  • Mensajes: 3575
    • Juntos es mejor
Re: Luchando contra el ruido POR SOFTWARE
« Respuesta #30 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.

Desconectado Leon Pic

  • Colaborador
  • DsPIC30
  • *****
  • Mensajes: 3610
    • Impresiones en 3D
Re: Luchando contra el ruido POR SOFTWARE
« Respuesta #31 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.  :-/ :-/
Jesús dijo, yo soy el CAMINO, la VERDAD y la VIDA, nadie llega al PADRE si no es por mi.

Desconectado El_Guitre

  • Colaborador
  • PIC24H
  • *****
  • Mensajes: 1046
Re: Luchando contra el ruido POR SOFTWARE
« Respuesta #32 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.

Desconectado Nocturno

  • Administrador
  • DsPIC33
  • *******
  • Mensajes: 18269
    • MicroPIC
Re: Luchando contra el ruido POR SOFTWARE
« Respuesta #33 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.

Desconectado El_Guitre

  • Colaborador
  • PIC24H
  • *****
  • Mensajes: 1046
Re: Luchando contra el ruido POR SOFTWARE
« Respuesta #34 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?.

Desconectado RedPic

  • Administrador
  • DsPIC33
  • *******
  • Mensajes: 5538
    • Picmania by Redraven
Re: Luchando contra el ruido POR SOFTWARE
« Respuesta #35 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. }

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

« Última modificación: 15 de Septiembre de 2007, 04:57:15 por RedPic »
Contra la estupidez los propios dioses luchan en vano. Schiller
Mi Güeb : Picmania

Desconectado Leon Pic

  • Colaborador
  • DsPIC30
  • *****
  • Mensajes: 3610
    • Impresiones en 3D
Re: Luchando contra el ruido POR SOFTWARE
« Respuesta #36 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.  :-/ :-/
   
Jesús dijo, yo soy el CAMINO, la VERDAD y la VIDA, nadie llega al PADRE si no es por mi.

Desconectado Azicuetano

  • Moderadores
  • PIC24H
  • *****
  • Mensajes: 1020
    • Aplicaciones Electrónicas en Alicante.
Re: Luchando contra el ruido POR SOFTWARE
« Respuesta #37 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.

Desconectado Nocturno

  • Administrador
  • DsPIC33
  • *******
  • Mensajes: 18269
    • MicroPIC
Re: Luchando contra el ruido POR SOFTWARE
« Respuesta #38 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.

Desconectado RedPic

  • Administrador
  • DsPIC33
  • *******
  • Mensajes: 5538
    • Picmania by Redraven
Re: Luchando contra el ruido POR SOFTWARE
« Respuesta #39 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:





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

« Última modificación: 15 de Septiembre de 2007, 15:06:23 por RedPic »
Contra la estupidez los propios dioses luchan en vano. Schiller
Mi Güeb : Picmania

Desconectado LABmouse

  • Moderadores
  • DsPIC30
  • *****
  • Mensajes: 3575
    • Juntos es mejor
Re: Luchando contra el ruido POR SOFTWARE
« Respuesta #40 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.





Desconectado dogflu66

  • Moderadores
  • DsPIC30
  • *****
  • Mensajes: 3495
Re: Luchando contra el ruido POR SOFTWARE
« Respuesta #41 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.
Saludos desde Granada, España.

Desconectado MGLSOFT

  • Moderador Local
  • DsPIC33
  • *****
  • Mensajes: 7907
Re: Luchando contra el ruido POR SOFTWARE
« Respuesta #42 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:
Todos los dias aprendo algo nuevo, el ultimo día de mi vida aprenderé a morir....
Mi Abuelo.

Desconectado Leon Pic

  • Colaborador
  • DsPIC30
  • *****
  • Mensajes: 3610
    • Impresiones en 3D
Re: Luchando contra el ruido POR SOFTWARE
« Respuesta #43 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.  :-/ :-/
Jesús dijo, yo soy el CAMINO, la VERDAD y la VIDA, nadie llega al PADRE si no es por mi.

Desconectado maunix

  • Moderadores
  • DsPIC33
  • *****
  • Mensajes: 4751
    • Mi Sitio Web Personal
Re: Luchando contra el ruido POR SOFTWARE
« Respuesta #44 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
- La soberbia de un Einstein es entendible.. la de un salame es intolerable (A.Dolina)
- En teoría no hay diferencia entre la teoría y la práctica. En la práctica... si la hay.
- Lee, Lee, Lee y luego pregunta.(maunix)
- Las que conducen y arrastran al mundo no son las máquinas, sino las ideas (V. Hugo)
- Todos los hombres se parecen por sus palabras; solamente las obras evidencian que no son iguales.(Moliere)
- Todo debería ser hecho tan simple como sea posible pero no mas simple que eso.(A.Einstein)


 

anything