Guten Morgen,
ich möchte im Rahmen eines Hobby-Projektes eine Messkarte zur Erfassung
analoger Signale entwickeln. Den A/D-Umsetzer habe ich bereits
festgelegt: Delta-Sigma-Konverter mit 24 Bit Datenbreite pro Messkanal.
Die Abtastrate beträgt 52kHz pro Kanal, wobei insgesamt vier Kanäle
verwendet werden, die simultan abgetastet werden. Die Schnittstelle ist
in diesem Fall SPI, wobei die die vier Kanäle seriell rausgetaktet
werden. Dies entspricht einer Bitstreamrate von ca. 5MBit/s (96Bit *
52kHz) die vom A/D-Umsetzer in den Host-Controller fließen würde.
Host-Controller ist nun das richtige Stichwort. Ich möchte die Daten zur
weiteren Verarbeitung an einen PC weiterleiten. Bei einem minimalen
Payload von 5MBit/s (noch keine Header dazugerechnet) würde ich hier
entweder mind. USB2.0 im High-Speed Modus oder Ethernet wählen, so dass
die Daten in "Echtzeit" übertragen werden. (in diesem Kontext bedeutet
Echtzeit: keine langfristige Pufferung in einem volatilen oder
nonvolatilen Speicher, abgesehen der PC, welcher die letzte Datensenke
darstellt)
Nun zu der, mich quälenden Frage:
Was soll ich hier als Host-Controller zur Ansteuerung des A/D-Umsetzers
verwenden?
(1): Embedded System auf Basis der ARM-Architektur
(2): Digital Signal Processor
(3): FPGA
Unabhängig von euren Ratschlägen/Empfehlungen, hierzu meine
Stellungnahme:
Aus meiner bisherigen Erfahrung mit Mikrocontrollern würde ich
behaupten, dass die Realisierung mit einem ARM basierten Embedded System
bezüglich der Programmierung "am leichtesten" wäre. Nur habe ich nach
einiger Recherche keine Entscheidung treffen können.
Falls es doch ein Embedded System wird, dann stellen sich die Fragen:
(1): Dual Core ?
(2): Single Core (würde aber eine gut implementierte DMA Lösung
erfordern, so dass die Löwenarbeit größten Teils im Hintergrund erfolgt)
Dann natürlich die Frage der Kommunikation mit dem PC:
(1): USB2.0
(2): Ethernet
Wie würdet ihr hier vorgehen ? Was würdet ihr als Host-Controller für
den A/D-Umsetzer wählen ?
Gruß und einen guten Wochenstart,
Tux
Ein Nucleo F7 oder H7 Board mit Ethernet und Mbed. Ganz ohne Puffern
geht es bei blockweiser Übertragung über Ethernet oder USB aber nicht,
aber ein PC möchte auch nicht Interrupts mit zig kHz verarbeiten. UDP im
ms Takt ist aber kein Problem.
Tux schrieb:> eines Hobby-Projektes eine Messkarte zur Erfassung> analoger Signale entwickeln. Den A/D-Umsetzer habe ich bereits> festgelegt: Delta-Sigma-Konverter mit 24 Bit Datenbreite pro Messkanal.
Ich hoffe, dir ist bewusst, dass du allein dadurch die Datenrate
reduzieren kannst, indem du nur die Bits überträgst, die nicht rauschen.
Und dabei gibt es 2 Dinge, die dir in die Suppe spucken:
1. dein Design und das Layout, sowie
2. dein ADC.
Denn der AD7176-2 kann z.B. bis zu 250kSps, hat dann allerdings nur noch
"17 noise free bits":
Vielen Dank für die raschen Antworten bzw. euer Feedback. Beim Verfassen
des Posts habe ich bereits geahnt, dass ich kritische Rückfragen
bezüglich des Bitrauschens bekomme. Gewiss möchte ich keine
Unhöflichkeit oder gar eine Undankbarkeit mit folgendem zum Ausdruck
bringen:
Das die Anzahl der zu übertragenden Bits die Auswahl nach einem
geeigneten Host-Controller beeinflussen ist auch für mich evident.
Ich möchte die Ausganssituation des Posts an dieser Stelle ändern und
zwar soll es sich nicht um ein Hobby-Projekt handeln, sondern ich würde
gerne von den Experten hier wissen wollen, was man als Host-Controller
nehmen würde, wenn alle 24-Bit als "rauschfrei" angenommen werden und
somit die Bitrate sich nicht reduziert. Vielleicht kann hierdurch
weitere Rückfragen zum Bitrauschen vermieden und die Konzentration
weiterhin auf die eigentliche Frage, nämlich nach dem Host-Controller,
gelenkt werden.
Vielen Dank
Tux
Tux schrieb:> (1): Embedded System auf Basis der ARM-Architektur> (2): Digital Signal Processor> (3): FPGA
1,2,3 sind eingebettete Systeme du verwechselst da was mit einem
System-on-Chip?
Allenfalls waere noch interessant wieviele Daten es sein werden. Oder
soll dauernd gestreamt werden ?
Denn nur so nebenbei, ist Windows nicht geeignet zur Echtzeit
Verarbeitung. Die kleinste Zeitscheibe ist glaub ich 20ms fuer den
Desktop, 50ms fuer den server. Bedeutet, es kann auch laenger gehen, bis
der Prozess wieder dran kommt.
Bedeutet, allenfalls verlagerst du besser einen Teil der Verarbeitung an
den Controller.
Purzel H. schrieb:> Denn nur so nebenbei, ist Windows nicht geeignet zur Echtzeit Verarbeitung.
Auf dem Zielrechner wird nach einer "zeitnahen" Übertragung doch sowieso
alles erst mal gespeichert, denn
Tux schrieb:>>>> (in diesem Kontext bedeutet Echtzeit: keine langfristige Pufferung>>>> in einem volatilen oder nonvolatilen Speicher, abgesehen der PC,>>>> welcher die letzte Datensenke darstellt)Tux schrieb:> Falls es doch ein Embedded System wird, dann stellen sich die Fragen:> (1): Dual Core ?> (2): Single Core (würde aber eine gut implementierte DMA Lösung> erfordern, so dass die Löwenarbeit größten Teils im Hintergrund erfolgt)
Nein, für einen Singlecore STM32 mit z.B. 100MHz sind 5MBit = 800kByte =
400kWorte = 200kLongs nicht wirklich viele Daten...
> Dann natürlich die Frage der Kommunikation mit dem PC:> (1): USB2.0
Welche Kabellänge planst du? Welche EMV-Einflüsse hast du?
> (2): Ethernet
Nimm das.
Der Host Controller befindet sich in deinem PC. Du brauchst in deinem
Mikrocontroller das Gegenstück dazu. Da eignet sich prinzipiell jeder
Mikrocontroller mit integrierter USB Schnittstelle.
Ethernet geht natürlich auch.
Mach die lieber Gedanken über den Pufferspeicher. Denn egal welche
Schnittstelle du zum PC hin haben wirst: keine davon kann die Daten ohne
Ruckeln übertagen. Ich würde den Puffer für mindestens 200ms auslegen.
Wenn es sehr zuverlässig arbeiten soll würde ich sogar großzügig eine
Sekunde puffern. Ist natürlich auch eine Frage des Geldes.
Zu deiner Frage bezüglich single vs. dual core: Für Anfänger hört sich
ein Konstrukt mit mehreren Kernen immer verlockend an, da sie zwei
Aufgaben unabhängig voneinander ausführen können. Doch zwischen den
beiden Prozessen werden Daten ausgetauscht, damit sind sie doch nicht
mehr unabhängig. Die Programmierung solcher Systeme ist erheblich
komplexer, als wenn man nur einen Kern berücksichtigen muss. Wenn du
damit noch keine Erfahrung hast, dann bleibe besser bei einem
single-core System. Du eröffnest sonst zu viele Baustellen gleichzeitig,
die schnell außer Kontrolle geraten.
Tux schrieb:> (1): USB2.0> (2): Ethernet
Bei USB ist eine isochrone Übertragung direkt als Modus vorgesehen, d.h.
Streaming mit fester und reservierter Datenrate. Nachteil: Du musst dich
durch Standards oder verfügbare Stacks und entsprechende Doku wühlen.
Bei Ethernet ist zuverlässige isochrone Übertragung nicht unmittelbar
vorgesehen, aber dank reichlich Erfahrung mit Audio/Videostreaming
mittlerweile sehr verbreitet, z.B. im für VoIP/Video häufigen Protokoll
RTP. Innerhalb eines lokalen Netzes besteht auch die Möglichkeit,
Priorisierungen vorzunehmen, um grobe Abweichung von Latenzen zu
vermeiden.
Wichtig ist allerdings die Frage, wie wichtig zuverlässige Übertragung
jedes einzelnen Wertes überhaupt ist. Wenn in seltenen Fällen fehlenden
Daten keine wesentliche Rolle spielen, und das im lokalen Ethernet
bleibt, ist simples UDP "fire and forget" die mit Abstand einfachste und
evtl völlig ausreichende Lösung. Hier ist dann nur noch eine mitlaufende
Fehlerstatistik interessant, um aufkommende Probleme frühzeitig zu
erkennen.
Vorsicht Falle: TCP ist für solche Streams im Prinzip ungeeignet. Bei 5
Mbit/s in mindestens 100 Mbit Ethernet wird das kaum ein Problem sein,
aber wenn andere Netzformen wie WLAN oder Internet mitspielen, kann das
wichtig sein.
5 MBit/ pro sec bekommt man auch noch über Usb1.1 hin, da vieleicht mit
Double Buffer. ein USB2 Controller wie die Cypress FX2 lacht da drüber.
Nimm einen ARM mit Hispeed USB Schnittstelle (480MBit). Das ganze ist
eher eine Frage wie schnell du deine Daten raushauen kannst, bzw wie
schnell dein Treiber die am PC verarbeitet.
Da das Hobby-Projekt nach einer Einzellösung klingt, bleibt die beim
Erfassungssystem vom Aufwand her vermutlich einfachste Lösung im Layer 2
vom Ethernet, d.h. es wird nicht einmal UDP verwendet, also nackter
Ethernet-Controller ohne TCP/IP-Stack. Die Daten werden mit Timestamp in
einen Ethernet-Frame akkumuliert, der wird an die bekannte MAC-Adresse
des PCs rausgehauen und das wars auf dieser Seite.
(prx) A. K. schrieb:> bleibt die beim Erfassungssystem vom Aufwand her vermutlich> einfachste Lösung im Layer 2 vom Ethernet, d.h. es wird nicht> einmal UDP verwendet, also nackter Ethernet-Controller ohne> TCP/IP-Stack
Bis aus welchen Gründen auch immer ein Router ins Netz eingebaut wird.
Dann wird es plötzlich sehr kompliziert wenn man so anfängt.
Ich empfehle UDP.
Stefan ⛄ F. schrieb:> Ich empfehle UDP.
Ist die sicherere Lösung, zumal UDP ohne TCP kein sonderlich grosser
Aufwand ist. Aber wenn das eine spezifische Lösung für eine bestimmte
Umgebung ist, geht auch MAC-Layer.
Johannes S. schrieb:> oder auch TCP kann man sich da durchaus auf beiden> Seiten leisten.
Worin liegt in dieser Anwendung der Vorteil von TCP? Ein Nachteil ergibt
sich u.A. dann, wenn die Verbindung aus irgendeinem Grund stockt, dieser
Zustand erkannt werden muss, und neu aufgebaut werden muss. Und zwar
vorzugsweise ohne Deadlocks oder längere Timeouts, weil beide Seiten
sich uneins über den Zustand sind. BTDT.
Datenverlust gibts dann ohne tiefem Speicher im Erfassungssystem
genauso. Vorteil von TCP ist der Umgang mit sporadischen Fehlern im
Netz, aber wenn das kein Rübenacker ist, und Switch/Empfängersystem
nicht noch anderweitig durch Überlastung glänzen, ist auch UDP sehr
zuverlässig.
Die MAC-Variante hatte ich als Beispiel für eine Minimallösung erwähnt.
Bei UDP entsteht etwas Mehraufwand durch ARP, ICMP und mögliches
Routing. Aber wenn man einen fertigen Stack verwendet, der etwas mehr
als Dunkels uIP bietet, ist das schon vorhanden.
full ack, ich würde es auch mit UDP machen. Ich sage nur das es auch mit
TCP gehen würde wenn man wollte.
lwIP ist da ja der Quasi-Standard der für viele µC oder FPGA verfügbar
ist.
Wenn es denn USB 2.0 werden soll:
Bei den kleine Arms gibt es nur selten USB highspeed, fast immer nur
full speed.
z.B. STM
für high speed, den einige aus der F4 Serie können, brauchst Du in der
Regel ULPI Bausteine, weil der high speed PHY nicht on chip ist. Da muss
man vom Layout her aufpassen.
STM hat in der F7 Serie nur einen mit high speed PHY on chip, den
STM32F723. (Der sitzt z.B. auf den ST Link V3). Die neueste Version von
CubeMX erlaubt jetzt sogar die Nutzung davon mit clicki Bunti. Das ging
bisher nicht, vermutlich findet man da also noch Fehler.
Arduino due hat eine Atmel chip drauf der einen high speed PHY on chip
hat. (Ob das Arduino framework das unterstützt weiss ich nicht)
Martin B. schrieb:> Wenn es denn USB 2.0 werden soll:
Die nötigen Geschwindigkeiten erreichst Du bei USB nur, wenn Du korrekt
pufferst. Du musst dafür sorgen, daß im richtigen Moment ein voller
Puffer bereitsteht. Wenn der Puffer nicht voll ist, bricht der
Hostcontroller die schnelle Übertragung ab und legt eine Pause ein bevor
er das USB-Device wieder anspricht. Wenn man das falsch plant, läuft in
dem Moment dann der Puffer dort über. Auch die Software auf
Hostcontroller-Seite spielt eine Rolle, wenn man es dort nicht richtig
anspricht, bekommt man auch nicht die volle Performance.
Wenn man die Ansteuerung und Pufferung aber mal im Griff hat, bekommt
man z.B. mit einem Cypress FX2 dauerhaft 340 MBit/s Nutzdaten
übertragen. Die FTDIs gehen auch, sind aber meiner Erfahrung nach klar
langsamer und brauchen mehr "Mitarbeit" auf der Device-Seite als die
FX2.
Wenn es nicht so auf die Bauteilkosten ankommt, sondern mehr auf die
Entwicklungszeit, dürfte das vermutlich mit einem schnellen ARM-µC,
Ethernet und UDP leichter lösbar sein.
Stefan ⛄ F. schrieb:> Mach die lieber Gedanken über den Pufferspeicher. Denn egal welche> Schnittstelle du zum PC hin haben wirst: keine davon kann die Daten ohne> Ruckeln übertagen. Ich würde den Puffer für mindestens 200ms auslegen.> Wenn es sehr zuverlässig arbeiten soll würde ich sogar großzügig eine> Sekunde puffern. Ist natürlich auch eine Frage des Geldes.
Und eine Frage der Latenz. Da der TO von "Echtzeit" spricht, nehme ich
an, dass sie nicht beliebig verzögert werden sollen.
(prx) A. K. schrieb:> Bei Ethernet ist zuverlässige isochrone Übertragung nicht unmittelbar> vorgesehen, aber dank reichlich Erfahrung mit Audio/Videostreaming> mittlerweile sehr verbreitet, z.B. im für VoIP/Video häufigen Protokoll> RTP.
Für "krass latenzarm" gibt's auch noch AVB, aber das ist auf der
PC-Seite dann auch nicht mehr so einfach umzusetzen.
Stefan ⛄ F. schrieb:> (prx) A. K. schrieb:>> also nackter Ethernet-Controller ohne TCP/IP-Stack>> Bis aus welchen Gründen auch immer ein Router ins Netz eingebaut wird.> Dann wird es plötzlich sehr kompliziert wenn man so anfängt.
Abgesehen davon, dass man auf der Rechner-Seite dann immer mit
Raw-Sockets rumhantieren muss.
(prx) A. K. schrieb:> Da das Hobby-Projekt nach einer Einzellösung klingt,
Er hat sich ja inzwischen offenbar umentschieden. Es ist jetzt doch kein
Hobby-Projekt mehr:
Tux schrieb:> Ich möchte die Ausganssituation des Posts an dieser Stelle ändern und> zwar soll es sich nicht um ein Hobby-Projekt handeln
Nur der Vollständigkeit halber: UART mit 6 oder 12 MBaud und ein
FTDI-Chip mit 'H' im Namen, z.B.
https://ftdichip.com/products/ft232hl/
Der FT232HL könnte das evt. sogar ohne uC, SPI versteht er jedenfalls.
