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.
