Hey Zusammen, ich brauche mal eure Hilfe/Empfehlung. Habe ein bestehendes Projekt welches aktuell auf einem ATmega328 rennt.Ist plain C. Es nützt zur Kommunikation den UART. Hab dazu ein proprietäres Protokoll mit samt CRC Check gebaut. Aus verschiedensten Use Cases möchte ich den Übertragungsweg nach Ethernet umstellen. Zum testen habe ich ein ENC28J60 Modul (nichts besonderes aus Asien). Tut auch soweit und gut. Mangels Zeit möchte ich eine bestehende Lösung verwenden. Ich suche also einen TCP Stack der eine Verbindung annimmt. Gibt es eine Empfehlung des Tages? Bisher finde ich nur Eierlegende Wollmilchsäue mit DNS/DHCP/Webserver und allem Möglichen. Das brauche ich alles nicht. Der billig Code der da rum schwirrt ist mir zu instabil. Also ich bin bisher bei entweder Alles oder Ramsch angelangt. Wäre über einen Tipp denkbar...
Andy Y. schrieb: > Wäre über einen Tipp denkbar... Genau versteh ich nicht was du machen willst, aber den ENC28J60 würde ich nach aktuellen Stand der Dinge ersetzen durch ein Modul mit W5100 oder W5500. Da ist schon TCP drin, und der Code aussen herum ist sehr kompakt.
> Genau versteh ich nicht was du machen willst, aber den ENC28J60 > würde ich nach aktuellen Stand der Dinge ersetzen durch ein > Modul mit W5100 oder W5500. Da ist schon TCP drin, und der > Code aussen herum ist sehr kompakt. Ich bin auf der Suche nach einem kleinen, zuverlässigen, getesteten TCP Stack ohne Schnick Schnack drum herum. Wollte auf UDP verzichten weil ich dann die Kommunikation auf Applikativer Schicht sicherstellen muss. Konkret möchte ich den UART rauswerfen und durch TCP ersetzen. Ich schaue mir mal die W5100/W5500 Geschichten an. Vielleicht ist da was besseres dabei.
Der kleinste mir bekannte TCP Stack ist der µIP von Adam Dunkels. Aber der ATmega328 ist zu klein, um diesen sinnvoll zu nutzen. Hier hast du ein Beispielprojekt mit uIP für einen anderen (ähnlichen) Ethernet Controller und etwas größere AVR. http://stefanfrings.de/wlan_io/index.html Ich kann dir versichern, dass dieser Code auf den Crub-644-Net und CrumbX1-Net Modulen absolut zuverlässig läuft. Mit viel Mühe bekommt man das eventuell so weit reduziert, dass es in den ATmgea328 passt. Das wird aber keinen Spaß machen. Für den ATmega328 eignen sich eher Ethernet Controller, die den TCP/IP Stack bereits enthalten. Wiznet ist eine gute Anlaufstelle. Für WLAN taugt das viel billigere ESP-01 Modul. Zumindest mit der alten Firmware (SDK 1.5.4) laufen diese Module ebenfalls sehr stabil. Ich hatte eine Anwendung 3 Jahre lang durch laufen lassen, ohne einen einzigen Aussetzer. http://stefanfrings.de/esp8266/index.html Für die Kombination ATmgea328 + ESP-01 habe ich sogar konkrete Beispiele: http://stefanfrings.de/wlan_io/index.html und http://stefanfrings.de/mikrocontroller_buch/index.html in Band 3 Kapitel 13
Stefan ⛄ F. schrieb: > Der kleinste mir bekannte TCP Stack ist der µIP von Adam Dunkels. Ja, wurde z.B. hier verwendet: http://www.ethersex.de/index.php/Ethersex > Aber > der ATmega328 ist zu klein, um diesen sinnvoll zu nutzen. Das ist Unsinn. Ethersex beweist das Gegenteil. Das ist anfangs für ATmega32 gedacht gewesen und man kann schon damit sehr viele sinnvolle Anwendungen basteln. Der ATmega328 ist mindestens genausogut geeignet wie der ATmega32. Aber klar: Wenn die "einzig sinnvolle Anwendung" ein fetter HTTP-Server sein soll, dann wäre ein Controller mit mehr RAM und Flash natürlich vorzuziehen. Code von einem Mega328P sollte sich sehr leicht z.B. auf einen ATmega1284P anpassen lassen, weite Teile der Hardware sind ja identisch. Dann hat man den vierfachen Flash und den achtfachen RAM zur Verfügung. > Mit viel Mühe bekommt man das eventuell so weit reduziert, dass es in > den ATmgea328 passt. Das wird aber keinen Spaß machen. Nimmt man halt einfach den Code aus dem Ethersex-Projekt...
Andy Y. schrieb: > Konkret möchte ich den UART rauswerfen und durch TCP ersetzen. Dafür gibt es XPort u.ä. Dann brauchst du garkeine TCP-Software, und die für UART hast du ja. Ist dir aber vermutlich zu teuer. Georg
Georg schrieb: > Andy Y. schrieb: >> Konkret möchte ich den UART rauswerfen und durch TCP ersetzen. > > Dafür gibt es XPort u.ä. Dann brauchst du garkeine TCP-Software, und die > für UART hast du ja. > > Ist dir aber vermutlich zu teuer. > > Georg Ich Danke Dir für den Hinweis. Aber für das Geld nehme ich mir einen Orange Pi Zero mitsamt einem kleinen Busybox Kernel...
> Nimmt man halt einfach den Code aus dem Ethersex-Projekt...
Ich habe das ethersex Projekt auch schon im Auge gehabt. Vermutlich wird
es darauf rauslaufen.
Andy Y. schrieb: > Konkret möchte ich den UART rauswerfen und durch TCP ersetzen. ... und weiterhin auf dem (ur-)alten ENC28J60 herumreiten? Das ist auf den 8-bittern schon eine recht zähe Geschichte. Naja wenn man gerade Lust drauf hat ... ich würde jedenfalls bei einem neuen Projekt nicht nochmal mit so etwas anfangen das schon 15(?) Jahre auf dem Buckel hat. Ist ja schon der W5100 ein paar Jährchen alt aber eine tolle Geschichte wenn man den (geringen) Software-Aufwand betrachtet der aussen dazugefügt werden muss. Ausserdem braucht man sich um die minimal erforderlichen Neben-Funktionalitäten wie Ping und ARP nicht kümmern. Dann möchte ich auch gar nicht wissen wie uIP Zusatzfunktionen wie z.B. DHCP handled, und wie das alles in einen 328 Controller hineinpassen soll. Wenn ich mir die vorhandenen Möglichkeiten (es gibt noch weitaus mehr) auf den Bildern im Anhang anschaue wundere ich mich doch sehr wie man noch an den alten Geschichten hängen bleiben kann. Weil Pollin das noch anbietet? Naja, zumindest ist das Zeugs spottbillig, wenngleich ich heutzutage fünf Module W5500 für unter 30 Euro in Deutschland kaufen kann. Ganz schick finde ich die neuerdings erhältlichen Arduino Uno Module mit W5500 drauf integriert. Da möchte ich nichts mehr vom alten ENC28J60 wissen.
jo mei schrieb: > Dann möchte ich auch gar nicht wissen > wie uIP Zusatzfunktionen wie z.B. DHCP handled, und wie das > alles in einen 328 Controller hineinpassen soll. Der DHCP Client für µIP umfasst etwa 400 Zeilen Code.
jo mei schrieb: > Ist ja schon der W5100 ein paar Jährchen alt aber eine tolle > Geschichte wenn man den (geringen) Software-Aufwand betrachtet > der aussen dazugefügt werden muss. Du weisst schon, dass nahezu jede Protokoll-Implementierung der W3/5* angreifbar ist? Also zumindest ein DoS ist praktisch immer drin. > Dann möchte ich auch gar nicht wissen > wie uIP Zusatzfunktionen wie z.B. DHCP handled, und wie das > alles in einen 328 Controller hineinpassen soll. Kannst du dir halt einfach im Ethersex-Projekt anschauen... Man muss allerdings zugeben: auch diese Implementierungen sind praktisch durchweg zumindest im Sinne von DoS angreifbar. Der Vorteil ist: das kann ICH ändern, weil das Software auf dem µC ist, den ich kontrolliere...
Stefan ⛄ F. schrieb: > Der DHCP Client für µIP umfasst etwa 400 Zeilen Code. Und was willst du uns damit sagen?
c-hater schrieb: > Du weisst schon, dass nahezu jede Protokoll-Implementierung der W3/5* > angreifbar ist? Also zumindest ein DoS ist praktisch immer drin. Solche Mikrocontroller haben sowieso nichts im Internet verloren.
c-hater schrieb: > Du weisst schon, dass nahezu jede Protokoll-Implementierung der W3/5* > angreifbar ist? Du weisst schon, dass du mit einem 75-PS-Auto keine optimalen Rundenzeiten auf dem Nürburgring erreichen kannst?
jo mei schrieb: >> Der DHCP Client für µIP umfasst etwa 400 Zeilen Code. > Und was willst du uns damit sagen? Das er existiert und eine überschaubare Größe hat.
c-hater schrieb: > Kannst du dir halt einfach im Ethersex-Projekt anschauen... Ich möchte es wirklich nicht wissen: jo mei schrieb: > Dann möchte ich auch gar nicht wissen
Stefan ⛄ F. schrieb: > und eine überschaubare Größe hat. "400 Zeilen Quellcode" und "überschaubare Größe", was will man mehr? Das Auto xyz ist "bezahlbar", was will man mehr?
jo mei schrieb: > c-hater schrieb: >> Du weisst schon, dass nahezu jede Protokoll-Implementierung der W3/5* >> angreifbar ist? > > Du weisst schon, dass du mit einem 75-PS-Auto keine optimalen > Rundenzeiten auf dem Nürburgring erreichen kannst? Kommt auf das Gewicht des Fahrzeugs an.
Also vielen herzlichen Dank für eure Ausführungen. Ich denke ich habe kapiert wohin mich das führt. > ... und weiterhin auf dem (ur-)alten ENC28J60 herumreiten? Das > ist auf den 8-bittern schon eine recht zähe Geschichte. Naja > wenn man gerade Lust drauf hat ... ich würde jedenfalls bei > einem neuen Projekt nicht nochmal mit so etwas anfangen das > schon 15(?) Jahre auf dem Buckel hat. FullACK. > Wenn ich mir die vorhandenen Möglichkeiten (es gibt noch weitaus mehr) > > auf den Bildern im Anhang anschaue wundere ich mich doch sehr wie man noch an den alten Geschichten hängen bleiben kann. Weil Pollin das noch anbietet? Das hat überhaupt nichts mit dem Lieferanten zu tun. Ich habe die Dinger für ein paar US$ gekauft vor langer Zeit ohne zu Wissen was ich damit anfangen kann. Nun habe ich einen konkreten Use Case. Wenn ich aber Tage investieren muss um mir was zu stricken ist mehr Asche verbraten als das ich mir nach was anderem Umschaue. > Naja, zumindest ist das Zeugs spottbillig, wenngleich ich heutzutage fünf > Module W5500 für unter 30 Euro in Deutschland kaufen kann. Wo die her komme ist mir Egal. Ich würde beruflich natürlich auch nur das Beste wählen. Hier befinde ich mich aber im Hobby Bereich. Muss nicht schlechter sein deswegen - schon klar. > Ganz schick finde ich die neuerdings erhältlichen Arduino Uno > Module mit W5500 drauf integriert. Da möchte ich nichts mehr > vom alten ENC28J60 wissen. Das rechte Arduino Modul mit dem W5500 hat es mir angetan. Allerdings bin ich weit Weg vom Arduino Core und der IDE (falls man das so nennen möchte) und dem ganzen Zeugs. Mal schauen, ob ich das direkt am ATmega zum laufen bekomme. > Du weisst schon, dass nahezu jede Protokoll-Implementierung der W3/5* > angreifbar ist? Also zumindest ein DoS ist praktisch immer drin. Schon gut :) Das Ding rennt erstmal bei mir lokal und hat nicht viel mit der Welt gemein. Damit fällt es in jedemfall für eine Professionelle Anwendung flach. Aber zum Hobby Basteln tut es das schon oder?
Andy Y. schrieb: > Das rechte Arduino Modul mit dem W5500 hat es mir angetan. Allerdings > bin ich weit Weg vom Arduino Core und der IDE (falls man das so nennen > möchte) und dem ganzen Zeugs. Gut dass du es wagst über den Tellerrand hinauszuschauen. Andy Y. schrieb: > Mal schauen, ob ich das direkt am ATmega zum laufen bekomme. Klar geht das! Ich kaufe mir die Arduino-Module sowie Arduino-Controller nur damit ich schnell Hardware auf dem Tisch habe ohne selbst was zusammenzufrickeln (was im Fehl-Fall bei mir immer wieder passiert). Auf meinen Arduino-Controllern läuft nur ganz eigen geschriebene Software ohne Arduino-Framework. Auch für diesen Anwendungsfall von Ethernet/TCP-Controllern. Man lernt viel mehr, ist eigenständig, viel flexibler und hat den schnelleren Code.
jo mei schrieb: > Andy Y. schrieb: >> Das rechte Arduino Modul mit dem W5500 hat es mir angetan. Allerdings >> bin ich weit Weg vom Arduino Core und der IDE (falls man das so nennen >> möchte) und dem ganzen Zeugs. > > Gut dass du es wagst über den Tellerrand hinauszuschauen. Natürlich. Sonst würde ich hier nicht Fragen :) > Andy Y. schrieb: >> Mal schauen, ob ich das direkt am ATmega zum laufen bekomme. > > Klar geht das! > Ich kaufe mir die Arduino-Module sowie Arduino-Controller nur > damit ich schnell Hardware auf dem Tisch habe ohne selbst was > zusammenzufrickeln (was im Fehl-Fall bei mir immer wieder > passiert). Auf meinen Arduino-Controllern läuft nur ganz eigen > geschriebene Software ohne Arduino-Framework. Auch für diesen > Anwendungsfall von Ethernet/TCP-Controllern. Man lernt viel > mehr, ist eigenständig, viel flexibler und hat den schnelleren > Code. Ich habe mir immer die Module mit dem herausnehmbaren DIL ATmega besorgt. Da ich gerne noch mit dem JTAG ICE MKII debugge. Ich habe es allerdings mit den fest verlöteten noch nicht hinbekommen...
Andy Y. schrieb: > Ich habe mir immer die Module mit dem herausnehmbaren DIL ATmega > besorgt. Da ich gerne noch mit dem JTAG ICE MKII debugge. Ich habe es > allerdings mit den fest verlöteten noch nicht hinbekommen... Vielleicht auch für dich interessant: Für meine Entwicklungsarbeiten benutze ich mittlerweile einen Arduino Mega2560 mit dem man vorzüglich Debuggen kann da er ja ein JTAG-Interface hat. Nur um die Verdrahtung muss man sich selbst kümmern. Da sich die Controller in dieser Familie sehr stark ähneln ist es ein leichtes den lauffähigen Code auf einen anderen Controller zu übertragen. Auf diese Weise kann man z.B. komplizierten Code für einen Mega328 entwickeln und laufen lassen ohne ihn explizit auf diesem kleinen Controller debuggen zu müssen. Hier auf den Fotos neben Arduino Mega2560 und W5100-Modul meine steckbare Debug-Platine zum Anchliessen von Debugger, W5100 und W5500.
jo mei schrieb: > Andy Y. schrieb: >> Ich habe mir immer die Module mit dem herausnehmbaren DIL ATmega >> besorgt. Da ich gerne noch mit dem JTAG ICE MKII debugge. Ich habe es >> allerdings mit den fest verlöteten noch nicht hinbekommen... > > Vielleicht auch für dich interessant: > > Für meine Entwicklungsarbeiten benutze ich mittlerweile einen > Arduino Mega2560 mit dem man vorzüglich Debuggen kann da er ja > ein JTAG-Interface hat. Nur um die Verdrahtung muss man sich > selbst kümmern. Da sich die Controller in dieser Familie sehr > stark ähneln ist es ein leichtes den lauffähigen Code auf > einen anderen Controller zu übertragen. Auf diese Weise kann > man z.B. komplizierten Code für einen Mega328 entwickeln und > laufen lassen ohne ihn explizit auf diesem kleinen Controller > debuggen zu müssen. > > Hier auf den Fotos neben Arduino Mega2560 und W5100-Modul meine > steckbare Debug-Platine zum Anchliessen von Debugger, W5100 > und W5500. Wow... Heißt ich muss das JTAG Interface aktivieren über ISP und brauche dann eigentlich nur die Pins für das JTAG rausführen. Panne das mir das nicht eingefallen ist. Habe hier einen Mega2560. Muss ich gleich mal versuchen... Das DebugWire Interface ist so elend langsam das es schon kaum Spass macht :) Was nimmst Du dann zum Entwickeln? Bleibst Du auf dem AVR Studio hängen oder gibt es da dann noch eine Alternative...?
:
Bearbeitet durch User
Andy Y. schrieb: > Habe hier einen Mega2560. Muss ich gleich mal versuchen... Na also ... geht doch!
Andy Y. schrieb: > Was nimmst Du dann zum Entwickeln? Bleibst Du auf dem AVR Studio hängen > oder gibt es da dann noch eine Alternative...? Mittlerweile vorwiegend Atmel Studio 7.x, auch wenn ich das alte Atmel Studio 4.18 für den schnellen Hack nicht missen möchte. Auch allein zum Fuses programmieren oft recht nützlich. Wenn der eigene Rechner schnell genug ist dann hat das Atmel Studio schon tolle Vorteile, beim Editieren z.B. das Syntax- Highlighting, beim Debuggen der Komfort ... Dazu natürlich JTAG ICE MKII und Atmel-ICE je nachdem wie es gerade besser passt.
jo mei schrieb: > Atmel Studio 7.x, auch wenn ich das alte > Atmel Studio 4.18 ^^^^^^^^^^^^^^^^^^^^ Hier meinte ich natürlich AVR Studio 4.18
Spitze. Auch wenn ich in dem Eintrag was ganz anderes wollte (hoffe niemand achtet hier so sehr auf die Ordnung :) ). jo mei schrieb: > jo mei schrieb: >> Atmel Studio 7.x, auch wenn ich das alte >> Atmel Studio 4.18 > ^^^^^^^^^^^^^^^^^^^^ > Hier meinte ich natürlich AVR Studio 4.18 Spitze. Auch wenn ich in dem Eintrag was ganz anderes wollte (hoffe niemand achtet hier so sehr auf die Ordnung :) ). Das JTAGen tut echt gut...
Andy Y. schrieb: > Das JTAGen tut echt gut... Ja schon, besonders dann wenn man - wie du es tust - auch Masse und Vcc nicht vergisst zu verdrahten ;-) Ach wie ich diese fliegenden Aufbauten liebe ... nicht wirklich. Sie machen halt das Arbeiten nicht besonders zuverlässig.
jo mei schrieb: > Andy Y. schrieb: >> Das JTAGen tut echt gut... > > Ja schon, besonders dann wenn man - wie du es tust - auch Masse > und Vcc nicht vergisst zu verdrahten ;-) Haha und die Fuses anpasst... > Ach wie ich diese fliegenden Aufbauten liebe ... nicht wirklich. > Sie machen halt das Arbeiten nicht besonders zuverlässig. Keine Angst - wenn das einigermaßen fusioniert, da gibt es Adapterplatinen :)
Andy Y. schrieb: > Wollte auf UDP verzichten weil > ich dann die Kommunikation auf Applikativer Schicht sicherstellen muss Denke daran, dass bei TCP nur sichergestellt wird, dass alle Daten in der richtigen Reihenfolge ankommen. Deine Daten können auf mehrere TCP Pakete aufgeteilt werden, auch wenn die Daten theoretisch in ein TCP Paket passen würden. Deine Applikationsschicht muss das behandeln oder alternativ könntest du noch http auf TCP aufsetzen. Aus diesem Grund nehme ich UDP: Wenn ein Paket ankommt, liegt der Befehl/Datensatz vollständig vor und kann sofort bearbeitet werden.
Peter schrieb: > Andy Y. schrieb: >> Wollte auf UDP verzichten weil >> ich dann die Kommunikation auf Applikativer Schicht sicherstellen muss > > Denke daran, dass bei TCP nur sichergestellt wird, dass alle Daten in > der richtigen Reihenfolge ankommen. Deine Daten können auf mehrere TCP > Pakete aufgeteilt werden, auch wenn die Daten theoretisch in ein TCP > Paket passen würden. Deine Applikationsschicht muss das behandeln oder > alternativ könntest du noch http auf TCP aufsetzen. Aus diesem Grund > nehme ich UDP: Wenn ein Paket ankommt, liegt der Befehl/Datensatz > vollständig vor und kann sofort bearbeitet werden. Ok das war mir so nicht klar. Für mich war das Verbindungsorientierte Charmant. Hattest Du das bebobachtet oder ist das in der Spec so explizit dokumentiert? Ich muss nochmals über meinen Satz was UDP Betrifft nachdenken. Vielleicht war das etwas vorschnell. Da ich zum einen ja ein eigenes Protokoll gebaut habe, welches eine CRC16 Prüfsumme enthält und zum anderen gar nicht soooo lang ist was die Datengröße angeht... Nichts desto trotz wäre dann ja trotzdem ein W5100/W5500 Einsatz Möglich.
Andy Y. schrieb: > Konkret möchte ich den UART rauswerfen und durch TCP ersetzen. Dafür gibt es UART-zu-Ethernet Module: https://shop.usriot.com/serial-to-ethernet/serial-to-ethernet-module/serial-to-ethernet-module.html
Andy Y. schrieb: > Hattest Du das bebobachtet oder ist das in der Spec so > explizit dokumentiert? Ja und ja. Nagle algorithm ist das Stichwort nach dem du suchen musst. Man kann Nagle auch ausschalten (unter Windows) aber das gilt dann nicht nur für deinen socket sondern für alle tcp Verbindungen. Wenn du bei TCP bleiben willst, könntest du http draufsetzen. Http setzt deine Kommandos zusammen und übergibt sie erst an die Applikationsschicht, wenn das Kommando komplett ist.
Stefan ⛄ F. schrieb: > Der kleinste mir bekannte TCP Stack ist der µIP von Adam Dunkels. Aber > der ATmega328 ist zu klein, um diesen sinnvoll zu nutzen. nun ja der Pollin NETIO konnte das mit dem ATmega32, hat mich aber auch nicht befriedigt aber man konnte ja den ATmega 1284p einsetzen mit viel mehr flash und 8-fachen SRAM (und so läuft bei mir der NETIO seit 2008) https://www.pollin.de/p/bausatz-avr-net-io-810058 etwas getunt mit Schaltregler statt Linearregler mit Kühlkörper und fürs Steckbrett gibt es auch Arduino Umsetzungen https://github.com/JChristensen/mini1284 davon hatte ich einige selber aufgebaut einige fertig gekauft, finde ich aktuell nicht mehr fertig, Platinen bestellen bei OSH Park und selber löten geht aber immer noch oder: sowie andere Arduino Umsetzungen mit dem ATmega 1284p https://hackaday.com/2011/08/17/bobuino-arduino-based-on-atmega1284-goodies/ https://forum.arduino.cc/index.php?topic=663101.0 https://www.crowdsupply.com/pandauino/narrow https://aptinex.com/product/lakduino-dwee-1284-pro-mini/
:
Bearbeitet durch User
Der ATmega328 reicht prinzipiell aus, um so einen Ethernet Controller zu verwenden. Schließlich wurde µIP für derartige Hardware gemacht. Aber Spaß macht es nicht. Man stößt damit immer wieder an die Speichergrenzen. Es wird schon schwierig, eine Konfigurations-Webseite zu erstellen, wie sie bei Druckern selbstverständlich geworden sind. Ab Atmega644 aufwärts wird das ganze erheblich angenehmer. Ich habe mich damit lange beschäftigt. Heute ist für mich allerdings WLAN angesagt. Da kann ich das ganze Web-Interface bequem mit Arduino (oder meinetwegen auch LUA) auf dem "fetten" ESP Chip implementieren. Der Rest (vor allem alles zeitkritische) läuft dann auf dem kleineren Mikrocontroller. Dann hat man sozusagen eine Trennung zwischen Backend und Frontend, das bin ich von der Arbeit (Geschäftsanwendungen) her auch gewohnt. Für mich fühlt sich diese Kombo stimmig an. Anfangs hatte ich große Zweifel an der Zuverlässigkeit der ESP Module, deswegen waren verkabelte Sachen mit Ethernet noch sehr attraktiv für mich. Aber inzwischen laufen auch die WLAN Sachen so stabil, dass ich mir darüber keine Sorgen mehr mache.
Peter schrieb: > Andy Y. schrieb: >> Hattest Du das bebobachtet oder ist das in der Spec so >> explizit dokumentiert? > Ja und ja. > Nagle algorithm ist das Stichwort nach dem du suchen musst. > Man kann Nagle auch ausschalten (unter Windows) aber das gilt dann nicht > nur für deinen socket sondern für alle tcp Verbindungen. > Wenn du bei TCP bleiben willst, könntest du http draufsetzen. Http setzt > deine Kommandos zusammen und übergibt sie erst an die > Applikationsschicht, wenn das Kommando komplett ist. Vielen Dank. Was neues zum diskutieren an der Kaffee-Ecke. Nein ernsthaft muss ich mir unbedingt anschauen.
Also, ich Danke euch herzlich für den Input. Bin wirklich begeistert. Hätte nicht gedacht das sich noch jemand mit so etwas auseinander setzt. Bei mir auf Arbeit beschäftigen wir uns nur noch mit SOC's, FPGA's und Gigabit Ethernet. Da schert sich niemand mehr um einen "Popel-ATmega". So richtig antun will das niemand mehr. Und um die Stabilität und Angreifbarkeit der „Bastel-Lösungen“ will ich gar nicht anfangen. Hier ist bei mir Hobby, es gibt kein Produktentwicklungskodex und das muss nicht perfekt sein :) Also fassen wir mal zusammen: UART-Ethernet Umsetzer: Lantronix Xport USR-TCP232-T2 W7500 habe ich auch noch gesehen. Wobei eigentlich bei allen noch Level Shifter gebraucht werden. Vorteil: Fertige, stabile und getestete Lösungen. 100MBit Full Duplex kompatibel. Auch wenn die Daten nicht in der Geschwindigkeit weggeschafft werden müssen(können). Arduino Nano Platform mit fertigem ENC28J60 Modul: Muss quasi mit dem langen Arm selbst zusammen gebaut werden. Eher instabile Lösung. Vorteil: Kein Level Shifitng nötig und kann unter dem Arduino Nano platziert werden. Im übrigen und falls noch jemand eine Antwort zu meiner Eingangs gestellten Frage sucht – ich werde mal einen „Stresstest“ mit dem TCP Stack von Tuxgraphics machen den es hier gibt: http://www.tuxgraphics.org/common/src2/article09051/ Mal schauen ob ich den mit einem kleinen Script zum „Glühen“ bringen kann :) Neu war mir die W5100/W5500 Lösungen die ebenfalls unter den Arduino Nano oder Uno passen. Ich werde welche bestellen und mir das auch mal anschauen. Da ich nur mit der Hardware unterwegs bin und vom Arduino Framework gar nicht so viel halte – muss ich eben auch damit Leben mir selbst einen Treiber zu besorgen. Großer Vorteil hier: TCP Stack ist outgesourct und ebenfalls stabil/getestet usw. Soweit ich das gesehen habe bin ich hier auch mit 100MBit unterwegs. Erwähnt werden müsste auch noch der ESP8266 mit integriertem TCP Stack. Wobei ich hier die Hardware/Software komplett umbauen müsste. Vorteil: WIFI :) Auch charmant… In diesem Sinne wünsche ich einen schönen Sonntag.
Andy Y. schrieb: > Erwähnt werden müsste auch noch der ESP8266 mit integriertem TCP Stack. > Wobei ich hier die Hardware/Software komplett umbauen müsste. Wieso das? Wenn du die Hardware für einen UART-Ethernet Umsetzer nicht umbauen musst, dann auch nicht für ein ESP-01 Modul, denn das kommuniziert ebenfalls per UART mit dem AVR. Und die nötigen Levelshifter bestehen nur aus simplen Widerständen.
Bitte 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.