Que levanten la mano los que tienen osciloscopio

[cucaracha]

Vamos a ver si ahora se me entiende y no tengo que recurrir a un dibujo...

A ver, piensa en un ciclo de una onda. Un sólo ciclo. Ahora divide ese ciclo en 100 puntos por ejemplo, equidistantes en el tiempo. Dividimos el ciclo en 100 muestras. La primera tomada un tiempo T después del paso por cero, la segunda un tiempo T después de esa muestra... y así hasta la última, que sería un tiempo 100T después del disparo, que correspondería al cero, al final del ciclo.
Bien, por tanto tenemos 100 puntos que si los unimos formarían un ciclo.
Ahora viene el proceso que comentaba.
Imagina que en lugar de tomar esos puntos de la misma onda lo tomamos de 100 ciclos distinto...
Paso por cero, disparo, esperamos un tiempo T y muestra.
Paso por cero de otro ciclo ya, esperamos un tiempo 2T y muestra.
Y así hasta tomar 100 muestras de ondas distintas.
Que pasa si ahora uno esos cien puntos. Que resulta... Pues un ciclo.
Problema... que aun pudiendo usar un conversor de velocidad igual que la onda a muestrear, ese tiempo T hay que controlarlo. Osea, que si el micro funciona a 100ns por ciclo de intrucción, ese tiempo será el mínimo que podremos usar para ese T.
Por lo tanto... si es que se hace con micro, a 40MHZ(10MIPS) sería, si obtenemos 84muestras, una frecuencia máxima de 125KHZ.
Ahora... usando esto... como se podría desarrollar sin el micro y más veloz?? Ese es el dilema.

Esto sólo es una idea que no se si será la más adecuada... simplemente una idea.

Si alguien tiene un método, o una simple idea... pues que la comente sin miedo... siempre saldrá algo, aunque ese algo sólo sea descartar esa idea o método.

Y a ver Elenita, que se podría hacer con ese VHDL que tu dominas?? A que velocidad fucionan esos cacharros, los FPGA y demás...??


Saludos!!

[Nocturno]

Te he entendido perfectamente, pero no tengo ni idea de cómo hacerlo.

[cucaracha]

Un saludo!!

[cucaracha]

[Elena2000]

AH coño!! (perdón)
Ya, ya desperté!!


A ver, dame un minuto para releerme de nuevo el chorizo de mensaje tuyo y te contesto con lo de la FPGA. Un sg, plis.

[cucaracha]

Jajajajaja
Te distes por aludida!! Eres rápida sí!!


Tenía preparado otro post por si no lo pillabas jejejeje


jajajaja

Saludos!!!

[Elena2000]

Ya me he espabilido.



A ver, lo primero: el concepto de ciclo de instrucción es característico de los microprocesadores, por ejemplo de los PICs, pero los dispositivos programables como las FPGAs no utilizan instrucciones,
sino "procesos". Además, las FPGA pueden realizar varias operaciones en el mismo ciclo de reloj, cosa que los PICs no pueden porque son monoinstrucción.

Bueno,a lo que voy. Para aclararme yo pispa con respecto a lo que pretende hacer el cuca este
En definitiva, veo que necesitas un contador que mande la señal a 100 punteros; y cada uno de ellos esté preparado para tomar la muestra de la onda con un retardo determinado con respecto a la señal inicial. Es decir, el primero mida en el tiempo T, el segundo en el tiempo 2T y así sucesivamente. Tendrías que pensar en hacer funcionar en paralelo esos 100 punteros a la vez,y que todos tomaran el dato en el mismo ciclo de instrucción. Hacer eso con una FPGA no es demasiado complicado, porque además hay muchísimos puertos de entrada/salida y celdas para configurar lógica secuancial a porrillo, pero un pic solito haciendo esto... instrucción por instrucción,.... no se no se.... un multiplexor, quizás?

Voy a dormir otro rato......

[cucaracha]

Gracias Elena!

Mira, esa sería la idea más o menos... la verdad es que no sabemos ni nosotros mismo lo que queremos y como lo queremos aun jejejeje
Lo de hacerlo todo en el mismo ciclo tiene un problema... donde se guardan los resultados??
Es posible que el FPGA sea lo suficientemente rápido como para tomar muestras de un AD en un ciclo (por el AD no problem, los hay muyyy rápidos)... Pero eso, donde guardamos los resultados??? Las memorias si están limitadas en velocidad... Las mas rápidas que encontramos son de unos 133MHz, fifos sincronas.
Y tampoco es plan de usar 84 conversores jejejejeje
La cosa está complicadita como verás...
Por eso lo de hacerlo en ciclos distintos.
A lo de velocidad me refería a que tiempo T minimo sería posible conseguir, más o menos, para hacernos una idea de lo que se podría muestrear.

Un besote, bella durmiente!

[Elena2000]

Hola hola! (me ha gustado lo de bella durmiente, jejeje)

A ver, meto bazo otra vez, que ya me he vuelto a resetear.

Estaba pensando que igual sería interesante usar una memoria  SRAM en lugar de una FIFO, pero claro, la pega gorda sería controlar el direccionamiento de la memoria SRAM y además la captura de datos, todo a la vez... Lo bueno de las fifo son que tienen los punteros de lectura y escritura ya implementados internamente. Las FIFO se controlan muy bien con máquinas de estado. En una FPGA de la serie 6000, por ejemplo, se podría implementar el control de adquisición y de la FIFO (o varias FIFO, mejor), y un divisor de frecuencia para el muestreo. De todas formas, este dispositivo, igual que el pic, estará gobernado por el ciclo de reloj externo que le pongas, o sea que los tiempos son similares. Lo que podríais pensar es en capturar datos en varias ciclos, pero no un dato por ciclo, sino un conjunto de datos por ciclo, almacenarlos en la memoria y después reconstruir la señal con todos ellos.

Uff... me pica este proyecto. Me voy a dormir otra vez....

[Sispic]

Los puntos de referencias se adquieren de muchos ciclos para construir una imagen de pantalla .




El muestreo en tiempo real es un acercamiento más directo del muestreo. Es también la única manera capturar acontecimientos (no repetitivos) transitorios. Desafortunadamente, las tarifas bajas de la muestra en la mayoría de osciloscopios de hoy no son adecuadas apoyar la anchura de banda análoga completa de los instrumentos. Una solución común a este defecto es el muestreo en tiempo real interpolado, que dibuja en los circuitos de la conversión detrás de los canales inusitados de la entrada para ampliar el funcionamiento del muestreo de los instrumentos de varios canales. La interpolación de dos canales doblará la tarifa en tiempo real de la muestra; usando cuatro canales la cuadruplicará. Desafortunadamente, la interpolación inhabilita los canales de soporte, haciendo un alcance four-channel en una herramienta básica del uno-canal. La mayoría de los usuarios del alcance necesitan dos o más canales para casi cada medida que hacen.

La mayoría del uso de DSOs una combinación del tiempo real y ET de las técnicas de muestreo.  En frecuencias más bajas la adquisición en tiempo real proporciona bastantes puntos de la muestra para definir la forma de onda.  Pues un alcance acerca a su anchura de banda análoga, cambiará automáticamente a ET.  Es decir un DSO convencional negocia de capacidades transitorias críticas de la captura para alcanzar su anchura de banda especificada.

Dios nos coja confesados .

[cucaracha]

Eto etá traducío no?

Bueno... eso es a lo que yo me refería, pero ahora con imagen incluida. Tomar un muestra de ciclos distintos, cada vez a un tiempo mayor desde el paso por cero mayor.

Saldudos!!

[Elena2000]

La leche.............

Bueno vamos por partes.... yo veo que vamos a necesitar dos pics para distribuir el algoritmo :
1. adquisición de datos interpolados, control del ADC
2. almacenamiento y recuperación de datos en memoria, display de los resultados

¿habéis pensado en usar dos pics?

"Saldudos", Cuca!!

[Sispic]

El problema no estaria en usar 2 pics , el problema de momento es coger el maximo de muestras posibles con el .

por ejemplo con un 18Fxxx a 10MIPS se consigen 5MSPS , con un dspic 30Fxxx a 30MIPS salen 15MSPS .

La idea seria llegar a 100MSPS ó cerca ya que de esta manera se obtendrian 10 muestras de cada ciclo de 10mhz en la entrada (vastante pasable)

Entonces ya que con nuestros pics es imposible , solo queda la solucion de usar un hardware externo que guarde la info en una ram(x) y despues que el pic pueda tener acceso a ella para leerla .

Elena , cuentanos mas cositas de las FPGA . Estarian a nuestro alcance para programarlas ? , como se graban , algun enlace para ver algun dataSheet.

se podria hacer con ellas ?

Ala... ya tienes trabajo .

[Elena2000]

Encantada. Será un placer.

A ver, lo primero deciros que las FPGAs se pueden programar a partir de un esquemático, o sea que no hace falta saber VHDL para programarlas. El software que hay comercial dispone de una captura de esquemáticos donde se dibuja el diseño con todos los componentes hardware y la disposición de los pines de entrada/salida. Una vez que se tenga el esquemático hecho y simulado (esto es opcional, claro), se pasa al proceso de "síntesis", que viene a ser como una compilación, para obtener un fichero de configuración de nodos, el .hex de los pics, y ese fichero se baja a la FPGA para configurarla. La forma de programar físicamente el dispositivo normalmente es con un cable JTAG conectado al puerto serie del PC. Al otro lado del JTAG se conecta un entrenador donde se pincha la FPGA y una serie de componentes pasivos que hacen falta para hacer la interfaz y la conversión de protocolos a la hora de programar la FPGA.
Supongo que Cuca en la facultad tendría acceso a algún programador de FPGA, no, Cuca? Yo tengo uno, el que utilicé para hacer mi tesis doctoral, con una Xilinx de la familia 4000k. Pero está algo obsoleto... De todas formas, no sería problema intentar actualizarlo o mejor, podría conseguir en mi empresa algo más actual. Si queréis empiezo a moverme, en serio.

Tendríamos que ver exactamente qué bloques tiene el osciloscopio para determinar qué parte se hace en la FPGA y qué parte se hace en el PIC. Por ejemplo, veo que podríamos necesitar:
* Un bloque para acondicionamiento de la señal
* Un bloque de control
* Memoria para guardar los datos
* PIC para la comunicación con un display
* Display (el LCD del nokia, en nuestro caso)

La parte de acondicionamiento de la señal, entiendo que no sería difícil y seguro que esto ya lo tenéis más que trillado, no? La memoria pues pueden ser la FIFO, o varias FIFO. La parte de control se podría meter toda en la FPGA, para que controlara:
- El reloj para las tomas de muestras
- detectar la condición de disparo
- Algoritmo de interpolación que habéis comentado (y que ha pintado tan chulo Sispic)
- La escritura y lectura a la FIFO
- la comunicación con el PIC para ver la lectura de los datos

Entonces, chicos.... podemos empezar a pensar cómo implementar la parte de adquisición según los algoritmos de interpolación, porque eso es la parte más chunga de todo esto, no?

Os toca a vosotros. Despertad, bellos dormilones!! Yo mienstras miro a ver si consigo hacer una estimación de tiempos, ¿podría funcionar a 100 MHz?

[Nocturno]

Elena, ¿a qué velocidad trabaja un bicho de esos?, es que me pica el gusanillo de nuevo y necesito saberlo.