Hallo Community,
auf einem aktuellen Design habe ich den STM32F107 zusammen mit dem TI
DP83848l am laufen. Die Clock des DP838481 wird vom STM32 über MCO zu
verfügung gestellt. Nun würde ich mir gerne ein bisschen Platz auf der
Platine sparen und anstatt den 48 Pin DP838481 einen 32 Pin KSZ8081MNX
verwenden. Das ganze ist über MII und somit 25 Mhz umgesetzt.
Hat denn jemand Erfahrung mit dem STM32+KSZ8081MNX über MCO ?
VG,
Mathias
Pete K. schrieb:> Hier vielleicht?> http://andybrown.me.uk/2012/09/01/ethernet-phy-stm32f107/
Über diese Seite bin ich auf den KSZ8081MNX gekommen. Sehr interessant
macht es für mich auch die Aussage "..33Ω resistors.." "... are not
required in this design because they are integrated into the PHY itself"
.
Auf der verlinkten Seite ist der Phy allerdings mit einem zusätzlichen
Oszillator im Betrieb. Und zu der Aussage, dass die 33Ohm bereits
integriert sind find ich auch noch keinen Beleg in den Datenblättern.
Mathias _. schrieb:> Hat denn jemand Erfahrung mit dem STM32+KSZ8081MNX über MCO ?
Jaein. Ich habe verschiedene STM32 mit verschiedenen KSZ/DM PHYs
verschaltet und zertifiziert. Die Idee mit dem Sparen haben wir auch mal
ausprobiert.
Auf dem Labortisch zum Pingen bekommt man vieles.
Jedoch hat z.B. der Jitter der F4 PLL mehr Probleme gemacht als vom F1
her bekannt war. Vergleiche auch jeweils STM32 Datenblatt mit PHY
Anforderungen.
Einem Kunden fiel z.B. beim Belastungstest mit großen Datenmengen (>1GB)
an einem Linux-PC auf, dass viele Paketfehler auftraten.
Wir sind dann wieder auf einen eigenen Oszillator für die PHY
zurückgegangen. Dies war die einzige Änderung, und die Paketfehler waren
verschwunden.
Marcus H. schrieb:> Wir sind dann wieder auf einen eigenen Oszillator für die PHY> zurückgegangen.
Sehr vernünftig, statt sparen koste es was es wolle.
Dieser Euro für einen extra Oszillator ist bestens
angelegtes Geld.
Ganz so einfach ist das Thema leider nicht.
Man muss die Gesamtsituation im Auge haben.
Der zusätzliche Oszillator kostet Geld, kostet LP-Fläche, erhöht den
FIT-Wert, stellt ein zusätzliches Bauteil dar, das gehandhabt werden und
verfügbar sein muss, bringt eine neue Signalquelle ins Spiel, die
Abstrahlungen und Intermodulationen erzeugen kann, et cetera ad nauseam.
Marcus H. schrieb:> Einem Kunden fiel z.B. beim Belastungstest mit großen Datenmengen (>1GB)> an einem Linux-PC auf, dass viele Paketfehler auftraten.> Wir sind dann wieder auf einen eigenen Oszillator für die PHY> zurückgegangen. Dies war die einzige Änderung, und die Paketfehler waren> verschwunden.
Das ist ja sehr interessant. Mit großen Datenmengen gehen wir zwar nicht
um, aber wir nutzen neben TCP auch UDP um uns bei schnellen
Applikationen einen Geschwindigkeitsvorteil zu verschaffen. Da wäre
natürlich ein Paketverlust erst mit einem response-timeout zu
erkennen...
Das Problem in meinem Vorhaben ist weniger der Kostendruck sondern mehr
der verfügbare Bauraum.
Wenn ich mal zusammenfasse:
-MCO für Ethernet Phy nicht mit Sicherheit als stabil anzusehen
-Innerhalb der STM32 Familien kein gleiches Jitter-Verhalten
Diese beiden Punkte sprechen natürlich schon sehr für die Verwendung
eines diskreten Oszillators. Danke erst mal für diese Informationen.
Mathias _. schrieb:> Sehr interessant> macht es für mich auch die Aussage "..33Ω resistors.." "... are not> required in this design because they are integrated into the PHY itself"
Hat denn hierzu noch jemand einen Tipp, wo ich etwas für die
verifizierung dieser Aussage finde ?
Mathias1988 schrieb:> Mathias _. schrieb:>> Sehr interessant>> macht es für mich auch die Aussage "..33Ω resistors.." "... are not>> required in this design because they are integrated into the PHY itself">> Hat denn hierzu noch jemand einen Tipp, wo ich etwas für die> verifizierung dieser Aussage finde ?
Neben dem eigentlichen Datenblatt hat der Hersteller sicher noch
Appnotes und Evalboards inkl. deren Schaltplan im Angebot. Was sagen
denn die Originalunterlagen über Deinen Chip?
Mathias1988 schrieb:> Das Problem in meinem Vorhaben ist weniger der Kostendruck sondern mehr> der verfügbare Bauraum.
Das nenne ich mal so richtig kleinkariert bzw uninformiert.
Für einen Oszillator heutiger möglicher Bauformen (3-4mm
Kantenlänge) soll kein Platz mehr sein?
Anbei der Aufbau meines PHY in einer STM32F407 Implementierung.
Marcus H. schrieb:> Neben dem eigentlichen Datenblatt hat der Hersteller sicher noch> Appnotes und Evalboards inkl. deren Schaltplan im Angebot. Was sagen> denn die Originalunterlagen über Deinen Chip?
Im Datenblatt selber habe ich bisher keine Information dazu gefunden.
Ich werde aber die Unterlagen nächste Woche noch einmal prüfen.
STM Apprentice schrieb:> Mathias1988 schrieb:>> Das Problem in meinem Vorhaben ist weniger der Kostendruck sondern mehr>> der verfügbare Bauraum.>> Das nenne ich mal so richtig kleinkariert bzw uninformiert.> Für einen Oszillator heutiger möglicher Bauformen (3-4mm> Kantenlänge) soll kein Platz mehr sein?>> Anbei der Aufbau meines PHY in einer STM32F407 Implementierung.
Ich sage mal so, wenn man 2 STM32 und einen Ethenet Phy mit jeweils
einem seperaten Oszillator versorgen muss, braucht man den Platz eben
3x.
Zudem:
Marcus H. schrieb:> Ganz so einfach ist das Thema leider nicht.> Man muss die Gesamtsituation im Auge haben.>> Der zusätzliche Oszillator kostet Geld, kostet LP-Fläche, erhöht den> FIT-Wert, stellt ein zusätzliches Bauteil dar, das gehandhabt werden und> verfügbar sein muss, bringt eine neue Signalquelle ins Spiel, die> Abstrahlungen und Intermodulationen erzeugen kann, et cetera ad nauseam.
Mathias1988 schrieb:> Zudem:
... muss man Rücksicht nehmen darauf dass der PHY entweder
50 MHz oder 25 MHz von aussen bekommt was einem (im Fall
der Versorgung vom Prozessor aus) beim Prozessor in der
Wahl der Taktkonfiguration einschränkt.
Alles in allem ergibt das eine heillose Pfuscherei. Aber
spätestens wenn die Leiterplatten fertig auf dem Labortisch
liegen und das Programmieren beginnt weiss man was man
(nicht getan) hat.
Wie sieht es Eurer Erfahrung nach aus, wenn man nicht den PLL-Takt am
MCO ausgibt, sondern direkt den HSE Takt. Da sollte (TM) ja nicht so
viel dabei sein, das den Jitter in die Höhe treibt, oder? Natürlich
müssen die Takte irgendiwie zueinander passen...
So versorge ich z.B. einen USB3320 Phy mit 12 MHz ohne eigenen
Oszillator und das scheint prächtig zu funktionieren.
Natürlich ist der HSI - wenn er von einem Quarz kommt
sozusagen "jitterfrei" verglichen mit dem der aus einer
PLL kommt. Auch wenn er wieder aus dem Controller
herusgeführt wird.
Karl schrieb:> Natürlich müssen die Takte irgendiwie zueinander passen...
Das tun sie aber dann aller Wahrscheinlichkeit nicht. Oder
man muss beträchtliche Zugeständnisse machen.
STM Apprentice schrieb:> Das tun sie aber dann aller Wahrscheinlichkeit nicht. Oder> man muss beträchtliche Zugeständnisse machen.
Das kann leider passieren.
Um nicht zu sehr OT zu werden, es ging ja ums Platz sparen: Was haltet
Ihr von den MEMS Oszillatoren die es (neuerdings?) von Microchip etc
gibt? Habe die in einem kleineren Projekt verwendet und war eigentlich
sehr angetan. Die gibt es auch in winzig.
Mathias1988 schrieb:> Ich sage mal so, wenn man 2 STM32 und einen Ethenet Phy mit jeweils> einem seperaten Oszillator versorgen muss, braucht man den Platz eben> 3x.
Nö. Man kann mehr als einen Phy an einen Oszillator hängen. Nur bei
nacktem Quarzkristall geht das nicht.
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang