Hallo, könnte man theoretisch 2 Enc28J60 mit entsprechenden Übertragern direkt miteinander (~>50 Meter, Cat.5) "vernetzen", um somit eine "SPI-Over-Ethernet" Verbindung zwischen zwei µC herzustellen, ohne dabei einen TCP/UDP-Stack mit zu implementieren? Also worauf ich hinaus wollte ist, ob man somit evtl. eine höhere Datenrate zwischen den Controllern hinbekommt, wenn man sie "abgespeckt" und außerhalb der Specs nutzt (ist aber eher nebensächlich) und ob man so etwas wie ein PTP-Protokoll verwenden kann/darf, dass sogar evtl ohne Adressierungen läuft, und ob das überhaupt Sinn macht so ganz ohne TCP/IP. Also so, dass z.B. die Header kleiner werden, und man mehr oder weniger RAW-Bytes zwischen 2 ENC28J60 hin und her schaufelt, wobei (vom "abgeänderten" Protokoll bzw. Stack) einer den Master und der andere den Slave spielt. Es geht dabei um eine Direktverbindung zwischen 2 µC über eine etwas weitere Distanz. Es muss nicht mit anderen Netzen oder Teilnehmern verbunden werden können, und es wird auch kein Switch zwischen drin sein. Die nächste Frage wäre, ob sich das in eine vorhandene Infrastruktur (mit Switches) einbinden lässt. Geht das? Oder ist das absoluter Schwachsinn? Gruß, TS
:
Bearbeitet durch User
Timmey S. schrieb: > könnte man theoretisch 2 Enc28J60 mit entsprechenden Übertragern direkt > miteinander (~>50 Meter, Cat.5) "vernetzen", um somit eine > "SPI-Over-Ethernet" Verbindung zwischen zwei µC herzustellen, ohne dabei > einen TCP/UDP-Stack mit zu implementieren? Ja, Du kannst problemlos rohe Datenpakete vollduplex hin- und herschicken, ohne IP zu bemühen. Die bis zu 1500 Nutzdatenbytes hinter em Ethernet-Header sind Deine. > Also worauf ich hinaus wollte ist, ob man somit evtl. eine höhere > Datenrate zwischen den Controllern hinbekommt, wenn man sie "abgespeckt" > und außerhalb der Specs nutzt (ist aber eher nebensächlich) und ob man > so etwas wie ein PTP-Protokoll verwenden kann/darf, dass sogar evtl ohne > Adressierungen läuft, und ob das überhaupt Sinn macht so ganz ohne > TCP/IP. Das Ethernet-Protokoll ist fix, da kannst Du nichts dran machen. Den höchsten Datendurchsatz bekommst Du mit maximal großen Paketen (14 Byte Ethernet Header+1500 Nutzbytes). > Also so, dass z.B. die Header kleiner werden, und man mehr oder weniger > RAW-Bytes zwischen 2 ENC28J60 hin und her schaufelt, wobei (vom > "abgeänderten" Protokoll bzw. Stack) einer den Master und der andere den > Slave spielt. Bei Ethernet sind alle Knoten gleichberechtigt. > Es geht dabei um eine Direktverbindung zwischen 2 µC über eine etwas > weitere Distanz. Es muss nicht mit anderen Netzen oder Teilnehmern > verbunden werden können, und es wird auch kein Switch zwischen drin > sein. Das spielt keine Rolle. Der ENC28J60 ist halt nicht besonders schnell. Mit einem PIC32MX795F512 oder einem äquvalenten ARM könntest Du 100 MBit/s fahren und würdest dabei auch Transferraten von 8MByte/s erreicht. Mit einem popeligen AVR geht das natürlich nicht. Der wird nicht einmal ein 10 MBit/s-LAN sättigen können. Da ist nicht di Verbindung selber der Flaschenhals, sondern die Kombination aus AVR und ENC. > Die nächste Frage wäre, ob sich das in eine vorhandene > Infrastruktur (mit Switches) einbinden lässt. Problemlos. Es bleibt ja immer noch Ethernet. Ihr müsst natürlich gültige MAC-Adressen verwenden, die in Eurem LAN eineindeutig sind, und Ihr solltet einen eigenen Ethernet Type Code im Header eintragen, damit alle Teilnehmer wissen, dass das kein IP, sondern ein proprietäres Spezialprotokoll ist. Bei der Direkt-Verbindung zwischen zwei Computern müsst Ihr gekreuzte Kabel verwenden und 10 MBit (oder 100, wenn Eure Hardware das kann) vollduplex fest einstellen, beim Anschluss an einen Switch müsst Ihr 1:1 Kabel verwenden und die Linkparameter automatisch aushandeln lassen. fchk
Danke für deine sehr ausführliche und aufschlussreiche Antwort!!! Genau das was ich hören wollte ;-) ^^ Mir fällt gerade auf, dass das ganze ja sogar komplett potentialfrei (und differential ??) ist. Besser geht es ja gar nicht. Frank K. schrieb: > Den höchsten Datendurchsatz bekommst Du mit maximal großen Paketen (14 > Byte Ethernet Header+1500 Nutzbytes). Hatte ich schon öfters gehört / gelesen. Liegt das daran, dass ich mir dann die 14 Bytes Header (evtl. mehrfach) sparen kann, wenn ich den "Nutzbytes"-Anteil verhältnismäßig groß mache bzw. ausnutze? Meintest du das spezifisch zum ENC oder beim Ethernet allgemein? Gruß, TS
Timmey S. schrieb: > Frank K. schrieb: >> Den höchsten Datendurchsatz bekommst Du mit maximal großen Paketen (14 >> Byte Ethernet Header+1500 Nutzbytes). > Hatte ich schon öfters gehört / gelesen. Liegt das daran, dass ich mir > dann die 14 Bytes Header (evtl. mehrfach) sparen kann, wenn ich den > "Nutzbytes"-Anteil verhältnismäßig groß mache bzw. ausnutze? Meintest du > das spezifisch zum ENC oder beim Ethernet allgemein? Das liegt an Ethernet selbst, weil die Maximalgröße des Payloads (von Sonderlösungen, wie Jumbo-Frames, die aber nicht überall funktionieren, abgesehen) per Ethernetframe 1500 beträgt. Es ist daher genau so, wie Du angenummen hast, je größer die Framesize wird, desto geringer wird der prozentuale Anteil an Header-Daten, die für eine gegebene Datenmenge verschickt werden müssen. LG, NOR
Timmey S. schrieb: > Danke für deine sehr ausführliche und aufschlussreiche Antwort!!! > Genau das was ich hören wollte ;-) ^^ > > Mir fällt gerade auf, dass das ganze ja sogar komplett potentialfrei > (und differential ??) ist. Besser geht es ja gar nicht. > > Frank K. schrieb: >> Den höchsten Datendurchsatz bekommst Du mit maximal großen Paketen (14 >> Byte Ethernet Header+1500 Nutzbytes). > > Hatte ich schon öfters gehört / gelesen. Liegt das daran, dass ich mir > dann die 14 Bytes Header (evtl. mehrfach) sparen kann, wenn ich den > "Nutzbytes"-Anteil verhältnismäßig groß mache bzw. ausnutze? Meintest du > das spezifisch zum ENC oder beim Ethernet allgemein? Den Header kannst Du Dir niemals sparen, der muss immer da sein. Plus: Du hast eine Mindestgröße von 60 Bytes, d.h. Selbst wenn Du nur ein Byte verschicken willst, musst Du 14 Byte Header plus Dein Byte plus 45 Füllbytes senden. Dazu kommt eine Präambel vor dem Paket und eine Crc dahinter und eine definierte Mindestpause. Das macht aber meist die Hardware. Aber wie gesagt: bei AVR+ENC wirds eh langsam. fchk
Super, danke für die vielen Informationen, und die Aufklärung diverser Fragen. GN8, TS.
Genaugenommen kann man am Ethernet-Header auch noch sparen. Den Ethernet
Type kann man weglassen, wenn alle Netzteilnehmer "einverstanden" sind
und kein oberschlauer Switch beteiligt ist. Und die Ethernet-Adressen
von Empfänger und Absender kann man weglassen, wenn es sich um eine
Punkt-zu-Punkt-Verbindung handelt (zwei Ethernet-Chips mit gekreuztem
Kabel dazwischen) und beide Seiten ihren Ethernet-Chip entsprechend
einstellen ("promiscuous mode"). Aber das ändert natürlich nichts daran,
daß es immer noch pro Paket einen gewissen Overhead gibt (Präambel, CRC,
inter-packet-gap), so daß große Pakete mehr Durchsatz bringen. Und auf
das eine Prozent (14 Bytes von 1500) kommt es auch nicht mehr an, wenn
z.B. ein AVR dahintersteckt, der die 10Mbit sowieso nicht auslasten
kann.
"SPI-over-Ethernet" wird daraus übrigens sowieso nicht; dazu müßte man
sich erstmal überlegen, welche Eigenschaften von SPI entfallen dürfen
und wie man den Rest auf Ethernet abbildet.
Nosnibor schrieb: > das eine Prozent (14 Bytes von 1500) kommt es auch nicht mehr an, wenn Du meinst "(14 Bytes von 1514)". Der Ethernet-Header zählt nicht zum Nutzdatenbereich von 1500 Bytes. fchk
Zwei Infos, einfach mal in den Raum geworfen: - Der ENC kann das 60 Byte Padding selbständig einfügen, du schreibst also einfach nur deine Daten (und wenn es nur ein Byte ist) in den Puffer und sendest. - Der ENC unterstützt Pakete >1500 Byte.
Frank K. schrieb: > Du meinst "(14 Bytes von 1514)". Der Ethernet-Header zählt nicht zum > Nutzdatenbereich von 1500 Bytes. Da hast du natürlich Recht. Andererseits hatte ich ja schon gesagt, daß es darauf nicht ankommt. :) Ist sowieso nur Theorie. Den Ethernet-Header für Nutzdaten zu verwenden, bringt mehr Ärger als es wert ist. Man kann dann z.B. nicht mehr so einfach mit Wireshark nachsehen, was los ist, weil der allerlei Blödsinn anzeigt, wenn er die "Adressen" auswertet. Man müßte erstmal einen echten Hub aus dem Schrott klauben, um Wireshark überhaupt anschließen zu können!
> Man müßte erstmal einen echten Hub aus dem Schrott klauben, > um Wireshark überhaupt anschließen zu können! Alternativ ein Switch mit Monitoring-Port.
Svenska schrieb: > Alternativ ein Switch mit Monitoring-Port. Damit zäumt man aber auch das Pferd am falschen Ende auf. Der ENC spielt doch eh schon größenteils Autopilot, da kann man sich zumindest noch die Zeit nehmen, ordentliche Ethernet-Frames zu bauen. Das wie und was ist auch nochmal hervorragend im Datenblatt beschrieben, dort wird man von Anfang bis Ende an die Hand genommen.
Svenska schrieb: >> Man müßte erstmal einen echten Hub aus dem Schrott klauben, >> um Wireshark überhaupt anschließen zu können! > > Alternativ ein Switch mit Monitoring-Port. Ist kein zuverlässiger Ersatz, wenn jemand wirklich den Ethernet-Header für andere Daten mißbraucht. Einerseits wird der Switch die "Adressen" interpretieren und möglicherweise deshalb nicht alle Pakete weiterleiten, andererseits gibt es auch Protolle (zur Flußkontrolle z.B.), die ausdrücklich nur von einem Switch zum nächsten stattfinden, also auch nicht durchgereicht werden.
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.