Hallo an alle! Mein RS232-LAN-Modul ist mittlerweile in der Lage Daten so zu versenden, wie vorgesehen. Leider funzt das erst mit einer Derekten Verbindung (gekreuztes Patchkabel vom Modul zum PC). Ist ein Hub- oder höherwertihe Netzwerktechnik dazwischen geschaltet, so werden keine Daten empfangen. Stattdessen zeigt mir der Hub total viele Kollisionen an. Dazu muß ich segen, daß ich den CS8900a im 8-Bit-I/O-Modus betreibe und nur warte, bis er ein Rdy4Tx-Flag gesetzt hat. Das Signal, welches den Ethernetkontroller verläßt wurde mittels eines Oscar's mit ein anderes Signal verglichen und schaut gut aus. Wer kann mir weiterhelfe? Megadanke im Voraus!! Gruß Markus
Hat denn hier keiner Ahnung von Ethernet? Wo holt ihr euch denn die benötigten Infos her?
Hallo! Ich habe ja die Hoffnung noch nicht ganz aufgegeben;-)) Wenn ich das Datenblatt von Cirrus richtig verstanden habe, so sorgt die MAC-Engine für die Kollosionserkennung. Dementsprechend muß ich nicht tätig werden. Aber dennoch wird kein Trafic im Netz verzeichnet! Vieleicht nur ein kleiner Hinweis? Danke Markus
>Ist ein Hub- oder >höherwertihe Netzwerktechnik dazwischen geschaltet, so werden keine >Daten empfangen. Stattdessen zeigt mir der Hub total viele Kollisionen >an. Kannst du bitte mal genauere Angaben zum Protokoll geben ? Hängst du nun an einem Switch oder an einem Hub ? Welche Linkgeschwindigkeit liegt an ? Wenn du mit 100Mbit über einen Hub gehst dann bitte nicht Vollduplex weil dort die Kollisionsabfrage abgeschaltet ist. Halbduplex ist da richtig. Oder du nimmst einen Switch. andere Möglichkeit: Du nutzt 10Mbit und der Hub kann nicht auf 100Mbit vermitteln. auch hier ist dann ein Hub oder Switch mit Bridge erforderlich. aber gibh erstmal Infos über die Hardware. Ohne ist eine Hilfe nicht so einfach zu bewerkstelligen
Hi Ratber!
Super daß Du dich meldest!!! Weil, leider weiß ich nicht ich nicht mehr
weiter.
Also: Ich sende mit 10 Mbit und der Hub hat auch 10 Mbit. An einen 100
Mbit Router habe ich das Teil auch schon angeschlossen. Da erhalte ich
auch keine Daten auf andere Rechner.
Ich schicke ausschließlich UPD-Daten, d.h. Mein Board sendet
ununterbrochen Daten ins Netz.
Die Daten werden von einer seriellen Schnittstelle in den Atmega32 mit
der USART eingelesen. Der Atmega initialisiert den Ethernetkontroller
und resettet ihn.
Im Anschluß wird jedem von der USART empfangenen Datensatz erst ein
UDP-Header (ohne Checksumme) und dann ein IP-Header vorangestellt.
Anschließend folgt der MAC-Header. Somit schaut dann das Packet so
aus:
MAC-Header| IP-Header| UDP-Header| Datensatz
Die meisten Daten in den Headern sind statisch. Es sollen ja nur Daten
als Broadcast (MAC: FF FF FF FF FF FF, IP: FF FF FF FF) an einen
beliebigen Port(z.B.: 4000) gesendet werden.
Wie schon gesagt: In der direkten Verbindung klapt das auch. Da kann
ich mir bestens mit Ethereal die Frames anzeigen lassen. Da ist alles
super.
Gruß Markus
Hmmm. Was passiert wenn nur zb. ein Hub dazwischenhängt ? (Also Rechner,Hub,AVR.Keine weiteren Geräte) Dort auch Sendepause oder gehts dann ?
Hi Ratber! Auch bei der Konfiguration AVR-Board, Hub, PC und nur ein gesendeten Frame wird eine Kollision erkannt. Selbst wenn nur AVR-Board und Hub angeschlossen sind, zeigt der Hub Kollisionen an :-((( Ist ein Hub - im allgemeinen - eigendlich so intelligent, daß er Kollisionen erkennt und die Stopsignale versendet, oder reagiert bringt er nur erkannte Stopsignale zur Anzeige? Angenommen der Hub verhält sich passiv, dann könnten die Kollisionen nach der Konfiguration (AVR-Board, Hub) nur vom AVR-Board erkannt worden sein. Da in direkter Verbindung die Daten aber empfangen werden (Die LED der Netzwerkkarte ist dann allerdings gelb statt grün) könnte dies bedeuten, daß RXD Hardwareseitig nicht sauber ist. Das die LinkLED vom PC gelb ist, mag daran liegen, daß der PC zwar ein Netzwerk erkennt, abder mit diesem keinen Kontakt via ARP aufnehmen kann, da der AVR wirklich nur Daten sendet und keine Protokolle zuläßt. Sind nun alle Klarheiten beseitigt;-) Viele Grüße Markus
Nicht ganz. Erstens ist ein Hub salopp gesagt nix anderes als ein Strohdummer Verteiler äller Daten. Dh. jedes Datenpaket steht an allen angeschlossenen Geräten an was dann auch die Bandbreite auslastet. Eine analogie wäre alle Telefongespräche in einer riesigen Konferenz zu schalten wo jeder jeden höhrt. Quatschen alle gleichzeitig drauflos dann gibts eben "Datenkollisionen" und keiner versteht mehr was. Ergo muß man eine Sprechpause abwarten um seinen nächsten Satz abzusetzen. Ein Switch dagegen verbindet nur die beiden beteiligten Gesprächspartner miteinander.(Kein anderer höhrt mit) Dabei wird jede Leitung nur mit dem Datenstrom belastet des auch hier hingehöhrt. Die Analogie hierzu ist das Telefonieren wie wir es kennen. Eine Kollisionsabfrage ist hier überflüssig. Natürlich gilt auch zwischen zwei Geräten das man seine Pakete zu zugelassenen Zeiten loschickt sonst schlägt die Kollisionserkennung des Hubs Alarm. Zimindest einies deiner Geräte (AVR oder PC fürht kein korrektes Protokoll aus. Spiel mal mit Halb und Vollduplex rum Am PC gehts auf jeden Fall.Was mit deinem AVR-Teil ist weiß ich nicht weil ich die Konstruktion nicht kenne. Was die Kollision als solches betrifft so ist es ja so das kein Ethernetgerät "nur reine Daten" schickt. Ein Protokoll ist immer dabei selbst auf 255 imn Broadcast. Ich vermute das der Ethernetteil am AVR nicht ganz Konform geht.
Hallo Ratber! Also, der AVR macht folgendes und wirklich nur das: - CS8900a initialisieren - GPS-Daten mit UDP-Header versehen (ohne Checksumme) - UDP-Frame mit IP-Header versehen - IP-Frame mit MAC-Header versehen - CS8900a konfigurieren - Daten an den CrystalLan senden Dementsprechend reagiert der AVR auf kein höheres Protokoll. Das einzige ist die Kollisionserkennung. Die aber geschieht in der MAC-Engine des Ethernetkontrollers. >Zimindest einies deiner Geräte (AVR oder PC fürht kein korrektes >Protokoll aus. Wenn dann der AVR! Was muß noch berücksichtigt werden, wenn ich nur stur UDP-Packete als Broadcast versenden möchte? Gestern habe ich meine Hardware nocheinmal kontrolliert. Aber es mir kein Fehler aufgefallen. Fast vermute ich, daß es ein SW-Fehler ist. Mißachtung von Protokollregeln. Hast du eine mögliche Antwort? Danke und Gruß Markus Wenn ich
Hi, Doofe Frage: MAC Addresse FF FF FF FF FF FF FF ? Ich dachte FF FF FF.... und 00 00 00.... sind verboten ?!? Oder ist das tatsächlich die Broadcast Addresse im MAX Heaser ? Wie soll man dann den Sender Identifizieren ?!? Gruß ka-long
Hallo ka-long! Es sollen tatsächlich alle Rechner angesprochen werden. Nur der, der ein UDP-Programm mit dem richtigen Port gestartet hat, empfängt die Packete. Das ist zunächst durchaus so gewollt. Gruß Markus
da steht ... initialisieren ... GPS daten in udp header senden ... also alle daten in ein(!) paket packen und dann das gesamte paket senden. normalerweise packt doch der ethernet-controller das level 2-paket zusammen, also müsste das dann evtl. nicht mehr an den controller gesendet werden (ins datenblatt schauen) also ethernet senden läuft im prinzip so ab: -an der leitung horchen (gab-Zeit) -wenn leitung frei, dann senden -wenn eine kollision auftritt, sendung abbrechen und die backoff-zeit warten, danach kann erneut versucht werden ich nehme aber an, dass du twisted pair kabel verwendest, da kann es eigentlich keine kollisionen geben. (Evtl. ein Cross-Over-Kabel erwischt oder im Hub/Switch die "Uplink"-Funktion aktiviert?)
@Markus
>Wenn dann der AVR!
Ja,das vermute ich auch.
Wie es Läuft hat Hans ja schon gesagt.
Ich gehe aber mal davon aus das du beim Betrieb mit Hub oder Switch
auch ein normales Patchkabel nimmst oder ds Crosoverkabel über den
Uplink betreibst (Doppelte drehung damits stimmt.)
Mehr fällt mir aber im Momment auch nicht ein
schau mal in den rfc zu ethernet und den ganzen protokollen nach, vielleicht stimmt die checksumme oder ein paket nicht und das falsche paket wird als kollision angezeigt. was gibts du als quell-adresse an? da kannst du die FFs nicht verwenden... rfc791 -> ip rfc768 -> udp Was meinst du mit gps daten ... ohne checksum ? bei udp gibt es eine checksum (4. wort im header)
Hi, Oh ja, das hatte ich vergessen.... FF .. oder 00 .. sind als Quelle verboten. das hattte ich vergessen, in meinem Beitrag oben zu erwähnen..... Also was hast Du als QuellenMac und IPO und als Ziel MAC und IP ? Gruß ka-long
Hallo hans müller! Als IP-Quell-Adresse suche ich mir eine schöne aus. Als MAC-Quell-Adresse verwende ich die einer ausgemusterten Netzwerkkarte. Die Checksumme im UDP-Header habe ich mit 0x0000 aufgefüllt, damit wird erkannt, daß ich auf eine Prüfsummenberechnung verzichte. So auch die Aussage von Ethereal. Kannst du mir zufällig sagen, wie hoch der Pegel vom Manchaster-Code sein muß? Ich nehme an, das er von Spitz zu Spitze 7,5V betragen muß! Bei mir messe ich aber nur 5V! Gruß Markus
@ ka-long! Quelle: MAC: MAC-Adresse ausrangierter Netzwerkkarte IP. 192.168.0.179 Port: 3000 Ziel: MAC: FF FF FF FF FF FF IP: FF FF FF FF Port: 4000 Gruß Markus
hallo! vielleicht liegt es doch an der hardware: eine kollision auf dem netzwerk wird durch gleichanteilmessung ermittel. ich glaub dass wenn mehr als 40mA gleichstrom festgestellt wird, dann wird eine kollision gemeldet. hast du schon mal probiert: 1.) nur avr und hub (hub eingeschaltet) 2.) nur avr und hub (hub ausgeschaltet) 3.) nur avr und statt hub einen endwiderstand rein lt. def von lan der hub ist ja ein dummes ding, d.h. wenn du nur avr und hub hast und es wird eine kollision angezeigt, dann muss etwas in der ahrdware falsch sein. das problem ist natürlich erkennt dein controller eine kollision sendet er ein jam signal und versucht nach einer zufälligen zeit wieder zu senden. (vielleicht hast du reflexionen auf der leitung? verwendest du patch kabeln?)
Kurz nocheinmal zum Ethernetkontroller! Beim CS8900a muß alles zwischen den SFD und CRC vom Host bereitgestellt werden, MAC-Header inclusive. Der CS8900a hat nur ein Register für die eigene MAC-Adresse und das nur für Receive. Die Idee mit dem gekreuzten Kabel am Uplink hatte ich auch schon. Daran lag es aber auch nicht! Gestern hatte ich den Ethernetübertrager noch getauscht und nun habe ich am TXD vom CrystalLan noch ein schönen Nadelimpuls mit 2,5V anliegen. Öfters mal was neues;-/ Gruß Markus
Hallo, das frontend für den CS8900 hast du selbst gemacht oder eine fertige ISA Netzwerkkarte genommen? Martin
@ Chris! zu 1. Hub zeigt Kollision an. zu 2. ??? Das kann doch gar nicht funktionieren. Ein Hub refreshed doch das Signal. zu 3: muß ich versuchen Natürlich verwende ich ein Patchkabel. Ein Jam-Signal konnte ich nicht messen. Gruß Markus
@ Martin! Das Frontend habe ich selber gemacht. Die Beschaltung habe ich aus dem Datenblatt von Cyrrus. Gruß Markus
hallo!
sorry ich hab das falsch verstanden, ich dachte du bekommst vom avr ein
signal dass du kollisionen hast, daher 2.) aber vielleicht kannst du den
controller abfragen nach kollisionen? den dann wäre der versuch 2
berechtigt, somit könnte man feststellen ob es ein problem mit dc ist.
was mir aber noch komisch erscheint, du hast follkommend recht, der hub
macht eigentlich nichts anderes alls das signal zu refreshen bzw. er
verbindet halt alle station untereinander und repeatet. ("collision in
a box") allso du hast nur eine collisiondomain! wenn du aber nur den
avr und den hub in verwendung hast, dann ist es sehr komisch das du
kollisionen angezeigt bekommst. wer soll den eine kollision
verursachen? der hub bestimmt nicht, der darf ja nichts senden, da auf
den andern port schweigen herscht, somit analysiert er nur deinen port,
also kommt etweder misst auf diesem port daher (was ja nicht sein kann
wenn der pc avr link funktioniert) oder es gibt einen hardwaredefekt.
vielleicht ist die hardware bei nic's etwas unterschiedlicher als bei
hub's/switch, oder deine nic ist nicht so empfindlich wie die anderen
geräte.
hast du den oszi immer dran hängen? bzw. wo hast du den hängen? ich könnte mir vorstellen, dass die 50pF der Kabel schon ausreichen um das signal deutlich zu stören...´ der manchester-code sagt nur aus, wie ein signal behandelt werden muss (umcodiert) nichts über pegel oder so etwas. der hub zeigt kollisionen an? dann kann das nur eine bridge (oder höher) sein... dann kann es daran liegen dass die checksum doch berechnet werden muss... pack mal ein statisches paket zusammen und verwende die checksum (vielleicht ist die firmware nicht ganz so toll implementiert und will eine checksum)
@ Chris! Eigendlich müßte das Netz doch DC-frei sein. Es sind doch Übertrager zwischenEthernetkontroller und Netz geschaltet. Was die nic's (heißt das Netzwerkkarte?) betrifft, so scheint mir, sind die Netzwerkkarten immer tollerenter, da ich es bisher mit drei Karten versuchte und es auch immer klappte. @ Hans! Das Oszi hängt nur manchmal dran. Auf dem Gerät steht auf jedenfall Hub drauf?! Hast du Code zur Berechnung der UDP-Prüfsumme? Ich weiß nähmlich nicht, wie der Pseudoheader berücksichtigt wird. Danke und Gruß Markus
hallo! ja der m.-code ist auch dc frei und durch diesen "trick" wird so festgestellt ob kollisionen auftetretten sind, denn die analyse wäre sonst etwas kompliziert und komplex. (dsp wäre nötig mit schneller fft, etc. denn man kann ja nicht ausschließen, dass drei senden -> muss man alles berücksichtigen, daher ist meines wissens eine 40mA DC Strom grenze eingeführt worden) aber ich lass mich gerne korregieren dass muss nicht stimmen, du könntest aber trotzdem mal messen!?
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.