Wie ethernet zu Messgerät hinzufügen

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!

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.

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.

In der, und fuer die Industrie wird man kaum einen ESP32 benutzen.
Darauf kommen die Bastler hier wieder nicht.

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.