Vamos ter uma visão geral de alto nível do que um osciloscópio possui:
Primeiro, temos o front-end analógico. Aqui temos uma rede de correspondência de impedância para as sondas (mas as sondas também terão que ter uma parte de correspondência de capacitância), seção de atenuação (muito importante, para não sobrecarregar o ADC ou permitir a entrada de altas tensões), acionamento e conexão a conversor analógico para digital. Não vou falar muito sobre isso, já que não sou muito bom com coisas analógicas, mas o ponto principal é: não há nada que possamos fazer com Pi nesta seção.
Em seguida, temos a parte do conversor analógico para digital. Você precisará de pelo menos um ADC para cada canal. Mais pode ser usado para uma taxa de amostragem mais alta. No escopo tradicional, o ADC está conectado a um dispositivo ASIC ou FPGA. Eles são usados porque os computadores tradicionais não são em tempo real o suficiente (e não confundem em tempo real com rápido!) Para processar os dados fornecidos pelo ADC. Esses dados são armazenados em algum tipo de RAM. Alguns dispositivos usarão RAM estática, enquanto outros usarão RAM dinâmica. Em geral, a abordagem SRAM é mais tradicional e vista em grandes fabricantes, enquanto o uso de DRAM parece ser a abordagem mais nova vista nas unidades mais baratas projetadas na China.
A quantidade de RAM e sua velocidade determinarão quantas amostras podem ser armazenadas. Quase sempre o ADC será um ADC de 8 bits, portanto, por exemplo, uma megasample precisará de 8 b vezes 100000 = 8 Mb ou 1 MB de RAM. Para um MSa / s, precisaremos de RAM que possa funcionar nessa velocidade. Hoje, isso deve ser relativamente fácil de obter. O FPGA normalmente dirige a RAM diretamente e é responsável por armazenar dados nela. Ele funciona preenchendo a memória de amostra enquanto ainda há espaço vazio e substituindo-o quando estiver cheio. Quando houver vários ADCs por canal, o FPGA os definirá para que primeiro comece a amostragem, depois no próximo relógio, segundo e assim por diante. Quando eles terminam a amostragem, a amostra do primeiro ADC será gravada primeiro na memória, depois a segunda amostra do ADC. Isso fará com que pareça que os ADCs estão amostrando mais rapidamente do que realmente são.
O próximo ponto desta seção é que as amostras devem ser equidistantes no tempo. Este é o principal problema com o uso de PCs em osciloscópios e a razão pela qual FPGAs e ASICs são predominantes. Se algumas amostras estiverem atrasadas ou adiantadas, a imagem representada na tela estará incorreta.
Nesta parte, vemos o primeiro uso possível do Pi. Se a taxa de amostragem for baixa o suficiente, poderemos conduzir os ADCs diretamente do Pi e armazenar seus resultados na RAM do Pi. A rapidez com que podemos ir depende da maneira como o ADC está conectado ao Pi e de como o Pi faz sua E / S. Pelo que li, a velocidade mais alta das portas I ^ 2C do Pi é de 150 MHz (o que seria mais fácil de obter no GNU / Linux é outra questão), enquanto a velocidade padronizada mais alta é de 5 MHz e para o SPI a velocidade mais alta em Pi é 250 MHz. Não tenho certeza de qual é a velocidade padrão mais alta do SPI, mas espero que esteja em algum lugar na faixa de 100 MHz no máximo.
Portanto, em teoria, temos velocidade mais do que suficiente no Pi para executar um ADC na faixa de MSa / s baixa. Sinto que a velocidade da RAM não será um problema aqui, mas não tenho dados para fazer backup disso. Se for esse o caso, teríamos um grande benefício em relação aos escopos comuns: haveria uma quantidade muito grande de memória de captura disponível. Por exemplo, se dedicarmos 32 MiB de RAM ao programa para memória de amostra e tivermos dois canais, isso nos deixará com 16 MiB para cada canal ou um pouco mais de 134 Mb ou 134 megasamples por canal. Isso é algo que até hoje muitos osciloscópios não possuem.
A desvantagem é que precisaríamos de modificações pesadas no sistema operacional para poder obter amostras precisas aqui. Eu não tenho nenhuma experiência com Linux em tempo real, então não sei como isso seria fácil.
De qualquer forma, vamos ao próximo passo. Portanto, temos um sistema de amostragem que preenche a RAM. A próxima parte é o gatilho. O gatilho está intimamente relacionado à taxa de atualização da tela. O que basicamente faz é encontrar uma amostra interessante e mantê-la na memória. Quando o osciloscópio é acionado, ele continua a amostragem após o acionamento até encher a memória e envia-o para ser processado e exibido na tela. Enquanto os dados estão sendo processados, o sistema de amostragem, se frequentemente congelado, aguarda a exibição dos dados. É por isso que os escopos low-end têm taxas de atualização mais baixas, enquanto os escopos high-end têm exibições especiais de alta taxa de atualização e gastam muito menos tempo aguardando a exibição dos dados.
Nesta seção, haverá frequentemente outro ASIC ou FPGA que processará o sinal nas amostras, qualquer decodificação de protocolo se o escopo o suportar e realmente direcionar o próprio monitor.
Esta é a parte em que, pelo que vejo, o Pi pode realmente brilhar. Ele pode exibir uma bela exibição de 1920 x 1080 (enquanto os escopos geralmente estão no terreno inferior a 800x600) e pode decodificar muito bem o protocolo. O único problema que vejo é a velocidade e como o processamento afetaria o tempo de espera. Se optarmos por uma baixa taxa de atualização, podemos obter um analisador lógico muito bom com ele.
Finalmente, uma palavra sobre os osciloscópios USB e por que o USB geralmente é ruim para esse tipo de projeto: O osciloscópio USB tradicional faz entrada e amostragem e envia os dados de amostragem ao PC para processamento para o qual existe um aplicativo host. Basicamente, algo muito semelhante seria feito com o Pi também. Geralmente, os aplicativos para PC são mal projetados e cheios de bugs. A próxima parte ruim é o próprio USB. Ele é anunciado como barramento rápido, que pode fazer 480 Mb / s no modo "Alta velocidade". A verdade é que é extremamente raro encontrar um controlador USB capaz de suportar velocidades tão altas (a média parece estar em torno de 250 Mb / s do que eu vi) e que, como um protocolo, não é muito adequado para qualquer real aplicação em tempo real. Primeiro, ele é compartilhado entre todos os dispositivos em um hub (e o Pi possui apenas uma porta USB à qual o Ethernet + USB Hub está conectado), possui uma sobrecarga relativamente alta (quando comparado ao SPI) e alta latência (lembre-se de que a 1 MSa / s cada amostra dura apenas 1 µs, portanto, devemos ter memória em nossa placa, pois não podemos enviar amostras em tempo real via USB). Finalmente, o uso do USB tornaria a aquisição de dados parte do escopo para ser apenas outro osciloscópio USB e é aí que perdemos qualquer benefício do uso do Pi: os computadores de mesa tradicionais são muito mais comuns, mais rápidos, mais fáceis de obter e têm recursos USB muito melhores.
EDIT
Eu li um post relativamente recente de Gert van Loo e, segundo ele, taxas realistas para o I ^ 2C de Pi são 400 kHz e para o SPI são 20 MHz.
