Hallo. Hab zwar schon einige Einträge zum Thema durch gelesen. Aber die sind alle ziemlich konkret uC xy + PHY yz. Ich hab aber - bis auf den Prozessor (STM32F4x7) - keine Festlegung. Kann mir jemand Erfahrungswerte zum Thema PHY geben? Welche sind gut? Welche sollte man vermeiden? Was gibt es vielleicht sonst noch für Fallstricke? Vielen Dank. Pepe.
>Kann mir jemand Erfahrungswerte zum Thema PHY geben? Welche sind gut? Die die auf den EVAL Boards von ST verbaut sind. Dafür gibt es fertigen Code. >Welche sollte man vermeiden? Die die NICHT auf den EVAL Boards.....
So hab ich eigentlich anfangs auch gedacht. Hab mir auch schon einige EVAL Boards und OpenSource Boards ansehen/ausprobiert. Und dann bin ich über den ST802 gestolpert und musste feststellen, dass der nur mit Problemen läuft...
Vielleicht hilft das hier: http://andybrown.me.uk/wk/2012/09/01/ethernet-phy-stm32f107/ http://blog.tkjelectronics.dk/2012/08/ethernet-on-stm32f4discovery-using-external-phy/ Wobei ich Ethernet auf einem Mikro für sehr anstrengend halte. Nimm lieber einen Raspi, da funktioniert das auf Anhieb.
:
Bearbeitet durch User
wo ist das problem? ethernet ist nach nem ieee standard definiert. es sollte daher praktisch jeder phy funktionieren. die ersten paar register, die für den phy erforderlich sind, sind ebenfalls bei allen typen gleich. Also einfach einen passenden aussuchen und ggf. für sonderfunktionen die auswertung der entsprechnden register implementieren.
> es sollte daher praktisch jeder phy funktionieren. Beim STE100 geht gerne die Autonegotiation schief. Statt 100 Mbit kommen dann nur 10 Mbit aus der Leitung. Lustigerweise verwendet ST den Chip auf den eigenen Evalboards auch kaum. Ausser auf dem STE100-Evalboard natuerlich :-). Dort zusammen mit einem STM32F207. Recht unproblematisch verhielt sich bisher der LAN8720. (Allerdings an einem LPC1768.) Aus der Tiva-Serie von TI kommt der TM4C1294 mit dem Phy On-Chip. Der braucht extern dann nur einen MagJack. Auch der arbeitet zuverlaessig.
Du kannst Dir auch den KSZ8031 anschauen, mit dem hab ich gute Erfahrungen gemacht. Ist klein und günstig.
Irgendwie hatte ich den Eindruck, dass es mehr Probleme mit den PHYs gibt. Aber vielleicht findet man die Probleme auch nur wenn man danach sucht ;-) Werde mir wohl den DP83848 näher betrachten: Gibt von ST ein EVAL und Software. Vielen Dank an alle.
Falls noch jemand mitliest: Am STM32F407 verwenden wir sehr erfolgreich (inkl. EMI-Tests) folgende Bausteine: - KS8721BL - RMII - PHY - KSZ8863RLL - RMII - Switch - 2xPHY Die Bausteine werden jeweils per Bootstrap konfiguriert, so dass der Firmwareaufwand eigentlich aus der Anpassung der PHY-ID besteht. Wem die Originalbeispiele von ST zu komplex sind, der findet bei mikrocontroller.bplaced.net mehrere ausgekernte, aber lauffähige Beispiele.
Hi Marcus, Ich möchte auch einen KSZ8863 (aber MLL) an einem STM32F407 verwenden. Da ich mittlerweile mit PHY Mode und MAC Mode vollständig durcheinander bin: Kommuniziert der STM32F4 über die M/RLL Schnittstelle "out of the Box" mit dem Switch oder muss der Switch über SPI/SMI in den "anderen" Modus geschaltet werden? Ich meine: Er müsste so ohne jede weitere Änderung laufen und verpasst dem STM32F4 auf diese Weise zwei geswitchte Ethernet Ports, richtig? Danke und Gruß Martin
Pete K. schrieb: > Wobei ich Ethernet auf einem Mikro für sehr anstrengend halte. Nimm > lieber einen Raspi, da funktioniert das auf Anhieb. Das kommt immer auf den Anwendungsfall an. Beispiel: Was nützt mir die Problemlose Ethernetanbindung, wenn ich dann auf die gesamte Steuerungsperepherie verziechten muß die dieser spezielle µC eben hat und der Rasberry nicht ? - Ansteuerung von Antrieben - CAN ...... Sicher kann man den Rasberry als intelligenten Gateway für den µC verwenden ob sich dieser Aufwand lohnt kommt aber eben auch wieder auf den konkreten Fall an. Projekte mit rasberry PI sind also nicht per seh weniger anstrengend ;-)
Pepe schrieb: > Welche sollte man vermeiden? Was gibt es vielleicht sonst noch für > Fallstricke? Wenn Sie etwas mit weniger (nicht ohne) Fallstricke möchten, und ggf. dafür mit dem entsprechenden Perfomanceverlust leben können. - > "Wiznet" Produkte - > "Netburner" Produkte Gruß
Hi Martin, zumindest die von mir genannten PHYs können über Bootstrap-Widerstände vorkonfiguriert werden. Wenn Du Dir das dazugehörige Datenblatt und die Evalboards anschaust, siehst Du wie das geht. Gleichzeitig können die Bausteine über das (R)MII zur Laufzeit umkonfiguriert werden. Die mir bekannten Ethernet/IP-Stacks für den STM erfordern häufig höchstens eine Anpassung der PHY-ID. Wenn das Bootstrapping passt, läuft der IP-Stack meist sofort problemlos. Schnapp Dir doch eines der vielen webserver-Beispiele und setze einen Breakpoint auf die Webserver-Config. Dann einfach einmal die komplette Config durchsteppen und Du weißt was Sache ist. Grüße, Marcus
Marcus H. schrieb: > Hi Martin, > zumindest die von mir genannten PHYs können über Bootstrap-Widerstände > vorkonfiguriert werden. Wenn Du Dir das dazugehörige Datenblatt und die > Evalboards anschaust, siehst Du wie das geht. > Gleichzeitig können die Bausteine über das (R)MII zur Laufzeit > umkonfiguriert werden. > > Die mir bekannten Ethernet/IP-Stacks für den STM erfordern häufig > höchstens eine Anpassung der PHY-ID. Wenn das Bootstrapping passt, läuft > der IP-Stack meist sofort problemlos. > > Schnapp Dir doch eines der vielen webserver-Beispiele und setze einen > Breakpoint auf die Webserver-Config. Dann einfach einmal die komplette > Config durchsteppen und Du weißt was Sache ist. > > Grüße, > Marcus Hallo Marcus, Danke für die Antwort. Ich habe auf einem anderen Board bereits einen 8 Port Gigabit Switch am laufen, der über RMII am STM32 hängt. Das Konzept ist mir also bekannt, sie Sourcecodes dafür kann ich auch weiter nutzen. Mir ging es speziell um den KSZ8863MLL und dessen Beschreibung im Datenblatt in Richtung „MAC Mode“ und „PHY Mode“ die mich durcheinander brachte. So wie sehe starte der Baustein ohne weitere Beschaltung im PHY-Mode. Das hiesse für mich: Er ist direkt über die MII Schnittstelle als PHY vom STM32 nutzbar und muss nicht weiter eingestellt werden - zumindest würde das Sinn ergeben (er hätte jasonst gleich 3 interne PHYs) und ist genau das was ich brauche. Wenn ich ihn andererseits als 3 Port Switch nutzen wollte, dann müsste an den dritten Port über MII ein externer PHY angeschlossen werden und der Switch müsste über Befehle (SPI/SMI) oder einen angeschlossenen EEProm (für Standalone Betrieb) extra so konfiguriert werden. Kannst Du das so bestätigen? Dann hätte ich den Konten endlich aus meinem Kopf raus… Danke und Gruß Martin
Yo Martin, ich denke Du siehst das richtig. Das Datenblatt ist Dein Froind, sind doch nur 107 Seiten... :) Die KSZ8863 hat drei MACs und zwei PHYs am Switch. Die PHY-lose MAC spricht per RMII mit dem STM32. Für die Serie brauchen wir kein EEPROM, wird alles per Bootstrapping erledigt. Ich hatte am Anfang etwas Probleme mit dem Taktsystem, deswegen habe ich das Eval-Board hier liegen. Die Main-PLL des STM32F407 jittert anscheinend zu stark, deswegen bekommt der KSZ einen Quarzgenerator, der dann auch das RMII zum STM32 taktet. Und Micrel empfiehlt dringend die aufwändige Reset-Logik mit dem großen Kappa - die lange Rampe auf der Reset-Leitung ist notwendig, um nacheinander die einzelnen Subsysteme im KSZ zu starten. Aber wie auch immer, die CE/UL war kein Problem und die Boards fallen seit einem halben Jahr problemlos vom Fließband. Grüße, Marcus
H. R. schrieb: > Hi > Weiss jemand was hier PHY-ID sein soll? 1.) Machstdu fuer neues Problem neuen Thread auf 2.) Guggstu in ECMA-369.pdf ; Annex B Gruss WK
Danke für den Link, aber das ist ja ein sehr ähnliches Problem. Was ich noch nicht verstehe: in context von Ethernet, wo taucht da PHY-ID auf? und warum finde ich in Datasheet von LAN8742A kein PHY-ID?
:
Bearbeitet durch User
Moin, H. R. schrieb: > Was ich noch nicht verstehe: in context von Ethernet, wo taucht da > PHY-ID auf? Das ist vielleicht fuer einen Treiber interessant, der ggf. bei verschiedenen PHYs verschiedene Gimmicks verwenden will/kann/... Fuer die eigentliche Datenuebertragung via Ethernet kratzt das wohl keinen. H. R. schrieb: > und warum finde ich in Datasheet von LAN8742A kein PHY-ID? Weil du nicht genau genug guckst? Vielleicht auf Seite 61/62? Gruss WK
Das ist sogar im Datenblatt des LAN8742A erstaunlich gut erklärt. Außerdem schreibst Du hier im falschen Thread.
>> Was ich noch nicht verstehe: in context von Ethernet, wo taucht da >> PHY-ID auf? Im Ethernetcontext gibt es keine. > Das ist vielleicht fuer einen Treiber interessant, der ggf. bei > verschiedenen PHYs verschiedene Gimmicks verwenden will Nur mit der richtigen PHY-ID tut es.
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.