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":
1 | Performance specifications |
2 | 17 noise free bits at 250 kSPS |
3 | 20 noise free bits at 2.5 kSPS |
4 | 22 noise free bits at 5 SPS |
Wie sieht das bei deinem ADC aus?
Das wäre auch meine erste Frage gewesen: Hast Du die Möglichkeiten und das Know-How, damit bei Deinen 24 Bits nicht 10 Bits im Rauschen landen? fchk
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.
bei der Datenrate besteht kein Bedarf an Standards vorbei zu programmieren, UDP oder auch TCP kann man sich da durchaus auf beiden Seiten leisten.
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.
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.