Forum: Mikrocontroller und Digitale Elektronik Raspberry Pi / Orange Pi ADC Schnittstelle


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Gerald (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hallo!
ich möchte gern ein Signal mit 10MSa/s abtasten, ein bisschen 
verarbeiten und anzeigen. Dazu möchte ich einen Raspberry Pi oder Orange 
Pi einsetzen, welchen ist mir eigentlich egal. Wichtig ist nur, dass ich 
die Samples vom ADC schnell genug in den Rechner bekomme.
Ich sehe 2 Möglichkeiten:
a) entweder man baut ein kleines externes PCB mit dem ADC drauf und 
einem kleinen Mikrocontroller, der den ADC steuert und die Daten an den 
Pi sendet. Vorteil: man hätte die Abtastrate genau im Griff und das 
Betriebssystems des Pi wäre weniger ausgelastet.
b) man steuert einen schnellen ADC mit den GPIO/SPI Pins des Pi an. Ich 
habe da keine Erfahrung, aber angeblich sollen mit SPI bis zu ca. 
100MBit/s möglich sein - schwer zu glauben.
Der Punkt ist eigentlich nur, dass ich Messdaten schnell erfassen will, 
in Software verarbeiten und anzeigen will. Ist so etwas möglich?
Notfalls könnte ich auch mit 5 MSa/s leben, aber weniger geht sicher 
nicht.

Wie ich die Messdaten verarbeiten und anzeigen kann, weiss ich, aber wie 
ich sie von meinem ADC schnell genug in den Pi bekomme, das ist die 
schwierige Frage.

von N. M. (mani)


Bewertung
0 lesenswert
nicht lesenswert
Vergess es. So bekommst du das nie hin.
Wenn du nur ein Kanal hast mit nur 8 Bit Auflösung hast du 10MS/s * 8 
Bit *1 Kanal. Sind  80MBit/s (ohne Overhead).
Das bekommst du so noch nicht Mal weitergeleitet über Ethernet.
Geschweige denn verarbeitet.

Ich würde ein Zynx oder Cyclone 5 SoC nehmen. Der FPGA macht die 
aqidistante Abtastung und evtl Vorverarbeitung. Der HPS macht evtl eine 
weitere Verarbeitung /Präsentation/Weiterleitung über Gigabit Ethernet.
Fertige Eva Boards gibt es für 100$ oder weniger...

von Tim T. (tim_taylor) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Hab erst neulich versucht den Raspberry als Logic Analyzer zu 
missbrauchen, trotz Bare Metal und DMA ist aus den IOs nicht mehr als 
60MS/s rauszukitzeln, wohlgemerkt Digital, nicht Analog und ohne 
irgendwelche Verarbeitung, einfach direkt ins RAM.

von M. K. (sylaina)


Bewertung
0 lesenswert
nicht lesenswert
Gerald schrieb:
> Der Punkt ist eigentlich nur, dass ich Messdaten schnell erfassen will,
> in Software verarbeiten und anzeigen will.

Und wer soll das lesen können? Als mich würde es schon wundern, wenn 
jemand 1.000 Sa/s lesen kann, geschweige denn das 10.000fache davon. 
Verarbeiten ist ja noch OK aber anzeigen kannst du vergessen

Gerald schrieb:
> Notfalls könnte ich auch mit 5 MSa/s leben, aber weniger geht sicher
> nicht.

Soso, weniger geht sicher nicht...ich frag mal laienhaft: "warum?"

Professionell gesehen: Du willst eigentlich 10 MSa/s, 5 MSa/s wären aber 
auch OK...was genau willst du denn machen dass die halbe Abtastrate auch 
OK ist?
Und welche analoge Bandbreite benötigst du? Bei welcher Auflösung soll 
der Spass laufen?

Einen ADC mit 10 MSa/s zu finden wird ja nicht wirklich das Problem 
sein...oder doch?

von Alex G. (dragongamer)


Bewertung
0 lesenswert
nicht lesenswert
Da du einen uC in Erwägung ziehst, nehme ich mal an dass da sofort eine 
Verarbeitung mit den Werten vom ADC stattfinden soll, denn dessen Ram 
ist sonst ja in Sekundenbruchteilen voll.
Willst du nur Wert-Spitzen oder sowas detektieren mit dem System?

Hier gäbe es übrigens ein Board das 1MS/s verspricht: 
https://www.reichelt.de/shield-fuer-raspberry-pi-vm205-oszilloskop-10-kanaele-vel-vm205-p148930.html?PROVID=2788&gclid=CjwKCAiAqt7jBRAcEiwAof2uKw-i4AcKqyWDumN0LAKe_vAKLdik2LEUxBUTtHBwaUFiwm8SSdbVwxoCvGsQAvD_BwE&&r=1
Wenn du nach "raspberry Oszilloskop" googelst, findest du ein paar 
Projekte; mal mit mehr mal mit weniger externer Elektronik.


Die Lösung die Verarbeitung per uC oder FPGA zu machen und nur die 
anzuzegenden Ergebnisse per SPI, I2C oder einfacher, Uart an den Raspi 
zu übertragen ist wahrscheinlich die zielführendere. 
Programmierkenntnisse vorrausgesetzt.

: Bearbeitet durch User
von N. M. (mani)


Bewertung
0 lesenswert
nicht lesenswert
Alex G. schrieb:
> Da du einen uC in Erwägung ziehst, nehme ich mal an dass da sofort eine
> Verarbeitung mit den Werten vom ADC stattfinden soll, denn dessen Ram
> ist sonst ja in Sekundenbruchteilen voll.

Vielleicht möchte er es auch "nur"weitersenden. Aber selbst wenn der 
Controller nichts anderes macht (ohne OS !) wird das nichts. Der Raspi 
hat auch kein Gigabit Ethernet. (EDIT: Der "Neue" anscheinend doch).

Aber genau wie du sagst ist der Speicher schnell voll. Deshalb steht bei 
dem verlinkten Board auch:
1
maximum sample rate : 1MS/s
2
measurements up to: 100kHz
3
record length: 800 samples

: Bearbeitet durch User
von Olaf (Gast)


Bewertung
0 lesenswert
nicht lesenswert
> Notfalls könnte ich auch mit 5 MSa/s leben, aber weniger geht sicher
> nicht.

Mein Eindruck ist das du dies zumindest beim Raspberry vergessen kannst.
Es ist zwar grundsaetzlich moeglich 30Mbit (oder gar mehr) als SPI-Takt 
zu fahren, aber die IRQ-Zeit bis der Kernel sich um deine Bytes kuemmert 
ist relativ lang. Effektiv kommst du dann nur auf 2-3Mbit. Vermutlich 
sogar noch weniger wenn der Kernel staerker belastet ist.
Ich denke das die SPI-Hardware im Controller ziemlich mies ist. Die 
haette einen 10x groesseren Buffer gebraucht.

Ausserdem hab ich den Eindruck als wenn die IO-Leistung des Raspberry 
nicht so prall ist. Es lohnt da einen Leitungstreiber zwischen zu bauen 
wenn die Leitungen auch nur leicht laenger sind und man hoehere 
Taktraten fahren will.

Such dir eine Hardware die mindestens 32Byte Buffer hat und die 
Transfers mit DMA im Hintergrund ausfuehren kann.

Olaf

von Gerald (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich wollte mittels FFT die gemessenen Daten verarbeiten und das Spektrum 
als Diagramm anzeigen. Es würde mir genügen, wenn man das Diagramm 1..5x 
pro Sekunde auffrischt, ich benötige also nicht kontinuierlich 
5..10MSa/s, sondern nur für kurze Zeit, danach kann man wieder für eine 
Weile warten.

von neuer PIC Freund (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Schau dir mal das beagle logic Projekt an. Da schaufeln die PRUs eines 
BBB Daten mit 100MHz in den RAM. Wohl auch mit 12 Bit. Wenn du die 200 
MHz eines ARM-PRU-Kerns auf 10 MHz runterbrichts, ist das eher langsam. 
Mit dem RAM des BBB hast du ein Aufnahmefenster von über 10 Sekunden.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.