Was ist denn die beliebteste Ethernet-Hardware für kleine 8-Bit-Rechner? Also RJ45, nicht WLAN und ATtiny, nicht RPi. Vor ein paar Jahren gab es nur den XPort und der braucht mehr Strom als ein RPi Zero. Und heute? Gibt es nur noch WLAN?
ENC28J60 über SPI. Der sendet und empfangt Ethernet-Frames, alles da drüber (IP, TCP/UDP, DNS/HTTP/ect) musst du in Software nachbauen. Oder eine Lib nehmen, z.B. LwIP. Wird mit einem atTiny schwierig. W5100 über SPI Dieser kann bereits von selbst TCP/IP, du kannst eine begrenzte Anzahl an Sockets damit verwalten. Man muss nur die höheren Protokollschichten implementieren (DNS/HTTP, etc)
Einen winzigen 8-Bitter mit einem ENC28J60 o.ä. ausstatten ist ungefähr so wie mit einem VW Käfer einen LKW zu ziehen. Funktioniert irgendwie, aber... Effizienter und letztlich wahrscheinlich auch billiger und einfacher ist es einen Controller zu verwenden welcher einen Ethernet-Core eingebaut hat und auch genug Leistung für TCP/IP, wie z.B. einen der vielen STM32.
Warum nicht einen uC mit eingebautem Ethernet MAC nehmen ? Im ARM Bereich ist das nicht ungewöhnlich. Z.B. STM32F407/417 haben ein Ethernet MAC eingebaut. Man benötigt nur noch ein Ethernet PHY (z.B. mit DP83848) und entsprechende Software.
Angehängte Dateien:
-
DSC04935s.JPG
130 KB -
DSC04937s.JPG
130 KB
Bauform B. schrieb: > Was ist denn die beliebteste Ethernet-Hardware für kleine 8-Bit-Rechner? > Also RJ45, nicht WLAN und ATtiny, nicht RPi. Vor ein paar Jahren gab es > nur den XPort und der braucht mehr Strom als ein RPi Zero. Und heute? > Gibt es nur noch WLAN? Die kleinstmögliche Lösung ist ein PIC18F67J60. Da ist in einem TQFP64 Package Prozessor, RAM, Flash, Peripherie, Ethernet MAC und Ethernet PHY drin. Du brauchst noch einen 25 MHz Quarz, eine RJ45 Buchse mit Magnetics (Magjack), ein paar R, L, Cs, und 3.3V von irgendwoher. Das wars. Das teuerste daran war bei mir der Magjack. Wenn Du mehr Pins brauchst, gibts das ganze als PIC18F97J60 auch im größeren Gehäuse. IP-Stack usw gibt von Microchip in den MLA. fchk PS: dadurch, dass der Ethernet MAC direkt am Prozessor hängt, ist der Durchsatz am Ethernet doppelt so hoch wie bei der Kombination eines anderen PICs mit gleichem Kern und gleichem Takt und ENC28J60 per SPI.
:
Bearbeitet durch User
Frank K. schrieb: > Die kleinstmögliche Lösung ist ein PIC18F67J60. Da ist in einem TQFP64 > Package Prozessor, RAM, Flash, Peripherie, Ethernet MAC und Ethernet PHY > drin. Du brauchst noch einen 25 MHz Quarz, eine RJ45 Buchse mit > Magnetics (Magjack), ein paar R, L, Cs, und 3.3V von irgendwoher. Das > wars. Das teuerste daran war bei mir der Magjack. Postest du uns bitte die Leiterplattenfiles?
Angehängte Dateien:
-
xport-power.png
37 KB
ck schrieb: > W5100 über SPI > Dieser kann bereits von selbst TCP/IP, du kannst eine begrenzte Anzahl > an Sockets damit verwalten. > Man muss nur die höheren Protokollschichten implementieren "nur" ist gut, der XPort konnte dass alles alleine und hatte UART statt SPI, was ich auch nochmal einfacher finde. Die anderen Vorschläge sind natürlich gut und richtig, wenn es um Stückzahlen geht, trotzdem Danke. Ja, die Bastler-Einzelstück-Salamischeibe hat wieder gefehlt. Aber schon erstaunlich, was es alles nicht gibt. oerks schrieb: >> XPort und der braucht mehr Strom als ein RPi Zero > Das ist Unsinn. Es muss natürlich RPi Zero W heißen, ganz ohne Netzwerk kann ja jeder Strom sparen. Aber die offiziellen Zahlen sehen echt nicht gut aus, siehe Bild, und dann das:
1 | Typical bare-board active current consumption |
2 | Raspberry Pi Zero 100mA |
3 | Raspberry Pi Zero W/WH 150mA |
https://www.raspberrypi.org/documentation/hardware/raspberrypi/power/README.md
Bauform B. schrieb: > Ja, die > Bastler-Einzelstück-Salamischeibe hat wieder gefehlt. Aber schon > erstaunlich, was es alles nicht gibt. Auch als Bastler kann ein Controller mit eingebautem Ethernet einfacher sein. Man muss die richtigen Software-Pakete einbinden, ein paar Funktionen aufrufen und es funktioniert. Ob du jetzt die Library für die Ansteuerung vom XPort/W5100/ENC28J60 oder eine TCP/IP-Library einbindest macht dann auch keinen großen Unterschied mehr. Die ganzen Ethernet-Sachen durch eine SPI- oder UART-Schnittstelle zu quetschen hat was vom Kamel+Nadelöhr...
Bauform B. schrieb: > "nur" ist gut, der XPort konnte dass alles alleine und hatte UART statt > SPI, was ich auch nochmal einfacher finde. > Die anderen Vorschläge sind natürlich gut und richtig, wenn es um > Stückzahlen geht, trotzdem Danke. Ja, die > Bastler-Einzelstück-Salamischeibe hat wieder gefehlt. Aber schon > erstaunlich, was es alles nicht gibt. Meine PIC-Boards waren auch Einzelstücke, davon mal abgesehen. Und ich habe auch weder IP noch TCP noch HTTP selber implementieren müssen, das hat Microchip mir alles abgenommen. Und das Zeugs ist stabil. Ich habe auf dieser Basis eine Power Distribution Unit gebaut, die mir diverse 230V-Verbraucher schaltet, und dieses Teil ist seit 2012 im 24/7 Dauerbetrieb und funktioniert einfach. fchk
> Und ich > habe auch weder IP noch TCP noch HTTP selber implementieren müssen Gleiches fuer dien XPort. > ist seit 2012 im 24/7 Dauerbetrieb und funktioniert einfach. Ich lege da noch ein paar Jahre und den Plural drauf...
Hallo, Die Wiznet IC's sind für sowas schon ganz brauchbar. Nimm aber einen W5100"S", W5500 oder W6100. Die sind am SPI schon klar fixer als der W5100, optimiertes SPI Frame in der Datenphase für n*Bytes und damit effektiv weniger Overhead. Aufgrund der 16k+16k Fifo und dem etwas einfacheren FiFo Buffer Handling bevorzuge ich den W5500/W6100. Über deren LIB kann man, naja, geteilter Meinung sein, ich nutze sie schlussendlich nicht aber je nach Anforderung/Geschmack schon soweit funktionell und nüzlich. Also wenn die MCU (vor)gegeben/gesetzt ist dann eine probate Möglichkeit.
Ich könnte da noch den Silabs CP2201 in den Ring werfen. Unterschiede zum ENC26J60: - nimmt etwas weniger Strom auf - wird mit MAC Adresse geliefert (man ist nicht darauf angewiesen, eine zu kaufen oder zu klauen) - hat ein paralleles Interface zum µC (der ENC28J60 hat SPI) - hat nicht den berühmten Bug im Mac Filter, der unter Umständen die CPU Last in die Höhe treibt
Bauform B. schrieb: > "nur" ist gut, der XPort konnte dass alles alleine Die Wiznet-Dinger können auch viele höhere Protokolle bereits alleine. Man muss sie nur konfigurieren und aktivieren. > und hatte UART statt > SPI, was ich auch nochmal einfacher finde. Einfacher ist hier nicht das Thema. Hier geht's um Speed. Außerdem: was, zum Teufel, soll an UART eigentlich einfacher sein als SPI? > Es muss natürlich RPi Zero W heißen, ganz ohne Netzwerk kann ja jeder > Strom sparen. Falsche Betrachtungsweise. Richtig ist: mit physischem Ethernet kann niemand wirklich stromsparende Endpunkte herstellen. Der systemimmanente Bedarf des PHY bleibt immer über. Man braucht allerdings auch keine extremen Stromsparwunder an dieser Stelle. Schließlich wurde PoE vor geraumer Zeit erfunden. Das kann den unvermeidlichen PHY versorgen und locker auch das, was dahinter noch kommt. Irgendeinen verschissenen AVR8 jedenfalls ganz sicher problemlos, der fällt da kaum auf. Im übrigen hindert einen auch niemand daran, den Teil hinter dem unvermeidlichen PHY so stromsparend umzusetzen, wie möglich. Auch wenn es nicht wirklich nötig ist...
Der ENC28J60 gehört genau wie der w5100 in die Tonne. Der W5500 ist einfach deutlich schneller, mehr Buffer, schnelleres SPI. Klar, da braucht es auch schon nen ARM um den auszureizen, aber man muss dem armen AVR ja nicht noch Knüppel zwischen die Beine schmeißen..
Das gibt's ja hier auch nicht so oft, dass eine Frage so schnell und freundlich und eindeutig beantwortet wird, danke dafür. Leider hätte ich gerne etwas ganz anderes gelesen. Jedenfalls ist mir jetzt klar, warum so oft ein RPi eingesetzt wird; also für Aufgaben, die auch ein tiny erledigen könnte - bis auf diese Kleinigkeit. Ich recycle jetzt erstmal ein Alix1 Board.
No Y. schrieb: > Oder einen PIC32 ? oder einen ESP32, sogar 3,3V passt und man muss wlan nicht einschalten
Bauform B. schrieb: > Jedenfalls ist mir jetzt klar, warum so oft ein RPi eingesetzt wird Richtig. Ein RPi wirkt oft wie mit Kanonen auf Spatzen geschossen, erspart einem aber jede Menge Arbeit an Stellen, die es darin schon fix und fertig gibt - und das auch noch ständig aktualisiert.
Ethernet an sich ist noch kein Hexenwerk und für einen 8bit Controller problemlos machbar. Aber man will ja heutzutage Internet, Web-browser und kostenlose Tools nutzen. Deswegen führt um einen TCP/IP Stack kaum noch ein Weg vorbei, dicht gefolgt von Protokollen wie HTTP, MQTT, DNS, SMTP, und und und. Neuerdings wird man schon blöd angeguckt, wenn man meint, auf HTTPS verzichten zu können, was wiederum nur mit einem sicheren Austausch von Zertifikaten Sinn macht. Und so explodiert der Aufwand plötzlich. Ein Raspberry Pi kann das alles ab Werk. Ein ESP8266 oder ESP32 kann immerhin die Basics. Aber ein ATmega328 ... eeeeh. Wenn das alles so einfach wäre, hätten wir schon in den 80er Jahren unserer Heimcomputer (C64, Amiga, Atari) mit Netzwerkkarten ausgestattet. Bedarf war auf jeden Fall vorhanden.
Stefan ⛄ F. schrieb: > Ethernet an sich ist noch kein Hexenwerk und für einen 8bit Controller > problemlos machbar. Ich habe so einen AVR mit einem ENC seit langem im Internet hängen, mit dem uIP Stack von Dunkels und sehr einfachem Webserver. Heute wärs ein RPi - es lohnt einfach nicht, das Rad immer neu zu erfinden.
:
Bearbeitet durch User
Stefan ⛄ F. schrieb: > Wenn das alles so einfach wäre, hätten wir schon in den 80er Jahren > unserer Heimcomputer (C64, Amiga, Atari) mit Netzwerkkarten > ausgestattet. Bedarf war auf jeden Fall vorhanden. Haben wir doch. In meinen A2000 und A3000 steckten damals zuerst A2060 Arcnet, später A2065 Ethernet-Karten. Kein Problem. Ich habe damals problemlos Daten mit einer Vaxstation 2000 ausgetauscht. fchk
Stefan ⛄ F. schrieb: > Wenn das alles so einfach wäre, hätten wir schon in den 80er Jahren > unserer Heimcomputer (C64, Amiga, Atari) mit Netzwerkkarten > ausgestattet. Bedarf war auf jeden Fall vorhanden. Vor reichlich 10 Jahren machte man AVRs gerne auch mit Netzwerkkarten von Anno Dunnemal netzwerkfähig. Bevor der ENC da war. Das wäre mit sowas wie einem Atari auch möglich gewesen. Aber die dafür nötige Hausvernetzung fehlte üblicherweise, beschränkte sich auf Unis und Unternehmen, vom Internet ganz zu schweigen.
:
Bearbeitet durch User
Stefan ⛄ F. schrieb: > Wenn das alles so einfach wäre, hätten wir schon in den 80er Jahren > unserer Heimcomputer (C64, Amiga, Atari) mit Netzwerkkarten > ausgestattet. Beim Amiga und ST/TT war das auch kein technisches, sondern eher ein finanzielles Problem. Wenn ich mich recht erinnere, gingen die Preise für VME-Bus-Ethernet-Karten für den TT bei 1000 DM los. (prx) A. K. schrieb: > Das wäre mit sowas wie einem Atari auch möglich gewesen. Wurde auch gemacht, Stichwort TUW-TCP. Dafür wurde ein Netzwerkadapter für den (PC-)Parallelport an den ST-ROM-Port gehängt.
Bauform B. schrieb: > Ja, die > Bastler-Einzelstück-Salamischeibe hat wieder gefehlt. Aber schon > erstaunlich, was es alles nicht gibt. Es ist halt auch für Bastler nur von begrenztem Nutzen, mit einem ATtiny Ethernet-Kommunikation machen zu wollen. Klar kann man da einen Chip dranhängen, der 20 mal so leistungsfähig ist und 40 mal so viel RAM hat, damit der alles macht, was wirklich Aufwand ist, aber warum sollte man den dann von einem ATtiny aus steuern, statt diesen Teil dann auch noch direkt da drauf zu machen?
c-hater schrieb: > Bauform B. schrieb: >> und hatte UART statt >> SPI, was ich auch nochmal einfacher finde. > > Einfacher ist hier nicht das Thema. Hier geht's um Speed. Mal dem Verständnis halber... Um welchen wahnsinnigen Speed reden wir hier denn den der uC so braucht? Ich weiß ja nicht was ihr alle so mit euren uC treiben wollt, aber ich verschicke damit Sensorwerte/Statusinformationen oder nehme Schaltbefehle an (Steckdosen, etc.) Also ... ich weiß nicht.. "Speed" war mir da bisher nicht wichtig...
Schön klein: https://www.wiznet.io/product-item/wiz850io/ http://wizwiki.net/wiki/doku.php?id=products:wiz850io:start#pin_out https://www.ebay.de/itm/274363689111?chn=ps&mkevt=1&mkcid=28
:
Bearbeitet durch User
Also ich benutze fertige Module vom W5500, die auch noch einen Spannungswandler haben, am Mega328. Ähnlich dem hier gezeigten Beitrag "Problem WIZnet W5500 auf Tenstar" Die LIB benötigt etwa 10 kB des Programmspeichers. Da läuft ein kleiner Webserver im Dauereinsatz (geschütztes Netz). Die MAC sind kein Problem, die denke ich mir selbst aus. 100 Mbit benötigt ca. 140 mA und 10 Mbit ca. 100 mA. Läuft sehr stabil.
svensson schrieb: > Beitrag "Problem WIZnet W5500 auf Tenstar" svensson schrieb: > Läuft sehr stabil. Ja was jetzt? Ich denke du hast da soooo grosse Probleme? Zuerst mal das Forum rebellisch machen und dann nichts mehr von sich hören lassen, gelle? Einfach mal die "Probleme" für sich im Raum stehen lassen, die lösen sich dann von selbst auf. Wie ich das lieeeebe ....
Wenn es um einfach Sensoren und Ethernet verbindung geht, kommt neue 2-Draht Ethernet mit bis zu 10Mbit. Es gibt schon PHY+MAC Lösungen, wo uC selber kein MAC haben muss. Über SPI verbindet man z.B. ein Cortex uC und diese MAC+PHY. ADIN1110: https://www.analog.com/en/products/adin1110.html
ElektroFH schrieb: > Wenn es um einfach Sensoren und Ethernet verbindung geht, kommt neue > 2-Draht Ethernet mit bis zu 10Mbit. Dann brauchst Du aber auch das passende Gegenstück, das kann man nicht einfach an einen normalen Switch stecken. Das Ganze gibt es auch für 100MBit als IEEE 802.3bw. (z.B. TJA1100) > Es gibt schon PHY+MAC Lösungen, wo uC selber kein MAC haben muss. > Über SPI verbindet man z.B. ein Cortex uC und diese MAC+PHY. > > ADIN1110: > https://www.analog.com/en/products/adin1110.html Den Du als Bastler quasi nicht (oder zum Preis von einer Standard Ethernet-Schnittstelle) bekommst. Kein Wunder, die gehen alle zu den Autozulieferern. ( Das ist im Moment der Hauptmarkt für diese Zwei-Draht Systeme) Bei uns in der Industrie ist das auch im kommen (100 MBit Variante) aber im Moment ist die Lieferbarkeit ein großes Problem. ( Der Moment ist schon ein paar Jahre lange...) Aber vom der Effizienz ist das schon der richtige Weg, 100mW gegenüber 500mW sind schon eine Verbesserung.
Andreas M. schrieb: > Das Ganze gibt es auch für > 100MBit als IEEE 802.3bw. 100MBit ist für mich zu schnell, sowohl als Bastler als auch geschäfftlich. Wenn es um Sensoren oder Aktorik geht, wird 10MBit ausreichend für viele Sachen. Wie CANBUS, RS-485, SPI usw. Andreas M. schrieb: > Den Du als Bastler quasi nicht (oder zum Preis von einer Standard > Ethernet-Schnittstelle) bekommst. Doch, man bekommt die Teile. Digikey und Mouser sind dran. Sie sind gelistet auch 100er Preis is ca 4 USD/stk. (Das ist ein MAC+PHY, Reine $-vergleich zum PHY macht nicht voll Sinn). Mit ATTiny und ATmega den Rad wieder zu finden, lohnt sich gerade nicht für kleine Serie. Soviel Zeit und so viel Mühe einzunehmen.. Beim großen Stückzahlen wahrscheinlich soll/kann man besser versuchen..
Andreas M. schrieb: > Bei uns in der Industrie ist das auch im kommen (100 MBit Variante) ?ist das > Aber vom der Effizienz ist das schon der richtige Weg, 100mW gegenüber > 500mW sind schon eine Verbesserung. das Argument oder warum macht man das? Neue Kabel, neue Switches, neue Stecker... das tut man sich doch freiwillig nicht an? Ja, ich hab' mich über zu viel Strom beklagt, aber wenn ich neue Geräte nicht einfach ans vorhandene Netzwerk anstöpseln kann, kann ich auch gleich RS-232 nehmen (na gut, evt. -485).
ElektroFH schrieb: > Doch, man bekommt die Teile. Digikey und Mouser sind dran. Lagerbestand bei Mouser ist aktuell "0". Es gibt nichtmal einen Liefertermin. Bei Digikey ebenfalls "0". ElektroFH schrieb: > Doch, man bekommt die Teile. Digikey und Mouser sind dran. > Sie sind gelistet auch 100er Preis is ca 4 USD/stk. Ein Bastler wird sich auch kaum 99 Stück davon auf Lager legen, Das Einzelstück schlägt mit gut 10 Euro zu buche. Bauform B. schrieb: > das Argument oder warum macht man das? Neue Kabel, neue Switches, neue > Stecker... das tut man sich doch freiwillig nicht an? - Weniger Strom (ja das ist in modernen PKWs und auch der Industrie langsam ein Problem) - billigere Kabel. Es reichen zwei Adern. Fürn PKW gibt es eine Variante mit 1 Ader + Chassis. Dadurch kann man beim Verkabeln auch nicht mehr viel Falsch machen. - Bei 10Base-T1L kommt man bis zu 1km weit, für Industrieanlagen relevant - Weniger Bauteileaufwand generell - Es wird bald Microcontroller geben die den gesamten Kram dafür intern haben (MAC,PHY) und dabei trotzdem winzig sein werden, weil der Leistungsbedarf so gering ist. Dieses Zwei-Draht Ethernet (Advanced Physical Layer/APL) ist im Prinzip weiterentwickeltes GBit Ethernet. Bei 1000Base-TX werden die vier Adernpaare auch bidirektional zum Senden und Empfangen verwendet, bei APL gibts halt nur noch ein Adernpaar. Je nach Kabellänge kann man damit dann unterschiedliche Geschwindigkeiten erreichen.
Andreas M. schrieb: > - Weniger Strom > - billigere Kabel > - kann man beim Verkabeln auch nicht mehr viel Falsch machen > - bis zu 1km weit ok, überredet. Nur weil das für meine aktuelle, konkrete Anwendung nicht passt, muss es ja nicht ganz schlecht sein. Und immer dran denken: die Umstellung vom dicken gelben Kabel auf normales Koax und von Bus auf Stern mit Switch haben wir auch überstanden.
Eventuell noch zu dem Kabel, die 1km sind mit 8 Klemmstellen angenommen. ( z.B. Lüsterklemmen) Man kann dann also so ziemlich jedes halbwegs verdrilltes Zwillingskabel nehmen. Hier sind wir wieder bei den Industrieanlagen, man glaubt gar nicht wieviele Sensoren/Aktoren da noch über 4-20mA irgendwo zentral angeklemmt sind. Da kann man dann einfach die vorhanden Infrastruktur weiternutzen. Wird aber sicher noch ne ganze Weile dauern bis sich da was etabliert.
> Ja was jetzt? Ich denke du hast da soooo grosse Probleme?
Ja, ich hatte große Probleme. Jetzt führe ich nach jeder
Clientverbindung einen Softreset des Moduls durch (das habe ich auch
geschrieben). Ist halt QnD, aber funktioniert für meine Anwendung
wunderbar, kann man aber schlecht an die große Glocke hängen.
Mal schauen, ob sich das neue 2-Leiter-Ethernet durchsetzen wird. Kann mir aber nicht vorstellen, daß man da einfach ungeschirmten Klingeldraht verwenden kann. Da dürften die Kabel schöne Antennen abgeben, oder? Für mich wäre das erst dann richtig interessant, wenn es die ersten bezahlbaren Switche gäbe mit "richtigen Ethernet" und dem "single Pair", idealerweise mit selbsterkennenden und selbstkonfigurierenden Ports - und dann natürlich möglichst noch zum Preis derzeitiger Switche.
svensson schrieb: > Mal schauen, ob sich das neue 2-Leiter-Ethernet durchsetzen wird. Das braucht sich nicht mehr durchsetzen weil schon geschehen. Natürlich nicht zuhause, das ergibt keinen Sinn. Im Automotivebereich schon, denn da geht es um Biegeradien, Crimpungen, kein Schirm etc.. EMV-technisch brauchst Du dir auch keine Sorgen machen, das ist alles in entsprechenden Richtlinien geregelt. Und es ist nicht so, dass die automotiven Normen weich wären.
Frank K. schrieb: > Die kleinstmögliche Lösung ist ein PIC18F67J60. Da ist in einem TQFP64 > Package Prozessor, RAM, Flash, Peripherie, Ethernet MAC und Ethernet PHY > drin. Du brauchst noch einen 25 MHz Quarz, eine RJ45 Buchse mit > Magnetics (Magjack), ein paar R, L, Cs, und 3.3V von irgendwoher. Das > wars. Das teuerste daran war bei mir der Magjack. Würdest du bitte die Leiterplattenfiles posten?
Andreas schrieb: > Frank K. schrieb: >> Die kleinstmögliche Lösung ist ein PIC18F67J60. Da ist in einem TQFP64 >> Package Prozessor, RAM, Flash, Peripherie, Ethernet MAC und Ethernet PHY >> drin. Du brauchst noch einen 25 MHz Quarz, eine RJ45 Buchse mit >> Magnetics (Magjack), ein paar R, L, Cs, und 3.3V von irgendwoher. Das >> wars. Das teuerste daran war bei mir der Magjack. > > Würdest du bitte die Leiterplattenfiles posten? Da isses. Eagle 6.x/7.x fchk
Andreas M. schrieb: > Es wird bald Microcontroller geben die den gesamten Kram dafür intern > haben (MAC,PHY) und dabei trotzdem winzig sein werden, weil der > Leistungsbedarf so gering ist. Gerne kann ich überlegen. Ich finde aber keine solche uC. Wie heißt das Teil bitte? Andreas M. schrieb: > ElektroFH schrieb: >> Doch, man bekommt die Teile. Digikey und Mouser sind dran. >> Sie sind gelistet auch 100er Preis is ca 4 USD/stk. > > Ein Bastler wird sich auch kaum 99 Stück davon auf Lager legen, Das > Einzelstück schlägt mit gut 10 Euro zu buche. Deutlich unter 10EUR für Bastler auch. Mouser-Preise bitte schön. https://www.mouser.de/ProductDetail/Analog-Devices/ADIN1110BCPZ?qs=%2Fha2pyFaduiESMV9cZfzCSCSCSoyMti2tt5SzTfmof7BH76IaOc%2FFA%3D%3D Bei Digikey ab 10Stk sogar 6,6EUR https://www.digikey.de/product-detail/de/analog-devices-inc/ADIN1110BCPZ-R7/505-ADIN1110BCPZ-R7CT-ND/14290681
Hier noch zwei Links zum Thema https://www.mikrocontroller.net/articles/Einfacher_und_billiger_Webserver_mit_AtMega32 http://www.lochraster.org/etherrape/ Ergänzung: myEthernet 64k https://shop.myavr.de/index.php?sp=article.sp.php&artID=100065
:
Bearbeitet durch User
geht noch günstiger. AX88796CLF von ASIX kann SPI, 8 Bit und 16 Bit Port Mode. Bei Ebay gibt es ab und an mal Angebote, Ali oder hier: https://www.shotech.de/de/ax88796clf.html Kostet derzeit 1,85 EUR pro Stück.
sepp schrieb: > geht noch günstiger. AX88796CLF von ASIX kann SPI, 8 Bit und 16 Bit Port > Mode. Der sieht tatsächlich gar nicht mal so schlecht aus, zumal der Phy da gleich mit drinnen ist. Kann man nur hoffen das der halbwegs funktioniert, wir haben von ASIX ne PCIe-SPI Bridge und die hat massive Probleme mit DMA und bestimmten PCIe Transfers. Wobei die PCI/PCIe - Parallel Bridges von denen ganz brauchbar sind. ElektroFH schrieb: > Deutlich unter 10EUR für Bastler auch. > Mouser-Preise bitte schön. > > https://www.mouser.de/ProductDetail/Analog-Devices/ADIN1110BCPZ?qs=%2Fha2pyFaduiESMV9cZfzCSCSCSoyMti2tt5SzTfmof7BH76IaOc%2FFA%3D%3D Da kommt noch Mehrwersteuer drauf -> 9Euro/Stück.
H. schrieb: > Das braucht sich nicht mehr durchsetzen weil schon geschehen. Natürlich > nicht zuhause, das ergibt keinen Sinn. Im Automotivebereich schon, denn > da geht es um Biegeradien, Crimpungen, kein Schirm etc.. > EMV-technisch brauchst Du dir auch keine Sorgen machen, das ist alles in > entsprechenden Richtlinien geregelt. Und es ist nicht so, dass die > automotiven Normen weich wären. Erstaunlich, denn beim Ethernet wird ja immer ein Bohei um die Schirmung gemacht und die Länge der nicht verdrillten Strecke und, und, und. Neuerdings sogar um den Querschnitt der Kabel (für PoE mit bis zu 90W). In meinem Bereich haben wir nahezu überall stinknormales Ethernet, da wäre das Single Pair nur eine nette Ergänzung, wenn man mal erweitern muß. OT: Erschreckend, wenn ein Kfz jetzt auch schon mit Netzwerk vollgestopft wird. Mein Alptraum ist immer eine Fehlermeldung dieser Art "Wegen eines unbekannten Fehlers in Windows steht das ABS nicht mehr zur Verfügung. Bitte Neustart!" mitten auf der Autobahn.
svensson schrieb: > Erschreckend, wenn ein Kfz jetzt auch schon mit Netzwerk > vollgestopft wird. Mein Alptraum ist immer eine Fehlermeldung dieser Art > "Wegen eines unbekannten Fehlers in Windows steht das ABS nicht mehr zur > Verfügung. Bitte Neustart!" mitten auf der Autobahn. Das hatten wir alles schon und nicht nur auf der Autobahn: https://www.wired.com/1998/07/sunk-by-windows-nt/ Auf der Autobahn passieren allerdings deutlich üblere Dinge, sogar ohne Windows: https://www.edn.com/toyotas-killer-firmware-bad-design-and-its-consequences/
svensson schrieb: > Erstaunlich, denn beim Ethernet wird ja immer ein Bohei um die Schirmung > gemacht und die Länge der nicht verdrillten Strecke und, und, und. Wird es? Es gibt UTP-Kabel zu kaufen. Das ist ungeschirmt und stellt laut Wikipedia den weit überwiegenden Teil aller verwendeten Ethernet-Kabel dar. Da geht auch Gigabit-Ethernet drüber. https://de.wikipedia.org/wiki/Twisted-Pair-Kabel#UTP Und die Leitungen im Fahrzeug sind durchaus auch verdrillt. > OT: Erschreckend, wenn ein Kfz jetzt auch schon mit Netzwerk > vollgestopft wird. Steuergeräte sind seit langem vernetzt. Ob man als Medium dafür nun CAN, Flexray oder Ethernet nutzt, macht da nur im Bezug auf die Bandbreite einen Unterschied. Und Ethernet-Komponenten sind auf Grund der großen Verbreitung billig. > Mein Alptraum ist immer eine Fehlermeldung dieser Art "Wegen eines > unbekannten Fehlers in Windows steht das ABS nicht mehr zur Verfügung. > Bitte Neustart!" mitten auf der Autobahn. Dass Ethernet verwendet wird, heißt nicht, dass deshalb die Steuergeräte alle unter Windows laufen.
Rolf M. schrieb: >> Mein Alptraum ist immer eine Fehlermeldung dieser Art "Wegen eines >> unbekannten Fehlers in Windows steht das ABS nicht mehr zur Verfügung. >> Bitte Neustart!" mitten auf der Autobahn. > > Dass Ethernet verwendet wird, heißt nicht, dass deshalb die Steuergeräte > alle unter Windows laufen. Ethernet ist ein meistens Best-Effort Ding. Bis auf Profinet, Ethernet IP usw. Deswegen gibt es diese Industrielle-Ethernet (a.k.a Realtime Ethernet). Sorry, immer billiger wird sich irgendwann ausrachen. Besonders für Auto-Hersteller immer billiger ist der Fall. Egal es geht um Technik, Produktion oder Logistik. Für die letzte Zwei erleben wir gerade so eine Zeit. Wo fast keine Teile verfügbar im Markt sind. Und die Preise höher gegangen sind...
Rolf M. schrieb: > Wird es? Es gibt UTP-Kabel zu kaufen. Das, was hierzulande als UTP Kabel gehandelt wird, ist oft einfach geschirmt, z.B. als F/UTP, statt doppelt als z.B. S/FTP. U/UTP wird m.W. für Ethernet nicht allzu oft neu eingesetzt. > Das ist ungeschirmt und stellt > laut Wikipedia den weit überwiegenden Teil aller verwendeten > Ethernet-Kabel dar. Weltweit wohlgemerkt. In D nicht ganz so häufig.
:
Bearbeitet durch User
ElektroFH schrieb: > Rolf M. schrieb: >>> Mein Alptraum ist immer eine Fehlermeldung dieser Art "Wegen eines >>> unbekannten Fehlers in Windows steht das ABS nicht mehr zur Verfügung. >>> Bitte Neustart!" mitten auf der Autobahn. >> >> Dass Ethernet verwendet wird, heißt nicht, dass deshalb die Steuergeräte >> alle unter Windows laufen. > > Ethernet ist ein meistens Best-Effort Ding. Was meinst du, wie das bei CAN ist? Nur hängen bei dem die Steuergeräte am Bus alle parallel, während es bei Ethernet einen Switch und Full-Duplex-Betrieb gibt, so dass es nicht zu Kollisionen kommen kann. > Sorry, immer billiger wird sich irgendwann ausrachen. Welchen Vorteil siehst du darin, was neues zu entwickeln, das das gleiche macht, statt was bestehendes zu nutzen?
ElektroFH schrieb: > Ethernet ist ein meistens Best-Effort Ding. Bis auf Profinet, Ethernet > IP usw. Deswegen gibt es diese Industrielle-Ethernet (a.k.a Realtime > Ethernet). Ja das mit den Industriellen Netzwerken stimmt. Im Automotive wird das neu definierte TSN (Time-Sensitive-Networking) genutzt werden um jedem Gerät eine definierte Bandbreite und/oder Zeitslot zu geben. (Etwas bekannter dürfte dafür der Begriff AVB Audio/Video Bridging sein) Im Prinzip eine Art von Profinet IRT. Im Auto ist das noch recht einfach umzusetzen, man hat dort ein geschlossenes System mit vorher bekannten Teilnehmern. D.h. es wird einmalig eine Zeitslot/Bandbreitenplanung gemacht und fest konfiguriert. Auch die Industrie scheint sich in Richtung TSN bewegen zu wollen aber hier wird es komplizierter weil eher mal eine neuer Netzteilnehmer dazukommt oder einer wegfällt. Da muss dann dynamisch neu konfiguriert werden. Da zerbrechen sich gerade noch viele Leute die Köpfe drüber.
Gab es doch schon alles als Token Ring. War sogar tolerant gegenüber einem Kabelschaden, allerdings bei höherem Verkabelungsaufwand. Rolf M. schrieb: > Was meinst du, wie das bei CAN ist? Nur hängen bei dem die Steuergeräte > am Bus alle parallel, während es bei Ethernet einen Switch und > Full-Duplex-Betrieb gibt, so dass es nicht zu Kollisionen kommen kann. Nein, ich habe auch kein Unbehagen gegenüber der Ethernettechnik, sondern eher gegenüber der immer mehr zunehmenden Komplexität, die dann auch eine immer mehr Fehlfunktionen hat.
Stefan ⛄ F. schrieb: > - wird mit MAC Adresse geliefert (man ist nicht darauf angewiesen, eine > zu kaufen oder zu klauen) Man kann auch einfach eine local adminstrated addresse nehmen, dann muss man keine klauen. So lange die MAC in der Broadcastdomain eindeutig ist kann eh nichts schief gehen (ausser der DHCP Server hat es nicht gerne wenn die gleiche MAC in mehreren IP Netzen erscheint, aber solche DHCP Server sollte man dringend ersetzen).
Peter S. schrieb: > Stefan ⛄ F. schrieb: >> - wird mit MAC Adresse geliefert (man ist nicht darauf angewiesen, eine >> zu kaufen oder zu klauen) > > Man kann auch einfach eine local adminstrated addresse nehmen, dann muss > man keine klauen. Man muss sich dann aber eben auch darum kümmern, sie "local" zu "administraten", sofern man mehrere davon in einem Netz betreiben will. > So lange die MAC in der Broadcastdomain eindeutig ist > kann eh nichts schief gehen (ausser der DHCP Server hat es nicht gerne > wenn die gleiche MAC in mehreren IP Netzen erscheint, aber solche DHCP > Server sollte man dringend ersetzen). Warum? Eigentlich darf es nicht vorkommen, dass ein Rechner die selbe MAC mehrfach zu sehen bekommt.
Rolf M. schrieb: > Man muss sich dann aber eben auch darum kümmern, sie "local" zu > "administraten", sofern man mehrere davon in einem Netz betreiben will. Nunja, das ist sicher richtig. Stellt ungefähr so eine Herausforderung dar, wie feste IP-Adressen in einem Netz zu vergeben... Sprich: sollte für jeden normal gebildeten Menschen durchaus beherrschbar sein. Wenn er das Prinzip verstanden hat. > Warum? Eigentlich darf es nicht vorkommen, dass ein Rechner die selbe > MAC mehrfach zu sehen bekommt. Doch, natürlich kommt das vor. ff:ff:ff:ff:ff:ff z.b. kann er von jedem beliebigen Netzteilnehmer umd Ohren gehauen bekommen. Und es gibt noch andere MAC-Adressen, die zwar nicht jeder beliebige Netzteilnehmer verwenden darf, aber doch immerhin mehr als einer. Sprich: ein ordentlicher Ether-Layer muss mit sowas umgehen können. Ende der Ansage.
c-hater schrieb: >> Warum? Eigentlich darf es nicht vorkommen, dass ein Rechner die selbe >> MAC mehrfach zu sehen bekommt. > > Doch, natürlich kommt das vor. ff:ff:ff:ff:ff:ff z.b. kann er von jedem > beliebigen Netzteilnehmer umd Ohren gehauen bekommen. Als Absender? Soweit ich weiß, wird die Broadcast-Adresse nur als Ziel verwendet, und sie wird mit Sicherheit von keinem Teilnehmer als dessen feste Adresse verwendet. Warum ein DHCP-Server der eine IP zuordnen können müsste, erschließt sich mir nicht. > Und es gibt noch andere MAC-Adressen, die zwar nicht jeder beliebige > Netzteilnehmer verwenden darf, aber doch immerhin mehr als einer. Ja, es mag auch noch weitere Spezialadressen geben, wie z.B. Multicast. Aber auch denen muss der DHCP-Server keine IP-Adresse zuweisen.
Rolf M. schrieb: > Aber auch denen muss der DHCP-Server keine IP-Adresse zuweisen. Es gibt noch andere Netzwerkanwendungen als nur DHCP-Server, meinst du nicht?
c-hater schrieb: > Rolf M. schrieb: > >> Aber auch denen muss der DHCP-Server keine IP-Adresse zuweisen. > > Es gibt noch andere Netzwerkanwendungen als nur DHCP-Server, meinst du > nicht? Ja, soll es geben. Nur ging es um die halt im Gegensatz zu DHCP-Servern nicht. Hier noch mal die ursprüngliche Aussage, auf die sich das bezieht: Peter S. schrieb: > So lange die MAC in der Broadcastdomain eindeutig ist kann eh nichts > schief gehen (ausser der DHCP Server hat es nicht gerne wenn die gleiche > MAC in mehreren IP Netzen erscheint, aber solche DHCP Server sollte man > dringend ersetzen).
Die Source MAC muss nur innerhalb einer Broadcast Domain eindeutig sein. Es ist durchaus zulässig, wenn ein Gerät die selbe MAC Adresse als Source auf verschieden Interfaces in verschiedenen Broadcast Domains verwendet. Im Grunde ist das der Normalfall wenn man mit VLAN arbeitet. Ein DHCP Server der damit nicht auskommt der hat auch mit DHCP Requests vom gleichen Gerät mit mehreren VLAN (sub-interfaces oder wie das auch immer auf dem Gerät heisst) Probleme. Grundsätzlich muss jedes Gerät damit klarkommen, dass die gleiche Source Mac auf mehreren Schnittstellen erscheint. Die ARP Tabelle muss für jedes Netzwerkinterface (Layer3) getrennt verwaltet werden. Den DHCP Server habe ich nur erwähnt, weil die merken sich die MAC Adressen der ganzen Verwaltungsdomänen und es gab solche die die MAC Adresse als Unique Key in der Datenbank hatten. Er muss das natürlich immer mit dem Subnetz verknüpfen.
:
Bearbeitet durch User
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.