Bucles call anidados.

[Azicuetano]

Hola a todos.

Vamos a ver si alguien se ve (o se ha visto en mi situación).

El diseño en el que trabajo ahora (con un PIC16f877 y en ASM) tiene, en relación al hadware,  unos cuantos botones y un Display LCD. Si hablamos de software tengo programadas unas cuantas interrupciones (flanco de bajada por RB0 etc. etc.)

Cual es el problema?? Pues que tengo que hacer verdaderas peripecias para programar y no pasarme anidando bucles call (se pueden anidar 8 como máximo).

Ejemplo. Le doy a un boton y me voy a un sistema de calibrado. Mientras el aparato se calibra tengo que detectar si pulsamos una tecla. dentro del pulsado de la tecla llamo a una rutina antirrebotes, que a su vez llama a un retardo.Puesto que ya tengo llenas las 2 primeras páginas del pic también tengo implementado un sistema de paginación que me gasta un call adicional. Ahora le metemos las llamadas de las interrupciones y... ufff... me veo un poco apurado reduciendo llamadas. Bastantes cosas tengo ya que programar como para tener que estar continuamente pendiente de los dichosos "call´s".

Alguien se ha visto en mi misma situación? Mi problema es normal o necesito hacer una programación más fina?

Gracias a todos por vuestro tiempo.

Un saludo desde Alicante.

[antoniof]

Buenas.

Tu problema de call"s se solucionaría bastante si el teclado lo manejaras con la interrupción por cambio de estado en RB4 ~ RB7, ya que no manejas el mismo por software bruto sino que lo tratas en su rutina de interrupción.

Después en la rutina de interrupción, utilizas los antirebotes.

De esta forma ahorrarás código, ya que no tienes que comprobar en dos sitios lo mismo, y ahorrarás niveles de la pila.

Por otra parte, la función de calibrado que comentas, parece muy importante como para estar en una subrrutina. La deberías programar con un "goto XXX". Si una subrrutina tiene más de 100 líneas, yo personalmente la prefiero poner dentro del programa principal con un "goto".

[Azicuetano]

Gracias por las sugerencias antoniof.

Es un consuelo saber que no soy el único que cada 2 por 3 se está peleando con los niveles de la pila.

Un saludo desde Alicante

[maunix]

Escrito originalmente por antoniofBuenas.
Si una subrrutina tiene más de 100 líneas, yo personalmente la prefiero poner dentro del programa principal con un "goto".

De nuevo opino que no tiene nada que ver eso de las 100 lineas o 400 lineas.....
yo tengo subrutinas de muchas lineas, que las llamo con CALL  porque son rutinas que hacen muchas cosas donde el código ppal las llama varias veces y no por eso hace falta un goto.  En ese caso un goto no es aplicable , por eso dar conceptos generalistas puede ser peligroso.  Ojo, solo doy mi opinión no te estoy criticando.
Mucha gente toma esos conceptos generalistas como "leyes" y luego los adopta para si y luego se ve enredado con algunos software donde utilizó gotos donde iba mejor un call solo por el hecho que la rutina tenia 100 lineas.

Escrito originalmente por antoniofBuenas.

Después en la rutina de interrupción, utilizas los antirebotes.

Por el contrario, yo siempre aconsejo a que las rutinas de interrupción sean pequeñas, para volver lo más bucle principal del programa.

No es bueno en casi ningun caso hacer delays en las rutinas de interrupción.

El consejo de las interrupciones, no es solo para los PICs.... es para cualquier microcontrolador o microprocesador y para cualquier sistema operativo.

Las interrupciones por concepto deben ser "breves" , "atender el problema" y devolver el control al software ppal.

[maunix]

Escrito originalmente por Azicuetano
Alguien se ha visto en mi misma situación? Mi problema es normal o necesito hacer una programación más fina?

Si, esto le ha pasado a cualquiera que ha hecho un software en pic + o - complicado.
La solución es siempre por software... si te pasa esto es porque o pretendes hacer un softwar que no se puede hacer con un PIC o estas organizando mal tu diagrama de flujo ppal del software.  En tu caso creo que la aplicación es bastante simple y debiera resolverse con un pic perfectamente.

El donde y como utilizar las interrupciones... pues depende de tu código... no suele ser bueno hacer "reglas generales" sobre conceptos que son tan específicos de cada código, lo que si es una regla general es que hagas las rutinas de interrupcion pequeñas, en lo más posible.

Para solucionar este problema, deberás ver que parte de tu código se llama desde el bucle principa y se la llama solo 1 vez.  Si se la llama solo una vez entonces es buen motivo para hacer un goto y volver desde la rutina con otro goto inmediatamente despues del goto que la llamó.

Esto es una técnica muy práctica.

Yo que tu revisaría el código, si quieres pudes postear algun diagrama de flujo de las ppales subrutinas para que te podamos ayudar mejor.

[antoniof]

Hola de nuevo.

Esta claro que si una rutina la llamas muchas veces dentro del programa principal, aunque tenga 1000 líneas, debes utilizar call"s. Con lo de las 100 líneas me refiero a que en mi caso particular, prefiero hacer subrrutinas muy breves. Por supuesto si no queda otra pues se hace mas grande. Cuando las subrrutinas se hacen breves se suelen evitar los call"s anidados y consumir niveles de pila.

Por otra parte, le he aconsejado que haga los antirrevotes y demás menesteres con el teclado en la rutina de interrupción. Me paso con un programa que controlaba un teclado y un menu en un LCD, que tube que repetir el scan de las teclas por software en tres sitios distintos del programa(Poner en hora el reloj, ajustar la alarma y en el bucle principal). Más tarde descubrí la interrupción por cambio de estado en RB4 ~ RB7 que está pensada para poder controlar un teclado por interrupción y no vuelvo a poner un teclado en un PIC si utilizarla

[Azicuetano]

Hola de nuevo.

Estoy de acuerdo que si a una subrrutina la vamos a llamar varias veces, evidentemente ha de hacerse con un call. De la misma forma... si a una subrrutina la llamo solo una vez, por supuesto, goto al canto.

La explicación que di de mi programa fué muy concisa pero... puesto que dentro del vector de interrupción lo que hago es controlar el ángulo de condución de 4 tiristores, para que no se me "vallan de varas" los ángulos no puedo poner los antirrebotes dentro de la rutina de interrupción (sino fuera así... habría hecho caso a antoniof con los ojos cerrados).

Nunca he dudado que la chorrada que estoy haciendo no se pueda hacer con un pic, de hecho, más que un problema era una duda (saber si era normal que tubiera tantas complicaciones con los niveles de la pila).

Aprendí a programar en C por placer hace ya muchos años (demoscene en 2 y 3D) y tengo la mente demasiado abstraida hacia este lenguaje. De todas formas, ya he reestructurado el programa y ahora la cosa va de perlas.

Gracias a ambos por vuestra molestia.

Un saludo desde Alicante.

[antoniof]

Hay un truco para los antirrebotes.

Puesto que debes controlar el ángulo de disparo de los tiristores, tendrás la interrupción del timer activada.
Pues bien, una forma muy simple de evitar los rebotes es, dentro de la rutina de tratamiento de la ointerrupción del teclado, desactivas dicha interrupción poniendo el bit RBIE a cero y, dentro de la rutina de tratamiento de la interrupción del timer, borras el flag RBIF y activas de nuevo la interrupción RBIE, cuando a ti te convenga, es decir, si quieres un antirrebotes de 10ms y el timer salta cada 1ms, puies con un contador, de que llege a 10 activas el RBIE.

Yo he utilizado este método y funciona a la perfección. No se pierde nada de tiempo en la captura de datos del teclado y se obtiene el tiempo de antirrebotes deseado.

[Azicuetano]

Un truco buenísimo ejecutado con una excelente explicación antoniof... excelente.

Un saludo desde Alicante.