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.
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
Es fehlen elementare Angaben.... So kann niemand Deine Hausaufgaben erledigen. Wahrscheinlich gibt es eh kein Feedback mehr.
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.
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. :)
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?
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
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.
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
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)
-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.
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.
-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"? ...
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.
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.
-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 ;)
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.
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.
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.
Das wichtigste, was bisher gefehlt hat ist die Kabellaenge. Bei USB ist mit 5m auch Schluss.
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.
rasenderpi schrieb: > Entscheidend ist wohl auch die Aufzeichnungsdauer (Buffer???). Aufzeichnungsdauer wären bis zu 180 Sekunden.
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
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.
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?
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.