Precisión del PIC16F84A ?

[silicon blood]

Buenas.

Estoy usando un par de PIC's 16F84A para experimentar y comprobar la precisión de los mismos, me refiero a los ciclos que consume una instrucción o una serie de instrucciones, suponiendo que la señal de reloj sea estable, entonces si el micro es estable en cuanto cuantos ciclos tarda en hacer algo, entonces se puede predecir con exactitud el tiempo de una tarea, con una resolución dada por el reloj.

Por eso me arme un circuito usando integrados de la serie 74HCxxx que son bastante rapidos y un par de PIC's a 4Mhz, la idea es que en un micro genero dos pulsos separados por 8 intrucciones NOP (asm) esto en teoria deberia hacer algo asi:

señal1------8 ciclos-------señal2

Este es el codigo correspondiente:

BTFSS  PORTB,RB6 ;[COLOR="Red"]aqui me equivoque al transcribir el verdadero codigo usa BSF no BTFSS[/COLOR]
NOP
NOP
NOP
NOP
NOP
NOP
NOP
NOP
BTFSS  PORTB,RB7  ;[COLOR="Red"]aqui me equivoque al transcribir el verdadero codigo usa BSF no BTFSS[/COLOR]

como cada ciclo en el PIC consume 4 ciclos de reloj deberia contar 32 ciclos entre las dos señales, pues con algo de esfuerzo me arme este circuito que hace esta medición, despues de una semana de programación (asm) y otra para corregir errores y ponerlo a funcionar, ya funciona de manera estable y correcta.

El asunto es que esta midiendo 34 a 35 ciclos en lugar de 32. Por fin la pregunta:

Alguien sabe a que se debe esto? si tiene corrección? si algun otro PIC es mas preciso en ese aspecto? o que me recomiendan para mejorar la precisión en general?

 

[Scooter]

No solo los nops tardan tiempo, las otras instrucciones también

 

[silicon blood]

Scooter pero la diferencia con el tiempo teorico es de 2 a 3 ciclos, eso no es ni siquiera un ciclo interno del PIC, si la diferencia fuese un multiplo de 4 ciclos te creo...

 

[Scooter]

Yo solo veo problema en un ciclo que puede ser problema de con que lo mides, que una instrucción de cuatro ciclos cambie a mitad me parece normal, si tiene cuatro ciclos es que en cada uno hace una cosa, si todo lo hiciese en uno de los cuatro no le harían falta cuatro.
A lo mejor en poner a uno va en el tercero y en poner a cero en el segundo o algo así.

Además para medir no puedes usar una puerta conectada al mismo reloj, usa una conectada a uno que funciona diez veces mas rápido y despreciando un ciclo debe de medir bien.

 

[Ardogan]

Las instrucciones de salto condicional siempre pueden tardan más dependiendo de si la condición se cumple o no.
Mira la sección 7 de la hoja de datos, si la condición de la instrucción btfss se cumple el tiempo que tarda es 2 ciclos de instrucción, si no se cumple 1 ciclo. En la tabla 7-2 está cada instrucción con la cantidad de ciclos que insume entre otra información.

Esto se debe a que cualquier micro normalmente mientras ejecuta una instrucción está buscando en memoria la siguiente, y en las instrucciones de salto condicional no es posible saber de antemano si el salto se cumple o no.
Bueno, como siempre la cosa es más complicada, tendrías que leer sobre arquitecturas de micros, pipelines, predictor de saltos (branch predictor)...

Normalmente al usar un micro uno no espera tener una precisión de tiempos comparable con los tiempos de instrucción del micro (alguna excepción habrá, pero no es lo usual). Por qué tu interés en manejar esa resolución de tiempo?, cual es tu necesidad?, que precisión de tiempo querés lograr?.

Saludos.

 

[BKAR]

...
Normalmente al usar un micro uno no espera tener una precisión de tiempos comparable con los tiempos de instrucción del micro (alguna excepción habrá, pero no es lo usual). Por qué tu interés en manejar esa resolución de tiempo?, cual es tu necesidad?, que precisión de tiempo querés lograr?.

Saludos.

Si,cual amigo?

----------
Seleccionando Debugger/Select Tool/MPLAB SIM..

luego en Debugger/Stop Watch
se ponemos BreakPoints y con el StopWatch (lo mismo que un cronometro) medimos el tiempo(teorico Fosc/4 =1 instruccion) y al cantidad de intrucciones.

bueno, ayuda a saber que tantas instrucciones tarda en ejecutarse una seccion del programa.

 

[Chico3001]

El asunto es que esta midiendo 34 a 35 ciclos en lugar de 32. Por fin la pregunta:

Los PICs (o cualquier otro micro de otra marca) son extremadamente precisos... si el manual indica que una instruccion toma x ciclos entonces eso es lo que va a tomar... ya que son circuitos sincronos organizados por una señal master de reloj y si cualquiera de ellos se atrasa o se adelante el chip completo dejaria de funcionar

Lo que si puede variar es la precision del cristal y del circuito oscilador interno, que son afectados por temperatura, cambios de voltaje etc.. pero esos cambios son minimos y se miden en ppm (10,000 partes por millon = 1%)

La otra afectacion grave que es lo que creo que notas de alguna manera, es el startup time, o tiempo de inicio que le toma al oscilador en llegar a su estado estable.... estos tiempos para un oscilador de cristal son notables y pueden estar en el orden de milisegundos, asi que te recomiendo que replantees tu prueba para que la medicion ocurra varios milisegundos despues de iniciado el PIC y nunca apagar o poner al el PIC en sleep durante la prueba ya que eso puede apagar el oscilador interno, haciendo que ocurra de nuevo el startup time

 

[silicon blood]

A lo mejor en poner a uno va en el tercero y en poner a cero en el segundo o algo así.

Es exactamente lo que yo imaginaba pero necesitaba alguna confirmación, en las hojas de especificaciones no hablan del tema, siempre me pregunto eso, si son 4 ciclos en cual en realidad se activa/desactiva una pata? ya que eso es importante cuando uno esta desarrollando algo sensible al tiempo.

Además para medir no puedes usar una puerta conectada al mismo reloj, usa una conectada a uno que funciona diez veces mas rápido y despreciando un ciclo debe de medir bien.

Probe con 10 Mhz el contador y 4 Mhz el PIC que genera las señales, el resultado teorico 80 ciclos, el medido 84-85 ciclos. Parece ser proporcional a 2 o 3 ciclos de 4 Mhz

Normalmente al usar un micro uno no espera tener una precisión de tiempos comparable con los tiempos de instrucción del micro (alguna excepción habrá, pero no es lo usual). Por qué tu interés en manejar esa resolución de tiempo?, cual es tu necesidad?, que precisión de tiempo querés lograr?.

Si bueno yo esperaba tener una resolución de 4 ciclos y eso no me molesta, ya que pensaba que siempre se comportaria de esta manera, al parecer estaba muy equivocado, eso es lo que me intriga, como es que las diferencias no son multiplos de 4? puede ser lo que menciono arriba, pero como se verifica esto de que el PIC puede hacer la operación de E/S en el ciclo 1,2,3 o 4?

Respecto a lo que quiero lograr es un Time Interval Counter (TIC) este circuito es apenas un prototipo básico inicial de lo que quiero hacer.

Si,cual amigo?

----------
Seleccionando Debugger/Select Tool/MPLAB SIM..

luego en Debugger/Stop Watch
se ponemos BreakPoints y con el StopWatch (lo mismo que un cronometro) medimos el tiempo(teorico Fosc/4 =1 instruccion) y al cantidad de intrucciones.

bueno, ayuda a saber que tantas instrucciones tarda en ejecutarse una seccion del programa.

}

Oye... No sabia que en el debugger se mide el tiempo real!! guao! gracias, voy a probar y les aviso.

Lo que si puede variar es la precision del cristal y del circuito oscilador interno, que son afectados por temperatura, cambios de voltaje etc.. pero esos cambios son minimos y se miden en ppm (10,000 partes por millon = 1%)

Pero como (en el caso de 4 Mhz) tengo el mismo reloj para todo el circuito, las variaciones deben afectar por igual al contador y al pic, y bueno yo me tomé la molestia de hacer 100 mediciones dos veces en dos momentos diferentes del dia (aunque tengo termostato en el cuarto) y la media es de 34.18 y la desviación estandar de 0.38 es decir hay muchos resultados de 34 y no tantos de 35. Muy constante.

PD: lo del start-up time si que lo tengo en cuenta, si les dijera los primeros 3 resultados que arroja me mandan a la basura con todo y circuito....

 

[Ardogan]

Es exactamente lo que yo imaginaba pero necesitaba alguna confirmación, en las hojas de especificaciones no hablan del tema, siempre me pregunto eso, si son 4 ciclos en cual en realidad se activa/desactiva una pata? ya que eso es importante cuando uno esta desarrollando algo sensible al tiempo.

No toda la información de los micros está en la hoja de datos, mucha información la ponen aparte en los "reference manuals":
http://www.microchip.com/TechDoc.aspx?type=ReferenceManuals

Por ejemplo, en el pdf "Architecture - PICmicro Mid-Range MCU Family" habla algo de arquitectura del micro (ciclo de oscilador, de instrucción, pipeline):
http://ww1.microchip.com/downloads/en/DeviceDoc/31004a.pdf

Acá habla de en qué fase del clock se leen/escriben los puertos (sección 9.10.2):
http://ww1.microchip.com/downloads/en/DeviceDoc/31009a.pdf

En fin... hay para entretenerse.

Probe con 10 Mhz el contador y 4 Mhz el PIC que genera las señales, el resultado teorico 80 ciclos, el medido 84-85 ciclos. Parece ser proporcional a 2 o 3 ciclos de 4 Mhz
Si bueno yo esperaba tener una resolución de 4 ciclos y eso no me molesta, ya que pensaba que siempre se comportaria de esta manera, al parecer estaba muy equivocado, eso es lo que me intriga, como es que las diferencias no son multiplos de 4? puede ser lo que menciono arriba, pero como se verifica esto de que el PIC puede hacer la operación de E/S en el ciclo 1,2,3 o 4?

Respecto a lo que quiero lograr es un Time Interval Counter (TIC) este circuito es apenas un prototipo básico inicial de lo que quiero hacer.
....

Veo que usas 2 pics, hay que tener en cuenta también la capacidad de entrada del pic que lee el intervalo de tiempo, el tiempo de subida/bajada que puede generar el pic generador, y los umbrales para detectar '0' y '1' del lado del pic lector.
Mira la figura 9-7/tabla 9-3 (página 56) de la hoja de datos del pic16f84a.
También la tabla 9-2 (página 51) -> ¿que te parece que conviene usar, schmitt trigger o ttl buffer?, ¿lo mismo para receptor y transmisor o usar ttl buffer para uno y schmitt trigger para el otro?

Fuera de eso, en la parte práctica no creo que logres una precisión mucho mejor que algunos Tcy (ciclos de instrucción = 4 * Tosc). Así que si precisás mayor precisión vas a tener que pensar en solucionarlo de otra forma.

¿Pensaste en usar algún pic con un módulo ccp? (en modo captura).

 

[silicon blood]

Ardogan Gracias por tu respuesta, esta misma noche me pongo a leer todos los manuales que colgaste, ya habia leido el manual 33023a pero no enconre nada de ayuda.

Es mi culpa que tengas que trabajar la mente con tan pocos datos, de verdad que no es intencional la falta de información, ahora que tenga más tiempo, te coloco el esquematico completo y si es necesario el código, solo te adelanto que para contar uso un 74HCT193 que es un contador binario de 4 bit, por lo tanto cada 15 pulsos se desborda y se activa una pata para indicar este desbordamiento, yo capturo esta señal en RA4/TOCKI y luego de terminado el conteo leo las demás patas para realizar los calculos en el PIC dedicado a esto, el otro PIC solo genera las dos señales de start y stop.

Para el resto de la lógica uso flip flop, y puertas xor y and, todos CMOS de la serie 74HC para garantizar la velocidad. De verdad muchas gracias. Mas tarde les escribo el resto.

 

[Vick]

Los tiempos en un PIC (usando oscilador a cristal) pueden ser sumamente exactos, como ya te mencionaron aun el cristal puede tener alguna variación o tolerancia, pero en general es muy exacto.

yo he trabajado con programas que miden tiempo y realmente puedes lograr una gran exactitud, si sabes programarlo, precisamente ahora estoy trabajando en circuitos con un PIC16F84A o un PIC16F628A (con oscilador externo) para generar diferentes señales que requieren de gran exactitud y todo funciona muy bien, logro una precisión y estabilidad extremadamente buena que con otro tipo de circuitos no sería posible.

Precisamente te doy una idea para tus mediciones, programa una muy simple rutina para que PIC genere una señal de salida en uno de sus pines con una frecuencia X por ejemplo 100Hz, si programas correctamente puedes medir la señal con un buen osciloscopio o un un buen frecuencímetro y verás que es sumamente exacta y estable.

la precisión depende mucho del programador, debes tomar en cuanta que instrucciones usas, en el ejemplo que pones la instrucción BTFSS no siempre dura lo mismo, varia entre uno o dos ciclos de máquina dependiendo de si la condición se cumple o no, y hay que compensar estos tiempos variables, hay que tomar en cuenta la latencia de interrupción (si usas interrupciones), los retardos al inicio del PIC, las rutinas de configuración al principio del programa, que los retardos sean muy exactos... etc....

 

[silicon blood]

en el ejemplo que pones la instrucción BTFSS no siempre dura lo mismo, varia entre uno o dos ciclos de máquina dependiendo de si la condición se cumple o no

Por dios que idiota soy!! Disculpa, con razon me habian mencionado que hay instrucciones que duran dos ciclos y tal y yo decia pero que tiene que ver? El codigo real en el PIC No es ese me he equivocado al escribirlo aqui, a lo mejor fue un lapsus o estaba pensando en esta intrucción cuando lo escribí. De verdad disculpen todos, la instrucción que uso realmente es BSF.

Voy a editar el primer mensaje. Gracias por la información.

 

[silicon blood]

No toda la información de los micros está en la hoja de datos, mucha información la ponen aparte en los "reference manuals":
http://www.microchip.com/TechDoc.aspx?type=ReferenceManuals

Por ejemplo, en el pdf "Architecture - PICmicro Mid-Range MCU Family" habla algo de arquitectura del micro (ciclo de oscilador, de instrucción, pipeline):
http://ww1.microchip.com/downloads/en/DeviceDoc/31004a.pdf

Acá habla de en qué fase del clock se leen/escriben los puertos (sección 9.10.2):
http://ww1.microchip.com/downloads/en/DeviceDoc/31009a.pdf

En fin... hay para entretenerse.



Veo que usas 2 pics, hay que tener en cuenta también la capacidad de entrada del pic que lee el intervalo de tiempo, el tiempo de subida/bajada que puede generar el pic generador, y los umbrales para detectar '0' y '1' del lado del pic lector.
Mira la figura 9-7/tabla 9-3 (página 56) de la hoja de datos del pic16f84a.
También la tabla 9-2 (página 51) -> ¿que te parece que conviene usar, schmitt trigger o ttl buffer?, ¿lo mismo para receptor y transmisor o usar ttl buffer para uno y schmitt trigger para el otro?

Fuera de eso, en la parte práctica no creo que logres una precisión mucho mejor que algunos Tcy (ciclos de instrucción = 4 * Tosc). Así que si precisás mayor precisión vas a tener que pensar en solucionarlo de otra forma.

¿Pensaste en usar algún pic con un módulo ccp? (en modo captura).

Ardogan he leido los manuales y encontré en el manual 31009a en la página 15 que la operacion de escritura en el puerto sucede al final del Tcy, no especifican cuando exactamente, ahora en la hoja de datos me parece que dicen algo diferente, ahora que leo con detenimiento veo que la figura 9-7 que dice "CLKOUT AND I/O TIMING" dice que el i/o pin (output) está al final de Q1 que sería el primer ciclo de OSC1. No se, puedes revisar eso? Pero sigo sin resolver el motivo exacto de la variación en los ciclos medidos. Por qué 2 a 3 ciclos más, por qué nunca ni de casualidad dá 32 como debe ser? hay algo extraño.

Respecto al ST o el buffer, yo usé flip flops para asegurar el disparo de las señales provenientes del PIC generador, en realidad los usé por motivos de generalización del diseño, no estaba seguro de que iba usar como señales de start y stop, podian ser pulsos y ser asíncronos, y en otros circutos del mismo tipo los usan con frecuencia.

Por ultimo lo del módulo CPP no tenia ni idea de su existencia! ahora es que me entero y no he leido de que se trata... Ahora chequeo y te aviso. Gracias por ese dato.

Adjunto el circuito. EDITO: El circuito se volvió algo más complejo de lo necesario pero esto se debe a la escasez de componentes en mi país así que me las tengo que ingeniar con lo que consigo.

basicamente el PIC de arriba cuando se presiona el pulsador genera la señal por RB6, lo que activa el primer FF, lo que cambia el estado de la puerta XOR que deja pasar la señal de reloj hacia el contador, este comienza a contar y cada 16 pulsos manda una señal a RA4, en realidad ahi va un transistor en medio, ya que la señal que bota el contador es muy pequeña y así no la capta el PIC. Cuando el PIC generador manda un high por RB7 la puerta XOR se va a low y el contador ya no recibe señal del reloj y para el conteo, a la vez la puerta and le dice al PIC que ha acabado el conteo y este procede a realizar los calculos y mostrarlos en el LCD, resetea todo y vuelve a esperar.

 

[Ardogan]

Ardogan he leido los manuales y encontré en el manual 31009a en la página 15 que la operacion de escritura en el puerto sucede al final del Tcy, no especifican cuando exactamente...

Es cierto, no está claro esa información. Lo sugerí por la siguiente figura:


Ahí se ve que en la instrucción BSF PORTx,PINy se cambia el estado del pin al final de Q4, y que la lectura se del puerto se hace al final de Q1/inicio de Q2.

La situación está más clara en la hoja de datos:



La escritura al puerto se hace un tiempo después del flanco de subida de Q1, especificado por el parámetro 17 (TosH2ioV = 125 ns max).
La lectura se hace en el flanco de subida de Q2, precisa un tiempo de establecimiento de 75 ns antes de la lectura (TioV2osH), y luego un tiempo de mantenimiento de 10 ns (TosH2ioI).

....dice que el i/o pin (output) está al final de Q1 que sería el primer ciclo de OSC1. No se, puedes revisar eso?
Pero sigo sin resolver el motivo exacto de la variación en los ciclos medidos. Por qué 2 a 3 ciclos más, por qué nunca ni de casualidad dá 32 como debe ser? hay algo extraño.

Mmmm hay información contradictoria entre los "reference manuals" y la hoja de datos.
En 31004a.pdf sección 4.3 Instruction Flow/Pipelining dice que la lectura se hace en Q2 y la escritura en Q4.
Sin embargo en la hoja de datos figura 9-7 parece que además hay un retardo adicional (parámetro 17 = 125ns) entre el final de Q4 y tener un dato válido en el puerto.
Más aún, viendo la estructura del puerto (figuras 4-x de la hoja de datos), se ve que los flip-flop de salida funcionan por flanco descendente. Esto último indicaría que la escritura se hace en el flanco descendente de Q4.... creo
Pienso que el parámetro 17 es un dato de peor caso que dan para cubrirse, pero yo esperaría que el dato de salida tenga una incertidumbre de tiempo entre flanco de bajada de Q4 y Q1 + parámetro 17 de la instrucción siguiente. Aproximadamente unos 100 + 125ns -> 225 ns, redondeemos a 250 ns (hay tiempos de subida y bajada que pueden variar...).

Fijate que entre el flanco de bajada de Q4 y el de subida de Q2 tenés aproximadamente 1.5 ciclos -> se lo podés descontar por software porque es un retardo conocido.
Todavía no llega a los 2 o 3 ciclos de diferencia que estás observando, pero el faltante podría adjudicarse a tiempos de subida/bajada, umbrales de tensión de lectura, capacidad equivalente de entrada al pic lector, etc.
Podrías comprobar si el tiempo faltante se debe a esto conectando directamente el pic generador al pic lector, acortando longitud de cables entre los pics, etc.

///////////////////////////////
En fin, la idea creo que no es hacer el cálculo exacto en nanosegundos de cuanto tiempo pasa entre que se ejecuta la instrucción de lectura y el puerto realmente se lee o lo mismo para escritura.
Pero sí viendo esos tiempos tener una idea a ojo de que es lo que se puede lograr, 100 nanosegundos me parece un límite razonable.

Por ultimo lo del módulo CPP no tenia ni idea de su existencia! ahora es que me entero y no he leido de que se trata... Ahora chequeo y te aviso. Gracias por ese dato.

Sí, creo que la solución más práctica sería usar un micro con ccp. Ojalá puedas conseguirlo. Hay varios pic16f que lo tienen.

Una nota de aplicación muy sencilla pero que sirve de introducción:
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1824&appnote=en011064

 

[silicon blood]

Hola Ardogan veo que tenemos la misma duda al leer ambos documentos, puede que sea como dices, que el parámetro 17 sea el mas pesimista y el de el manual algo mas cercano a lo ideal, en todo caso, ayer estuve analizando mucho el circuito, y he encontrado una posible fuente de error mucho mayor y por eso es que no nos cuadra, si puedes ver el circuito, el transistor bjt a la salida de la puerta xor debe de ser causante del problema, fijate que al pasar de alto a bajo la puerta xor el transistor en lugar de pasar de saturación a corte de inmediato, seguramente las capacitancias de union y parásitas (protoboard) hacen que se tarde mucho mas en cortarse, lo mismo debe suceder mas adelante con el jfet y creo que eso le da unos ciclos extra al contador. Que te parece?


Módulo CPP: anoche estuve leyendo sobre el módulo, parece muy util para estas situaciones pero me parece que está limitado a la frecuencia de trabajo del PIC, tambien se puede usar una fuente externa de reloj para el timer1 pero me imagino que no puede exceder la frecuencia del PIC que para el caso del 16F877A en cambio los contadores son mucho mas rápidos y me dan posibilidades de mejorar la resolución.

 

[Ardogan]

Primero que nada, si la intención es medir cuanto tiempo tarda una rutina en ejecutarse creo que lo más práctico es lo que propuso BKAR, usar el stop watch del mplab sim.

A mí también me gusta darle vueltas a las cosas, y analizar en qué flanco del reloj se escribe o leen los puertos, etc, etc; pero la realidad es que a veces no hay que enredarse y hacer lo que está más a mano.
Si uno quiere ver cuánto tarde en ejecutarse una rutina, no creo que importe una resolución superior a +/-1Tcy.

Ahora, si uno está manejando un sistema de medición de distancia por láser donde cada nanosegundo cuenta, entonces sí, a exprimir los tiempos a fondo. Y ahí ni siquiera se usa un pic, más probablemente un FPGA... en fin.

//////////////////////////
Respecto del circuito, el hardware no es mi fuerte, pero no creo que haya problemas con que las compuertas metan retardos (son pequeños), y los transistores están con resistores chicos, así que no esperaría problemas de capacidad parásita.

De hecho podrías eliminar los transistores, los flip-flop y la xor si usas la pata con la que parás la cuenta (RB7) y la señal de reloj a la and, y la salida de la and a la entrada de reloj del contador.
Cuando RB7 se ponga a 0 la and va a inhibir la señal de clock al contador y se para la cuenta, y ahí podés leer la cuenta con el otro pic.

/////////////////////////
Respecto del módulo CCP, realmente no creo que tengas una mejor resolución de tiempo usando instrucciones sueltas del micro que usando un módulo de hardware preparado para eso. Trabaja con el timer1 que acepta como máxima frecuencia de entrada Fosc/4 = Fcy -> 1 ciclo de instrucción, que debería ser suficiente para medir tiempos de ejecución de un pic.

///////////////////////
Conclusión, y por favor no lo tomes a mal, pero mi recomendación es que no te sigas complicando y usa el stopwatch del mplab sim para medir tiempos de ejecución de rutinas.
Y si querés medir otros tiempos de dispositivos externos al pic con precisión y mayor resolución, para eso está el CCP combinándolo con un cristal de la mayor frecuencia que te permita el PIC.
Pero con cualquier sistema digital es imposible lograr una resolución mejor que la frecuencia de reloj utilizada.

Suerte y que la fuerza te acompañe

 

[silicon blood]

Conclusión, y por favor no lo tomes a mal, pero mi recomendación es que no te sigas complicando y usa el stopwatch del mplab sim para medir tiempos de ejecución de rutinas.
Y si querés medir otros tiempos de dispositivos externos al pic con precisión y mayor resolución, para eso está el CCP combinándolo con un cristal de la mayor frecuencia que te permita el PIC.
Pero con cualquier sistema digital es imposible lograr una resolución mejor que la frecuencia de reloj utilizada.

Si, el objetivo es medir tiempos externos al PIC, es un TIC (time interval counter) que es una variación o derivado de los TDC (time to digital converter) lo que quiero hacer al final, est es un prototipo básico que no pretende tener mucha resolución ni precisión sino que es más con fines educativos si se quiere.

Estoy tratando de usar el stopwatch de mplab pero tengo que modificar el codigo un poco para no tener que emular todas las señales por que se vuelve algo complicado.

Si tengo muy en cuenta que no voy a tener nunca una resolución mayor a un ciclo interno, solo que esto que está sucediendo es algo muy curioso como bien sabes. Pero lo que pienso hacer para obtener una mayor precisión en un futuro es agregar un preescalador, con la ayuda de un ADC y un circuito de tipo Time to Amplitude Converter, obtener una resolución de sub-ciclos, es decir mucho menor a un ciclo. Entonces el circuito anterior (mejorado) sería el contador digamos que del nible alto osea a largo plazo (unos cuantos uS) y el TAC del nible bajo osea (unos cuantos nS). Por eso mi fe en este pequeño, estupido circuito muy tonto...

Que la [LATEX]m\vec{a}[/LATEX] te acompañe a ti tambien.

PD: Buena idea de como simplificar el circuito, la cuestion es que yo lo tengo pensado para recibir pulsos y no señales estables como la que bota el PIC, pero con fines de prueba podria pasar a esa arquitectura y probar. Cualquier cosa les cuento. Gracias de nuevo.

 

[Ardogan]

Ah ok, entonces no es sólo para medir tiempos de ejecución del pic sino tiempos en el mundo físico/real.

CCP (ya te lo dije no? ). El único punto flaco respecto a usar un contador externo es que no vas a poder medir con la resolución de Fosc sino con la de Fcy (4 veces menor).
Pero vas a poder capturar pulsos (no hace falta que sean como decís señales estables fáciles de manejar por software porque el módulo es hardware), cambiar a voluntad si querés detectar flanco ascendente/descendente, medir tiempos "largos" (es decir, mayores a los que permite el desborde del contador, milisegundos, segundos, minutos...).

....
Pero lo que pienso hacer para obtener una mayor precisión en un futuro es agregar un preescalador, con la ayuda de un ADC y un circuito de tipo Time to Amplitude Converter, obtener una resolución de sub-ciclos, es decir mucho menor a un ciclo. Entonces el circuito anterior (mejorado) sería el contador digamos que del nible alto osea a largo plazo (unos cuantos uS) y el TAC del nible bajo osea (unos cuantos nS). Por eso mi fe en este pequeño, estupido circuito muy tonto...

Ah... eso es interesante. A ver si entiendo bien: querés usar un integrador (con un operacional por ejemplo) con una entrada de tensión cuadrada, que a la salida daría una rampa:



Y entonces al detectar el pulso parar la integración y leer con el ADC el nivel de la señal triangular (mal llamada rampa en el dibujo que hice con el ArdoCad).
Esta bien, me gusta la idea . Tiene sentido porque a la resolución de tiempo de la señal de reloj se agrega la del ADC.
Espero tus futuros comentarios para ver si lo pudiste implementar .
Suerte!!!

 

[silicon blood]

Disculpen la demora, no me habia podido dedicar al circuito en estos dos días, pero son Buenas noticias las que traigo, el PIC resulta ser tan preciso como dicen que es, el problema en circuito tal y como lo había planteado en el mensaje #13 era que se trataba de cortar la señal de reloj hacia el contador a travez del bjt y el jfet, pero esto no sucedia de la forma ideal osea, instantaneamente, por eso es que el contador alcanzaba a contar los ciclos que transcurrian mientras se desvanecía la señal de reloj por debajo del umbral minimo para ese ic.

Lo he resuelto de la forma mas rara posible, el contador 74HCT193 posee una caracteristica de poder presetear el valor inicial del contador, por eso tiene 4 entradas (D0...D3) y 4 salidas (Q0...Q3), una pata llamada PL activa el preset poniendo la salida igual a la entrada por lo tanto desactiva el reloj, es decir, para el conteo, lo cual es justo lo que necesito, por lo tanto conecté las entradas a las salidas de manera que cuando active la para PL las entradas sean algo como FIFO'S de las salidas. Lo cierto es que funciona, ahora obtengo el resultado esperado en el 99% de las pruebas.

Gracias a todos en especial a Ardogan, adjunto el nuevo circuito.

PD: Pregunto a quien pueda interesar, ¿sería conveniente abrir otro hilo donde deje este circuito y código como un aporte? el circuito sirve para medir ciclos (hasta 255) consumidos entre dos señales en general y mostrarlos en un módulo LCD 16x2.

 

[Ardogan]

Buena solución!!!, tenías razón al final con los transistores .