Hi, wenn ich mir den Schaltplan des Eval-Boards für den STM32H7 von ST ansehe, dann ist dort ein 25-MHz-Oszillator verbaut, der einmal mit dem Ethernet-Chip des Boards verbunden ist und einmal mit dem PH0-OSC_IN-Pin des STM selber. Um den STM zu takten, benötige ich diesen exernen Clock nicht, der lässt sich so konfigurieren, dass alle Clocks intern erzeugt werden. Das führt mich zu meiner Frage: kann ich dann auf einer eigenen Hardware nicht auch den PH1-OSC_OUT verwenden, um den Ethernet-Chip damit zu füttern? Sprich könnte der Quarz nicht komplett wegfallen, wenn ich PH1-OSC_OUT mit CLKIN des LAN8742A verbinde und PH1-OSC_OUT so konfiguriere, dass dort 25 MHz geliefert werden? Oder ist dieser Clock zu ungenau? Danke!
LAN8742A: "The device can accept either a 25 MHz crystal or a 25 MHz single-ended clock oscillator (±50ppm) input." Wie bekommt man diese Genauigkeit mit den internen Oszillatoren und PLLs eines H7 ohne Quarz hin?
1 | To comply with the IEEE 802.3 standard, each Ethernet node must have |
2 | a reference clock with accuracy of ±100 parts per million (ppm). |
Texas Instruments SNLA290 "Selection and specification of crystals for Texas Instruments ethernet physical layer transceivers" Also die STM32 HSI schaffen das nicht. So ein kompletter externer Quarzoszillator ist schon praktisch und pflegeleicht. In diesem speziellen Fall könnte man den nur für Ethernet verwenden und den STM32 intern takten. Eine 25-MHz-Leiterbahn weniger... Unabhängig davon: alle STM32 können diverse Taktsignal über den MCO-Pin ausgeben; man muss nicht den OSC_OUT missbrauchen.
Chris schrieb: > Oder ist dieser Clock zu ungenau? Der von einem MCO oder einem internen RC-Oszillator gelieferte Takt ist zu ungenau. Beim MCO gilt das insbesondere, wenn nicht ganzzahlige Teiler oder eine PLL verwendet wird. Das haben hier schon andere Leute versucht, funktioniert nicht. fchk
Bauform B. schrieb: > Also die STM32 HSI schaffen das nicht. So ein kompletter externer > Quarzoszillator ist schon praktisch und pflegeleicht. In diesem > speziellen Fall könnte man den nur für Ethernet verwenden und den STM32 > intern takten. Eine 25-MHz-Leiterbahn weniger... Klingt gut. Was wäre denn ein passender Quarz? Die Beschreibung des LAN-Chips redet von einer 100 uW und einer 300 uW-Variante, die verwendet werden kann, ohne klar zu spezifizieren, wann welche der beiden Varianten zu wählen ist...
Bauform B. schrieb: > Also die STM32 HSI schaffen das nicht. So ein kompletter externer > Quarzoszillator ist schon praktisch und pflegeleicht. In diesem > speziellen Fall könnte man den nur für Ethernet verwenden und den STM32 > intern takten. So isses. Beitrag "STM32F107RBT6 Ethernet Clock"
Chris schrieb: > wenn ich mir den Schaltplan des Eval-Boards für den STM32H7 von ST > ansehe, dann ist dort ein 25-MHz-Oszillator verbaut Neben der Erkenntnis dass man beim Thema Referenztakt für den PHY durchaus so päpstlich sein sollte wie der Papst, stellt sich für mich noch die Frage ob dir schon bekannt ist dass sich schon manche Leute an der LwIP-Implementierung für den STM32H7 schon die Zähne ausgebissen haben. Aus meiner Erfahrung tut man sich beim STM32F407 und STM32F429 wesentlich leichter als beim STM32H7. Diese Controller funktionieren auf Anhieb. Wobei es scheinbar schon verschiedenene Chip-Versionen vom STM32H743 gibt die sich unterschiedlich kapriziös bezüglich Ethernet verhalten. Finde leider gerade den Thread nicht der hier auf uC.net die Probleme mit dem STM32H743 und LwIP behandelt. Vielleicht kann einer der Mitleser noch den Thread hier verlinken.
Wastl schrieb: > ob dir schon bekannt ist dass > sich schon manche Leute an der LwIP-Implementierung für > den STM32H7 schon die Zähne ausgebissen haben. CubeMX liefert eine fertige LwIP-Implementierung für den STM32H7. also wo ist das Problem?
Chris schrieb: > CubeMX liefert eine fertige LwIP-Implementierung für den STM32H7. also > wo ist das Problem? Dass die Implementierung nicht (reibungslos) funktioniert. Wenn du lieber erst mal das (nicht funktionierende) Rad neu erfinden willst dann, dann mach das. Natürlich bietet CubeMX eine Default-Implementierung an. Meinst du ich wäre so blau-äugig das nicht zu wissen bzw. nicht vorauszusetzen? YMMV. Aber: Wastl schrieb: > Finde leider gerade den Thread nicht der hier auf uC.net die > Probleme mit dem STM32H743 und LwIP behandelt. Vielleicht > kann einer der Mitleser noch den Thread hier verlinken.
Wastl schrieb: > Dass die Implementierung nicht (reibungslos) funktioniert. OK, ich habe es eben mal schnell auf dem Eval-Board probiert: lwIP klappt problemlos mit dem LAN8742A auf dem STM32H7. Also ohne genau zu wissen, WAS da in diesem Posting gestanden hat, ist diese Aussage so alleine eher nutzlos.
Chris schrieb: > lwIP klappt problemlos mit dem LAN8742A auf dem STM32H7. Was hast du denn an Funktionen überprüft?
Chris schrieb: > lwIP klappt problemlos mit dem LAN8742A auf dem STM32H7 Was hast du denn an Funktionen überprüft? Welche Funktionen, welche Version des Eval-Boards und welche Chip-version des H7? Wastl schrieb: > Wobei es scheinbar schon verschiedenene > Chip-Versionen vom STM32H743 gibt die sich unterschiedlich > kapriziös bezüglich Ethernet verhalten.
Ich habe das STM32H753I-EVAL-Board mit dem STM32H753XI drauf - und probiert habe ich DHCP sowie Zugriffe per HTTPD. Also ein TCP/IP Socket. Funktioniert. Statische IP geht auch.
Chris schrieb: > Ich habe das STM32H753I-EVAL-Board mit dem STM32H753XI drauf Ja ja, die Salami-Taktik mal wieder. Erst seit jetzt wissen wir welchen H7 du benutzt. Hier mal eine detailliertere Abhandlung zum H743. Beitrag "STM32 NUCLEO H743ZI - Ethernet / WebServer-Probleme" Beitrag "Re: STM32 NUCLEO H743ZI - Ethernet / WebServer-Probleme"
Wastl schrieb: > Ja ja, die Salami-Taktik mal wieder. Erst seit jetzt wissen > wir welchen H7 du benutzt. Nein, es stand schon im allerersten Posting ,dass ich vom Eval-Board rede.
Chris schrieb: > Nein, es stand schon im allerersten Posting ,dass ich vom Eval-Board > rede. Ja, schon klar. Es gibt ja nur ein H7 Eval-Board.
Wastl schrieb: > Beitrag "STM32 NUCLEO H743ZI - Ethernet / WebServer-Probleme" > Beitrag "Re: STM32 NUCLEO H743ZI - Ethernet / WebServer-Probleme" Und was hat das jetzt alles genau mit mir zu tun? Die haben lwIP-Probleme mit einer lwIP-Implementierung aus irgend einer dubiosen Quelle. CubeMX-Probleme gibt es da nur beim COMPILIEREN - und die habe ich ja ganz offensichtlich nicht, da ich passenden Code problemlos erzeugen kann.
Chris schrieb: > Die haben > lwIP-Probleme mit einer lwIP-Implementierung aus irgend einer dubiosen > Quelle. Nö.
Ist https://github.com/windsorschmidt/stm32h7-nucleo-h743zi-ethernet-lwip CubeMX? Nein. Ist "es gibt Probleme mit lwIP" eine Antwort auf meine Frage nach dem Ethernet-Hardwareclock? Nein. Die gesamte Diskussion zum Schluss kann man also knapp zusammenfassen: Zeitverschwendung.
Chris schrieb: > Die gesamte Diskussion zum Schluss kann man also knapp zusammenfassen: Deine Frage "PH1-OSC_OUT als Clock für Ethernet verwenden?" kannst du dir dann also selbst mit "ja" beantworten.
Wastl schrieb: > Deine Frage "PH1-OSC_OUT als Clock für Ethernet verwenden?" > kannst du dir dann also selbst mit "ja" beantworten. Nein, konnte ich nicht, aber "es gibt Probleme mit lwIP" ist keine Antwort auf diese Frage! Du merkst das wirklich nicht, oder?
Frank K. schrieb: > Chris schrieb: > >> Oder ist dieser Clock zu ungenau? > > Der von einem MCO oder einem internen RC-Oszillator gelieferte Takt ist > zu ungenau. Beim MCO gilt das insbesondere, wenn nicht ganzzahlige > Teiler oder eine PLL verwendet wird. Das haben hier schon andere Leute > versucht, funktioniert nicht. > > fchk Wen du den H7 mit einem externen 25Mhz Quarz betreibst und den MCO auf den HSE Oszillator schaltest ist der Ausgang nicht ungenauer wie der Quarz. Bei den Nucleo Boards kann es Probleme geben, das liegt aber nicht an der PLL oder den MCO Ausgängen, sondern am STLINK der den externen Takt für die MCU erzeugt.
Hans-Georg L. schrieb: > Wen du den H7 mit einem externen 25Mhz Quarz betreibst und den MCO auf > den HSE Oszillator schaltest ist der Ausgang nicht ungenauer wie der > Quarz. Was aber nicht so viel bringt, weil man sich auf diese Weise den Quarz eben nicht spart!? Allerdings könnte das ein Hack sein, um eine Leitung auf dem Board zu sparen, so fern der MC0-Ausgang näher am LAN-Chip liegt als der Quarz.
Chris schrieb: > so fern der MC0-Ausgang näher am LAN-Chip liegt als der Quarz. du möchtest aber den LAN-Chip nicht direkt am Quarz anschließen. Oder meinst du mit "Quarz" immer "externer Quarz-Oszillator"? Das ist mir ein paar Beiträge vorher schon aufgefallen.
Hans-Georg L. schrieb: > Frank K. schrieb: >> Chris schrieb: >> >>> Oder ist dieser Clock zu ungenau? >> >> Der von einem MCO oder einem internen RC-Oszillator gelieferte Takt ist >> zu ungenau. Beim MCO gilt das insbesondere, wenn nicht ganzzahlige >> Teiler oder eine PLL verwendet wird. Das haben hier schon andere Leute >> versucht, funktioniert nicht. >> >> fchk > > Wen du den H7 mit einem externen 25Mhz Quarz betreibst und den MCO auf > den HSE Oszillator schaltest ist der Ausgang nicht ungenauer wie der > Quarz. Bei den Nucleo Boards kann es Probleme geben, das liegt aber > nicht an der PLL oder den MCO Ausgängen, sondern am STLINK der den > externen Takt für die MCU erzeugt. Das ist eine der wenigen Konfigurationen, die funktioniert. Gegenüber einem externen Quarzoszillator hast Du damit aber nichts gewonnen. fchk
Bauform B. schrieb: > du möchtest aber den LAN-Chip nicht direkt am Quarz anschließen. Doch, das hat ST in seinem Eval-Board auch so gemacht. Da ist lediglich ein 100-Ohm-Widerstand dazwischen...
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.