Lassen Sie uns einen allgemeinen Überblick über die Funktionen eines Oszilloskops geben:
Zuerst haben wir das analoge Frontend. Hier haben wir ein Impedanzanpassungsnetzwerk für die Sonden (aber die Sonden müssen auch einen Kapazitätsanpassungsteil haben), einen Dämpfungsabschnitt (sehr wichtig, damit wir den ADC nicht überlasten oder hohe Spannungen einlassen), Triggern und Anschließen an Analog-Digital-Wandler. Ich werde nicht zu viel darüber reden, da ich nicht so gut mit analogen Sachen umgehen kann, aber das Fazit lautet: Mit Pi können wir in diesem Abschnitt nichts anfangen.
Als nächstes haben wir den Analog-Digital-Wandler Teil. Sie benötigen mindestens einen ADC für jeden Kanal. Mehr kann für eine höhere Abtastrate verwendet werden. Im herkömmlichen Bereich ist der ADC mit einem ASIC oder einem FPGA-Gerät verbunden. Sie werden verwendet, weil herkömmliche Computer nicht in Echtzeit genug sind (und Echtzeit nicht mit Schnelligkeit verwechseln!), Um die vom ADC bereitgestellten Daten zu verarbeiten. Diese Daten werden dann in irgendeiner Art RAM gespeichert. Einige Geräte verwenden statisches RAM, andere dynamisches RAM. Im Allgemeinen ist der SRAM-Ansatz traditioneller und bei namhaften Herstellern zu beobachten, während der DRAM-Einsatz der neuere Ansatz zu sein scheint, der bei billigeren, in China entworfenen Einheiten zu beobachten ist.
Die Größe des Arbeitsspeichers und seine Geschwindigkeit bestimmen, wie viele Samples gespeichert werden können. Fast immer handelt es sich bei dem ADC um einen 8-Bit-ADC. Beispielsweise benötigen wir für ein Mega-Beispiel 8 mal 100000 = 8 MB oder 1 MB RAM. Für eine MSa / s benötigen wir RAM, das mit dieser Geschwindigkeit arbeiten kann. Heute sollte das relativ einfach zu bekommen sein. Das FPGA steuert normalerweise den RAM direkt an und ist für die Speicherung der Daten verantwortlich. Es füllt den Samplespeicher, solange der Raum noch frei ist, und überschreibt ihn, wenn er voll ist. Wenn es mehrere ADCs pro Kanal gibt, werden diese vom FPGA so eingestellt, dass zuerst mit dem Abtasten begonnen wird, dann mit der nächsten Taktsekunde und so weiter. Wenn sie die Abtastung beendet haben, wird zuerst der Abtastwert des ersten ADC in den Speicher geschrieben, dann der Abtastwert des zweiten ADC. Dadurch sieht es so aus, als würden die ADCs schneller abtasten als sie es tatsächlich sind.
Der nächste Punkt in diesem Abschnitt ist, dass die Proben zeitlich äquidistant sein sollten. Dies ist das Hauptproblem bei der Verwendung von PCs in Oszilloskopen und der Grund, warum FPGAs und ASICs vorherrschen. Wenn einige Proben zu spät oder zu früh eintreffen, ist das auf dem Bildschirm dargestellte Bild nicht korrekt.
In diesem Teil sehen wir die erstmögliche Verwendung des Pi. Wenn die Abtastrate niedrig genug ist, können wir die ADCs möglicherweise direkt vom Pi aus ansteuern und ihre Ergebnisse im RAM des Pi speichern. Wie schnell wir gehen können, hängt davon ab, wie der ADC mit dem Pi verbunden ist und wie Pi seine E / A ausführt. Wie ich gelesen habe, beträgt die höchste Geschwindigkeit der I ^ 2C-Ports von Pi 150 MHz (wie einfach dies unter GNU / Linux zu erreichen wäre, ist eine andere Frage), während die höchste standardisierte Geschwindigkeit 5 MHz und für SPI die höchste Geschwindigkeit in ist Pi ist 250 MHz. Ich bin nicht sicher, was die höchste Standardgeschwindigkeit von SPI ist, aber ich gehe davon aus, dass sie maximal im Bereich von 100 MHz liegt.
Theoretisch haben wir also mehr als genug Geschwindigkeit auf Pi, um einen ADC im niedrigen MSa / s-Bereich zu betreiben. Ich habe das Gefühl, dass die RAM-Geschwindigkeit hier kein Problem darstellt, aber ich habe keine Daten, um das zu sichern. In diesem Fall hätten wir einen großen Vorteil gegenüber herkömmlichen Bereichen: Es wäre sehr viel Erfassungsspeicher verfügbar. Wenn wir beispielsweise dem Programm 32 MiB RAM für den Sample-Speicher widmen und über zwei Kanäle verfügen, verbleiben 16 MiB für jeden Kanal oder etwas mehr als 134 Mb oder 134 Mega-Samples pro Kanal. Das haben viele Oszilloskope auch heute noch nicht.
Der Nachteil ist, dass wir umfangreiche Änderungen am Betriebssystem vornehmen müssen, um hier genaue Stichproben zu erhalten. Ich habe keine Erfahrung mit Echtzeit-Linux, deshalb weiß ich nicht, wie einfach das sein würde.
Kommen wir zum nächsten Schritt. Wir haben also ein Sampling-System, das den Arbeitsspeicher auffüllt. Der nächste Teil ist der Auslöser. Der Auslöser hängt eng mit der Bildschirmaktualisierungsrate zusammen. Im Grunde genommen findet es ein interessantes Sample und speichert es im Gedächtnis. Wenn das Oszilloskop ausgelöst wird, setzt es die Abtastung nach dem Auslösen fort, bis der Speicher voll ist, und sendet sie dann zur Verarbeitung und Anzeige auf dem Bildschirm. Während die Daten verarbeitet werden, wird das Probenahmesystem häufig eingefroren und wartet auf die Anzeige der Daten. Aus diesem Grund weisen Low-End-Bereiche niedrigere Aktualisierungsraten auf, während High-End-Bereiche spezielle Anzeigen mit hoher Aktualisierungsrate aufweisen und viel weniger Zeit darauf verwenden, auf die Anzeige der Daten zu warten.
In diesem Abschnitt befindet sich häufig ein weiterer ASIC oder FPGA, der die Signalverarbeitung für die Samples ausführt, die Protokolldecodierung, sofern das Oszilloskop dies unterstützt, und die eigentliche Ansteuerung des Displays.
Dies ist der Teil, von dem aus ich sehen kann, dass der Pi wirklich scheint. Es kann ein schönes 1920x1080-Display steuern (während sich Bereiche häufig im Sub-800x600-Bereich befinden) und Protokolldecodierungen sehr gut durchführen. Das einzige Problem, das ich sehen kann, ist die Geschwindigkeit und die Auswirkung der Verarbeitung auf die Wartezeit. Wenn wir eine niedrige Bildwiederholfrequenz anstreben, können wir damit einen wirklich guten Logikanalysator bekommen.
Zum Schluss noch ein Wort zu USB-Oszilloskopen und warum USB für diese Art von Projekten generell schlecht ist: Herkömmliche USB-Oszilloskope führen Eingaben und Abtastungen durch und senden die Abtastdaten zur Verarbeitung an den PC, für den eine Host-Anwendung vorhanden ist. Grundsätzlich würde man mit Pi auch etwas sehr Ähnliches machen. Normalerweise sind die PC-Anwendungen schlecht gestaltet und voller Fehler. Das nächste schlechte Teil ist USB selbst. Es wird als schneller Bus beworben, der im "Hi-Speed" -Modus 480 Mbit / s kann. Die Wahrheit ist, dass es extrem selten ist, einen USB-Controller zu finden, der so hohe Geschwindigkeiten unterstützt (der Durchschnitt scheint etwa 250 Mbit / s zu betragen, was ich gesehen habe) und dass er als Protokoll für kein reales Protokoll besonders geeignet ist -Zeit-Anwendung. Zuerst wird es von allen Geräten an einem Hub gemeinsam genutzt (und Pi hat nur einen USB-Anschluss, an den Ethernet + USB-Hub angeschlossen ist). hat einen relativ hohen Overhead (im Vergleich zu SPI) und eine hohe Latenz (denken Sie daran, dass bei 1 MSa / s jedes Sample nur 1 µs dauert, sodass wir Speicher auf unserer Platine haben müssen, da wir keine Samples in Echtzeit senden können über USB). Die Verwendung von USB würde den Datenerfassungsteil schließlich zu einem weiteren USB-Oszilloskop machen, und hier verlieren wir alle Vorteile der Verwendung von Pi: Herkömmliche Desktop-Computer sind viel häufiger, schneller, einfacher zu beziehen und verfügen über viel bessere USB-Funktionen.
BEARBEITEN
Ich habe einen relativ neuen Beitrag von Gert van Loo gelesen und ihm zufolge betragen die realistischen Raten für Pi I ^ 2C 400 kHz und für SPI 20 MHz.
