Duda con punteros en C18(Solucionado)

[manwenwe]

Hola, me gustaría hacer algo como lo siguiente:

Código: [Seleccionar]


void funcion1(void){

int8 a = 5;
funcion2(&a);

}

void funcion2(int8 *b){

(*b)++;
funcion3(*b);

}

void funcion3(int8 c){

.
.
.

}


Cuando paso la  direccion de la variable "a"     a la funcion 2 y esta incrementa el puntero "*b" (en realidad incrementa "a" ) no tengo ningun problema. El caso es que cuando le paso *b a la funcion3 esta no coge el valor que debería("a")... No se muy bien porque es, ya que se lo justo sobre punteros; en cambio he hecho esto mismo en ANSI C y no he tenido ningún problema, en cambio en C18 no lo consigo...

¿Sabría alguien decirme  la forma de igualar el puntero de la función 2 a un entero para poder pasarselo a la función 3 sin que "me reviente" el programa?

Gracias de antemano!

PD. Lo que quiero hacer no es justamente lo que puse en las funciones: es un poco absurdo... ya lo se . Las funciones hacen más cosas... lo expliqué a si para simplificarlo...

Saludos a tod@s!

[maunix]

Amigo, probé tu código con C18 y anda perfecto.  Eso sí, tuve que adaptar algunas cosas ya que INT8 no existe en  C18.

En funcion3 c vale 6.

Saludos

[manwenwe]

Gracias por las molestias maunix.

Estoy contigo, si copio el código tal cual en C18 este funciona sin problema y c=6 en func3. La cosa está en que mis funciones realmente no son estas: las que puse simplemente expresan lo que quiero hacer con 3 funciones:

1ª pasa puntero a 2ª.
2ª modifica contenido del puntero
2ª pasa contenido del puntero a 3ª

En mis funciones reales si que me ha funcionado varias veces. El problema está es que cuando añado más código(sin tocar ninguna de las tres funciones mencionadas), deja de funcionar y la función 3 no recibe el valor que debe. Lo se porque intento visualizarlo por un LCD y este se vuelve literalmente loco???

En la realidad las funciones 1 y 2 están declaradas muy cerca dentro del mismo archivo. En cambio las funciones 2 y 3 están a unas 2000 lineas de código(en C) de distancia dentro del mismo archivo. Comento todo esto porque no tengo ni idea de como compila C18 y de si aloja las variables en memoria según se las va encontrando.

Tampoco tengo ni idea de que problemas con el direccionamiento me puedo encontrar. Hasta ahora, no he tenido ningun problema de direccionamiento pasando argumentos por valor. Pero no se que problemas se pueden dar al pasarlos por referencia...

Como podeis ver estoy bastante perdido .

¿Alguna idea al respecto?

Gracias!

[manwenwe]

Finalmente solucioné el problema. Creo que era debido a que excedia la capacidad de la pila. Cambíe single-bank model por multi-bank model en las "build options" y ahora funciona bien. ¿Podría alguien explicarme la diferencia entre single y multi bank model y la relación que tienen con la pila... no lo entiendo muy bien...

Saludos!

[Trev_11]

Yo haria lo siguiente:asignaria y=*b++;
int y;
void funcion1(void){

int8 a = 5;
funcion2(&a);

}

void funcion2(int8 *b){

y=(*b)++;
funcion3(&y);

}

void funcion3(int8 c){

.
.
.

}
nunca lo vi como lo haces tu,creo ke primero se debe cargar la direccion del dato en *b para luego poder tener acceso al dato a traves de su puntero con *b

[manwenwe]

Hola Trev_11, ya comenté que el problema está solucionado y creo que era debido a sobrepasar la pila. Como tu lo haces creo que no funcionaría porque lo que hay que pasarle a la funcion3 es el contenido de un puntero(un entero), en cambio tu estás igualando el contenido de un puntero a un entero y pasando un puntero a un entero cuando el argumento de la funcion3 es un entero, por lo que recibirias una direccion no un dato...

Saludos!

[Trev_11]

Tienes razon me la morfe  :Desto seria valido si a tu funcio3 le pasaras el parametro por referencia,entonces creo ke si,saludos

[maunix]

Finalmente solucioné el problema. Creo que era debido a que excedia la capacidad de la pila. Cambíe single-bank model por multi-bank model en las "build options" y ahora funciona bien. ¿Podría alguien explicarme la diferencia entre single y multi bank model y la relación que tienen con la pila... no lo entiendo muy bien...

Saludos!

Justamente te iba a apuntar a un problema de  pila, me alegra que lo hayas solucionado.

En cuanto al modelo de single y multibank bueno, esto hace que el compilador use el registro FSRnL y FSRnH (no recuerdo pero creo que es el FSR2) para las indexaciones de la pila.  Eso hace que todas las operaciones sean más lentas y que ocupe más código por eso viene deshabilitado por defecto.

A modo de aclaración, que ubiques el código junto a otro , o a 2000 líneas por debajo no tiene nada que ver con el problema que planteas.  Podrías tener 2 códigos pegados que usen variables locales de decenas de bytes y que te aparezca el mismo problema. 

No hay warning ni nada por el estilo en tiempo de ejecución de estas cuestiones porque en caso de error , no hay a donde ir... no hay sistema operativo al cual recurrir si el software 'tiene una excepción'.... 

De todas formas, te comento que tener variables muy grandes que sean locales a las funciones no es buena idea en un microcontrolador... son alguna de las costumbres que conviene desterrar si uno viene del entorno de las PCs.

Saludos

[manwenwe]

Hola,

En cuanto al modelo de single y multibank bueno, esto hace que el compilador use el registro FSRnL y FSRnH (no recuerdo pero creo que es el FSR2) para las indexaciones de la pila.  Eso hace que todas las operaciones sean más lentas y que ocupe más código por eso viene deshabilitado por defecto.

Trabajo con un PIC de 64KB y apenas me queda un 10% de memoria libre, por lo que sunpongo que era cuestión de tiempo el tener problemas con el "banking". Si es cierto que el código es un poco más grande y la ejecución un poco más lenta... quizá un 10% más lenta pero ya que tengo el reloj a 40Mhz no es algo crítico en mi caso.

A modo de aclaración, que ubiques el código junto a otro , o a 2000 líneas por debajo no tiene nada que ver con el problema que planteas.  Podrías tener 2 códigos pegados que usen variables locales de decenas de bytes y que te aparezca el mismo problema.

Mi di cuenta en cuanto "fui de listo" y probé a pegar el código de las funciones de forma seguida con idéntico resultado .

A modo de aclaración, que ubiques el código junto a otro , o a 2000 líneas por debajo no tiene nada que ver con el problema que planteas.  Podrías tener 2 códigos pegados que usen variables locales de decenas de bytes y que te aparezca el mismo problema.

Está claro que no se le puede pedir a C18 un sistema de manejo de excepciones tipo compilador POO, pero no estaría de más que al menos el compilador te avisara de la posibilidad de sobrepasar la pila... por pedir que no quede XD.

De todas formas, te comento que tener variables muy grandes que sean locales a las funciones no es buena idea en un microcontrolador... son alguna de las costumbres que conviene desterrar si uno viene del entorno de las PCs.

Estoy contigo aunque pienso que es muy dificil manejar variables globlales en un código amplio: muchas veces "te explota" el programa por donde menos te lo esperas y la mayoria de las veces, al menos en mi caso, es debido a despistes con las variables globales. De hecho pienso eliminar todas las que pueda y utilizar el paso de punteros como argumentos entre funciones. No creo que esto sea lo mejor para el tamaño del código y la velocidad de ejecución, pero creo que a veces compensa más tener un código más "limpio" y facil de depurar.

Muchas gracias por tu aclaraciones maunix.

Saludos!

[maunix]

Está claro que no se le puede pedir a C18 un sistema de manejo de excepciones tipo compilador POO, pero no estaría de más que al menos el compilador te avisara de la posibilidad de sobrepasar la pila... por pedir que no quede XD.

El problema es que estos sobreexcesos se dan en tiempo de ejecución no de compilación.  El compilador podría hacer algo para detectar estas cuestiones pero tampoco sería una buena solución.  Si tu código llama a una función que llama a otra función, pero todas estas llamadas están sujetas a condicionantes que puedan o no darse, entonces el compilador no tiene forma de saberlo.  Solo en tiempo de ejecución se darán

De todas formas, te comento que tener variables muy grandes que sean locales a las funciones no es buena idea en un microcontrolador... son alguna de las costumbres que conviene desterrar si uno viene del entorno de las PCs.

Estoy contigo aunque pienso que es muy dificil manejar variables globlales en un código amplio: muchas veces "te explota" el programa por donde menos te lo esperas y la mayoria de las veces, al menos en mi caso, es debido a despistes con las variables globales. De hecho pienso eliminar todas las que pueda y utilizar el paso de punteros como argumentos entre funciones. No creo que esto sea lo mejor para el tamaño del código y la velocidad de ejecución, pero creo que a veces compensa más tener un código más "limpio" y facil de depurar.

Soy amigo de las variables locales, entiendaseme bien.  Una variable local si es para algo local, resuelve el problema puntual y santa solución.

Tampoco tendrías problemas si tuvieras muchas variables locales, el problema son las llamadas 'anidadas' de funciones como explique antes.  Lo que digo de evitar son grandes buffers como variables locales y en un microcontrolador

En la PC "a veces" también es conveniente evitar un gran buffer local, pero eso ya es otra historia. 

No soy amigo de dictar leyes absolutas sobre qué hacer siempre siempre en todo los casos porque no creo que sea aplicable a todos los casos.  Opino que siempre hace falta el criterio del programador , porque cada caso en particular tiene sus particularidades (valga la redundancia) y es allí donde uno debe decidir y darse cuenta qué conviene más o menos en cada caso. 

De todas forams me alegro que lo hayas solucionado