Registro TRIS (TRISIO) tiempo de transicion

estoy utilizando un pic 12f675 en el cual necesito cambiar el puerto de entrada a salida y viceversa, pero he notado que no hace el cambio si no se deja un tiempo antes de la siguiente instrucción, algo asi como con la escritura en la memoria EEPROM, ¿alguien sabe cual es el tiempo minimo de transición de estado?
 
Cuando realizas un cambio de estado en un pin de entrada a salida este debe estar listo después de ejecutar la instrucción.
Pero si quieres estar seguro que el pin ya esta listo para trabajar como entrada o salida, puedes ejecutar un NOP después de hacer el cambio.
Después de ejecutarse el NOP el pin ya debe estar listo para funcionar como I/O dependiendo el caso.
La mayoría de las instrucciones son de uno a dos ciclos de reloj, con uno más que des ya puedes estar seguro.
Ahora que si requieres de más seguridad ante el cambio del TRISIO, usa un retardo de 10us.

Saludos.
 
Cuando realizas un cambio de estado en un pin de entrada a salida este debe estar listo después de ejecutar la instrucción.

al parecer el registro si queda listo, o sea que si lo leo en la siguiente instruccion si reconoce que hace el cambio, pero en la electronica o hardware no...:eek:

puse pausas de hasta 10 milisegundos y ahi si funciona, y cabe aclarar que en proteus no esta considerado eso, o sea que en la simulacion si es simultanea.

la cuestion es que quisiera saber si existe alguna nota de aplicacion de microchip que confirme esa observacion.
 
Al parecer el registro si queda listo, o sea que si lo leo en la siguiente instrucción si reconoce que hace el cambio, pero en la electrónica o hardware no...:eek:

puse pausas de hasta 10 milisegundos y ahi si funciona, y cabe aclarar que en proteus no esta considerado eso, o sea que en la simulación si es simultanea.
Si usas el oscilador interno, debes verificar que tenga correcto el valor de OSCCAL.
El problema puede deberse a los ciclos de instrucción que no están siendo ejecutados dentro del rango óptimo.
La cuestión es que quisiera saber si existe alguna nota de aplicación de microchip que confirme esa observacion.
Tal vez exista alguna, yo no la he visto aunque la he buscado, pero tengo asesoría directa para preguntar.
Primero verifica lo que te menciono sobre el valor de OSCCAL.
Usando FOSC = XT/HS todo debería ser como te mencioné.
 
al parecer el registro si queda listo, o sea que si lo leo en la siguiente instruccion si reconoce que hace el cambio, pero en la electronica o hardware no...:eek:

puse pausas de hasta 10 milisegundos y ahi si funciona, y cabe aclarar que en proteus no esta considerado eso, o sea que en la simulacion si es simultanea.

la cuestion es que quisiera saber si existe alguna nota de aplicacion de microchip que confirme esa observacion.


¿Cómo determinas que aún no está configurado en hardware?, ¿que frecuencia usas para el PIC? y algo importante ¿que carga le estas poniendo al puerto?
 
La frecuencia es de 4MHz con oscilador interno, el osccal está correcto, el de fábrica.
Es muy extraño, acabo de realizar una prueba con un programa sencillo para comprobar el cambio de estado con TRIS pero usando la instrucción Input, así como lo estás haciendo.

El cambio es inmediato cuando se ejecuta la interrupción externa.
Código:
[COLOR=Green];*******************************************************************************[/COLOR]
[COLOR=Green]; Palabra de configuración:[/COLOR]
[COLOR=Blue]#Config[/COLOR]
[COLOR=SlateGray]    __CONFIG _FOSC_INTRCIO & _WDT_OFF & _PWRTE_ON & _BOREN_OFF[/COLOR]
[COLOR=Blue]#EndConfig[/COLOR]
[COLOR=Green];*******************************************************************************[/COLOR]
[COLOR=Blue]Rem[/COLOR] [COLOR=Green]FOSC = 4MHz.[/COLOR]


Inicio:
    ANSEL = 0              [COLOR=Green] ; Conversores ADC = OFF[/COLOR]
    CMCON = 7              [COLOR=Green] ; Comparadores analógicos = OFF[/COLOR]
    OPTION_REG.6 = 0       [COLOR=Green] ; Interrupción por flanco de bajada[/COLOR]
    INTCON = %11010000     [COLOR=Green] ; Interrupción externa por GP2[/COLOR]
   [COLOR=Blue] High[/COLOR] GPIO.0            [COLOR=Green] ; Encender LED en GP0[/COLOR]
    
    [COLOR=Blue]On Interrupt GoTo[/COLOR] INTE_ISR
    
    
Programa:
[COLOR=Green]; Bucle infinito solo para esperar interrupción.[/COLOR]
    [COLOR=Blue]GoTo[/COLOR] Programa
    
[COLOR=Green]; Controlador de la interrupción externa por GP2[/COLOR]
INTE_ISR:
    [COLOR=Blue]Disable [/COLOR]              [COLOR=Green]  ; Desactivar interrupciones[/COLOR]
    INTCON.1 = 0           [COLOR=Green] ; Limpiar bandera INTF[/COLOR]
    [COLOR=Blue]Input[/COLOR] GPIO.0            [COLOR=Green]; GPO como entrada (Apaga LED)[/COLOR]
    [COLOR=Blue]Resume [/COLOR]               [COLOR=Green]  ; Retomar el programa principal[/COLOR]
    [COLOR=Blue]Enable[/COLOR]                 [COLOR=Green] ; Activar interrupciones[/COLOR]
    

   [COLOR=Blue] End[/COLOR]
Está escrito en MCS v5 con PBP3

¿Ya probaste usando TRISIO.X = X?
 
Última edición:
Microchip si da esos datos en sus manuales de referencia.. pero el tiempo que el chip tarda en trancisionar de entrada a salida es despreciable (en el orden de nS) por lo que para la gran mayoria de las aplicaciones se puede considerar que el PIN ya esta listo para trabajar en la siguiente instruccion

Si mal no recuerdo el problema que habia era cuando uno cambia de salida a entrada y lee el valor del puerto, ya que no esta leyendo directamente el puerto sino un registro intermedio, pero ya tiene rato que no uso los PICs asi que mejor alguien confirme este ultimo dato...
 
Microchip si da esos datos en sus manuales de referencia.. pero el tiempo que el chip tarda en trancisionar de entrada a salida es despreciable (en el orden de nS) por lo que para la gran mayoria de las aplicaciones se puede considerar que el PIN ya esta listo para trabajar en la siguiente instruccion

Si mal no recuerdo el problema que habia era cuando uno cambia de salida a entrada y lee el valor del puerto, ya que no esta leyendo directamente el puerto sino un registro intermedio, pero ya tiene rato que no uso los PICs asi que mejor alguien confirme este ultimo dato...

Esto último es cierto, pero sólo en la serie 18F y superior, de hecho se tiene un registro específico para leer datos (PORTX) y otro para enviar datos (LATX)

port.png

En la serie 16 no se tiene el registro LATX, y el tiempo que tarde en cambiar de dirección es despreciable a comparación de la frecuencia con la que trabaja esa serie de micros
 
¿Ya probaste usando TRISIO.X = X?

ya, probe con trisio y es lo mismo, pero hice la prueba que pusiste y si el cambio es inmediato. estoy depurando todo el codigo a ver si doy con el error.


En la serie 16 no se tiene el registro LATX, y el tiempo que tarde en cambiar de dirección es despreciable a comparación de la frecuencia con la que trabaja esa serie de micros

ok. voy a dar por echo que es inmediato el cambio, porque en realidad no tiene razon de tardar tanto.

en cuanto tenga algo posteo.... saludos.
 
¿que aplicación traes entre manos que demanda tiempos tan cortos de conmutación E/S?

no son los tiempos, lo que traigo escasa es la memoria de programa, uso varios cambios y si cada cambio es una pause me come memoria, de echo no me habia molestado hasta que quedo en ceros la memoria XD.
 
Atrás
Arriba