Variables cambian de valor misteriosamente

[El_Coach]

Hola 

¿Es posible que una variable local se vea afectada por otras funciones ajenas?
Es que tengo una función en la que llamo a otras, pero al volver, hay una variable que me cambia de valor sin sentido alguno... sin pasarla ni siquiera como argumento. He hecho mil pruebas y he llegado a la conclusión de que es un bug del compilador.
He buscado en el foro pero no encontré nada acerca de esto.
Lo he intentado poniendo  #separate antes de cada función, pero sigue sin funcionarme.
Aunque tampoco tengo muy claro lo que hace la directiva #separate, en la ayuda lo explica, pero sigo sin entender lo que hace, cual es su finalidad.

Por cierto... utilizo la ultima versión del compilador de CCS (3.249) y el PIC es un 16F688.


Saludos!

[maunix]

¿Es posible que una variable local se vea afectada por otras funciones ajenas?

Claro, una memoria es eso , "una memoria".  El que tu definas una memoria en una funcion como local, no implica que dicha memoria no esté por ejemplo ubicada en la posición 0xF0 de la RAM.

Si tu 'otra' rutina modifica esa posición de memoria porque usas un puntero... entonces seguro lo puedes hacer.  Aquí no hay páginas 'protegidas' por un sistema operativo.

Es que tengo una función en la que llamo a otras, pero al volver, hay una variable que me cambia de valor sin sentido alguno... sin pasarla ni siquiera como argumento. He hecho mil pruebas y he llegado a la conclusión de que es un bug del compilador.

Pudiera ser, aunque lo veo raro.  Es lo primero que un diseñador de compiladores se fija. 

Es decir, no creo que sea un 'bug del compilador' a lo sumo le debes incrementar la pila (que supongo CCS tendrá una opción para hacerlo) porque la pila se ve incrementada cuantas más funciones anidadas tengas.

Saludos

[vszener]

¿podrias poner la funcion? ¿las variables son locales o globales?


Suerte!!!

[BrunoF]

Hola vszener.

Una variable local, es una variable que se utiliza solo en una sub-rutina. La posicion de memoria se reserva para dicha variable cuando ingresa a la sub-rutina, y la posicion de memoria se libera cuando se sale de la misma(de la sub-rutina).
Por lo tanto, si vos definis una variable como local, se ejecuta la sub-rutina, y luego se ejecutan otras rutinas y luego intentas leer la variable que habias definido como local, es muy probable que el valor se haya adulterado ya que declaradola como local, le dijiste al compliador que esa posicion de memoria queda libre para otras rutinas, las cuales tienen,de ese modo, acceso a modificar su valor.

Las variables globales, por el contrario, permiten que el complilador te asegure que la posicion de memoria asignada a la variable se exclusiva de la misma, por lo que, bajo programacion normal, las demas rutinas no tendran acceso a la misma.

Ejemplo de variable local:

#include <16f648a.h>            //pic a utilizar         
#fuses XT,NOWDT,NOPROTECT,PUT,NOLVP      //ordenes para el programador
#use delay (clock=4000000)         //Fosc=4Mhz
#use standard_io(B)               //puerto B como salida

///PROGRAMA
void main(void)
{
   int i,cont;                  //variables definidas
   //Codigo aqui
}

Ejemplo de variable global:

#include <16f648a.h>            //pic a utilizar         
#fuses XT,NOWDT,NOPROTECT,PUT,NOLVP      //ordenes para el programador
#use delay (clock=4000000)         //Fosc=4Mhz
#use standard_io(B)               //puerto B como salida

int i,cont;                  //variables definidas

///PROGRAMA
void main(void)
{
   //Codigo aqui
}

Saludos!

[vszener]

Jeje perfecta explicacion BrunoF!!!jeje bueno, yo le preguntaba al amigo El_Coach sobre que tipo de variables habia definido para cuando contestara darle una explicacion similar a la tuya, pero ya no hace falta!jeje Por eso le he preguntado como ha definido la variable 'misteriosa'....


Suerte!!!

[BrunoF]

Uhh jaja perdona vszener! le pifie al usuario! jaja eso iba para El_Coach, no para vos...
Perdona el error.
Saludosss!!

[maunix]

Por lo tanto, si vos definis una variable como local, se ejecuta la sub-rutina, y luego se ejecutan otras rutinas y luego intentas leer la variable que habias definido como local, es muy probable que el valor se haya adulterado ya que declaradola como local, le dijiste al compliador que esa posicion de memoria queda libre para otras rutinas, las cuales tienen,de ese modo, acceso a modificar su valor.

Bruno, no me queda claro lo que dices con que una variable cuando es local , cuando se llama a otra subrutina se haya adulterado. 

En mi opinión, si una variable es local y la llamas de un lugar donde no esté declarada, el COMPILADOR debiera dar error y no lo veo un problema.

Esa 'reserva' se hace en tiempo real y por eso los compiladores de C usan un stack por software, es ahí donde se guardan las variables locales cuando se llama a otra subrutina.  De la misma forma, es el stack el que se usa para guardar los 'parámetros' al llamar a subrutinas.

Las variables globales, por el contrario, permiten que el complilador te asegure que la posicion de memoria asignada a la variable se exclusiva de la misma, por lo que, bajo programacion normal, las demas rutinas no tendran acceso a la misma.

Nuevamente, en mi opinión, si uno usa un puntero sí tiene acceso a dicha memoria por mas que sea global ó local.

La misma no está "protegida" cuando se ejecuta el programa, simplemente el compilador no asignará otra variable en dicha posición cuando "compila"  lo cual no signfica que no la podamos acceder a ella o sobreescribirla "de otra forma".

De todas formas, como he dicho antes, tal vez te mal interpreto o yo estoy confundido pero no me ha quedado claro tu post.


Saludos

[BrunoF]

Maunix respondiendo a la primer parte, y puede que este equivocado, me referia a que una vez que el programa en tiempo real ha salido de la subrutina, el compilador libera esa posicion de memoria para poder ser utilizada en caso de necesitar memoria por otra subrutina.
No quiere decir que necesariamente se haya adulterado, quiero decir que puede que se haya adulterado si el compilador utilizo esa posicion de memoria para otra subrutina.
Ni mencioné llamar a una rutina local desde una subrutina que no corresponde.
Puede que el CCS sea distinto, no lo se.

Respecto al segundo punto:
Releyendo mi post podes ver que aclaré: "bajo programacion normal", eso implicaba no hacer justamente lo que mencionas.

Saludos

[maunix]

Maunix respondiendo a la primer parte, y puede que este equivocado, me referia a que una vez que el programa en tiempo real ha salido de la subrutina, el compilador libera esa posicion de memoria para poder ser utilizada en caso de necesitar memoria por otra subrutina.

Bruno, en esto estamos de acuerdo, el punto es que por ejemplo si tenemos a la rutina A, que llama a la rutina B, al volver de la rutina B, las variables de A no debieran porqué cambiar que es lo que pone nuestro amigo Coach en su post.

No quiere decir que necesariamente se haya adulterado, quiero decir que puede que se haya adulterado si el compilador utilizo esa posicion de memoria para otra subrutina.
Ni mencioné llamar a una rutina local desde una subrutina que no corresponde.
Puede que el CCS sea distinto, no lo se.

Queda la posición liberada en el stack y seguramente será sobreescrita.  Es más tampoco hay garantías de que al llamar de nuevo a la misma subrutina se use exactamente la misma posición de memoria. 

Ahora si nuestro amigo Coach no inicializa sus variables al ingresar en la subrutina tampoco puede esperar que se mantengan (esto sería pregunta hacia él).

Respecto al segundo punto:
Releyendo mi post podes ver que aclaré: "bajo programacion normal", eso implicaba no hacer justamente lo que mencionas.

Es que el uso de punteros es muy común en C, no lo veo como "anormal", de hecho debe ser el lenguaje de alto nivel que más los utiliza. 

El punto es que yo expuse es que podria ocurrir que un puntero (lo cual a mi entender es programación normal y tradicional de C) se mal utilice por un error en el código en sí (apuntando a otro lado) y no en el compilador en sí.


El_Coach, esta parte va para tí:  puedes exponer más claramente tu problema? Con un ejemplo de como es tu código y que problema tienes?

Saludos

[jfh900]

El CCS es un compilador peculiar por que sirve para programar un micro que es peculiar y cual es la peculiaridad, pues que no tiene casi stack, de echo el número de subrutinas anidadas que se puede realizar es pequeño. Esto como afecta al funcionamiento de las variables?, pues que todas son declaradas en la memoria ram. Si la programación es limpia y no hacemos cosas raras las variables no deben de cambiar. Pero si accedemos directamente a memoria, o declaramos una variable local y la utilizamos de forma global o declaramos una variable local y la devolvemos como valor de una función, pues nos encontraremos con cosas raras. El_Coach una cosa importante si quieres que te demos respuestas mas concretas debes de aportar el código que te esta fallando, si no solo podremos elocubrar posibles errores.

Un saludo.

[maunix]

El CCS es un compilador peculiar por que sirve para programar un micro que es peculiar y cual es la peculiaridad, pues que no tiene casi stack, de echo el número de subrutinas anidadas que se puede realizar es pequeño. Esto como afecta al funcionamiento de las variables?, pues que todas son declaradas en la memoria ram. Si la programación es limpia y no hacemos cosas raras las variables no deben de cambiar. Pero si accedemos directamente a memoria, o declaramos una variable local y la utilizamos de forma global o declaramos una variable local y la devolvemos como valor de una función, pues nos encontraremos con cosas raras. El_Coach una cosa importante si quieres que te demos respuestas mas concretas debes de aportar el código que te esta fallando, si no solo podremos elocubrar posibles errores.

Un saludo.

jfh900 creo que las limitaciones que comentas son así para cualquier compilador embedded o no.  El stack nunca es 'infinito'.

Más allá de las "peculiaridades" del CSS (principal razón por la cual no lo uso) creo que no se debiera cambiar ninguna variable por más que usemos muchas subrutinas anidadas.  Si hay un desbordamiento del stack, debiera haber un "warning" que indique esto durante la compilación, no es algo tan complicado si la anidación es "obvia" al punto de ser una función a, que llama a la b, que a su vez llama a la c.  De hecho en el C18 es posible aumentar/disminuir el tamaño del stack.

Otra cuestión es que si uno accede a una variable global dentro de una subrutina, a lo sumo se generará algo más de código si es que dicha variable global está en una página diferente a las variables de la subrutina pero no veo porqué se deban sobreescribir.

Más aún, no me ha quedado claro lo siguiente y quisiera detenerme en la siguiente frase:

"declaramos una variable local y la utilizamos de forma global o declaramos una variable local y la devolvemos como valor de una función"


Y he aquí mis dudas:

1) ¿Cómo haces para acceder a una variable local en forma global? ¿Acaso si la llamas no te da error?

2) Devolver una variable local como resultado de una función es la cosa más común que he visto en mi vida, salvo que uno en las funciones solo devuelva "constantes" en cuyo caso no le veo la gracia.


Saludos

[jfh900]

Hola maunix:

Empiezo por la ultima parte. Si declaras una variable como local y la devuelves es una incongruencia, como tu bien has dicho sobre todo si esta en el stack deja de existir, con lo que tendra que ser devuelta por valor y no por referencia, de echo hay compiladores que dan error con esta técnica. En cuanto al tamaño del stack, los pic de la gama baja y de la gama media su stack es muy limitado, por ejemplo el 16F84 solo tiene 8 posiciones o byte`s en el stack, como comprenderas no hay mucho sitio para llamadas a funciones y creación de variables locales. En cuanto a la creación de variables locales dentro de funciones CCS las implementa en la memoria y son reutilizadas por varias variables locales en distintas funciones al objeto de optimizar la utilizacion de la memoria. En cuanto a la utilizacion del compilador C18 no lo he utilizado y por consiguiente no puedo opinar de como trabajara.

Un sa ludo.

[maunix]

Hola maunix:

Empiezo por la ultima parte. Si declaras una variable como local y la devuelves es una incongruencia, como tu bien has dicho sobre todo si esta en el stack deja de existir, con lo que tendra que ser devuelta por valor y no por referencia, de echo hay compiladores que dan error con esta técnica. En cuanto al tamaño del stack, los pic de la gama baja y de la gama media su stack es muy limitado, por ejemplo el 16F84 solo tiene 8 posiciones o byte`s en el stack, como comprenderas no hay mucho sitio para llamadas a funciones y creación de variables locales. En cuanto a la creación de variables locales dentro de funciones CCS las implementa en la memoria y son reutilizadas por varias variables locales en distintas funciones al objeto de optimizar la utilizacion de la memoria. En cuanto a la utilizacion del compilador C18 no lo he utilizado y por consiguiente no puedo opinar de como trabajara.

Un sa ludo.

Lo de las 8 posiciones es una limitante del hardware, pero yo hablaba del stack del compilador C y no del pic en sí.

Más allá de eso, en las optimizaciones del compilador cuando una rutina que se utilice una sola vez, debiera ser optimizada por el compilador como un 'goto' y no como un 'call'.

De todas formas, a ver si nos entendemos

1) Tu dices "Si declaras una variable como local y la devuelves es una incongruencia"

Esto te parece una incongruencia?

Código: C

1. char func_a(void)
2. {
3.    char a;
4.  
5.    a = 20;
6.    return (a);
7. }
8.  
9. // y la llamo como
10.  
11. main() {
12.    myvar = func_a();
13. }

2) Acaso no sería lo mismo que hacer

Código: C

1. char func_a(void)
2. {
3.    return ((char) 20);
4. }
5.  
6. // y la llamo como
7.  
8. main() {
9.    myvar = func_a();
10. }

Con la diferencia que en la primera opción antes de devolver el dato se hace un 'copy' de la variable a la posición donde debe devolverse el parámetro (esto es algo que lo maneja el compilador de todas formas está bien documentado en el C18 cuales registros son).


3) Haciendo al llamada por referencia:

Código: C

1. func_a(char *a)
2. {
3.    *a = 20;
4. }
5.  
6. y la llamo como
7.  
8. main() {
9.    func_a(&myvar);
10. }

¿Estas opciones te parecen que estan mal o que el compilador te debiera tirar error?

Si estoy mal interpretando tu post, ¿podrias poner un código de ejemplo?

Saludos

[El_Coach]

En primer lugar disculparme por responder tan tarde, no pude antes.
También decir que el pic que utilizo aquí es el 18F2520, me confundí con otro que también utilizo.
El proyecto en el que estoy trabajando trata sobre una red inalámbrica de sensores.
En esta red exite un dispositivo maestro y hasta 31 esclavos, es decir un total de 32 nodos.
La función en concreto se encarga de comprobar qué esclavos se encuentran en el área de cobertura de la red.
Para ello envía un mensaje de comprobación uno a uno, esto lo hace la rutina recibir_actividad, la que devuelve un 1 si el esclavo está activo y un 0 si no lo está.
El progreso de la comprobación lo muestro en una línea de un LCD de 2x16, mostrando cada dos comprobaciones el caracter 0xFF, al estilo de las barras que te muestran el progreso de instalación de un programa.
Finalmente devuelve un entero de 32 bits en el cual están a cero los bits correspondientes a las direcciones inactivas y a uno las que estan activas.

Este es mi código:

Código: [Seleccionar]

int32 comprobar_esclavos( int origen )
{
int32 esclavos = 0;
int destino, i;

destino = origen & 0xE0; // Se prepara la primera dirección a comprobar, conservando los bits de red (los 3 msb)

for( i = 0 ; i < 32 ; i++ ) // Se comprueba la actividad de los esclavos uno a uno, poniendo a 1 el bit
{ // correspondiente de "esclavos", indicando así su actividad.
if( destino != origen )
{
if( recibir_actividad( destino, origen ) )
bit_set( esclavos , i );
}
else
bit_set( esclavos , i );

if( i%2 ) // Sirve para mostrar en el lcd el progreso del test cada 2 comprobaciones (nums impares)
lcd_putc( 0xFF );

destino++;
}

return( esclavos );
}


El problema me ocurre cuando la dirección origen es 0x00, la dirección destino  tomaba el valor 0x00 cada 2 comprobaciones, así que me quedaba la variable esclavos=0b10101010101010101010101010101010
Poniendo cualquier otra dirección origen, como 0x3F, ya no me ocurre.
Despues de hacer muuuchas pruebas, conseguí evitar esto simplemente borrando la línea:

Código: [Seleccionar]

if( i%2 )
lcd_putc( 0xFF );
En teoría no debería influir en nada, pero así sí que funciona
Ahora en vez de mostrar una barra de progreso, muestro el porcentaje del proceso, así:

Código: [Seleccionar]

n = i * 3.15;
printf( lcd_putc, "\n      %02u%%", n );
Esto lo hago declarando n=0 al principio de la función, claro está.
Eso es todo, muchas gracias a todos los que me habeis intentado ayudar.
Ojalá este post le sirva a la gente para aclarar sus dudas acerca de las características de las variables.
De todos modos agradecería si alguien pudiera explicarme cual es la finalidad de la directiva #separate, no lo que hace, sino para que nos sirve.

De nuevo gracias a todos.

Un saludo 

[jfh900]

Estamos diciendo lo mismo, si lee mi post veras que digo en primer lugar devolver la variable y no su valor y en sugundo lugar hago referencia a devolverlo por valor y no por referencia, así que decimos lo mismo. La incongruencia es:

char func_a(void)
{  
   char a;    
   a = 20;  
   return (&a);
}

La segunda opción que pones es perfectamente válida la llamada a una función con parámetros por referencia, ademas es la unica forma de poder pasar variables y modificarlas desde una función.

Un saludo