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
Ä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.
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.
1 | void nicWrite16(unsigned char *buf, unsigned int len) |
2 | {
|
3 | unsigned long val; |
4 | |
5 | len=(len+1)/2; |
6 | while(len--) { |
7 | val = *buf++; |
8 | val |= *buf++ << 8; |
9 | outWord(NIC_DATA_ADDR, val); |
10 | }
|
11 | |
12 | return; |
13 | }
|
14 | |
15 | int sendData(unsigned char *data, unsigned int txlen) |
16 | {
|
17 | /* Enable data write. */
|
18 | outByte(NIC_BASE_ADDR, NIC_MWCMD); |
19 | |
20 | /* Transfer the Ethernet frame. */
|
21 | nicWrite16(data, txlen); |
22 | |
23 | /* Start the transmission. */
|
24 | nicOutW(NIC_TXPL, txlen); |
25 | nicOutB(NIC_TCR, NIC_TCR_TXREQ); |
26 | |
27 | return 0; |
28 | }
|
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"?
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.
> 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.
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 :-)
> 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.
Bitte 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.