Hallo, ich möchte in einem Projekt mehrere Module über Ethernet verbinden können. Ich würde das Projekt gerne mit dem lwIP Stack und einem STM32 aufziehen. Kann mir jemand sagen ob ich die Module über die sog. Socketverbindungen verbinden kann? Es wird dabei ein Hauptmodul geben mit dem sich alle anderen Module (z.b. 16 Stück) verbinden und Daten austauschen. Zusätzlich soll auf jedem Modul noch ein Webserver laufen. Gibt das der lwIP Stack her? Und gibt es irgendwo eine gute aktuelle Beschreibung (in deutsch) des lwIP? Gruß Florian
lwip unterstützt TCP-Sockets (auch mehrere gleichzeitig) von daher sollte das kein Problem sein - genau dafür ist es ja da. Wichtig ist, dass dein STM32 ethernet unterstützt (Connectivity Line). Wenn du in der Richtung Fortschritte hast, würd ich gern davon hören, da ich demnächst auch STM32+Ethernet zum Laufen bringen will... :-)
>lwip unterstützt TCP-Sockets (auch mehrere gleichzeitig) von daher >sollte das kein Problem sein - genau dafür ist es ja da. Bei ST gibt es Code für lwip. lwip futtert allerdings einiges an RAM. >Gibt das der lwIP Stack her? Und gibt es irgendwo eine gute aktuelle >Beschreibung (in deutsch) des lwIP? Bei der Qualität deiner Frage solltest du dir überlegen ob du das gebacken bekommst. Ethernet ist die Königsklasse der Programmierung. Für Anfänger nicht geeignet.
Hallo, die "Connectivity Line" und die RAM-Anforderungen sind mir bekannt. Trotzdem Danke für den Hinweis. Auch wenn die Qualität meiner Frage auf meinen Erfahrungsschatz zu dem Thema Ethernet zurück schließen läßt muss das ja nicht bedeuten das ich aufgebe bevor ich begonnen habe. Hat jemand mit TCP-Socketverbindungen unter dem lwIP Erfahrungen gemacht und kann mir die Frage beantworten ob es möglich ist bis zu 16 clients an einen lwIP-Server zu hängen? Kennt jemand ein gutes Projekt in dem man sich mal schlau lesen kann? Gruß Florian
>Hat jemand mit TCP-Socketverbindungen unter dem lwIP Erfahrungen gemacht >und kann mir die Frage beantworten ob es möglich ist bis zu 16 clients >an einen lwIP-Server zu hängen? Möglich schon, letztendlich kommt es drauf an, ob alle Sockets gleichzeitig die Daten übertragen, Datenmenge und die Größe einzelner Buffer und ob die Socket-Verbindungen ständig offen bleiben müssen. Dann bleibt noch zum Überdenken, wie viel RAM der Rest deiner Anwendung benötigt. Webserver ist auch machbar (läßt sich mit fsdata tool vom uIP im Programmspeicher ablegen). LwIP ist da sehr flexibel. Vielleicht könntest du uns verraten, um welche Art der Daten es sich handelt. Ich benutze LwIP im RAW-Modus. Habe ca. 65Mbit/s Durchsatz mit dem STM32F107. Webserver Beispiel liefert ST zum LwIP auch. Habe den Webserver als Grundlage genommem, alles andere wie das Parsen von GET/POST Daten selbst realisiert. Deutsche Doku kenne ich nicht, Beispiel Projekt liefert ST für das Evalboard.
Hallo "af", danke für Deine Antwort. Die Daten sind lediglich einige Messwerte wie z.B. Temperatur. Also keine riesen Datenmengen und nichts zeitkritisches. Die einzelnen Verbindungen sollten eigentlich ständig offen bleiben. Wenn es aber Sinn macht die Verbindung immer nur bei einer Änderung neu aufzubauen käme ich damit auch klar. Da kann ich noch nicht einschätzen was sinnvoll ist. Was für ein Evalboard von ST meinst Du genau? Gruß Florian
Florian schrieb: > Die Daten sind lediglich einige Messwerte wie > z.B. Temperatur. Also keine riesen Datenmengen und nichts > zeitkritisches. Bei solchem Kleinkram nehme ich den uIP, der ist viel einfacher zu behandeln. Auch gibt es mehrere Beispiele im Netz.
Dem kann ich mich nur anschließen UC3 schrieb: > Bei solchem Kleinkram nehme ich den uIP, der ist viel einfacher zu > behandeln. Auch gibt es mehrere Beispiele im Netz. Dem kann ich mich nur anschliessen. Um ein paar Messwerte an einen eigenen Server zu übertragen braucht man weder die Socket-Programmiererei noch den viel aufwendigeren lwIP. Noch ein Tip: Lass die Verbindung nicht offen oder nimm gleich udp. Mit einer Verbindungsunterbrechung musst du sowieso immer rechnen, deshalb ist es besser gleich davon auszugehen dass sie vor der Übertragung aufgebaut wird. Denk auch an die Zeit beim Entwickeln. Der gesamte Code muss vor dem Debuggen geflasht werden und abhängig von der Größe deines restlichen Codes kann da schon mal die 3-4fache Zeit draufgehen. Wenn du die Hardware selbst bauen willst, denk auch mal über das LPCXpresso1769 nach. Da hast du fuer 23€ den kompletten Ethernetteil mit drauf (bis auf die Buchse), einen I2C-EEprom fuer die Konfiguration und bis auf die Batterie alles für die RTC. Ziemlich unschlagbar.
STM3210C-EVAL, kannst aber jedes Chinaboard zulegen (hauptsache nichts, wo die ST PHY drauf ist wie z.B. auf dem Reva, Propox oder Olimex stm32f107 RevA Board). Da haben die alle voneinander abgekupfert und gleichen Mist in die Welt gesetzt. Wobei Olimex REV B mit einer anderen Phy hat, aber Reva die defekten Boards immer noch schön weiter verkauft...Gute Erfahrung hatte ich mit dem Steinert o.ä Board aus Thailand. Für deine Aufgabe würde ich auch eher uIP nehmen.
@"temp" Ist den udp nicht viel zu unsicher in der Übertragung? Ich müsste dann ja auch sicherstellen, das die Packete beim Server angekommen sind. Also ein Handshake selber programmieren. Oder sehe ich das falsch? @"af" Danke für die Ausführungen. Soweit ich weis ist der ST Phy auf dem Olimex Rev. A Board abgekündigt. Ich merke schon, das ich vom µIP überzeugt werden soll :-) Ich glaube nur für die Zukunft mit dem lwIP besser aufgestellt zu sein. Performancetechnisch sehe ich auch kein Problem beim STM32. Gruß Florian
temp schrieb: > UC3 schrieb: >> Bei solchem Kleinkram nehme ich den uIP, der ist viel einfacher zu >> behandeln. Auch gibt es mehrere Beispiele im Netz. > > Dem kann ich mich nur anschliessen. Um ein paar Messwerte an einen > eigenen Server zu übertragen braucht man weder die Socket-Programmiererei > noch den viel aufwendigeren lwIP. Was hier noch keiner erwähnt hat: lwIP hat drei verschiedene Interfaces, die jeweils auf einander aufbauen. Das Socket-Interface ist quasi gleich wie die Berkley-Sockets, braucht aber auch am meisten Ressourcen. Dann gibt es das netconn-Interface, das im Prinzip die gleichen Funktionen bietet, wie die Sockets, aber sich einige Puffer-Kopieraktionen spart. Und dann gibt's da noch das raw-Interface, das sehr viel mehr "low-level" ist. Wenn man das nutzt, kann man die höheren APIs abschalten, und dann ist der Stack auch sehr kompakt und einfach, ich denke ähnlich wie uIP. > Noch ein Tip: > Lass die Verbindung nicht offen oder nimm gleich udp. Mit einer > Verbindungsunterbrechung musst du sowieso immer rechnen, deshalb ist es > besser gleich davon auszugehen dass sie vor der Übertragung aufgebaut > wird. Das sollte der Stack aber selbst erkennen.
Ein rausgezogenes Netzwerkkabel ist fuer viele kein Problem. Aber wenn sich ein dazwischenliegender Router ne neue Addresse gönnt, dann wird das nicht mehr so einfach als Verbindungsabruch erkannt. Wenn du noch nie auf solche Probleme gelaufen bist, hast du noch nicht viel damit zu tun gehabt.
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.