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?
Angehängte Dateien:
-
DP83848_mit_Osc.jpg
76 KB
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.
Vergleich doch einfach die Jitter angaben von PHY und STM, dann kann man abschätzen, ob man einen Quarzoszi braucht oder nicht.
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.
wenns um platz geht ... warum MII und nicht RMII ? KZS8081RNA die 5 leiterbahnen weniger schaffen platz für einen 25MHz XO
tzewruwroiqw schrieb: > die 5 leiterbahnen weniger schaffen platz für einen 25MHz XO Gegen Beton im Kopf ist kein Argument gewachsen.
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.
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.