Ethernet an uController

[Sebastian (Gast)]

Hi,

ich sitz grade an meiner Diplomarbeit, in der unter anderem ein ARM7 ans 
Ethernet angeschlossen werden soll. Ich benutze dafür das Olimex-Board 
LPC-E2294-RB mit einem LPC 2294 als uController und einem 
Ethernetcontroller DM9000 von Davicom (meine MAC/PHY).

Ich bin grade am dabei, einen Treiber dafür zu schreiben (schon ne 
Weile) - und es funktioniniert mittlerweile auch einigermasen (ich kann 
einen 1k großen Text von einem Board zum anderen schicken).

Im Moment befinde ich mich allerdings noch im "Promiscuous Modes", also 
er läßt alles durch, nicht nur das, was an die eigene MAC-Adresse 
gerichtet ist.

Beim Ethernetbaustein (MAC/PHY) DM9000 gibt es ein Register (Physical 
Adress Register), in dem ich meine eigene MAC-Adresse eintragen kann 
(außerdem ein Multicast-Adress-Register - aber sonst habe ich nichts 
gefunden, wo ich ne MAC-Adressse eintragen kann).

So, wie ich das verstanden habe, kriege ich ja nur die Daten weiter 
geleitet, die auf dem Bild 
(http://upload.wikimedia.org/wikipedia/de/f/fa/Etherframe.png) als 
"Type-Feld" und "Daten" bezeichnet werden? Das ist schon die erste 
Frage: stimmt das, oder habe ich da schon einen Denkfehler?
(|Prabmle|SFD|Ziel MAC|eigene|MAC|die Daten, die an den Controller 
weiter geleitet werden|CRC)

Gestern ist mir dann der Gedanke in den Kopf geschossen: wo kann ich 
denn dem Ethernetbaustein die Ziel-MAC-Adresse mitteilen? Ich möchte uIP 
benutzen (open source von Adam Dunkels), das bedeutet, auch dann das 
ARP-Protokoll. Und beim ARP-Protokoll kriege ich ja als Antwort die 
Ziel-MAC-Adresse, die ich ja irgendwo eintragen muss.

In der Hoffnung, dass hier schon jemand Ethernet angeschlossen hat, 
dachte ich mir, ich probier hier mein Glück :-)

Wenn jemand da nen Tipp hat, wäre ich sehr dankbar...

Gruß

Sebastian

[Ing-Dom (Firma: OpenKNX) (sirsydom)]

Ähm nein normal solltest du das komplette Ethernet-Packet (also von 
Ziel-Mac bis Datenfeld Ende) bekommen und auch senden. Das musst du aber 
selbst zusammenbauen! Du sagst du kannst schon Daten hin und herschieben 
- wie machst du dass denn da? Kann es sein das du einfach Daten auf den 
Bus schiebst und dir das Ethernetprotokoll einfach wurscht ist und du 
gar keine Adressen sendest? Schau dir doch mal deine Kommunikation mit 
Wireshark an.

[PeakRunner (Gast)]

Wie Sirsydom schon gesagt hat,
du musst erst dein eigenes Paket zusammenbauen.
Dieses Paket schreibst du dann in den Transmit-Buffer.
Anbei zwei Funktionen, wie das bei mir läuft ...
Das PAR wird nur am Beginn beschrieben, damit dein Device ne MAC-Adresse 
besitzt.

void nicWrite16(unsigned char *buf, unsigned int len)
{
  unsigned long val;

  len=(len+1)/2;
  while(len--) {
    val = *buf++;
    val |= *buf++ << 8;
    outWord(NIC_DATA_ADDR, val);
  }

  return;
}

int sendData(unsigned char *data, unsigned int txlen)
{
  /* Enable data write. */
  outByte(NIC_BASE_ADDR, NIC_MWCMD);

  /* Transfer the Ethernet frame. */
  nicWrite16(data, txlen);

  /* Start the transmission. */
  nicOutW(NIC_TXPL, txlen);
  nicOutB(NIC_TCR, NIC_TCR_TXREQ);

  return 0;  
}

[Sebastian (Gast)]

Vielen Dank, seit ne große Hilfe...

Ich werd ja sowieso uIP benutzen, das baut mir das Packet zusammen. Im 
Quellcode von uIP sind für mich die einzelnen Schichten nicht wirklich 
zu erkennen (um Zeit und Platz zu ersparen wird recht schnell mit 
globalen Variablen und goto-Befehlen gearbeitet - ist aber ne bewärte 
Software, die weltweit recht heufig eingesetzt wird) - deswegen war mir 
jetzt nicht klar, ob es mir nur das Packet bis inkl. der IP-Schicht 
zusammenbaut, wie bisher angenommen.

@Sirsydom: du hast recht, bisher war mir das Protokoll egal, ich wollte 
erst einmal lediglich den Baustein zum laufen bringen - und hab daher 
die Daten einfach nur auf den Bus geschickt. Am Kabel hängt eh im Moment 
nur ein Sender (Entwicklungsboard), ein Empfänger (Entwicklungsboard).

Aber eins versteh ich immer noch nicht: wenn ich die kompletten Daten 
von Quell-MAC bis Ende Datenfeld sende, warum interessiert den 
Ethernetbaustein (DM9000 von Davicom) die eigene MAC-Adresse wärend der 
Initialisierung überhaupt? Wofür sind dann das "Physical Adress 
Register" (PAR) und das "Multicast Adress Register"?

[PeakRunner (Gast)]

Der Davicom kann in verschiedenen Modi betrieben werden,
so gibt es den promiscous mode, da hört er auf alles, was ankommt,
oder den normalen mode, da hört er nur auf seine MAC-Addresse und Pakete 
die an alle geschickt werden. Und die eigene MAC-Address wird halt im 
PAR-Register abgelegt.

[Andreas K. (a-k)]

> warum interessiert den Ethernetbaustein (DM9000 von Davicom)
> die eigene MAC-Adresse

Für ausgehende Pakete garnicht. Aber bei eingehenden Paketen werden 
normalerweise nur passende Pakete, Broadcasts und Multicasts akzeptiert.

[Sebastian (Gast)]

Ah, ok - so hatte ich das mit dem normalen Modus und dem promiscous mode 
(in dem bin ich) auch verstanden gehabt - was ja überhaupt mich erst zur 
Annahme gebracht hat, dass ich nur "Typ-Feld" und "Daten" kriege und wo 
ich mich gewundert habe, wo ich dann  die Ziel-MAC-Adresse hinspeichere.

Der Tipp mit wireshark war schon mal Gold wert - vielen Dank an der 
Stelle.
Bestätigt auch noch einmal, dass ich das komplette, selbst 
zusammengesetze Ethernetframe inkl. Ziel/Quell-MAC bis Datenende senden 
muss (Wireshark hält die ersten 12 Byte für die beiden MAC-Adressen).

Ich hab jetzt das Entwicklungsboard mit dem Rechner verbunden und 
aufgezeichnet, was er schickt: der Text, den ich sende, kommt perfekt in 
der richtigen Länge an, so oft ich auch sende.

Eigendlich hab ich schon fast n schlechtes Gewissen, wieder hier zu 
fragen - vor meiner Diplomarbeit jetzt hatte ich aber noch nie mit 
TCP/IP oder so zu tun (also, auf der Ebene halt) und auch nicht soo die 
Erfahrung mit uControllern: hab da beim Ethernetchip noch kleine 
Problme:

Sobald ich ein Packet empfange, wird ein Pin auf "high" gesetzt. Dieses 
prüfe ich in der Main ab - sollte es aktiviert worden sein, rufe ich die 
Empfangsfuntion auf, empfange mein Packet (komischerweise mit 4 
zusätzlichen Zeichen am Ende, unterschiedlich bei einem anderen Text, 
allerdings zum Teil keine Zeichen, die im Text vorkommen) und setze das 
"Interruptpin" wieder zurück (DM9000_ISR-Bit[1]). Wieder in der Main 
stimmt die empfangene Länge nicht ganz (immer 4 Byte zuviel), die Daten 
(bis auf die letzen 4 Byte) passen auch soweit.
Das Problem, was ich habe: auch, wenn ich mit dem einem Board mit 
"voll-speed" sende, empfange ich bei dem anderen Entwicklungsboard nur 
sporadisch was. Wenn ich nur ein Packet sende, ne Sekunde warte und dann 
erst wieder ein sende oder eine bestimmte Anzahl an Packeten schicke, 
bestätigt sich der Fehler und es kommen nicht alle Packete an.
Als ich die Überprüfung (was empfangen oder nicht) langsamer hatte, weil 
ich die Empfangsfunktion immer aufgerufen hab, hab ich schon immer was 
empfangen, aber auch nur dann, wenn ich mit voll-speed sende.
Kommt mir fast so vor, wie wenn ich auf ein Metallband mit Löchern drin 
Daten schieße, das langsam vorbeizieht und ich nur was empfange, wenn 
ich zufällig ein Loch treffe.

Um ehrlich zu sein, bastel ich schon ne Weile jetzt an der init/sende 
und empfangsfunktion rum und mir gehen grad die Ideen aus, woran das 
liegen kann. Hat vielleicht hier einer ne Idee? Wäre echt super :-)

[Andreas K. (a-k)]

> komischerweise mit 4 zusätzlichen Zeichen am Ende

Die CRC?

Zu fullspeed: Wie betreibst du den DM9000 was duplex und 
auto-negotiation angeht? Probier da mal etwas rum, anfangs indem du ohne 
auto-neg und fest auf half-duplex gehst. Wenn du Pech hast steht nämlich 
der DM9000 auf full duplex und der Switch auf half.