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 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 ???
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.
>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.
> 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.
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
