Hallo, ich spiele gerade mit meinem STM32 rum. Gerade habe ich die PLL derart umkonfiguriert, so dass dieser jetzt statt mit 24MHz jetzt auf 56MHz läuft. Weiter hoch ging es leider nicht. Der Controller hat sich dann aufgehängt. Hat jemand Erfahrung damit. Läuft der STM32 übertaktet stabil? Wie ist es mit der Peripherie? Läuft diese dann auch schneller, z.B. AD-Wandler? Wäre für Infos dankbar. Achso, gibt es eigentlich einen PIN auf dem man den internen Takt nach aussen legen kann? Danke und Gruß, H
Was soll das ? Eine CPU muss zuverlaessig laufen, nicht unbedingt schnell. Ich wuerd ne andere CPU nehmen, die den passenden Dampf hat.
Was der Hersteller in seine Datenblätter schreibt, muss nicht die wirkliche Tatsache sein. Atmel-Mitarbeiter bestätigen beispielsweise privat eine 100%ige Stabilität bei 20 Mhz-Betrieb von Atmega32-16. Beim STM32 wird es ähnlich sein.
A...aha Soooo. schrieb: > Was soll das ? Eine CPU muss zuverlaessig laufen, nicht unbedingt > schnell. Ich wuerd ne andere CPU nehmen, die den passenden Dampf hat. Wann werden es die Leute endlich kapieren. EIN MICROCONTROLLER IST KEIN CPU ! Herrgott man kann doch Huhn und Ei auch auseinanderhalten oder verwechselt ihr das auch permanent ???
Hört mal. Ich brauch hier keine Klugscheisserei. Bei solchen Kommentaren sag ich einfach auf wiedersehen.
Wenn du die Frequenz der PLL erhöhst muss beim STM32 nicht alles schneller laufen. Schau dir mal den Clock Tree im Datenblatt an, der beschreibt wie die verschiedenen Clock Signale zusammenhängen. Da siehst du auch den MCO Pin, an dem verschiedene Clocks ausgegeben werden können. Warum willst du einen STM32 mit max. 24 MHz übertakten, wenn es auch Versionen bis 72 Mhz gibt? Zwar wird die 24 MHz Version auch ein wenig schneller noch laufen, aber wie zuverlässig das ist weiß man nicht.
Hallo, ja das mit dem MCO-Pin habe ich heraus gefunden. Ich habe den Controller übertaktet, damit ich mal ein Gefühl dafür bekomme, wieviel schnell sein Bruder mit dem 72MHz sein würde. Bisher bin ich ziemlich begeistert von diesem Controller. Für ein professionelle Anwendung würde ich das nicht machen, aber zum spielen schon. Ich habe hier einen ziemlich komplexen Algorithmus laufen und das Ding hat sich bisher noch nicht verschluckt. Außerdem sieht man dann auch mal mit was für Sicherheitsfaktoren die Core-Entwickler arbeiten. Außerdem kann es auch gut sein, dass die uCs bewüsst aus marktwirtschaftlichen Gründen runter getakten sind bzw. für einen niedrigen Takt spezifiziert wurden, damit sich ein höherer Preis bei den Schnelleren rechtfertigt.
Nebenbei: Ich habe gerade über die Suchmaschine einen Artikel gefunden, wo angeblich ein STM32 mit 72MHz auf 225 (!)MHz erfolgreich übertaktet wurde.
>Außerdem kann es auch gut sein, dass die uCs >bewüsst aus marktwirtschaftlichen Gründen runter getakten sind Könnte, hätte, wollte, müsste... Alles Spekulation. Wenn du willst dann übertakte ihn. Und leb mit den Nebenwirkungen.
Harald schrieb: > Hört mal. Ich brauch hier keine Klugscheisserei. Bei solchen Kommentaren > sag ich einfach auf wiedersehen. der charakterlich schwach anmutende "Lehrmann" ist für derartige Kommentare bekannt, ist eine Person die gerne auch mal mit sinnlosen und völlig falschen Gesetzeszitaten umsichwirft, bemitleidensert.
ST verkauft eine CPU mit einem Temperaturbereich von Minus xxx °C bis Plus xxx °C. Dabei muss die CPU garantiert mit 72MHz laufen. Es ist also gut möglich dass bei Zimmertemperatur deutlich mehr drin ist, aber sicher nicht über den gesammten Temperaturbereich, bzw. man muss den erlaubten Temperaturbereich herabsetzen. Übrigends lasse ich meinen STM32 meist mit nur 8MHz ohne PLL laufen, das reicht für meine Programme in der Regel und spart Strom.
Harald schrieb: > Weiter hoch ging es leider nicht. Der Controller hat sich dann aufgehängt. Hattest du dabei das Thema Flash-Waistates auf der Rechnung? Das Flash ist nämlich die wahrscheinlichste Bremse.
Man könnte das Programm aus dem Flash ins RAM kopieren, dann im RAM geht's weiter und übertaktet die CPU. Dann braucht der keinen Flash Zugriff mehr.
Klar, aber ich habe eher den Verdacht, dass er unfreiwillig ausprobiert hat, wie weit er ohne Flash-Waitstate kommt, weil er nicht daran gedacht hat.
> wie weit er ohne Flash-Waitstate kommt, weil er nicht daran gedacht > hat. stimmt. Daran hab ich wirklich nicht gedacht, obwohl ich erst vor kurzen eine Diskussion über den Flaschenhals verfolgt habe.
@A. K. Ich habe jetzt zwei Waitstates (mehr geht nicht) eingestellt. Leider ist trotzdem bei 56MHz Schluss.
Hallo, also mein STM32F103ZE6 läuft mit 120 MHz! Benutzt wird einfach ein multiplier von 10 (bei einem 12 MHz Qurz). Soweit ich das sagen kann läuft alles sabil und warm wird da nicht viel. Da Produziert die Hintergrundbeleuchtung von einem 4.3" deutlich mehr Hitze! Also für kritische sachen wüde ich es trotz allem nicht empfehlen, möchte jemand aber just for fun eine schnellere CPU, ist das eine recht einfache Methode!
Harald schrieb: > Ich habe jetzt zwei Waitstates (mehr geht nicht) eingestellt. Leider ist > trotzdem bei 56MHz Schluss. Prüf mal nach ob diese Einstellung überhaupt greift. Müsste sich beispielsweise bei der Laufzeit einer 2-Befehls-Schleife 1: subs rx,rx,#1 bne 1b spürbar auswirken.
Ich habe inzwischen auch gelesen, dass das mit dem 103er problemlos geht. Ich vermute, das A.K. mit dem Flash recht hat. Möglicherweise ist bei denen ein schnellerer Flash drin. Aber zum spielen reicht mir das hier auch eigentlich. Gegen die STM32 und auch STM8 sehen die Mega AVRs erstmal alt aus. Aber der Vergleich ist auch nicht fair.
Ich bin ziemlich sicher, dass die Dies alle vom selben Waver stammen. In der Fertigung werden sie dann geprüft, und entsprechend dem Ergebnis auf die eine oder andere maximale Frequenz eingestuft. Da kann der Hersteller dann noch ein bischen mischen, z. B. 72MHz-Typen als 20MHz-Typen labeln etc. Damit er von allen Sorten ausreichend hat. Ich schätze, so wird es gemacht. Stephan.
> Prüf mal nach ob diese Einstellung überhaupt greift.
Meinst Du, dass ich möglicherweise die Einstellung an der falschen
Stelle vornehme? Also compiliert wird die Einstellung. Ich habe extra
einen Fehler eine Zeile später eingebaut um zu sehen, ob der Compiler es
auch mit compiliert.
Harald schrieb: >> Prüf mal nach ob diese Einstellung überhaupt greift. > Meinst Du, dass ich möglicherweise die Einstellung an der falschen > Stelle vornehme? Wäre immerhin denkbar, dass ST beim Ein"brennen" des exakten Modells eine Sperre eingebaut hat. So dass das Register zwar existiert, aber nicht greift.
Stephan schrieb: > Ich bin ziemlich sicher, dass die Dies alle vom selben Waver stammen. In > der Fertigung werden sie dann geprüft, und entsprechend dem Ergebnis auf > die eine oder andere maximale Frequenz eingestuft. Das sind keine PC-Prozessoren. Da die Fertigungstechnik solcher Bausteine schon etwas älter und dementsprechend eingefahren ist, tippe ich eher darauf, dass entsprechend dem nach aktuellem Bedarf eingestellten Fertigungsprofil getestet wird und der Ausschuss im Müll landet. Die reine Fertigung des Dies ist anteilig nicht so arg teuer und das dürfte logistisch einfacher sein und eine einfachere Testprozedur erfordern als ein Rebinning der wenigen Dies, die dadurch geretten würden.
Hm. Tatsächlich. Im Debugger kann ich das Register FLASH_ACR_LATENCY beobachten. Egal was ich einstelle es bleibt auf null. Ich hatte auch vermutet, dass die PLL vielleicht nicht mehr einrastet. Dann ist dieses Register irgendwie nur Read-Only.
Um welchen Typ geht es eigentlich? Die F101 Typen aufwärts gibt es m.W. nur ab 36MHz, ein offizielles 24MHz Limit spricht also für die F100 Reihe und da sind diese Bits als "reserved" dokumentiert.
Stephan schrieb: > Ich bin ziemlich sicher, dass die Dies alle vom selben Waver stammen. Für die Typen 101-103 dürfte das zutreffen, die 101 und 102 sind niedriger getaktete Subsets der 103er und wohl intern die gleichen Chips, lediglich unterschieden in 4 Varianten von Speicherkapazität (32/128/512/1024) und Pincount (64/100/144/144). Die 100er, die es nur als 24MHz Typen gibt, sind jedoch kein Subset (CEC/HDMI-Schnittstelle), d.h. die sind technisch verschieden.
Ein paar Kommentare zu diesem Thread. 1. Uebertakten geht meistens und auch irgendwann schief. 2. Bitte gleich zu Beginn den genauen Typen angeben, also F101, F103... erspart viele unnuetze Beitraege. 3. Fuer "reserved" bits gibts zwei generelle Moeglichkeiten. 3a. Im Abschlusstest beim Hersteller werden die fix auf einen Wert geschrieben ohne Aenderungsmoeglichkeit 3b. Die sind tatsaechlich nicht implementiert Version 3a ist viel wahrscheinlicher 4. Beim Uebertakten wird meist nur die CPU mit Speicherzugriff auf Zuverlaessigkeit getestet. Die Peripherie kann genausogut bei hoeherem Takt ploetzlich merkwuerdige Dinge machen. 5. Das Argument mit Spezifikation bei hoher Temperatur ist sicher richtig, allerdings lassen sich damit nur ein paar Prozent Leistungssteigerung herauskitzeln. Also ein 125C Typ der mit 72 MHz spezifiziert ist und dort "gerade noch" zuverlaessig laeuft, laesst sich locker bei 25C mit 75 MHz betrieben, wahrscheinlich auch bei 80 MHz aber sicher nicht bei 100 MHz. A.K. hat auch recht mit dem binning (Datum: 14.11.2010 10:10). Bei MCUs wird in aller regel kein binning gemacht, d.h. was bei 72 MHz durchfaellt, fliegt in den Muell, nicht in den 24 MHz Korb. Testzeit und logistischer Aufwand sind ein signifikanter Bestandteil des Endkundenpreises. Gruss, Robert
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.