STM32F103C8T6 Blue Pill übertakten

00Z schrieb:
> Wie man den STM über den externen Oszi übertaktet steht im Internet,

Da ist es gut aufgehoben.
Du solltest Dir schon die Mühe machen, es selber zu verstehen. Dann 
erübrigt sich auch Deine Frage.

Ich will lediglich wissen ob es eine Möglichketi gibt dieses Übertakten 
auch
mit dem internalen (HSI) Oszillator hinzu kriegen, habe auch etliches 
schon versucht an der PLL zu drehen z.B. den PLL Multi über 16 zu 
erhöhen, nur das funktioniert schon beim Compillieren nicht.

00Z schrieb:
> Ich will lediglich wissen ob es eine Möglichketi gibt dieses
> Übertakten auch mit dem internalen (HSI) Oszillator hinzu kriegen

Sicher geht das. Einfach die PLL entsprechend einstellen. Dazu liest Du 
Dir mal das Refman durch und kalkulierst, welche der Register Du wie 
einstellen mußt.

Ich würde empfehlen, direkt danach irgendeine Testroutine zu haben, die 
einige Laufzeit hat und ein bekanntes Ergebnis berechnen soll.

HSI gibt es nur über Teiler 2 = 4MHz als PLL Quelle.

PLL Multiplikator hat nur 4 Bit, also maximal 16 x 4MHz = 64MHz.

Versuchsweise würde ich die PLL auf maximalen Wert stellen und dann 
mittels eines extern angeschlossenem Funktiongenerator oder vergleichbar 
die Frequenz solange erhöhen bis sich eine Änderung ergibt. Z.B 4MHz x16 
= 64MHz. 6Mhz x16 = 96MHz, insofern der PLL Oszillator sich noch 
einrasten läßt.

Allerdings kann so eine Vorgehensweise unerwartete Konsequenzen haben. 
Generell sollte man die Datenblattgrenzwerte niemals aus trivialen 
Gründen übersteigen und dabei genau wissen man tut und hat deswegen eher 
akademisches Interesse. Da der Hersteller bekanntlich seine Angaben 
sorgfältig und mit genug Margen angibt, dürften da höchstwahrscheinlich 
noch gewisse Reserven drinn sein. Bekanntlich erhöht Abkühlung übrigens 
die obere Frequenzgrenze von CMOS. Wenn Z.B bei Zimmertemperatur noch 
96MHz möglich sind, ist das bei 85 oder 105 Grad Die-Temperatur 
höchstwahrscheinlich nicht mehr der Fall.

Es fragt sich aber ob das wirklich viel praktischen Wert hat. Wenn die 
Leistung nicht ausreicht, könnte man durch efizientere Algorithmen oder 
Wahl einer schnelleren Prozessorversion möglicherweise mehr erreichen.

You are on your own, Buddy!

Versuch macht kluuch;-)

Hier ging es ja um HSI.
Mit HSE 8MHz Quarz habe ich schon mal eine Testreihe gemacht.

96MHZ - kein Problem
104MHz - auch noch in Ordnung, keine Ahnung ob intern noch alles läuft, 
Blinky hat jedenfalls korrekt funktioniert

Erst bei 112MHz bekam die PLL das flattern.

Ich hatte das mal ausprobiert. Bei etwa 100 MHz war Schuss, das stürzte 
er alle paar Sekunden ab.

Also wenn 72 MHz regulär gehen und 100 Mhz schon zu viel sind, dann sehe 
ich im Übertakten keinen praktischen Nutzen. Ganz im Gegenteil, nach 
dieser Erfahrung nutze ich sie immer mit 48 oder 64 MHz.

Laut dem hier:https://www.youtube.com/watch?v=mhAeHdbLDMU
Müsste man aus dem STM noch mehr als nur 100 Mhz rausholen können, der 
hat
angeblich 128mhz stabil geschafft, vielleicht geht da auch noch mehr, 
immerhin
gibt es ja STMs die um die 400 Mhz ab Werk schaffen, auch wenn die eine 
ganz
andere Architektur haben. Dass man das nur zu Versuchszwecken nutzen 
kann, ist klar, immerhin besteht immer die Gefahr dass der Chip 
irgendwas tut, was ihm
nie einer angeschafft hat, und wenn sowas dann noch bei 
"sicherheitskritischen" Anwendungen passiert, wäre das nicht so toll. 
Bei meinen Versuchen geht es aber nur um reines Probieren. Aber pegel 
hat es ja schon gesagt, weiter hoch mit dem HSI ist nicht, da 16 und ein 
Teiler beim HSI von 2 das Maximum sind. Hab auch schon mal versucht 
RCC_PLLSOURCE_HSI_NODIV;
Aber das funktioniert nicht, Multiu ist bei 16 auch Schluss, also hilft 
nurnoch externer Oszillator. Oder das letzte was mir noch einfällt, die 
HSI Calibration Value zo erhöhen und damit den internen Oszi selbst zu 
übertakten, aber dabei werden dann gerade an solchen Sachen wie UART 
usw. ziemlich seltsame Baudraten rauskommen.

00Z schrieb:
> immerhin gibt es ja STMs die um die 400 Mhz ab Werk schaffen,
> auch wenn die eine ganz andere Architektur haben

Die kannst du nicht miteinander vergleichen, eben wegen der ganz anderen 
Architektur. Der Flash Speicher ist da das engste Nadelöhr.

Jap leider, mich würde ja mal interessieren was diese TSMC "Super 
Prozessoren" die beim Ami dann mit 3nm Strukturbreite gefertigt werden 
sollen wohl für einen Takt erreichen können, immerhin gilt ja kleinere 
Transistoren=höherer Takt. Wie alt ist eigentlich der STM32F103 schon? 
Wenn man wirklich z.B. ein Steuergerät aufmotzen will, wird man wohl zur 
Heißluftpisotle greifen müssen.
Hab mir auch mal aus Spaß ein Bosche Ebike von innen angesehen, warum 
nehmen die eigentlich 8 Bit Prozessoren, wenn selbst die 
Chinesencontroller schon bei 32Bit sind? Heißt es nicht dass je 
schneller und genauer der Chip ist, auch die Effizienz steigt? Dann 
würde ja alles dafür stehen dass man in ein 3000€ Ebike einen 32 Bit 
Controller baut, oder sind die bei Bosch super gute Assembler 
Programmierer, oder haben die so gute Compiler dass der Code so 
wahnsinnig effizient ist?

00Z schrieb:
> Wie alt ist eigentlich der STM32F103 schon?

13 Jahre

00Z schrieb:
> warum nehmen die eigentlich 8 Bit Prozessoren, wenn selbst
> die Chinesencontroller schon bei 32Bit sind?

Vermutlich weil sie ausreichen und die Entwickler damit gut vertraut 
sind.

> Heißt es nicht dass je schneller und genauer der Chip ist,
> auch die Effizienz steigt?

Welche Effizienz? Fährt das Fahrrad damit schneller oder länger? Wohl 
kaum.

> oder haben die so gute Compiler dass der Code so
> wahnsinnig effizient ist?

Das spielt doch überhaupt keine Rolle! Meinst du, eine Kaffeemaschine 
mit AMZ Ryzen 5 macht besseren Kaffee, als die Italienische 
Dampfmaschine?

Vergiss nicht, dass der Mensch mit 8bit Prozessoren zum Mond und wieder 
zurück geflogen ist. Wenn das dafür reicht, dann wohl auch für ein 
Fahrrad, sollte man annehmen dürfen.

Naja, Boschräder sollen angeblich kein echtes FOC können, mit 8Bit zum 
Mond
ist ja schön, nur die Rechenaufgaben sind inzwischen wohl deutlich 
komplexer geworden, und da geht es um Effizienz. Je "Besser" ich den 
BLDC ansteuern kann, desto effizienter ist er auch. Dass der STM32F103 
schon 13 Jahre alt ist, erschreckt mich, ich hab zwar erwartet dass der 
schon nichtmehr der neueste ist, aber dass er so alt ist wusste ich 
nicht. Ich hätte gerne mal einen BDLC Controller gebaut der so richtig 
effizient ist, aber da scheiterts an der Rechenleistung, das gibt der 
STM32F103 nicht her. Also müsste man einen anderen STM32 finden, der im 
TQFP 48 daher kommt, und richtig power hat. Was ist denn der schnellste 
Chip von ST den es in QFP 48 gibt?

00Z schrieb:
> mit 8Bit zum Mond
> ist ja schön, nur die Rechenaufgaben sind inzwischen wohl deutlich
> komplexer geworden, und da geht es um Effizienz. Je "Besser" ich den
> BLDC ansteuern kann, desto effizienter ist er auch.

Das mag ja sein, aber die Idee, dass mehr Rechenleistung automatisch 
auch mehr Effizienz bringt, ist schon ziemlich niedlich. Da müsste eine 
Aufrüstung mit AMD Ryzen 5 das Fahrrad ja zum Motorrad machen.

Nicht automatisch, nur wenn es eine effizientere Möglichkeit gibt, den 
Motor
zu steueren, die aber in ihrer Rechenintensität die Möglichkeiten des 
betreffenden Controllers übersteigt, dann lässt sich die Effizienz wohl 
um ein Paar prozent steigern, wobei das generell für Effizioenz geltende 
Naturgesetz zum Tragen kommt: 10% mehr Effizienz bedeuten 100% mehr 
Aufwand und: Je weiter man der 100% Marke kommt desto schwiriger und 
Aufwendiger wird jede weitere Annäherung an 100%. Wobei 100% Niemals 
erreicht werden können.

00Z schrieb:
> Ich hätte gerne mal einen BDLC Controller gebaut der so richtig
> effizient ist, aber da scheiterts an der Rechenleistung, das gibt der
> STM32F103 nicht her.

Das ist nicht korrekt.

Habe in 2014 einen BLDC Regler mit 700 Watt selbst aufgebaut,
mit einem solchen STM32F103.

Und er hatte dann immer noch Reserven, um die Kommunikation mit einem 
Display herstellen zu können.

Markus