Tengamos una visión general de alto nivel de lo que tiene un osciloscopio:
Primero tenemos el front-end analógico. Aquí tenemos una red de coincidencia de impedancia para las sondas (pero las sondas también tendrán que tener una parte de adaptación de capacitancia), sección de atenuación (muy importante, por lo que no sobrecargamos el ADC ni permitimos que entren altos voltajes), activación y conexión a Conversor analógico a digital. No hablaré demasiado sobre esto, ya que no soy demasiado bueno con cosas analógicas, pero la conclusión es: no hay nada que podamos hacer con Pi en esta sección.
A continuación tenemos la parte del convertidor analógico a digital. Necesitará al menos un ADC para cada canal. Se puede usar más para una frecuencia de muestreo más alta. En el ámbito tradicional, el ADC está conectado a un dispositivo ASIC o FPGA. Se usan porque las computadoras tradicionales no son lo suficientemente en tiempo real (¡y no confundan en tiempo real con rápido!) Para procesar los datos proporcionados por el ADC. Esos datos se almacenan en la RAM de algún tipo. Algunos dispositivos usarán RAM estática, mientras que otros usarán RAM dinámica. En general, el enfoque SRAM es más tradicional y se ve en fabricantes de renombre, mientras que el uso de DRAM parece ser el enfoque más nuevo visto en las unidades más baratas diseñadas en China.
La cantidad de RAM y su velocidad determinarán cuántas muestras se pueden almacenar. Casi siempre el ADC será ADC de 8 bits, por lo que, por ejemplo, necesitaremos 8 b por 100000 = 8 Mb o 1 MB de RAM. Para un MSa / s, necesitaremos RAM que pueda funcionar a esa velocidad. Hoy, eso debería ser relativamente fácil de obtener. El FPGA generalmente maneja la RAM directamente y es responsable del almacenamiento de datos en ella. Funciona al llenar la memoria de muestra mientras todavía hay espacio vacío y luego sobrescribirla cuando está llena. Cuando hay varios ADC por canal, el FPGA los configurará de manera que primero comience el muestreo, luego en el segundo reloj y así sucesivamente. Cuando terminen el muestreo, la muestra del primer ADC se escribirá primero en la memoria, luego la segunda muestra del ADC. Esto hará que parezca que los ADC están muestreando más rápido de lo que realmente son.
El siguiente punto en esta sección es que las muestras deben ser equidistantes en el tiempo. Este es el principal problema con el uso de PC en osciloscopios y la razón por la cual los FPGA y ASIC son predominantes. Si algunas muestras llegan tarde o temprano, la imagen representada en la pantalla será incorrecta.
En esta parte vemos el primer uso posible de Pi. Si la frecuencia de muestreo es lo suficientemente baja, podríamos controlar los ADC directamente desde el Pi y almacenar sus resultados en la RAM de Pi. Qué tan rápido podemos ir depende de la forma en que el ADC está conectado a la Pi y cómo Pi hace su E / S. Por lo que he leído, la velocidad más alta de los puertos I ^ 2C de Pi es de 150 MHz (lo fácil que sería lograr en GNU / Linux es otra pregunta) mientras que la velocidad estandarizada más alta es de 5 MHz y para SPI la velocidad más alta en Pi es de 250 MHz. No estoy seguro de cuál es la velocidad estándar más alta de SPI, pero espero que esté en el rango de 100 MHz como máximo.
Entonces, en teoría, tenemos una velocidad más que suficiente en Pi para ejecutar un ADC en un rango bajo de MSa / s. Tengo la sensación de que la velocidad de RAM no será un problema aquí, pero no tengo ningún dato que respalde eso. Si ese es el caso, tendríamos un beneficio importante sobre los alcances habituales: habría una gran cantidad de memoria de captura disponible. Por ejemplo, si dedicamos 32 MiB de RAM al programa para memoria de muestra y tenemos dos canales, eso nos dejaría con 16 MiB para cada canal o un poco más de 134 Mb o 134 megamuestras por canal. Eso es algo que incluso hoy en día muchos osciloscopios no tienen.
La desventaja es que necesitaríamos grandes modificaciones en el sistema operativo para poder obtener un muestreo preciso aquí. No tengo ninguna experiencia con Linux en tiempo real, así que no sé lo fácil que sería.
De todos modos, vayamos al siguiente paso. Entonces tenemos un sistema de muestreo que está llenando la RAM. La siguiente parte es el disparador. El disparador está estrechamente relacionado con la frecuencia de actualización de la pantalla. Lo que básicamente hace es encontrar una muestra interesante y guardarla en la memoria. Cuando se dispara el osciloscopio, continúa muestreando después del disparador hasta que se haya llenado la memoria y luego lo envía para ser procesado y mostrado en la pantalla. Mientras se procesan los datos, el sistema de muestreo a menudo se congela y espera a que se muestren los datos. Es por eso que los ámbitos de gama baja tienen tasas de actualización más bajas, mientras que los ámbitos de gama alta tendrán pantallas especiales de tasa de actualización alta y pasarán mucho menos tiempo esperando que se muestren los datos.
En esta sección, a menudo habrá otro ASIC o FPGA que realizará el procesamiento de la señal en las muestras, cualquier decodificación de protocolo si el alcance lo admite y realmente controla la pantalla.
Esta es la parte donde, por lo que puedo ver, el Pi realmente puede brillar. Puede manejar una bonita pantalla de 1920x1080 (mientras que los ámbitos suelen estar en el terreno sub 800x600) y puede decodificar el protocolo muy bien. El único problema que puedo ver sería la velocidad y cómo el procesamiento afectaría el tiempo de espera. Si buscamos una frecuencia de actualización baja, podemos obtener un analizador lógico realmente bueno.
Finalmente, una palabra sobre los osciloscopios USB y por qué el USB es malo en general para este tipo de proyecto: el osciloscopio USB tradicional ingresa y toma muestras y envía los datos de muestreo a la PC para el procesamiento para el cual existe una aplicación host. Básicamente, algo muy similar se haría con Pi también. Por lo general, las aplicaciones de PC están mal diseñadas y llenas de errores. La siguiente parte mala es el propio USB. Se anuncia como bus rápido que puede hacer 480 Mb / s en modo "Hi-Speed". La verdad es que es extremadamente raro encontrar un controlador USB que pueda soportar velocidades tan altas (el promedio parece estar alrededor de 250 Mb / s de lo que he visto) y que, como protocolo, no es muy adecuado para ningún -aplicación de tiempo. Primero se comparte entre todos los dispositivos en un hub (y Pi solo tiene un puerto USB al que está conectado Ethernet + USB Hub), tiene una sobrecarga relativamente alta (en comparación con SPI) y una alta latencia (recuerde que a 1 MSa / s cada muestra dura solo 1 µs, por lo que debemos tener memoria en nuestra placa ya que no podemos enviar muestras en tiempo real por USB). Finalmente, usar USB haría que la adquisición de datos sea parte del alcance de ser solo otro osciloscopio USB y es ahí donde perdemos cualquier beneficio de usar Pi: las computadoras de escritorio tradicionales son mucho más comunes, más rápidas, más fáciles de obtener y tienen capacidades USB mucho mejores.
EDITAR
He leído una publicación relativamente reciente de Gert van Loo y, según él, las tasas realistas para el I ^ 2C de Pi son 400 kHz y para SPI son 20 MHz.
