www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik RTL8019AS und Frameformat


Autor: Stefanie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
im Datenblatt des Realtek NIC steht, dass er Ethernet II und IEEE802.3 
10Base5, 10Base2 und 10BaseT kann.
Wenn ich nun mein Webboard mit diesem Controller ganz normal zuhause 
über RJ45 anstecke, welches Frameformat nutze ich dann?
Bezeichne ich das dann als Ethernet-Protokoll?
Sehe ich es richtig, dass ich dem RTL dann vorher initialisiere und ihm 
meine MAC-Adresse mitteile und anschließend ihm IP-Packete übergebe bzw. 
von ihm IP-Packete erhalte?

DANKE, Stefanie

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ob Ethernet II (üblich) oder IEEE802.3 (selten) ist dem Realtek völlig 
schnuppe. Das ist nicht sein Job, darum kümmert sich die Software.

10base5 (via 15pol AUI-Stecker) und 10base2 (BNC) sind 
Anschlusstechniken, die man nur noch im Museum findet.

Der Realtek interessiert sich nur für MAC-Frames. Ob darin TCP/IP oder 
IPX steckt, ist ihm egal. Aus IP-Paketen MAC-Frames zu machen ist Sache 
der Software.

Autor: Wegstaben Verbuchsler (wegstabenverbuchsler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Stefanie

es gibt eine recht "plakative" Struktur, welche die verschiedenen 
technischen und Bedeutungsebenen beschreibt: Das OSI 7-Schichten-Modell

jeder dieser Schichten ist soweit wie möglich von der vorherigenSchicht 
unabhängig, und gegebenenfalls in verschiedenen Varianten Verfügbar.

Wenn man nun die Schichten von oben nach unten durchläuft, dann hast du 
z.b:

Ebene_7: Applikation

Ebene_6: Presentation

Ebene_5: Session (Sitzung)
Aus der Anwendung heraus werden Datenströme (beliebiger Art) "Auf die 
Reise" in darunter liegende Transportschichten vübergeben. Auf 
Session-Ebene ist es "egal" (d.h. muß variabel und identisch sein) wie 
Datenpakete ihr Ziel erreichen. Die weiter unten liegeneden 
Transportmechanismen wissen auch nicht, was sie da transportieren (soll 
denen ja auch egal sein)

Ebene_4: Transport
Auf der Transportebene finden die "Verkehrsregeln" statt, wie ein 
Datenpaket von einem Punkt zu einem anderen Punkt zu gehen hat. Die 
Verkehrsregeln sind eng gekoppelt mit dem eigentlichen Netzwerkprotokoll 
der ebene_3, daher werden beide gerne in einem Stück benannt.
Gängige Transportprotokolle bei "TCP/IP" basierenden Netzen sind TCP 
oder UDP. Die alten Novell-Netzwerke kannten dazu alternativ im 
Protokollpaket "IPX/SPX" das Transportprotokoll IPX. Sogenannte Router 
steuern die Verkehrsflüsse nach definierten Regeln. [analoges Bild im 
Transportwesen:  "rechts vor links" hat inm Straßenverkehr in 
Deutschland = Transportprotokoll TCP eine andere Bedeutung wie links vor 
rechts im Straßenverkehr in UK. Beide genutzten Netzwerkarten (Straße) 
sind jedoch sehr ähnlich]

Ebene_3: Network
In der Netzwerkebene werden die logischen "Endknoten" der 
Kommunikationsverbindung behandelt, die mit Hilfe der Verkehrsregeln der 
ebene_4 sinnvoll durch das Netzwerk geleitet werden.
Gängige Netzwerkprotokolle bei "TCP/IP" basierenden Netzen sind IP 
(genauer: IPV4) oder demnächst IPV6. Die alten Novell-Netzwerke kannten 
dazu alternativ im Protokollpaket "IPX/SPX" das Transportprotokoll SPX
Eine definierte "IP-Adresse" ist. z.B. 172.30.1.1 (sind 4 dezimal 
geschriebene Bytes), bei SPX sah eine Netzwerkadresse typisch aus wie 
eine Hexadezimal-Adresse, z.B. 1F2B3CAA. [analoges Bild: Telefonnummern 
geben auch Endknoten-Adressen an, um z.B. eine Kommunikationsverbindung 
von 089-549876 nach 0221-658731 zu "schalten". Was über diese 
geschaltete Verbindung transportiert wird (Telefonie, Fax, Bilder) ist 
auf dieser Ebene irrelevant]

Ebene_2: DataLink
Her kommen die angefragten Frames zum Zuge. Von der nächst höheren 
Ebene_3 empfangene Datenpakete (Egal ob es IPV4, IPV6 oder SPX Pakete 
sind) werden "übersetzt" in die Medium-Adresse (MAC). Tpische 
MAC-Adressen werden in Hexadezimaler Form geschrieben, gerne so: 
3B:4C:00:01:8A:59

Ebene_1: Physikalischer Transport
Hier wird beschrieben, welche Strippen (bei Ethernet z.B: Dickes 
Koaxialkabel=10Base5; dünnes Koaxialkabel=10Base2 gemäß Strippenstandard 
RG58; Twisted Pair Kabel gemäß StrippenStandard KAT5 oder optische 
Lichtleiter) und zugehörige Stecker zu verwenden sind. Auf dieser 
Betrachtungsebene sind verwendete hüllende Frameformate vollkommen 
unbekannt, d.h. jedes beliebige Frameformat kann sowohl durch eindickes 
wie durch ein dünnes Koaxialkabel geschickt werden. Um es elektronisch 
zu sagen: Auf dieser Ebene spielen hapuptsächlich Optkoppler und 
Treibertransistoren eine Rolle. [Analoges Bild im Transportwesen: 
Container könenn per Schiff, LKW oder Zug transportiert werden]


Fazit: Damit dein Webboard einigermaßen verständlich mit einer anderen 
Ethernet Komponenten sprechen kann, muß es zumindest einen 
"IP-Protokollstack" kennen (also Ebene_3 und Ebene_4 abdecken) und 
nutzen wollen (in Ebene_5 und höher).
Darüber hinaus muß es mittels geeigneter Netzwerkchips (z.B. dem 
REALtec) Frame-mäßig korrekt (Ebene_2) an ein passendes Netzwerk 
angekoppelt sein (Ebene_1)

Autor: Stefanie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen herzlichen Dank  Wegstaben Verbuchsler Wegstaben Verbuchsler!
Durch dieses ganze Thema incl. Schichtenmodell habe ich mich auch gerade 
durchgearbeitet!
Nur ist mir die genaue Aufgabe des Realtec-Bausteins noch nicht so ganz 
klar. Mit Hilfe der Software auf dem Mikrocontroller werden IP-Packete 
erzeugt.
Nun setzt meiner Meinung nach doch der Realtec das IP-Packet in einen 
Ethernet II Frame und schickt es auf die Reise, oder?

Was genau macht denn überhaupt der RTL8019?

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Nun setzt meiner Meinung nach doch der Realtec das IP-Packet in einen
Ethernet II Frame und schickt es auf die Reise, oder?"

Nein. Einzig für die CRC sorgt er selber, ansonsten kriegt der Realtek 
fertige MAC-Frames von der Software geliefert. Aus IP-Frames einen 
Ethernet-II MAC-Frame herzustellen, ist Sache der Software.

Freilich kann es sein, dass das was du als "IP-Paket" bezeichnest, 
bereits ein solcher MAC-Frame ist. Je nach verwendeter TCP/IP-Software.

Autor: Stefanie (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
OK, sorry wenn ich nochmal nerve, aber mit dem Datenblatt kann ich nicht 
so recht was anfangen :-(

Die Präample und das SOF macht das der RTL9019AS?
Die Zieladresse hab ich ja vom ARP, die Quelladresse wird doch schon 
fest im RTL gespeichert, oder?

Der Reset ist klar. Ach ja, was macht eigentlich der Übertrager genau?

Autor: Ronny (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also mit dem RTL9019AS hatte ich nix zu tun,mir ist der CS8900A 
vertrauter.Und der wollte komplette Ethernet-Frames (inklusive der Ziel- 
und Quell-MACs) haben und hat lediglich die CRCs in die vollständigen 
Frames eingefügt.Diese zu erzeugen ist Teil der Software,weshalb da ein 
TCP/IP-Stack oder ein Betriebssystem das selbigen zur Verfügung 
stellt,laufen muss.

Der Übertrager dient in 1. Linie nur zum Entkoppeln des Chips vom 
Bus.Gerade bei längeren Netzwerkkabeln zum nächsten Hub ist ein 
Übertrager unbedingt zu empfehlen.Andererfalls fängt man sich sehr 
schwer zu lokalisierende EMV-Probleme im Layout ein.

Autor: A.K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"die Quelladresse wird doch schon fest im RTL gespeichert, oder?"

Nicht wirklich. Im am Controller angeschlossenen EEPROM ist eine 
MAC-Adresse gespeichert, die vom PC-BIOS oder -Treiber ausgelesen und 
als MAC-Adresse des Controllers verwendet wird. Ein Microcontrollern mag 
das auch so halten, oder verwendet aus Bequemlichkeit eine 
Phantasieadresse, oder das EEPROM existiert überhaupt nicht.

In der üblichen Betriebsart (*) überprüft der Controller alle 
eingehenden Frames, ob sie ihn überhaupt etwas angehen. Dazu vergleicht 
der die Zieladresse eigehender Frames mit (a) Broadcastadresse (b) der 
eigenen MAC-Adressen. Das war's aber auch schon hinsichtlich Adressen. 
Bei vergesendeten Frames steht das drin, was die Software in den Frame 
reinschreibt.

Die in diesem Kontext eingesetzten Ethernet-Controller mögen sich im 
Detail der Register unterscheiden, die grundlegende Arbeitsweise ist 
jedoch bei allen dem ISA-Bus entstammenden Controllern ziemlich ähnlich. 
Nur Controller mit integriertem TCP/IP-Stack, wie beispielsweise W3100, 
weichen davon erheblich ab.

*: Es gibt Betriebsart ("promiscuous", die Übersetzung solltest du 
lieber selber nachschlagen ;-) in dem er unabhängig von der Adresse alle 
eingehenden Frames durchreicht.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.