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).
>- 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)??
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.
