Ayons un aperçu de haut niveau de ce qu'un oscilloscope a:
Nous avons d'abord le frontal analogique. Ici, nous avons un réseau d'adaptation d'impédance pour les sondes (mais les sondes devront également avoir une partie d'adaptation de capacité), une section d'atténuation (très importante, donc nous ne surchargeons pas l'ADC ou ne laissons pas de hautes tensions), le déclenchement et la connexion à Convertisseur analogique-numérique. Je n'en parlerai pas trop, car je ne suis pas trop bon avec les trucs analogiques, mais le résultat est: il n'y a rien que nous puissions faire avec Pi dans cette section.
Ensuite, nous avons la partie convertisseur analogique-numérique. Vous aurez besoin d'au moins un ADC pour chaque canal. Plus peut être utilisé pour un taux d'échantillonnage plus élevé. Dans la portée traditionnelle, l'ADC est connecté à un périphérique ASIC ou FPGA. Ils sont utilisés parce que les ordinateurs traditionnels ne sont pas assez en temps réel (et ne confondez pas en temps réel et rapide!) Pour traiter les données fournies par l'ADC. Ces données sont ensuite stockées dans la RAM d'une sorte. Certains appareils utiliseront la RAM statique, tandis que d'autres utiliseront la RAM dynamique. En général, l'approche SRAM est plus traditionnelle et observée chez les grands fabricants, tandis que l'utilisation de la DRAM semble être la nouvelle approche observée dans les unités de conception chinoise moins chères.
La quantité de RAM et sa vitesse détermineront le nombre d'échantillons pouvant être stockés. L'ADC sera presque toujours un ADC 8 bits, donc pour un méga-exemple, nous aurons besoin de 8 b fois 100000 = 8 Mo ou 1 Mo de RAM. Pour un MSa / s, nous aurons besoin de RAM qui peut fonctionner à cette vitesse. Aujourd'hui, cela devrait être relativement facile à obtenir. Le FPGA pilote généralement la RAM directement et est responsable du stockage des données qu'il contient. Cela fonctionne en remplissant l'échantillon de mémoire alors qu'il y a encore de la place vide et en le remplaçant quand il est plein. Lorsqu'il y a plusieurs ADC par canal, le FPGA les réglera de sorte que commence d'abord l'échantillonnage, puis la seconde d'horloge suivante et ainsi de suite. Une fois l'échantillonnage terminé, l'échantillon du premier ADC sera d'abord enregistré dans la mémoire, puis l'échantillon du second ADC. Cela donnera l'impression que les ADC échantillonnent plus rapidement qu'ils ne le sont vraiment.
Le point suivant de cette section est que les échantillons doivent être équidistants dans le temps. C'est le principal problème avec l'utilisation des PC dans les oscilloscopes et la raison pour laquelle les FPGA et les ASIC sont prédominants. Si certains échantillons sont en retard ou en avance, l'image représentée à l'écran sera incorrecte.
Dans cette partie, nous voyons la première utilisation possible du Pi. Si le taux d'échantillonnage est suffisamment faible, nous pourrions être en mesure de piloter les ADC directement à partir du Pi et de stocker leurs résultats dans la RAM du Pi. La vitesse à laquelle nous pouvons aller dépend de la façon dont l'ADC est connecté au Pi et de la manière dont Pi effectue ses E / S. D'après ce que j'ai lu, la vitesse la plus élevée des ports I ^ 2C de Pi est de 150 MHz (combien cela serait facile à réaliser dans GNU / Linux est une autre question) tandis que la vitesse standardisée la plus élevée est de 5 MHz et pour SPI la vitesse la plus élevée dans Pi est de 250 MHz. Je ne sais pas quelle est la vitesse standard la plus élevée de SPI, mais je m'attends à ce qu'elle soit quelque part dans la plage de 100 MHz au maximum.
Donc, en théorie, nous avons plus de suffisamment de vitesse sur Pi pour exécuter un ADC dans une plage MSa / s faible. J'ai le sentiment que la vitesse de la RAM ne sera pas un problème ici, mais je n'ai pas de données pour le sauvegarder. Si tel est le cas, nous aurions alors un avantage majeur par rapport aux étendues habituelles: il y aurait une très grande quantité de mémoire de capture disponible. Par exemple, si nous consacrons 32 Mo de RAM au programme de mémoire d'échantillonnage et que nous avons deux canaux, cela nous laisserait 16 Mo pour chaque canal ou un peu plus de 134 Mo ou 134 méga-échantillons par canal. C'est quelque chose que de nombreux oscilloscopes n'ont pas encore aujourd'hui.
L'inconvénient est que nous aurions besoin de lourdes modifications du système d'exploitation afin de pouvoir obtenir un échantillonnage précis ici. Je n'ai aucune expérience avec Linux en temps réel, donc je ne sais pas à quel point ce serait facile.
Quoi qu'il en soit, passons à l'étape suivante. Nous avons donc un système d'échantillonnage qui remplit la RAM. La partie suivante est le déclencheur. Le déclencheur est étroitement lié au taux de rafraîchissement de l'écran. Ce qu'il fait, c'est de trouver un échantillon intéressant et de le garder en mémoire. Lorsque l'oscilloscope se déclenche, il continue l'échantillonnage après le déclenchement jusqu'à ce qu'il ait rempli la mémoire, puis il l'envoie pour être traité et affiché à l'écran. Pendant le traitement des données, le système d'échantillonnage est souvent gelé et en attente d'affichage des données. C'est pourquoi les étendues bas de gamme ont des taux de rafraîchissement inférieurs tandis que les étendues haut de gamme auront des affichages spéciaux à taux de rafraîchissement élevé et passent beaucoup moins de temps à attendre que les données soient affichées.
Dans cette section, il y aura souvent un autre ASIC ou FPGA qui effectuera le traitement du signal sur les échantillons, tout décodage de protocole si la portée le prend en charge et pilotant réellement l'affichage lui-même.
C'est la partie où d'après ce que je peux voir, le Pi peut vraiment briller. Il peut piloter un bel écran 1920x1080 (alors que les portées sont souvent dans le sous-pays 800x600) et peut très bien décoder le protocole. Le seul problème que je peux voir serait la vitesse et l'impact du traitement sur le temps d'attente. Si nous optons pour un faible taux de rafraîchissement, nous pouvons obtenir un très bon analyseur logique avec.
Enfin un mot sur les oscilloscopes USB et pourquoi l'USB est mauvais en général pour ce type de projet: l'oscilloscope USB traditionnel effectue la saisie et l'échantillonnage et envoie les données d'échantillonnage au PC pour le traitement pour lequel une application hôte existe. Fondamentalement, quelque chose de très similaire serait également fait avec Pi. Habituellement, les applications PC sont mal conçues et pleines de bugs. La mauvaise partie suivante est l'USB lui-même. Il est annoncé comme un bus rapide qui peut faire 480 Mb / s en mode "Hi-Speed". La vérité est qu'il est extrêmement rare de trouver un contrôleur USB capable de supporter des vitesses aussi élevées (la moyenne semble être d'environ 250 Mb / s d'après ce que j'ai vu) et que ce protocole n'est pas très adapté à tout réel -application de temps. Tout d'abord, il est partagé entre tous les appareils sur un concentrateur (et Pi n'a qu'un seul port USB auquel Ethernet + concentrateur USB est connecté), a un temps système relativement élevé (par rapport au SPI, par exemple) et une latence élevée (rappelez-vous qu'à 1 MSa / s, chaque échantillon ne dure que 1 µs, nous devons donc avoir de la mémoire sur notre carte car nous ne pouvons pas envoyer d'échantillons en temps réel via USB). Enfin, l'utilisation de l'USB ferait de la partie d'acquisition de données la possibilité d'être un autre oscilloscope USB et c'est là que nous perdons tout avantage d'utiliser Pi: les ordinateurs de bureau traditionnels sont beaucoup plus courants, plus rapides, plus faciles à obtenir et ont de bien meilleures capacités USB.
EDIT
J'ai lu relativement récent message par Gert van Loo et selon lui, les taux réalistes pour I ^ 2C Pi sont 400 kHz et SPI sont 20 MHz.
