Autor Tema: Puedo dañar un PIC poniendolo a que se haga el mismo el reset?  (Leído 15341 veces)

0 Usuarios y 2 Visitantes están viendo este tema.

AABHGA

  • Visitante
Re: Puedo dañar un PIC poniendolo a que se haga el mismo el reset?
« Respuesta #15 en: 19 de Septiembre de 2006, 01:00:10 »
Muy bien, si bien desperdicias un pin al menos estás seguro que será un reinicio "limpio" pero cuidado con lo que hagas con el pin en cuestión ni bien se inicia el software.

Si, en el proyecto es el único pin del PORTA que me quedaba libre y como me gusta el orden, cada dispositivo en un bloque de puertos, entonces lo usé para eso, solo hay 2 secuencias de reset en el programa, y ambas son llamadas solo cuando el usuario lo requiera.

Desconectado maunix

  • Moderadores
  • DsPIC33
  • *****
  • Mensajes: 4751
    • Mi Sitio Web Personal
Re: Puedo dañar un PIC poniendolo a que se haga el mismo el reset?
« Respuesta #16 en: 19 de Septiembre de 2006, 08:22:46 »
Muy bien, si bien desperdicias un pin al menos estás seguro que será un reinicio "limpio" pero cuidado con lo que hagas con el pin en cuestión ni bien se inicia el software.

Si, en el proyecto es el único pin del PORTA que me quedaba libre y como me gusta el orden, cada dispositivo en un bloque de puertos, entonces lo usé para eso, solo hay 2 secuencias de reset en el programa, y ambas son llamadas solo cuando el usuario lo requiera.

Me refería a que ni bien se reinicie el pic (donde los pines están como entrada), no hagas la clásica de poner el pin como salida y hacer un PORTA=0 o similar.

Eso te pondrá el pin en 0 hasta que lo pongas de nuevo en 1.  Dependiendo de cómo tienes hecho tu circuito, eso puede hacer que si no tienes un capacitor lo suficientemente grande en el pin MCLR tengas casualmente problemas con esto.

Era ese comentario nomás. 

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)

Desconectado elmasvital

  • Administrador
  • PIC24H
  • *******
  • Mensajes: 1713
Re: Puedo dañar un PIC poniendolo a que se haga el mismo el reset?
« Respuesta #17 en: 20 de Septiembre de 2006, 13:39:13 »
una pregunta tonta manuix... desde el desconocimiento dices que goto 000 no vacia el stack. Normalmente cuando un pic inicia su actividad se dedica a borrar todas las pilas que tiene en memoria?. Tenia entendido que cualquier componente de memoria contenia basura al arrancar.

1 saludo

Desconectado maunix

  • Moderadores
  • DsPIC33
  • *****
  • Mensajes: 4751
    • Mi Sitio Web Personal
Re: Puedo dañar un PIC poniendolo a que se haga el mismo el reset?
« Respuesta #18 en: 20 de Septiembre de 2006, 17:57:33 »
una pregunta tonta manuix... desde el desconocimiento dices que goto 000 no vacia el stack. Normalmente cuando un pic inicia su actividad se dedica a borrar todas las pilas que tiene en memoria?. Tenia entendido que cualquier componente de memoria contenia basura al arrancar.

1 saludo

A ver, vamos por partes

Hacer goto 000 es simplemente hacer que el PC = 0x000, nada más.  No vacía el stack. 

El stack es una sección de memoria que no se puede acceder por el usuario, la maneja el PIC.  Cuando uno hace un 'call' se carga en el stack la dirección de donde hicimos el call, y el puntero del stack se incrementa en 1.  Cuando hacemos un return se decrementa el puntero del stack y se vuelca el contenido del puntero en el PC.

Si hacemos un goto, no importa a qué dirección hacemos solo eso.  El stack , sigue cargado con lo que venía trayendo.  Hacer un goto no es resetear el pic.

Lo que puede suceder, como dije anteriormente es que el CCS reinicie su inicialización de variables pero no veo la forma en que pueda vaciar el stack porque simplemente "no hay forma", de hacerlo desde las instrucciones .  Solo una secuencia de returns puede vaciar un stack pero lo que hará será marear al programa.  Tal vez sepan algo que uno no sabe y por eso estaría interesante probar ese "reset" del CCS siendo llamado desde una subrutina a ver qué hace el CCS.

Tal vez en el manual del CCS indique que el uso de esa función reset se debe hacer UNICAMENTE desde el main o desde una función que se llame una sola vez desde el main (ya que esto hará que el compilador no genere un call hacia esa función sino que haga un goto, esto es una optimización básica que hace cualquier compilador de C).

Bien, volviendo al tema de la inicialización de los registros.

1) Es cierto que una memoria se inicializa con cualquier cosa cuando arranca

2) El PIC , tiene un microkernel que se encarga de "inicializar" los registros a ciertos valores.  Esto está documentado en el datasheet.  Así como los TRISC se inicializan en 1, algunos otros registros se inicializan en 0. 

3) Si no estuviera esa inicialización por hardware, no habría forma por ejemplo de garantizar que el PC en los 16F sea 0x000 , sino que podría valer cualquier otra cosa.

Espero haber clarificado el tema o al menos mi punto de vista.







- 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)

Desconectado delirio

  • PIC12
  • **
  • Mensajes: 64
Re: Puedo dañar un PIC poniendolo a que se haga el mismo el reset?
« Respuesta #19 en: 25 de Septiembre de 2006, 00:33:53 »
Que tema más que interesante el que se plantea aquí... desde mi humilde opinión, yo pienso lo mismo que maunix, un codigo limpio y ordenado no necesita un reset para seguir trabajando, y sacrificar un pin del micro para tal fin me parese absurdo, si en todo momento amigo AABHGA sabes cuando resetear al pic, no lo resetees, ¿¿¿que consigues con eso??? piensa en lo que consigues con el reset y haslo por software, ya sea para inicializarlo o para otro fin.
Saludos.

maggi

  • Visitante
Re: Puedo dañar un PIC poniendolo a que se haga el mismo el reset?
« Respuesta #20 en: 29 de Septiembre de 2006, 06:22:45 »
Esto pasa con la gente que usa mucho windows, todo lo solucionan con un reset, tengo un outage de 4 horas por que un dessarrollador oracle creyo que si reseteaba el servidor se iban a acomodar algunas cositas, no no, esto del reset es una lacura, las cosas se hacen prolijas, te armas una funcion llamemosla limpiar, que te deje las variables o lo que quieras fresquitas y listas para usar, y llamas a esa funcion osea haces que el programa se recicle.
Por otro lado ccs hace otras cosas antes de entrar al main, como la mayoria de los C..., por eso existe una funcion especial que se puede llamar antes que el main que es algo asi como after_reset() no se muy bien, a lo mejor realiza un proceso de limpieza, recordemos que ccs lleva cuenta del stak que usa:
Stack:    4 worst case (3 in main + 1 for interrupts)
y que ademas a los chicos de ccs les gusta esconder algunas cosas, hay que revisar bien ese codigo no se basen en el .lst que les deja al compilar.

Desconectado maunix

  • Moderadores
  • DsPIC33
  • *****
  • Mensajes: 4751
    • Mi Sitio Web Personal
Re: Puedo dañar un PIC poniendolo a que se haga el mismo el reset?
« Respuesta #21 en: 29 de Septiembre de 2006, 12:26:32 »
Esto pasa con la gente que usa mucho windows, todo lo solucionan con un reset, tengo un outage de 4 horas por que un dessarrollador oracle creyo que si reseteaba el servidor se iban a acomodar algunas cositas, no no, esto del reset es una lacura, las cosas se hacen prolijas, te armas una funcion llamemosla limpiar, que te deje las variables o lo que quieras fresquitas y listas para usar, y llamas a esa funcion osea haces que el programa se recicle.
Por otro lado ccs hace otras cosas antes de entrar al main, como la mayoria de los C..., por eso existe una funcion especial que se puede llamar antes que el main que es algo asi como after_reset() no se muy bien, a lo mejor realiza un proceso de limpieza, recordemos que ccs lleva cuenta del stak que usa:
Stack:    4 worst case (3 in main + 1 for interrupts)
y que ademas a los chicos de ccs les gusta esconder algunas cosas, hay que revisar bien ese codigo no se basen en el .lst que les deja al compilar.

No hay que generalizar. 

Creo que un problema en de base de datos oracle en un servidor , un problema con windows y un problema en un microcontrolador se resuelven tooodos de muy diversa manera.

A veces, cuando uno comienza, necesita de este tipo de soluciones para bueno, zafar por el momento.  Yo lo tomaría como parte del aprendizaje, con las advertencias que he expuesto anteriomente.

Lo que comentas de CCS debe ser para los 16F supongo. 

Considero que por ej. al decir "un llamado a una función limpieza" has generalizado.  En mi opinión muchos problemas se resuelven no con llamadas a funciones que inicializan variables sino a una buena diagramación del software , de las subrutinas y de como va el flujo del programa a medida que algunas condiciones se cumplen o no.

Podria usarse un flag que sea "restart" y que haga que el bucle del programa vaya 'cayendo solo' hasta llegar al más alto nivel y ahí sería como volver de nuevo.

En fin, técnicas hay muchas pero lo que sí a veces generalizar es malo.  Esa es mi moraleja.

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)

AABHGA

  • Visitante
Re: Puedo dañar un PIC poniendolo a que se haga el mismo el reset?
« Respuesta #22 en: 29 de Septiembre de 2006, 12:55:25 »
El asunto de querer hacer el reset es el siguiente:

Mi aplicación es para usuarios, el sistema es configurable por el usuario y maneja demasiadas opciones, demasiadas variables durante este proceso, tambien lectura y escritura en la eeprom,  y para evitar que alguna de estas variables y demas me interfiera en el funcionamiento nominal del proyecto entonces lo pongo a que se haga reset e inicie lo que necesita para trabajar, ademas tb es para safar un poco, porque tengo problemas con el lcd ya que durante la configuración activo el "parpadeo del cursor" y no soy capaz de quitarlo entre otras cosas.

Desconectado maunix

  • Moderadores
  • DsPIC33
  • *****
  • Mensajes: 4751
    • Mi Sitio Web Personal
Re: Puedo dañar un PIC poniendolo a que se haga el mismo el reset?
« Respuesta #23 en: 29 de Septiembre de 2006, 13:29:16 »
El asunto de querer hacer el reset es el siguiente:

Mi aplicación es para usuarios, el sistema es configurable por el usuario y maneja demasiadas opciones, demasiadas variables durante este proceso, tambien lectura y escritura en la eeprom,  y para evitar que alguna de estas variables y demas me interfiera en el funcionamiento nominal del proyecto entonces lo pongo a que se haga reset e inicie lo que necesita para trabajar, ademas tb es para safar un poco, porque tengo problemas con el lcd ya que durante la configuración activo el "parpadeo del cursor" y no soy capaz de quitarlo entre otras cosas.

Desde mi punto de vista, esta bien y te entiendo perfectamente.  De hecho fíjate lo que he puesto

Cita de: maunix
A veces, cuando uno comienza, necesita de este tipo de soluciones para bueno, zafar por el momento.  Yo lo tomaría como parte del aprendizaje, con las advertencias que he expuesto anteriomente.

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)

maggi

  • Visitante
Re: Puedo dañar un PIC poniendolo a que se haga el mismo el reset?
« Respuesta #24 en: 01 de Octubre de 2006, 21:03:26 »
Citar
Considero que por ej. al decir "un llamado a una función limpieza" has generalizado.  En mi opinión muchos problemas se resuelven no con llamadas a funciones que inicializan variables sino a una buena diagramación del software , de las subrutinas y de como va el flujo del programa a medida que algunas condiciones se cumplen o no.
Primero que nada una funcion no tiene por que inicializar ningun tipo de variables, segundo por funcion se entiende una rutina de codigo que realiza una funcion especifica. si a vos te gusta tirar todo en un solo main, me parece fantastico pero es una practica que desaconsejo, si bien muchos trabajan en assembler esto no quiere decir que estes restringido al modelo to-down sino creo que las herramientas de hoy en dia permiten incluso hacer un assembler modular, mucho mas limpio y facil de manejar, quiza mas dificil de leer como pasa con la programacion modular, pero ya basta de este tema que da para mucho...

Cuando uno quiere resetear un dispositivo, cualquiera no importa, hay una etapa que uno no controla el programa esta ciego ya es imposible intervenir o tomar desiciones, por eso el programador tiene que evitar esto a toda costa, por que uno ya no puede volver atraz y por que no existe ninguna manera de saber que va a pasar uno se queda esperando que retomar el control para dar servicio y eso es una falla tremenda, imaginemos que la condicion X se sucita en una maquina, si la contramedida es reiniciar perdemos conocimiento de lo que X provaca al resto de la maquina, por eso las contramedidas tienen que ser activas, la maquina se tiene que poder defender pero estando viva no muerta, si pensamos que la somucion de algo es perder el control absoluto, estamos cortemos la conversacion y vamos a jugar a las barbis...
« Última modificación: 01 de Octubre de 2006, 21:05:18 por maggi »

AABHGA

  • Visitante
Re: Puedo dañar un PIC poniendolo a que se haga el mismo el reset?
« Respuesta #25 en: 02 de Octubre de 2006, 06:43:32 »
Estas siendo extremista maggi, como dije antes, es para zafar de algunas y para que tomara las nuevas configuraciones que el usuario pone y acortar el código a su vez, en el proyecto que realizé, me toco que empezar a depurar en demasía el programa, xque me pasé de la capacidad del 16F84 antes de terminarlo.

Desconectado maunix

  • Moderadores
  • DsPIC33
  • *****
  • Mensajes: 4751
    • Mi Sitio Web Personal
Re: Puedo dañar un PIC poniendolo a que se haga el mismo el reset?
« Respuesta #26 en: 02 de Octubre de 2006, 08:56:40 »
Citar
Considero que por ej. al decir "un llamado a una función limpieza" has generalizado.  En mi opinión muchos problemas se resuelven no con llamadas a funciones que inicializan variables sino a una buena diagramación del software , de las subrutinas y de como va el flujo del programa a medida que algunas condiciones se cumplen o no.
Primero que nada una funcion no tiene por que inicializar ningun tipo de variables, segundo por funcion se entiende una rutina de codigo que realiza una funcion especifica. si a vos te gusta tirar todo en un solo main, me parece fantastico pero es una practica que desaconsejo, si bien muchos trabajan en assembler esto no quiere decir que estes restringido al modelo to-down sino creo que las herramientas de hoy en dia permiten incluso hacer un assembler modular, mucho mas limpio y facil de manejar, quiza mas dificil de leer como pasa con la programacion modular, pero ya basta de este tema que da para mucho...

Si te fijas acabas de citar MI post y no el de AABHGA que es quien usa esa función.  Yo estaba diciendo casualmente que usar una función o "procedimiento" (al cabo que un void fcn(void) es un procedimiento) para poner todo a 0 no es la forma de querer resetear un pic. 

Es común en los "chicos C" confundir llamar a todo "una función", pero tampoco lo veo tan grave, es decir, uno entendió lo que nuestro amigo quiso decir.  El se refería a un procedimiento.  No hace falta ser tan exquisito, hay gente que recién comienza y  tal vez una simple explicación les aclara tu punto y te ganas un amigo.

En cuanto a MI opinión, usar un void inicializarvariables (void) no solo que está perfecto, sino que es hasta aconsejable.  Siempre tengo mi código de inicialización en un procedimiento separado.  Al principio del main llamo a funciones que me configuran los periféricos e inicializan las variables.  No me gusta usar la inicialización de las variables en código C (en la declaración), porque hay que mezclar secciones UDATA con IDATA y se presta a confusión en programas largos (aclaro que uso C18).

Ahora, ¿cómo inicializas tu las variables si no usas ni una 'función' ni pones todo en el 'main ?


Cuando uno quiere resetear un dispositivo, cualquiera no importa, hay una etapa que uno no controla el programa esta ciego ya es imposible intervenir o tomar desiciones, por eso el programador tiene que evitar esto a toda costa, por que uno ya no puede volver atraz y por que no existe ninguna manera de saber que va a pasar uno se queda esperando que retomar el control para dar servicio y eso es una falla tremenda, imaginemos que la condicion X se sucita en una maquina, si la contramedida es reiniciar perdemos conocimiento de lo que X provaca al resto de la maquina, por eso las contramedidas tienen que ser activas, la maquina se tiene que poder defender pero estando viva no muerta, si pensamos que la somucion de algo es perder el control absoluto, estamos cortemos la conversacion y vamos a jugar a las barbis...

maggi, me parece que estás siendo extremista.  La aplicación de AABHGA es bastante simple y no requiere de tanto rigor.

Si bien la práctica de AABHGA no es la adecuada, ni la más aconsejable por ahora, como el bien dijo, le ayuda a zafar y es más que entendible.  Yo no hacia las cosas que hago ahora, ni siquiera hace 1 año atrás!.  Uno va evolucionando, aprendiendo, mejorando, optimizando.  El aprendizaje es un proceso gradual.

Si su aplicación lo permite y no le trae problemas, apruebo su decisión.  Hacer otra cosa, le traería semanas de trastornos y búsqueda que tal vez ahora no esté en condiciones de asimilar porque recién comienza.  A todos nos pasó alguna vez.  Mi primer firmware no fue el automatismo de un sistema de control a lazo cerrado... fue un simple display de dígitos.

Cuando haga alguna cosa más complicada en un proceso que no deba pararse nunca, ahí de seguro no usará ésta metodología y si la usa tendrá graves problemas.  Pero tiempo al tiempo.

No me parece que acá se haya dicho en algún momento que "en caso de no saber que hacer -> RESETEE", simplemente AABHGA fue muy sincero en reconocer sus limitaciones y las expuso frente a la solución que se le ocurrió.

Ahora bien, si tienes inquietudes en mostrarnos algunas cosas de tus opiniones sobre desarrollos de proyectos, te invito que comiences un tema nuevo exponiendo tus ideas pero no me parece que haya que seguir en este hilo donde hablamos de AABHGA y SU problema.  8)


Estas siendo extremista maggi, como dije antes, es para zafar de algunas y para que tomara las nuevas configuraciones que el usuario pone y acortar el código a su vez, en el proyecto que realizé, me toco que empezar a depurar en demasía el programa, xque me pasé de la capacidad del 16F84 antes de terminarlo.

Precisamente, y como dije para tu aplicación por ahora es aceptable y entendible.  A no darle mas vueltas al asunto :)
- 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)

Desconectado delirio

  • PIC12
  • **
  • Mensajes: 64
Re: Puedo dañar un PIC poniendolo a que se haga el mismo el reset?
« Respuesta #27 en: 02 de Octubre de 2006, 23:14:56 »
AABHGA, entiendo perfectamente tu decisión. Y no te preocupes por el cursor, ya pronto encontrarás la manera de que deje de parpadear. :), de echo, si quieres publicar el código para que te demos un aventón, pues para eso estamos mi amigo.
Saludos.

Desconectado joscar66

  • Colaborador
  • PIC16
  • *****
  • Mensajes: 116
Re: Puedo dañar un PIC poniendolo a que se haga el mismo el reset?
« Respuesta #28 en: 04 de Octubre de 2006, 14:01:44 »
Bueno Señores,

Luego de leer todos los mensajes de este post he quedado un poco traumado or la condicion Goto 0x00 ó RESET_CPU(); la verdad nunca imagine que fuera inefectiva y maliciosa en algunas oportunidades.
Personalmente me gustaria (si no es mucha molestia) pedirles a los amigos maunix y maggi alguna clase de ejemplos en donde dicha condicion afecta el funcionamiento del pic ya que de verdad no he asimilado muy bien la cuestion.

No se si los demas participantes del foro estan de acuerdo

Gracias

Esfuércense por ser mejor cada día...
¡Saludos desde COLOMBIA!

Desconectado maunix

  • Moderadores
  • DsPIC33
  • *****
  • Mensajes: 4751
    • Mi Sitio Web Personal
Re: Puedo dañar un PIC poniendolo a que se haga el mismo el reset?
« Respuesta #29 en: 04 de Octubre de 2006, 22:40:30 »
joscar66, no hay inconvenientes, te tiro un ejemplo en assembler a ver si así te queda más claro.  Si hace falta te lo tiro en

Te lo hago en assembler, que tal vez queda más claro.
Código: ASM
  1. org        0x000
  2.         goto       MAIN
  3. MAIN:
  4.         call       SUBRUTINA1
  5.         call       SUBRUTINA2
  6.         nop                        ;El programa jamás llegará acá.
  7.  
  8.  
  9. SUBRUTINA1:
  10.         nop
  11.         return
  12.        
  13.        
  14.  
  15. SUBRUTINA2:                       ;Al llamar a SUBRUTINA2 el stack se carga con la dirección de SUBRUTINA2
  16.                                   ;Nunca se descarga del STACK porque no hay un return.  El Programa continuará
  17.                                   ;a partir de la posición 000
  18.         nop
  19.         goto        0x000         ;'Supuesto Reset'

Al ejecutarse 8 veces, el STACK se habrá llenado y el PIC pudiera hacer cualquier cosa en estas circunstancias.  Creo que el puntero del Stack irá a 0 (se desbordará) y en ese caso en el próximo return volverá a la posición cargada en la posición 0x000 del stack.

Este es un ejemplo simple pero imaginen en un programa más complejo donde algunos 'calls' se hacen si se cumple o no alguna condición!  En ese caso, tenemos garantizado un software que irá para cualquier lado.

En los 18F hay un fuse que permite, que el pic haga un RESET cuando el stack se vacía (que se haga un return sin haber un call previo) o cuando se llena (se superan los 32 niveles de stack).  Esto constituye una gran mejora.

Espero se haya aclarado el tema, si no está claro puedo poner un ejemplo en C de un caso en qué se podría producir esto, pero les pediría a uds que lo compilaran ya que yo no uso CCS.

En el C, hay lo que se llama un "optimizador", que son procesos que corren con el compilador mismo para mejorar algunas cosas.  Si uno hace una función y la misma es llamada "una sola vez", en el código asm no se generará un CALL a dicha subrutina sino que se hace un GOTO (1) a la subrutina y al final de la misma un GOTO (2) nuevamente a la posición próxima siguiente del GOTO(1) que llamó a dicha subrutina.  De esa forma no usan un nivel de stack.  Eso funciona cuando una función se ejecuta una sola vez pero no cuando la misma se llama desde otras funciones.  En ese caso, se generará un CALL a la subrutina.  Si encima dentro de esa subrutina hacemos un Reset_CPU() como el antes mencionado... a mi entender, ocurrirá lo que mencioné con el ASM. 

Dejo al puerta abierta para decir que tal vez la gente de CCS documente muy bien en QUE caso usar el Reset_CPU() para los 16F y cómo usar el mismo, o tal vez sepan algún truco que se me esté escapando.

De nuevo si queda alguna duda, no se problema que pregunten.

- 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)