Hallo zusammen, vorab: Ich bin kein Informatiker oder Elektrotecniker, kann aber Programmieren und habe eine hohe IT-Affinität (Naturwissenschaftler). Bei uns am FG haben wir eine (eigenentwickeltes) Telemetriesystem einer Forschungseinrichtung mit einem relativ hohem Datendurchsatz (derzeit 1 MBit/s, kann auf 8 MBit/s anwachsen) am laufen. Nun möchten wir die Daten gerne (web-)visualisieren. Dafür muss ein Gateway entwickelt werden, der diese an einen PC (Windows) sendet. Bisher war ich eher auf Low-Level-Ebene im Embeded-Bereich unterwegs. Genutzt werden soll Hardware von STM (STM32Fxxx). Sollte man dafür noch auf USB setzen oder lieber direkt auf IP setzen? Was ist vom Implementierungsaufwand im Gerät einfacher zu handeln (ich habe weder Erfahrung mit TCP/IP noch USB-Stacks). Und wichtiger noch: Wie schwer ist die Implementierung eines USB Devices auf Windows? Fertige (kostenlose) Librarys würde ich nat einsetzen, für mehr ist aktuell leider kein Budget vorhanden. Nochmal zusammen gefasst: STM32Fx-Controller sendet Daten (1-8MBit/s) an Winddows-PC. USB oder Ethernet? Natürlich können wir ETler zu Rate ziehen. Vllt würde sich auch die Realisierung innerhalb einer studentischen Arbeit realisieren lassen. Es geht mir nur erstmal um eine Einschätzung.
Ich hätte mich an melden bzw nicht im Zug schreiben sollen. Seht bitte über die vorhandenen Rechtschreib- und Grammatik-Fehler hinweg. :/
Von der Software-Seite aus kommt es darauf an, was der Entwickler gut kann - ich empfände Ethernet/IP einfacher, andere wohl USB. Bei Ethernet kann man sich clientseitige Treiber meist sparen - UDP/TCP können inzw fast alle. Andere Punkte: USB ist eher für den direkten Anschluß an den Rechner geeignet, also Telemetriesystem in räumlicher Nähe zum Rechner/Laptop. Lange Kabel sind da nichts. Bei Ethernet kann sich das Telemetriesystem in einem anderen Raum/Stockwerk befinden, ohne Probleme zu bekommen. Die galvanische Trennung der Geräte ist ein weiterer Vorteil von Ethernet. Dann, was bietet der Mikrokontroller? Nicht alle STM32 (eher wenige) haben einen eingebauten Ethernetkontroller - sind dann eher die etwas dickeren (u.a. auch, weil IP etwas mehr RAM benötigt). Bei USB sieht es einfacher aus - breitere Palette und geringere Anforderungen.
Stefan T. schrieb: > STM32Fx-Controller sendet Daten (1-8MBit/s) an Winddows-PC. > USB oder Ethernet? 8 MBit/s an Nutzdaten gehen nicht mehr sicher über einen Full Speed USB Port - da sind die 12 MBit/s nämlich nur brutto. Wenn USB, dann braucht ihr High Speed USB (480 MBit/s), und das wiederum setzt Eure Auswahl an Controllern ein, weil nur wenige Typen High Speed USB haben und die, die es haben, oft noch einen externen PHY benötigen. Aufpassen! 10 MBit/s Ethernet wird ebenfalls eng. Damit scheidet für Euch die Möglichkeit aus, einen externen Ethernet-Controller wie Microchip ENC28J60 oder Micrel KSZ8851SNL per SPI an Eure vorhandene Hardware anzuschließen - das wird zu langsam. Ihr braucht dann unbedingt einen Controller mit eingebauter 10/100 MAC und externem PHY. IP brauchst auch RAM. fchk
> mit eingebauter 10/100 MAC und externem PHY. Der PHY darf auch gern im Kaefer sein. Nur, ST kriegt es nicht hin. Andere schon. (Selbst bei den Evalboards verbaut ST gern PHYs von anderen Herstellern..., obwohl sie ja zumindest den STE100 haetten.) > IP brauchst auch RAM. Das aber auf alle Faelle.
Vielen Dank für eure Einschätzungen. Ich werde mir dann wohl mal ein paar Beispiele anschauen. Für Ethernet gibt's da natürlich mehrere, USB wäre sonst mein Fav. foobar schrieb: > Von der Software-Seite aus kommt es darauf an, was der Entwickler gut > kann - ich empfände Ethernet/IP einfacher, andere wohl USB. bisher weder das eine, noch das andere. Leider! foobar schrieb: > Dann, was bietet der Mikrokontroller? Wir haben von ST einige Boards geschenkt bekommen. Wahrscheinlich würde ich einen Cortex M7 wählen, ggf noch ein externes RAM bei Bedarf. fchk schrieb: > 8 MBit/s an Nutzdaten gehen nicht mehr sicher über einen Full Speed USB > Port - da sind die 12 MBit/s nämlich nur brutto. Das ist natürlich ein berechtigter Einwand. Es soll schon ein interner Controller verwendet werden.
>> Dann, was bietet der Mikrokontroller? > > Wir haben von ST einige Boards geschenkt bekommen. Wahrscheinlich würde > ich einen Cortex M7 wählen, ggf noch ein externes RAM bei Bedarf. Aha, deswegen also ST. Wenn Du ansonsten eine Alternative brauchst: https://www.microchip.com/wwwproducts/en/PIC32MZ2048EFH144 und dazu das Board https://www.microchip.com/DevelopmentTools/ProductDetails/DM320007 Da hast Du 100 MBit Ethernet, High Speed USB Host/Device/OTG, 2M Flash, 512k RAM und sonst auch alles, was Du brauchst. Dazu sehr gute Softwareunterstützung. fchk
Die STM32F7 haben nur eine FS-PHY integriert, d.h. bei den Nucleo-Boards wird entsprechend nur die USB-FS auf die Buchse herausgeführt. Da müsstet ihr euch dann noch eine externe PHY und eine Buchse dazubauen. Sollte aber eigentlich kein großes Problem darstellen. Die Nucleo-Boards sind sehr gut auf Lochraster zu setzen, was bei euch sicher Sinn macht, da ich mal von Stückzahl 1 ausgehe. PHY und Buchse müsstet ihr dann eben auf eine kleine Adapterplatine setzen. Ethernet sollte hingegen mit den Nucleo-144 Boards out-of-the-box kein Problem sein, z.B. mit dem F746ZG. An eurer Stelle würde ich auch noch eine embedded-Linux Lösung mit beispielsweise Beaglebone Black in Betracht ziehen. Da habt ihr jedenfalls überhaupt keine Probleme wegen Durchsatz oder Speicher und ihr könntet mitunter Teile der Software in High-Level-Sprachen wie Java, Python oder Go schreiben. Die Hardware-Konfiguration beim BBB ist aber leider nicht ganz trivial (GPIO-Mux und co.), was es bei den STM32 jedoch auch nicht ist. Erst recht nicht, wenn man damit noch nie gearbeitet hat. Das müsst ihr halt abwägen, womit eure Leute besser zurechtkommen. PS: Die F7-Discovery-Boards haben die HS-PHY mit an Bord, nebst SDRAM und co. Leider ist da oft die Peripherie auf dem Board im Weg, wenn es darum geht eigene Peripherie anzuschließen. Das müsste man vorher abklären ob es geht.
:
Bearbeitet durch User
Moin, Ich taet's ganz klar mit IP loesen, nicht mit USB. Auf IP kann ich von allen moeglichen Sprachen in allen moeglichen Betriebssystem aus per Socket o.ae. zugreifen. Mit Wireshark prima gucken, was auf der Leitung ist. Bei USB siehts mit so uebergreifenden Standards eher truebe aus. Gruss WK
fchk schrieb: > Wenn Du ansonsten eine Alternative brauchst: > https://www.microchip.com/wwwproducts/en/PIC32MZ2048EFH144 > und dazu das Board > https://www.microchip.com/DevelopmentTools/ProductDetails/DM320007 Das sieht sehr gut aus, Danke. Würde ich wahrscheinlich auch gern versuchen, dennoch versorgt uns STM ganz gut mit Hardware und Software. Deswegen würde ich denen ungern vor den Kopf Stoßen. Wir brauchen auch ein paar CAN und UART (RS485) Schnittstellen. Christopher J. schrieb: > Die STM32F7 haben nur eine FS-PHY integriert, d.h. bei den Nucleo-Boards > wird entsprechend nur die USB-FS auf die Buchse herausgeführt. Das ist leider wahr. Und bei vielen Nucleos ist ein obligatorischer HS-Pin mit EINER LED(!!!!) beschaltet. Gab's denn nicht genug andere Pins (bei 120 I/O?!?!?) Christopher J. schrieb: > Die Nucleo-Boards > sind sehr gut auf Lochraster zu setzen, was bei euch sicher Sinn macht Ich traue mich es ja gar nicht zu sagen, aber so läuft das bei uns idR. Teilweise lassen wir aber auch custom PCBs fertigen, meist jedoch mit einem Nucleo auf dem Rücken. Christopher J. schrieb: > An eurer Stelle würde ich auch noch eine embedded-Linux Lösung mit > beispielsweise Beaglebone Black in Betracht ziehen. Es werden hauptsächlich Studenten daran werkeln und mit den STMs sind wir bisher ganz gut gefahren. Ich würde das ganze wirklich gerne näher beschreiben, aber geht leider nicht. Das BBB schaue ich mir gerne mal genauer an, wichtig sind natürlich deren BUS-Fähigkeiten. Daran ist der RPi nämlich gescheitert. Dergute W. schrieb: > Bei USB siehts mit so uebergreifenden Standards eher truebe aus. Das spricht neben der Leitungslänge definitiv für Ethernet
Stefan T. schrieb: > Christopher J. schrieb: >> Die Nucleo-Boards >> sind sehr gut auf Lochraster zu setzen, was bei euch sicher Sinn macht > > Ich traue mich es ja gar nicht zu sagen, aber so läuft das bei uns idR. > Teilweise lassen wir aber auch custom PCBs fertigen, meist jedoch mit > einem Nucleo auf dem Rücken. Da ist doch auch nichts verwerfliches dran. Wichtig ist doch immer nur, dass es am Ende funktioniert und Aufwand und Nutzen in einem vernünftigen Verhältnis stehen. Stefan T. schrieb: > Christopher J. schrieb: >> An eurer Stelle würde ich auch noch eine embedded-Linux Lösung mit >> beispielsweise Beaglebone Black in Betracht ziehen. > > Es werden hauptsächlich Studenten daran werkeln und mit den STMs sind > wir bisher ganz gut gefahren. Wenn ihr mit den STMs gut gefahren seid, dann würde ich vermutlich auch einen solchen nehmen. Hörte sich für mich erst so an, als ob ihr da noch nichts mit gemacht hättet aber das war wohl ein Missverständnis und nur auf USB/Ethernet bezogen.
Stefan T. schrieb: > Nun möchten wir die Daten gerne (web-)visualisieren. Wenn das das eigentliche Ziel ist: ihr werdet ja kaum diese Datenmengen tatsächlich anzeigen können. Vorverarbeitung auf dem MC-System und damit wahrscheinlich drastisch Reduktion der Datenmenge? Aber ansonsten: klar Ethernet.
Stefan T. schrieb: > Deswegen würde ich denen ungern vor den Kopf Stoßen. Wir brauchen auch > ein paar CAN und UART (RS485) Schnittstellen. Dann denke daran, dass einige der STM32 Controller nur entweder CAN oder USB können, weil beide Einheiten das selbe (nicht das gleiche!) Dual-Port RAM benutzen. Schon scheiße, dass Ihr Euch so einengen lasst. STM macht das nicht zum Spaß, sondern das ist Marketing, damit die Studenten STM-Erfahrung haben und dann in ihren Jobs auch diese Chips eindesignen. Das ist knallhart kalkuliert. Ihr müsst sehen, ob Ihr dieses Spiel mitspielen wollt. Woanders gibts auch nette Lösungen fchk
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.