Diamo una panoramica di alto livello di ciò che ha un oscilloscopio:
Per prima cosa abbiamo il front-end analogico. Qui abbiamo una rete di adattamento di impedenza per le sonde (ma le sonde dovranno avere anche una parte di adattamento della capacità), sezione di attenuazione (molto importante, quindi non sovraccarichiamo l'ADC o lasciamo entrare alte tensioni), attivazione e connessione a convertitore da analogico a digitale. Non parlerò troppo di questo, dal momento che non sono troppo bravo con le cose analogiche, ma la linea di fondo è: non c'è niente che possiamo fare con Pi in questa sezione.
Successivamente abbiamo la parte del convertitore da analogico a digitale. Avrai bisogno di almeno un ADC per ciascun canale. Altro può essere utilizzato per una frequenza di campionamento più elevata. Nell'ambito tradizionale, l'ADC è collegato a un dispositivo ASIC o FPGA. Vengono utilizzati perché i computer tradizionali non sono abbastanza in tempo reale (e non confondono in tempo reale con velocemente!) Per elaborare i dati forniti dall'ADC. Tali dati vengono quindi memorizzati nella RAM di qualche tipo. Alcuni dispositivi utilizzeranno la RAM statica, mentre altri utilizzeranno la RAM dinamica. In generale, l'approccio SRAM è più tradizionale e visto nei produttori di grandi nomi, mentre l'uso della DRAM sembra essere l'approccio più nuovo visto nelle unità progettate in Cina più economiche.
La quantità di RAM e la sua velocità determineranno quanti campioni possono essere memorizzati. Quasi sempre l'ADC sarà ADC a 8 bit, quindi per esempio un megasample avremo bisogno di 8 b volte 100000 = 8 Mb o 1 MB di RAM. Per un MSa / s, avremo bisogno di RAM che possa funzionare a quelle velocità. Oggi dovrebbe essere relativamente facile da ottenere. L'FPGA di solito guida direttamente la RAM ed è responsabile della memorizzazione dei dati al suo interno. Funziona riempiendo la memoria di esempio mentre c'è ancora spazio vuoto e quindi sovrascrivendolo quando è pieno. Quando sono presenti più ADC per canale, l'FPGA li imposterà in modo che inizi prima il campionamento, quindi il secondo di clock successivo e così via. Al termine del campionamento, il campione del primo ADC verrà prima scritto in memoria, quindi il secondo campione ADC. Questo farà sembrare che gli ADC stiano campionando più velocemente di quanto non siano in realtà.
Il prossimo punto di questa sezione è che i campioni dovrebbero essere equidistanti nel tempo. Questo è il problema principale con l'uso di PC negli oscilloscopi e il motivo per cui FPGA e ASIC sono predominanti. Se alcuni campioni sono in ritardo o in anticipo, l'immagine rappresentata sullo schermo sarà errata.
In questa parte vediamo il primo possibile utilizzo del Pi. Se la frequenza di campionamento è abbastanza bassa, potremmo essere in grado di guidare gli ADC direttamente dal Pi e archiviare i loro risultati nella RAM di Pi. La velocità con cui possiamo andare dipende dal modo in cui l'ADC è collegato al Pi e da come Pi esegue il suo I / O. Da quello che ho letto, la massima velocità delle porte I ^ 2C di Pi è di 150 MHz (quanto sarebbe facile raggiungere GNU / Linux è un'altra domanda) mentre la massima velocità standardizzata è di 5 MHz e per SPI la massima velocità in Pi è 250 MHz. Non sono sicuro di quale sia la massima velocità standard di SPI, ma mi aspetto che sia al massimo da qualche parte nella gamma di 100 MHz.
Quindi in teoria abbiamo una velocità più che sufficiente su Pi per far funzionare un ADC in un range MSa / s basso. Ho la sensazione che la velocità della RAM non sarà un problema qui, ma non ho dati per eseguirne il backup. In tal caso, avremmo un grande vantaggio rispetto ai normali ambiti: ci sarebbe una grande quantità di memoria di acquisizione disponibile. Ad esempio, se dedichiamo 32 MiB di RAM al programma per la memoria di campionamento e disponiamo di due canali, il che ci lascerebbe con 16 MiB per ciascun canale o poco più di 134 Mb o 134 megasample per canale. Questo è qualcosa che ancora oggi molti oscilloscopi non hanno.
L'aspetto negativo è che avremmo bisogno di pesanti modifiche al sistema operativo per poter ottenere un campionamento accurato qui. Non ho alcuna esperienza con Linux in tempo reale, quindi non so quanto sarebbe facile.
Comunque, andiamo al passo successivo. Quindi abbiamo un sistema di campionamento che sta riempiendo la RAM. La parte successiva è il grilletto. Il trigger è strettamente correlato alla frequenza di aggiornamento dello schermo. Ciò che fondamentalmente fa è trovare un campione interessante e tenerlo in memoria. Quando viene attivato l'oscilloscopio, continua il campionamento dopo l'attivazione fino a quando non ha riempito la memoria e quindi lo invia per l'elaborazione e la visualizzazione sullo schermo. Durante l'elaborazione dei dati, il sistema di campionamento è spesso bloccato e in attesa della visualizzazione dei dati. Questo è il motivo per cui gli ambiti di fascia bassa hanno frequenze di aggiornamento inferiori mentre gli ambiti di fascia alta avranno speciali visualizzazioni di frequenza di aggiornamento elevata e impiegheranno molto meno tempo ad aspettare che i dati vengano visualizzati.
In questa sezione ci sarà spesso un altro ASIC o FPGA che eseguirà l'elaborazione del segnale sui campioni, qualsiasi decodifica di protocollo se l'oscilloscopio lo supporta e guida il display stesso.
Questa è la parte in cui da quello che posso vedere il Pi può davvero brillare. Può guidare un bel display 1920x1080 (mentre gli ambiti sono spesso nella terra secondaria 800x600) e può fare molto bene la decodifica del protocollo. L'unico problema che posso vedere sarebbe la velocità e il modo in cui l'elaborazione influirebbe sui tempi di attesa. Se optiamo per una bassa frequenza di aggiornamento, possiamo ottenere un analizzatore logico davvero valido.
Infine, una parola sugli oscilloscopi USB e sul perché USB in genere è dannosa per questo tipo di progetto: l'oscilloscopio USB tradizionale effettua input e campionamento e invia i dati di campionamento al PC per l'elaborazione per cui esiste un'applicazione host. Fondamentalmente qualcosa di molto simile si farebbe anche con Pi. Di solito le applicazioni per PC sono progettate male e piene di bug. La prossima parte negativa è l'USB stesso. È pubblicizzato come bus veloce che può fare 480 Mb / s in modalità "Hi-Speed". La verità è che è estremamente raro trovare un controller USB in grado di supportare velocità così elevate (la media sembra essere di circa 250 Mb / s da quello che ho visto) e che come protocollo non è molto adatto a nessun reale -applicazione temporanea. Innanzitutto è condiviso tra tutti i dispositivi su un hub (e Pi ha solo una porta USB a cui è collegato Ethernet + Hub USB), ha un sovraccarico relativamente elevato (rispetto a SPI) e una latenza elevata (ricorda che a 1 MSa / s ogni campione dura solo 1 µs, quindi dobbiamo avere memoria sulla nostra scheda poiché non possiamo inviare campioni in tempo reale tramite USB). Infine, l'uso dell'USB renderebbe l'acquisizione dei dati parte dell'ambito come un altro oscilloscopio USB ed è qui che perdiamo tutti i vantaggi dell'utilizzo di Pi: i computer desktop tradizionali sono molto più comuni, più veloci, più facilmente ottenibili e hanno capacità USB molto migliori.
EDIT
Ho letto un post relativamente recente di Gert van Loo e secondo lui, i tassi realistici per I ^ 2C di Pi sono 400 kHz e per SPI sono 20 MHz.
