mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Schnittstelle für 5 bis 25 Mbit/s Datenstream


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.
Autor: ElecEddy R. (forrix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich bin recht neu auf dem Gebiet der Datenkommunikation, deswegen fehlt 
mir glaube ich ein wenig die Übersicht über das ganze Thema. Deswegen 
interessiert mich eure Meinung, bzw. vielleicht gibt es Tipps in welche 
Richtung ich sinnvoll gehen kann.

Ich habe einen Datenstream von einem 8-Kanal ADC 
(https://www.analog.com/en/products/ad7771.html), welcher mit 128ksps 
wandelt. Am Ausgang besteht dann 1 Sample aus 32 Bit (8 Header + 24 
Datenbits), MCLK max. ist 8,192 MHz.
Daraus ergibt sich ein Stream von 128ksps*32 = 4,096 Mbit/s für einen 
Kanal. Das Ziel sind irgendwann 8 Kanäle, das heißt die Datenmenge 
verachtfacht sich.
Diese Daten sollen jetzt am besten an den PC weitergeleitet werden (bzw. 
auf eine SD-Karte geloggt werden).

Ich bin am recherchieren, was jetzt eine gute Möglichkeit der Umsetzung 
ist. Erstmal nur für einen Kanal.
UART, CAN, i2c und RS232 fallen denke ich wegen fehlender Datenrate 
raus.
Da bleibt letzten Endes eher sowas in die Richtung USB2.0, Ethernet, 
FireWire... vielleicht auch ein USB-SPI-Host?

Auf die SD-Karte zum loggen bin ich gekommen, weil ich einen ADSP-BF609 
(https://www.analog.com/en/design-center/evaluation-hardware-and-software/evaluation-boards-kits/EVAL-BF609-EZ.html) 
zur Hand hätte, welcher einen SD-Kartenslot hat. Leider hapert es grad 
daran herauszubekommen, mit welcher Geschwindigkeit ich auf die Karte 
schreiben kann. An sich ist eine SD-Karte ja schnell genug.

Autor: fchk (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Eine SD-Karte ist nur im Durchschnitt schnell genug. Sie kann durchaus 
mal Pausen im Sekundenbereich einlegen, wo überhaupt nichts mehr geht. 
Das heißt: Du musst genügend RAM-Puffer für sagen wir 5...10s Daten 
einplanen. Das wären dann 20...40 MByte. Technisch überhaupt kein 
Problem, aber auf einem AVR oder so nicht machbar.

Ansonsten wären USB 2.0 High Speed oder 100MBit Ethernet gägige 
Schnittstellen. Ein PIC32MZ EF hätte sowohl USB 2.0 High Speed mit 
eingebauten HS-PHY (das haben viele andere nicht!)als auch 100 MBit 
Ethernet.

fchk

Autor: Wattis (Gast)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
Es fehlen elementare Angaben....

So kann niemand Deine Hausaufgaben erledigen.

Wahrscheinlich gibt es eh kein Feedback mehr.

Autor: -gb- (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Dann schreib doch dazu was fehlt.
Für mich fehlt da eigentlich nix. Daten zum PC kann man mit einem 
schnellen uC machen der USB oder Ethernet drinnen hat. Ich habe das 
bisher mit FPGAs und FT(2)232H gemacht. Das geht auch problemlos.

Autor: ElecEddy R. (forrix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
-gb- schrieb:
> Dann schreib doch dazu was fehlt.

Finde ich auch.

Autor: ElecEddy R. (forrix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
fchk schrieb:
> Eine SD-Karte ist nur im Durchschnitt schnell genug. Sie kann durchaus
> mal Pausen im Sekundenbereich einlegen, wo überhaupt nichts mehr geht.
> Das heißt: Du musst genügend RAM-Puffer für sagen wir 5...10s Daten
> einplanen. Das wären dann 20...40 MByte. Technisch überhaupt kein
> Problem, aber auf einem AVR oder so nicht machbar.
>
> Ansonsten wären USB 2.0 High Speed oder 100MBit Ethernet gägige
> Schnittstellen. Ein PIC32MZ EF hätte sowohl USB 2.0 High Speed mit
> eingebauten HS-PHY (das haben viele andere nicht!)als auch 100 MBit
> Ethernet.

Ah ok. Das hilft schon mal weiter. :)

Autor: Dergute W. (derguteweka)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Moin,

Klarer Fall fuer Ethernet.

Gruss
WK

Autor: ElecEddy R. (forrix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nochmal Danke für die vielen Rückmeldungen. :)

Dergute W. schrieb:
> Klarer Fall fuer Ethernet.

Da würde mich interessieren, was so klar für Ethernet im Vergleich zu 
USB und auch FT(2)232H spricht?

Autor: Dergute W. (derguteweka)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Moin,

ElecEddy R. schrieb:
> Da würde mich interessieren, was so klar für Ethernet im Vergleich zu
> USB und auch FT(2)232H spricht?

Die Debugmoeglichkeiten mit Wireshark, etc. Sowie die Betriebssystem- 
und weitgehende programmiersprachenunabhaengige (sowas wie Sockets 
koennen doch einige Sprachen) Programmierung auf der PC-Seite. Mit USB 
wird das sicher mehr Gewuerge.

Gruss
WK

Autor: ElecEddy R. (forrix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Verstehe. Danke!

Autor: c-hater (Gast)
Datum:

Bewertung
3 lesenswert
nicht lesenswert
Dergute W. schrieb:

> Die Debugmoeglichkeiten mit Wireshark, etc.

Auch USB kann man mit Wireshark debuggen. Das ist also kein Grund.

> Sowie die Betriebssystem-
> und weitgehende programmiersprachenunabhaengige (sowas wie Sockets
> koennen doch einige Sprachen) Programmierung auf der PC-Seite. Mit USB
> wird das sicher mehr Gewuerge.

So sieht's aus. Zuverlässige Kommunikation über USB mit einem 
garantierten hohen Durchsatz erfordert isochrone Transfers. Dafür gibt 
es keine Klassentreiber. D.h.: es steht in jedem Fall Programmierung 
eines Treibers an, ausserdem Registrierung als USB-Vendor, um zu einer 
PID für das Gerät zu kommen. Für Windows ausserdem noch die Signierung 
des Treibers durch Winzigweich.
Das alles lässt die Kosten sehr schnell unangenehme Höhen erreichen.

Ethernet ist sehr viel einfacher. Allerdings unter Windows auch nicht 
mehr ganz so einfach wie früher, in neueren Windowsversionen haben 
Anwendungen keinen Zugriff auf RAW-Sockets mehr. Aber 33Mbit über eine 
100MBit-Strippe lassen sich mit UDP noch völlig problemlos realisieren 
und UDP-Sockets dürfen Anwendungen verwenden.

Autor: Dergute W. (derguteweka)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:
> ausserdem Registrierung als USB-Vendor, um zu einer
> PID für das Gerät zu kommen.

Naja, bei Ethernet brauchste auch irgendwoher 'ne MAC-Adresse fuer jedes 
Geraet...

c-hater schrieb:
> Auch USB kann man mit Wireshark debuggen. Das ist also kein Grund.

Fuer mich in realistischer Einschaetzung meiner intellektuellen 
Faehigkeiten schon :-)

Gruss
WK

Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dergute W. schrieb:

> Naja, bei Ethernet brauchste auch irgendwoher 'ne MAC-Adresse fuer jedes
> Geraet...

Schon, die muß aber nicht zu irgendeinem zu signierenden Treiber passen. 
Außerdem ist die Chance für eine zufällige Kollision viel geringer. 
Sprich: man kann einfach eine klauen, zumindest so lange keine 
kommerzielle Nutzung angestrebt wird.

Notfalls kauft man einfach bei Pollin ein NetIO und wirft die Hardware 
weg. Eine vollkommen legale MAC ist als Aufkleber auf dem Mega32. ;o)

Autor: rasenderpi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
-gb- schrieb:
> Für mich fehlt da eigentlich nix.

Entscheidend ist wohl auch die Aufzeichnungsdauer (Buffer???).
Bei 25 Mbit Ethernet kommen da pro Sekunde locker 3-4 MBYTE Daten 
zusammen!!
Da ist ein RASPY schon ziemlich am Schwitzen.

Autor: -gb- (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Die Daten sollen zu einem PC weitergeleitet werden. Ausser ein paar 
Puffern für FIFO braucht man da nix. Bei dem FT2232H verwende ich 
64kBytes als Puffer und kann dauerhaft um die 40MBytes/s zum PC 
übertragen.

Autor: c-hater (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
-gb- schrieb:

> Die Daten sollen zu einem PC weitergeleitet werden. Ausser ein paar
> Puffern für FIFO braucht man da nix. Bei dem FT2232H verwende ich
> 64kBytes als Puffer und kann dauerhaft um die 40MBytes/s zum PC
> übertragen.

Hmm... Schliesse doch einfach mal eine USB-Platte an einen anderen Port 
desselben Hubs an und greife gleichzeitig intensiv auf diese Platte zu. 
Immer noch alles schick mit "dauerhaft um die 40MBytes/s"? ...

Autor: Bernd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
fchk schrieb:

> Sie kann durchaus mal Pausen im Sekundenbereich einlegen, wo überhaupt
> nichts mehr geht. Das heißt: Du musst genügend RAM-Puffer für sagen wir
> 5...10s Daten einplanen.

5 - 10 Sekunden. Märchenstunde.

Zeige mir ein Datenblatt einer SD-Card aus dem industriellen Bereich (o. 
ä.), das diesen Sachverhalt belegt. Für die von mir verwendeten SD-Cards 
von ATP stimmt deine Aussage nicht.

Autor: -gb- (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
c-hater schrieb:
> Hmm... Schliesse doch einfach mal eine USB-Platte an einen anderen Port
> desselben Hubs an und greife gleichzeitig intensiv auf diese Platte zu.
> Immer noch alles schick mit "dauerhaft um die 40MBytes/s"? ...

Warum sollte man das tun? Mein PC hat mehrere USB Schnittstellen die 
nicht an eine Hub hängen.
Man kann jede Lösung vermurksen. Auch Ethernet schafft die Datenrate 
nicht wenn man Hubs einbaut und da viele Daten schaufelt. Aber warum 
sollte man das? Er will die Daten auf einen PC bekommen also sollte man 
annehmen, dass er dort ordentliche Hardware hat und das USB ohne Hub 
direkt am PC einstöpselt.

Autor: Mw E. (Firma: fritzler-avr.de) (fritzler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
-gb- schrieb:
> Warum sollte man das tun? Mein PC hat mehrere USB Schnittstellen die
> nicht an eine Hub hängen.

Mach mal den Gerätemanager auf und staune:
"USB Root Hub"
Nicht jeder USB Anschluss ist exklusiv für sich alleine ;)

Autor: -gb- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stimmt, ist aber doch auch OK?! Man muss nicht gleichzeitig viele Daten 
über eine andere USB Schnittstelle schieben. Eine Festplatte kann man im 
PC auch anders anschließen. Und wenn doch dann gibt es dafür heute USB3 
und zur Not auch Steckkarten. Ich habe hier auch Maus und Tastatur und 
ein Audiointerface am USB und bekomme trotzdem die Datenrate zum FTDI 
hin. Dazu habe ich wie oben geschrieben den 64kByte Puffer im FPGA denn 
manchmal ist der FTDI belegt und man muss kurz warten.
Aber ja, man kann jede Lösung vermurksen wenn man es drauf anlegt. Auch 
Ethernet.

Autor: Sven B. (scummos)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Also 4 MB/s. Ich würde USB 2.0 nehmen. Wenn du auf der Client-Seite 
sowas wie 128 kB Buffer hast, sollte das mit einem Bulk-Transfer kein 
Problem sein.

Ein Treiber ist mit libusb für die Host-Seite in < 100 Zeilen gebaut.

Ethernet ist elektrisch komplexer als USB und ich glaube ich würde es 
nur nehmen, wenn ich entweder die Datenrate oder die Reichweite / 
Störfestigkeit brauche.

Autor: Weg mit dem Troll ! (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Die Geschwindigkeit einer SD Karte ist auf der Karte selbst, resp als 
Klasse angegeben. Es gibt Welche, nicht die Billisten, welche fuer 
90MByte/s Schreibgeschwindigkeit spezifiziert sind. Die taugen dann auch 
fuer in 4K Video.

Autor: Weg mit dem Troll ! (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das wichtigste, was bisher gefehlt hat ist die Kabellaenge. Bei USB ist 
mit 5m auch Schluss.

Autor: ElecEddy R. (forrix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Weg mit dem Troll ! schrieb:
> Das wichtigste, was bisher gefehlt hat ist die Kabellaenge. Bei USB ist
> mit 5m auch Schluss.

Die Kabellänge wäre nicht größer als 1,5m.

Autor: ElecEddy R. (forrix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
rasenderpi schrieb:
> Entscheidend ist wohl auch die Aufzeichnungsdauer (Buffer???).

Aufzeichnungsdauer wären bis zu 180 Sekunden.

Autor: ElecEddy R. (forrix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven B. schrieb:
> Also 4 MB/s. Ich würde USB 2.0 nehmen. Wenn du auf der Client-Seite
> sowas wie 128 kB Buffer hast, sollte das mit einem Bulk-Transfer kein
> Problem sein.
>
> Ein Treiber ist mit libusb für die Host-Seite in < 100 Zeilen gebaut.

Ich glaube ich muss mich in die Themen noch mehr einarbeiten.
Momentan tendiere ich doch zu nem FT232H (z.B. UM232H Modul mit 
Treibern).
Die Frage ist nur, ob ein Bulk-Transfer reicht. Kann ich einfach nicht 
einschätzen wegen der Unwissenheit. :D
Wenn es isochron sein müsste, wäre vermutlich Ethernet dann doch 
angenehmer...


Die SD-Karte ist grad auch nicht mein Favorit, weil ich denke, wenn ich 
vsl. eh relativ viel Zeit investieren muss, kann ich die Daten auch 
gleich an den PC leiten. Dann spare ich mir später das Umstecken der 
SD-Karte.

: Bearbeitet durch User
Autor: Sven B. (scummos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Isochrone Transfers sind hier m.E. eh Unsinn. Du willst doch alle Daten 
haben, das garantiert dir der isochrone Endpoint aber nicht ...

Die Zuverlässigkeit hängt hier auch weniger an Typ des Endpoints, 
sondern mehr an der Größe des Buffers des Clients.

Autor: ElecEddy R. (forrix)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Und doch noch eine vielleicht laienhafte Frage,

könnte man einen Arduino (z.B. Arduino Yun) für die USB 2.0 
Datenübertragung nutzen?

Autor: ElecEddy R. (forrix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sven B. schrieb:
> Isochrone Transfers sind hier m.E. eh Unsinn. Du willst doch alle Daten
> haben, das garantiert dir der isochrone Endpoint aber nicht ...

Ok, alles klar.

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]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [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.

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