Hallo, ich habe eine Frage an Euch. Ich möchte eine Applikation mit einem ATMega8 o. 32 mit dem Ethernet verbinden. Es sollen mehrere Module mit einem Netzwerk verbunden werden und Schalt- und Steueraufgaben übernehmen. Jedes Modul soll eine eigene IP-Adresse bekommen. Der Datenaustausch soll über ein Visual Basic –Programm mit dem WinSock-Modul stattfinden. Wichtig: Ich möchte kein Web-Server bauen! Welches Ethernet-Modul benötige ich und wo kann ich es beziehen? Mit besten Dank im Voraus.
Achim Tüchter wrote: > Der Datenaustausch soll über ein Visual Basic –Programm mit dem > WinSock-Modul stattfinden. > Wichtig: Ich möchte kein Web-Server bauen! Ich will dir jetzt nicht zu nahe treten, aber glaubst du, dass du dem gewachsen bist? Ein "Web-Server" ist nur eine Erweiterung, bzw. eine Applikation. Du kannst jedes der drei ENC28J60 Boards aus der Codesammlung benutzen und eine eigene Applikation (anstatt des Webservers) daraufprogrammieren.
Gast
#769529
Schau dir mal den ENC28J60 an. Den bekommst du unter anderem bei CSD.
Gast
#769628
Und der Vorteil eines Ethernet setups im Vergleich zu einem Seriellen ? Dass man die IP entweder mit Dipswitches oder DHCP einstellt. Der hohe Durchsatz der SPI angebundenen Ethernet chips ?
6635 wrote:
> Und der Vorteil eines Ethernet setups im Vergleich zu einem Seriellen ?
Eventuell existiert im Einsatzbereich ja schon ein Ethernetnetz.
Gast
#769674
Das ist es ja gerade. Einen Switch dran und dann werden die Embedded Devices mit Microsoft IP Packeten zugemuellt. Zudem suggereiert ein Ethernet Setup, dass die Devices multi-client faehig waeren. Wird denn wenigesten die Ethernet Bandbreite benoetigt.
Gast
#769724
@6635: Wenn Du nichts konstruktives beizutragen hast, nöle doch nicht sinnlos 'rum. Nicht in jedem Fall ist Ethernet sinnvoll, aber in vielen doch. Zudem ist Ethernet als "Schnittstelle" mittlerweile fast weiter verbreitet als seriell. Die Möglichkeit von Multi-Client/Multi-Drop wurde ja schon angesprochen und im Ursprungsposting war ja bereits von mehreren Modulen die Rede, da muss man seriell auch schon Aufwand treiben. Broadcast-Pakete sind in manchen Umgebungen wirklich ein Problem, aber das muss der OP für seine Anwendung eben selbst klären. Die Ethernet-Bandbreite wird man mit dem SPI-angebundenen Chip wohl nicht ausnutzen können, aber das ist ja im Normalfall auch nicht unbedingt Sinn der Sache. Verglichen mit serieller Verbindung sollte es zumindest kein Nachteil sein. Gruß, Wolfgang
@6635: Man merkt, dass du überhaupt keine Ahnung hast. Wie willst du denn ein Gerät bauen, über das mann über das Internet darauf zugreifen kann? Das geht wohl schlecht über die serielle Schnittstelle? Und warum wird das Gerät von "Microsoft IP-Paketen" zugemüllt? Was soll das überhaupt sein?
Gast
#769770
> @6635: Man merkt, dass du überhaupt keine Ahnung hast. > Und warum wird das Gerät von "Microsoft IP-Paketen" zugemüllt? Was soll das überhaupt sein? lol
Gast
#769810
Sorry Leute, mir schien ein Mega8 etwas klein fuer einen IP Stack plus Applikation. Der Overhead fuer die diversen noetigen Funktionalitaeten ist nicht gering. ARP und DHCP sind beide auch noetig. Es ist aufschlussreich zu sehen was auf einem Microsoft Netzwerk alles so laeuft. Broadcasts und keep alive packete ohne ende. Und die muessen alle bearbeitet werden. Allenfalls waere ein Gateway zwischen einem Microsoft LAN und einem Industrie Ethernet einzubauen.
Gast
#769996
Lantronix Xport mit ATMega8 über serielle Schnittstelle verbinden, beides mit 3.3V gepowert = 3 Bauteile = fertig Das war doch wohl die Frage, oder?
Gast
#770000
PS: Bezugsquelle: Farnell
6635 wrote: > Sorry Leute, mir schien ein Mega8 etwas klein fuer einen IP Stack plus > Applikation. Der Overhead fuer die diversen noetigen Funktionalitaeten > ist nicht gering. ARP und DHCP sind beide auch noetig. Allerdings. Ein ATMega8 dürfte nicht groß genug sein. Aber mit einem Mega168 habe ich es schon hinbekommen (Beitrag "ENC28J60 (Mikro-)Web-Server die Nächste") > Es ist > aufschlussreich zu sehen was auf einem Microsoft Netzwerk alles so > laeuft. Broadcasts und keep alive packete ohne ende. Und die muessen > alle bearbeitet werden. Allenfalls waere ein Gateway zwischen einem > Microsoft LAN und einem Industrie Ethernet einzubauen. Also so viele Broadcast Packages werden in einem "Microsoft LAN" auch nicht gesendet. Das übliche halt. NetBios Namensauflösung oder auch ARP. Aber mein ENC28J60 arbeitet am Mega168 problemlos in einem ~10 Computer Netzwerk. Und die Bearbeitung eines Broadcast-Frames dauert weitaus kürzer als die eines normalen TCP-Frames (mit ACK/SEQ Nummer-Vrgleich usw) beispielsweise.
Simon K. wrote: > Also so viele Broadcast Packages werden in einem "Microsoft LAN" auch > nicht gesendet. Das übliche halt. NetBios Namensauflösung oder auch ARP. > Aber mein ENC28J60 arbeitet am Mega168 problemlos in einem ~10 Computer > Netzwerk. > > Und die Bearbeitung eines Broadcast-Frames dauert weitaus kürzer als die > eines normalen TCP-Frames (mit ACK/SEQ Nummer-Vrgleich usw) > beispielsweise. Hatte mal 56k Broadcasttraffic in nem mittleren Firmennetzwerk. Nur weil deine 10 Rechner noch bearbeitet werden können heißt das noch lange nichts fürs berufliche Umfeld.
Marcus W. wrote: > Simon K. wrote: >> Also so viele Broadcast Packages werden in einem "Microsoft LAN" auch >> nicht gesendet. Das übliche halt. NetBios Namensauflösung oder auch ARP. >> Aber mein ENC28J60 arbeitet am Mega168 problemlos in einem ~10 Computer >> Netzwerk. >> >> Und die Bearbeitung eines Broadcast-Frames dauert weitaus kürzer als die >> eines normalen TCP-Frames (mit ACK/SEQ Nummer-Vrgleich usw) >> beispielsweise. > > Hatte mal 56k Broadcasttraffic in nem mittleren Firmennetzwerk. > Nur weil deine 10 Rechner noch bearbeitet werden können heißt das noch > lange nichts fürs berufliche Umfeld. Das stimmt allerdings. Die Belastung durch Broadcasts steigt natürlich mit den Netzwerkteilnehmern im gleichen physischen Netz. Das ist natürlich bei embedded System eine starke Zusatzbelastung, wobei ich rein gefühlsmäßig sagen würde, dass der Zeitpunkt, wo der embedded Webserver (ENC28J60 mit einem 8-Bit AVR der oberen Klasse) gar nicht mehr reagiert (weil er wirklich von Broadcasts überschwemmt wird) soo schnell nun auch nicht erreicht werden wird. Zumindest solange es nicht massig viele, durch (Firmen-)software hervorgerufene UDP Broadcasts sind. Aber das Problem hätte man auch in einem 2-PC-Netzwerk und nennt sich Flooding Angriff ;) Trotzdem wird der kleine embedded Webserver nicht mit "Microsoft-IP-Paketen" "zugemüllt". Selbst wenn Daten übertragen werden müssen (also ganz normal Unicast) hat der AVR damit ja überhaupt nichts am Hut.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.