Kollegen, ich verbinde gerade eine AVR32 CPU mit einem Ethernet PHY KSZ8041TL. Bis auf die TX_ER Leitung. Die gibt es zwar beim Controller, aber der PHY hat diesen Pin nicht. Meine Fragen: Warum braucht er dieses Signal nicht? Lass ich den PIN am Controller dann frei? Was sind die Konsequenzen? Ich habe folgende Signale verbunden: TX_CLK CRS COL MDIO MDC RX_DV RXD[0..3] RX_ER (den gibt's serwohl am PHY) RX_CLK TX_EN TXD[0..3] TX_ER -> (nur an der CPU, nicht am PHY).
Ok, niemand. Gut, dann probiere ich eine andere Frage: - Welche PHY's verwendet ihr? - Gibt es dort dieses Signal 'transmit error'?
>- Welche PHY's verwendet ihr? LAN8720 >- Gibt es dort dieses Signal 'transmit error'? Nö, nur RXER und der ist nicht angeschlossen. Geht aber trotzdem;)
>>- Gibt es dort dieses Signal 'transmit error'? > Nö, nur RXER und der ist nicht angeschlossen. > Geht aber trotzdem;) Aha, danke. Interessant zu wissen. Das heißt du benutzt nicht einmal RXER. Lässt du Pin am Controller offen schweben?
>> Nö, nur RXER und der ist nicht angeschlossen. >> Geht aber trotzdem;) > >Aha, danke. Interessant zu wissen. Das heißt du benutzt nicht einmal >RXER. Lässt du Pin am Controller offen schweben? Wenn du mit Controller den PHY meinst, ja. Wird wohl ein Ausgang sein. Hab die Schaltung aber nicht selber gemacht sondern selber gekauft und sie hängt an einem STM32F4;)
DP83848I und der hat auch kein TX-ER. Kannst Du vielleicht 2 KSZ8721BL brauchen? Die vergammeln bei mir. 'Gehen' ist ein unscharfer Begriff. Ich denke die Software (Treiber) hat viele M"oglichkeiten auf Fehler zu reagieren. Die Kommunikation ist ja sehr optimistisch. Kabel ausstecken und wieder einstecken ist ja z.B. nicht zwingend ein Verbindungs -abbruch - man stelle sich das mal bildlich vor! Darum sind vermutlich alle Fehlersignale purer (Performance-)Luxus
> Wenn du mit Controller den PHY meinst, ja.
Nein, mit Controller meine ich die CPU. Die stellt ja 'transmit-error'
bereit. Ich habe ja selbst noch keine TCP/IP Stack geschrieben, aber
greift er nicht auf diese Ebene zu? Die andere Frage wäre auch, was
passiert denn, wenn ein TR-ER kommt?
KSZ8041 schrieb: > Ich habe ja selbst noch keine TCP/IP Stack geschrieben, aber > greift er nicht auf diese Ebene zu? Nein tiefer: auf Ethernet-Ebene - also kleine handliche Pakete mit ganz wenig Schnickschnack drumrum. HW-Adressen, Daten, Checksumme ENDE. Was sagt denn die Controller-Doku zu dem Signal? Was tut es denn? Ein Paket das gerade gesendet wird kaputtmachen (abbrechen)??
Vielleicht kann man den Status auch aus einem Statusregister auslesen und braucht den HW Pin nicht immer?
Marc P. schrieb: > DP83848I und der hat auch kein TX-ER. Interessant. > Kannst Du vielleicht 2 KSZ8721BL brauchen? Die vergammeln bei mir. Der hat auf Pin 14 das TX-ER :-) Aber vielen Dank. Ich bin grad erst am Board entwerfen, bis das alles läuft kann noch viel Zeit vergehen :-) Und ich will jetzt nicht mehr Bausteinwechseln. Und hab ganz ehrlich auch den Unterschied zum KSZ8041TL nicht rausbekommen... > Darum sind vermutlich alle Fehlersignale purer (Performance-)Luxus So ein Gefühl bekomme ich gerade. Ist nicht so wichtig, ob das abgefragt wird, es wird eher im Protokoll behandelt.
Marc P. schrieb: > Was sagt denn die Controller-Doku zu dem Signal? Was tut es denn? Ein > Paket das gerade gesendet wird kaputtmachen (abbrechen)?? Der TX_ER Pin wird nur ein einziges Mal in der Doku beiläufig erwähnt. Das ist höchst interessant: If transmit DMA underruns, bad CRC is automatically appended using the same mechanism as jam insertion and the TX_ER signal is asserted. In a properly configured system, this should never happen. Naja, wenn das praktisch nie vorkommt, braucht man das Signal auch nicht. Es ist nur eines von mehreren TX Fehlern. Ich muss nur noch rausfinden, ob der Pin am Prozessor ein festes Potential braucht. Nicht, dass ich ihn offen lasse und 'floated'...
JojoS schrieb: > Vielleicht kann man den Status auch aus einem Statusregister > auslesen > und braucht den HW Pin nicht immer? Der Prozessor selber hat eine Menge Register für das Ethernet und auch Fehlerbehandlungen. Ich denke, ich habe den Pin TX_ER überbewertet. Das meiste geht alles über die Software.
Mit dem TX_ER kann man bewusst Fehlersignale auf der Leitung generieren, die der Empfänger dann als RX_ER an seinen MAC weitergibt. Man kann damit z. B. Übertragungen kontrolliert abbrechen. Normalerweise braucht man das nicht. Gruss Axel
Axel Laufenberg schrieb: > Mit dem TX_ER kann man bewusst Fehlersignale auf der Leitung generieren, > die der Empfänger dann als RX_ER an seinen MAC weitergibt. > > Man kann damit z. B. Übertragungen kontrolliert abbrechen. Aha, vielen Dank. Das würde auch erklären, warum alle ein RX_ER haben. Empfangen kann jeder dieser Abbruch, aber nicht alle Bausteine sind zum Senden dafür ausgelegt.
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.