Hallo zusammen! Ich habe ein Modul zum Erfassen von analogen Messwerten entwickelt. Simpler Aufbau mit analoger Signalkonditionierung, mehrere schnelle ADCs, STM32 und bisschen Speicher. Aktuell wird das ganze über UART ausgelesen. Nun sollen die Messdaten mit labVIEW in einem größeren Aufbau erfasst werden. Als Verbindung in unserem Testaufbau wäre Ethernet zu bevorzugen (örtliche Position, usw.), mir ist aber klar, dass es auch andere Optionen gibt. Wie funktioniert sowas? Wie "bringe ich meinem System Ethernet bei"? Geplant ist nicht, den vorhandenen UART auf Ethernet zu wandeln, sondern eher eine "native" Ethernet Schnittstelle an den STM32 anzubinden. Hat hier jemand einen Startpunkt (Beispielprojekte, Lektüre, App-Notes) für Soft- und Hardware? Ich bin irgendwie ein bisschen überfordert :-/ VIele Grüße und Danke!
Hat dein STM32 Controller denn Ethernet? Wenn nicht musst du einen Ethernet Controller dran hängen, zum Beispiel einen CP2201 und einen TCP-IP Stack in dein Projekt einbinden, zum Beispiel µIP von Adam Dunkels. Billiger und einfacher ist, einen ESP8266 zu verwenden. Siehe dazu: http://stefanfrings.de/net_io/index.html (das ist ein Projekt mit CP2201 an einem AVR, davon kannst du sicher einiges abkupfern) http://stefanfrings.de/esp8266/index.html (beschreibt den ESP8266)
Stefan ⛄ F. schrieb: > Hat dein STM32 Controller denn Ethernet? Ja, stimmt. Da hätte ich mal drauf kommen können. Der STM32F4 hat Ethernet und sollte das dann können! Wie sieht die Hardware-Anbindung aus, hat da jemand ein Beispiel? Danke, Stefanus, auch für die Beispiele. Ich denke aber, wenn ich da einen externen Chip dranhänge, wird mir das ganze zu langsam. Sind ja doch viele Daten die so Echtzeitig wie möglich rüber sollen! Vielen Dank und schönen Sonntag noch!
Mike schrieb: > Der STM32F4 hat Ethernet und sollte das dann können! Wie sieht die > Hardware-Anbindung aus, hat da jemand ein Beispiel? Du könntest vom Discovery Board abgucken.
Mike schrieb: > Ich denke aber, wenn ich da einen externen Chip dranhänge, wird mir das > ganze zu langsam. Sind ja doch viele Daten die so Echtzeitig wie möglich > rüber sollen Mach doch Mal ne Aussage dazu. Ein paar Mbit bekommt man selbst mit einem wiznet w5500 und spi hin, mit den neuen mit paralleler Ansteuerung sollte da deutlich mehr drin sein. Ein Nachteil von Software-Stacks a la uIP ist halt, dass es mit auf dem Controller läuft, also Rechenzeit braucht und ggfs von Bugs aus deinem Code zerlegt wird. Daher mag ich die wiznet-chips. Und viel einfacher wird es nicht mehr, von der Ansteuerung her.
Dunno.. schrieb: > Mach doch Mal ne Aussage dazu. Ein paar Mbit bekommt man selbst mit > einem wiznet w5500 und spi hin, mit den neuen mit paralleler Ansteuerung > sollte da deutlich mehr drin sein. Im worst-case (wird aktuell nicht verwendet, wäre aber gut wenn geht): 16Kanäle, 16bit, 100ksps = 25,6Mbit reine Nutzdaten plus bisschen overhead. Klingt schon heftig merke ich grad :D Klappt das überhaupt mit 100mbit Ethernet? Wiznet W5500 schaue ich mir an. Viele Grüße!
Angehängte Dateien:
-
Ethernet_PHY_an_F407.png
33 KB
Mike schrieb: > Wie sieht die > Hardware-Anbindung aus, hat da jemand ein Beispiel? Ist als abstrahierter Schaltungsvorschlag in "jedem Datenblatt" eines Ethernet-fähigen STM-Controllers zu finden.
Mike schrieb: > Im worst-case (wird aktuell nicht verwendet, wäre aber gut wenn geht): > 16Kanäle, 16bit, 100ksps = 25,6Mbit reine Nutzdaten plus bisschen > overhead. Upps, kleiner Rechenfehler. Es sind nur 4 ADCs an Board, mit jeweils einem 4er Multiplexer. Also nur 4 Kanäle, 16bit, 100ksps = 6,4MBit. Klingt schon besser.
Mike schrieb: > 25,6Mbit reine Nutzdaten plus bisschen overhead. Dazu brauchst du ja schon Gigabit Ethernet, damit es zuverlässig läuft.
Mike schrieb: > Es sind nur 4 ADCs an Board, mit jeweils einem 4er Multiplexer. Also nur > 4 Kanäle, 16bit, 100ksps = 6,4MBit. Klingt schon besser. Da wirds für den w5500 schon eher eng. Aber das ist auch ein schon eher älterer typ, da gibt's auch neuere.. Kriegst du denn die Daten so schnell erfasst? Wie viel Rechenzeit hast du da noch...? Egal wie, die Übertragung braucht ja auch noch ihre Zeit..
Ein LAN8720 Modul und MBed-OS, allemal besser als die Wiznet Krücke. Welcher STM32 wird denn verwendet, und ist das ein Standard Evalboard oder eigene HW?
Wenn Ethernet nicht von Anfang an mit hineindesignt ist, wird das mit "Dranproempeln" eher nichts. Tu dir einen 2. STM32 aufs Bord, z.B. einen STM32F107 nebst PHY. Oder einen M3/M4 der die PHY schon onbord hat. Der kann sich dann vollinhaltlich ums Ethernet kuemmern und stoert nicht die Messungen. Die Daten kannst du bordintern ja einigermassen schnell z.B. per SPI dahin schaufeln. Mit einer guten Library ist auch das Schreiben eines Socketservers recht einfach. Z.B. CMX MicroNet.
Mike schrieb: > Wie funktioniert sowas? Früher (tm) hätte man einfach irgendeinen Serial-to-Ethernet Konverter daneben gestellt und auf dem PC dann einen gewöhnlichen, wenn auch virtuellen Com-Port gehabt. Wenn man das für Einzelstücke betriebswirtschaftlich betrachtet, ist das die direkteste Lösung. In einer halben Stunde hast du den Stack auf dem STM wahrscheinlich nicht am Laufen.
Wolfgang schrieb: > In einer halben Stunde hast du den Stack auf dem STM wahrscheinlich > nicht am Laufen. Ja, heute braucht man nur noch so lange wenn Rechner oder Internet zu langsam sind, sonst geht es in ca. 15 Minuten. Aber bei der Informationsflut des TO scheint es ja nicht so wichtig zu sein.
Je nachdem was noch an Peripherie am STM übrig ist, gingen bspw. auch ein ESP32 (gibt ne Reihe fertiger Module mit Ethernet) oder bspw. LAN9250 oder AX88796C (Ethernet-Controller mit Phy, die entweder über SPI/Quad-SPI oder parallel 8-/16-Bit angesteuert werden können), LAN7500 (USB->Ethernet). Oder, wie schon geschrieben wurde, ein Redesign mit nem STM32, der schon Ethernet kann...
Na ja, nach der Hardware kommt die Software. Also zuerst einmal ein IP-Stack. Will man nur IPv4 oder soll es auch IPv6 sein? Vollständiger Stack oder "geht so gerade"? Verschlüsselung (TLS) oder nicht? Wie wird der Host konfiguriert (manuell, DHCP, SLAAC, mDNS ...)? Dann kommen die anwendungsspezifischen Protokolle. Will man irgendwas basteln oder soll es wegen labView eher was standardisiertes für Messgeräte sein (LXI mit oder ohne VXI-11 und der ganze Rattenschwanz der je nach Anforderungen dran hängt, wie SCPI und IVI-Treiber für den PC)? Das sollte man sich vorher mal überlegen, sonst wird das eine unendliche Geschichte und der Mikrocontroller ist schnell zu klein.
Arc N. schrieb: > Je nachdem was noch an Peripherie am STM übrig ist, gingen bspw. auch > ein ESP32 Ist der wirklich schnell genug? Ich frage, weil ein ESP8266 nicht einmal 1/10 der geforderten Übertragungsleistung wenn er die Nutzdaten bereits im Speicher hätte.
Hannes J. schrieb: > Na ja, nach der Hardware kommt die Software. Also zuerst einmal ein > IP-Stack. Will man nur IPv4 oder soll es auch IPv6 sein? Vollständiger > Stack oder "geht so gerade"? Verschlüsselung (TLS) oder nicht? Wie wird > der Host konfiguriert (manuell, DHCP, SLAAC, mDNS ...)? Da ist was dran. Mit der Schnittstelle kommt das Wunschkonzert. Auf einmal erwarten die Kunden Features als Selbstverständlichkeit, an die keiner gedacht hat.
Mike schrieb: > Im worst-case (wird aktuell nicht verwendet, wäre aber gut wenn geht): > 16Kanäle, 16bit, 100ksps = 25,6Mbit reine Nutzdaten plus bisschen > overhead. Vor knapp 10 Jahren hatte ich einen STM32F107 mit 66MBit/s via Ethernet gehabt (iperf Test). Denke mit einem STM32F407 sind die 25 Mbit locker möglich.
Stefan ⛄ F. schrieb: > Arc N. schrieb: >> Je nachdem was noch an Peripherie am STM übrig ist, gingen bspw. auch >> ein ESP32 > > Ist der wirklich schnell genug? Ich frage, weil ein ESP8266 nicht einmal > 1/10 der geforderten Übertragungsleistung wenn er die Nutzdaten bereits > im Speicher hätte. ESP32 != ESP8266. Ethernet geht beim ESP32 ziemlich nah an das theoretische Maximum (70 bis 90 MBit/s, iperf) und so viel Overhead sollte in dieser Anwendung eigentlich nicht mehr hinzukommen, dass die Datenrate zu weit einbricht. Siehe bspw. https://esp32.com/viewtopic.php?t=2013 oder https://www.crowdsupply.com/silicognition/wesp32/updates/why-ethernet bzw. https://hackaday.io/project/85389-wesp32-wired-esp32-with-ethernet-and-poe/log/151366-final-performance-checks
In der, und fuer die Industrie wird man kaum einen ESP32 benutzen. Darauf kommen die Bastler hier wieder nicht.
Aktuell wird ein UART verwendet? Wieviel Kilobit rennen da über die Leitung? Mach mal eine realistische Abschätzung. 25MByte/s sind für das bißchen Hardware zu viel.
Witzbold schrieb: > In der, und fuer die Industrie wird man kaum einen ESP32 benutzen. > Darauf kommen die Bastler hier wieder nicht. Mir ist immer wieder raetselhaft, warum einige immer wieder gebetsmuehlenartig die mit no-go-Fehlern bespickten Espressif-Chips empfehlen. Wenn da 'LabVIEW' und 'Messung' steht, duerfte eine 24/7-Verfuegbarkeit gefragt sein. @Mike: Wenn Du Echtzeit-Datenuebertragung willst, wuerde ich ausschliesslich auf DMA-basierte RTP(UDP)-Stacks setzen. uIP hat dafuer eine suboptimale Architektur, soll aber auf manchen Systemen ausreichen. Wir haben dafuer schliesslich eine Loesung auf FPGA-Basis entwickelt (um die ADC-Kanaele noch zu komprimieren). Die Schwierigkeit ist dann u.U., auf PC-Seite den passenden LabVIEW-Daemon zu entwickeln, der die gepushten Daten (Echtzeit) entgegennimmt und fuer LabVIEW-Pull-Betrieb aufbereitet.
Michael X. schrieb: > Mach mal eine realistische Abschätzung. 25MByte/s sind für das bißchen > Hardware zu viel. Wo hast du den Wert her? Er hat Anfangs von 25MBit geschrieben und ist dann auf 6,8MBit runter gegangen. Deshalb hab ich nicht verstanden, warum schon von Gigabit Ethernet geschrieben wurde.
Der UART vom F4 schafft schon 10,5 MBit/s, der beim F7 nochmal doppelt soviel. Aber ob der PC da noch mitkommt? Und um ESP ging es ja nicht, nur wenn der STM32 den der TO verwendet keinen EMAC hat.
Franz schrieb: > Deshalb hab ich nicht verstanden, warum schon von Gigabit Ethernet > geschrieben wurde. Das ist halt die Lösung aller Ahnungslosen: viel hilft viel. Georg
Mike schrieb: > Simpler Aufbau mit analoger Signalkonditionierung, mehrere schnelle > ADCs, STM32 und bisschen Speicher. > Aktuell wird das ganze über UART ausgelesen. Nun sollen die Messdaten > mit labVIEW in einem größeren Aufbau erfasst werden. Als Verbindung in > unserem Testaufbau wäre Ethernet zu bevorzugen Jaja: "Nichts ist zu schwer für den Mann, der es nicht SELBST tun muß"... ..aber du müßtest es selber tun. Momentan arbeitet dein ganzes Zeugs per UART und nun soll es per Netzwerk gehen. Also wieviele Netzwerk-Server auf µC-Basis hast du denn schon selbst gebaut (also HW und SW)? Es ist ja nicht nur die Schaltungstechnik, sondern eben auch die ganze Programmierung, wobei es nicht mal ausreicht, LowLevel-Treiber und nen TCP/IP-Stack hinzukriegen - sondern da ist eben auch die volle Kanne an Netzwerkprogrammierung fällig. Ganz oben meinte "jo mei", daß es als Ratschlag wohl ausreicht, vom µC ein paar Linien zu einem Kringel namens PHY zu malen und das Problem ist gelöst. Wieviele Leute hier können so einen weiten Spagat von Analogtechnik, schnellen ADC's bis hin zur Server-Programierung? Oder anders gefragt: Was hast du denn für ein Team für so ein Projekt? Nur dich selbst? Ich würde da etwas anders herangehen, zum Beispiel erst mal einen simplen FT245 an den µC anflanschen, womit der serielle Flaschenhals erstmal beseitigt ist und man dafür die übliche Infrastruktur am PC bereits fertig hat. Vielleicht reicht das bereits völlig aus - und wenn nicht, dann ist immer noch genug Zeit, an Zeugs wie Ethernet zu denken. Eventuell sogar derart, daß du von deinem µC aus per FT245 auf einen Raspberry oder Rockpi oder so gehst und von dort aus die Übertragung per Netzwerk erledigst. Aber das alles selbst machen wollen und ohne zuvor eigene Erfahrungen in Sachen Netzwerk_HW+SW gesammelt zu haben, halte ich für einen zu großen Brocken, an dem man sich leicht verschlucken kann. W.S.
W.S. schrieb: > Ganz oben meinte "jo mei", daß es als Ratschlag wohl ausreicht, vom µC > ein paar Linien zu einem Kringel namens PHY zu malen und das Problem ist > gelöst. Du leidest sehr wohl an grober Fehlwahrnehmung. Das einzige was ich in diesem Thread gegeben habe ist ein Hinweis wie man ein Netzwerk/LAN an einen STM32 bekommen kann. Zur Verbesserung (Hoffnung auf Genesung bzw Verbesserung des Krankheits- bildes) deiner massiven Wahrnehmungsstörung hier nochmal das volle Zitat meines Beitrages: jo mei schrieb: > Ist als abstrahierter Schaltungsvorschlag in "jedem Datenblatt" > eines Ethernet-fähigen STM-Controllers zu finden.
W.S. schrieb: > ber das alles selbst machen wollen und ohne zuvor eigene Erfahrungen in > Sachen Netzwerk_HW+SW gesammelt zu haben, halte ich für einen zu großen > Brocken, an dem man sich leicht verschlucken kann. ja, aber nur wenn man meint alles besser zu können und keiner fremden Software traut, und dann lieber EMAC + PHY mit magic numbers programmiert und einen eigenen IP Stack zusammenfrickeln will. Dagegen gibt es OS mit sehr Posix nahen Sockets, so das sich die Programmierung kaum von der am PC unterscheidet und man schnell eine UDP/TCP Kommunikation aufbauen kann.
@jojos: Ich will nich wissen wie ein IP Stack aus W.S. seiner Feder aussehen wird ;) Ansonsten ist es ja auch echt nicht schwierig den LWIP einzubinden, der kommt ja schon mit allem was man sich so wünschen kann und das auch als STM32 Port. Bzw FreeRTOS hat ja auch nen passenden IP Stack. https://www.freertos.org/FreeRTOS-Plus/FreeRTOS_Plus_TCP/index.html (gleich kommen von dem Geisteskranken wieder Hasstiraden gegen RTOS) W.S. schrieb: > Wieviele Leute hier können so einen weiten Spagat von Analogtechnik, > schnellen ADC's bis hin zur Server-Programierung? Du schonmal nicht!
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.