Im normalen Modus sind bis zu 150 MHz möglich. Ist es Ratsam, bis an diese Grenze zu gehen? Im boost Modus sind bis zu 170 MHz möglich. Ist es Ratsam, dem boost Modus dauerhaft zu benutzen? Ich frage, weil ich bisher aus Gewohnheit immer deutlich unter dem Limit geblieben bin, und Dinge wie "boost mode" (ST nennt es auch "overvolting") noch nie bewusst benutzt habe. Nun sehe ich allerdings, dass der Arduino Core die 170 MHz dauerhaft vorgibt. Sind dabei Probleme zu erwarten, oder bin ich zu ängstlich?
Nemopuk schrieb: > Sind dabei Probleme zu erwarten, oder bin ich zu ängstlich? Meiner Einschätzung nach solltest du dir immer einen Airbag umschnallen wenn du vor die Haustür gehst. Man weiss ja nie. Und die Arduino Leute wissen auch nicht was sie tun, sie lesen ja nicht mal die Datenblätter.
Nemopuk schrieb: > Im normalen Modus sind bis zu 150 MHz möglich. Ist es Ratsam, bis an > diese Grenze zu gehen? > > Im boost Modus sind bis zu 170 MHz möglich. Ist es Ratsam, dem boost > Modus dauerhaft zu benutzen? > > Ich frage, weil ich bisher aus Gewohnheit immer deutlich unter dem Limit > geblieben bin, und Dinge wie "boost mode" (ST nennt es auch > "overvolting") noch nie bewusst benutzt habe. Nun sehe ich allerdings, > dass der Arduino Core die 170 MHz dauerhaft vorgibt. Sind dabei Probleme > zu erwarten, oder bin ich zu ängstlich? Lies nochmal genau das Datenblatt "boost" bezieht sich nicht auf die Frequenz sondern wie du deinen main regulator abhängig von der Frequenz einstellen musst.
Hans-Georg L. schrieb: > Lies nochmal genau das Datenblatt "boost" bezieht sich nicht auf die > Frequenz sondern wie du deinen main regulator abhängig von der Frequenz > einstellen musst. Das ist schon klar. Aber um dauerhaft mit 170 MHz zu takten muss ich auch dauerhaft den boost Modus mit der erhöhten Spannung nutzen. Damit verbunden sind dann auch weniger Waitstates beim Flash Zugriff, da dieser dadurch schneller wird. Ich bin unsicher, ob das schadet oder zu instabilitäten führt. Schließlich rät man ja auch davon ab, PC überzutakten.
:
Bearbeitet durch User
Nemopuk schrieb: > Im boost Modus sind bis zu 170 MHz möglich. Ist es Ratsam, dem boost > Modus dauerhaft zu benutzen? Warum denn nicht? Bei mir laufen G431 bis 235 MHz unter 'normalen' Wohnbedingungen. Das ist sinnvoll, um maximale Timer-Frequenzen zu erhalten. Empfehlenswert ist es, das Übertakten beim Einschalten per ext. Pin-Abfrage zu aktivieren. Da kann man jederzeit selber entscheiden, ob man es haben möchte oder nicht.
Ich habe diesen Bericht gefunden https://github.com/m3y54m/stm32-overclocking-challenge Das beantwortet meine Frage nicht, aber ich finde dennoch interessant, wie weit er bei dem alten Räbbelchen gekommen ist.
Nemopuk schrieb: > Ich bin unsicher, ob das schadet oder zu instabilitäten führt. > Schließlich rät man ja auch davon ab, PC überzutakten. Es ist ja gar kein Übertakten, es ist Betrieb innerhalb der Spezifikation. Der Begriff "boost" ist nur ein Marketingname. Im Datasheet steht nichts zur reduzierter Zuverlässigkeit, daher kannst du das ohne Bedenken nutzen. Die STM32 sind schließlich für Industrieeinsatz, die halten ihre Spezifikation ein. Der Nachteil ist halt höherer Stromverbrauch. Wenn du fleißig die Low-Power-Modi zwischen "STOP0" und "Shutdown" nutzt (da ist der Oszillator abgeschaltet) liegt der höhere Verbrauch idealerweise immer nur kurz an. Das kann sogar insgesamt den optimalen Verbrauch erzielen ("race-to-sleep").
Nemopuk schrieb: > Sind dabei Probleme zu erwarten, oder bin ich zu ängstlich? Die Ängste sind unbegründet – 170 MHz sind nichts besonderes für den G431/441 und es ist auch keine Übertaktung im herkömmlichen Sinne wie man es z.B. von den PCs kennt, sondern einfach nur die von STM als maximal festgelegte Frequenz, wo der µC unter allen Bedingungen zuverlässig arbeiten muss. Eine kleine Sicherheitsreserve ist bei 170 MHz sowieso noch vorhanden – STM führt die Tests auch wirklich durch, denn wir reden hier auch nicht von einem IC-Hersteller in China, wo das nur so gesagt wird, im Hintergrund aber nichts erfolgt ist. Mittlerweile haben aber die Chinesen auch sehr viel dazugelernt und machen jetzt auch halbwegs vernünftige Halbleiter, zumindest die bekannten, renommierten Konzerne dort. Auch wegen der Hitzeentwicklung muss man sich nicht wie bei der alten F-Serie zu viele Sorgen machen, denn man ist bei der neuen G-Serie offensichtlich mit den Nanometern runtergegangen – die Folge davon sind geringere parasitäre Kapazitäten, geringere Leckströme und demnach weniger Schaltverluste, geringerer 'Stromverbrauch' und geringere Hitzeentwicklung; den Fortschritt erkennt man auch daran, dass man als User mehr Speicher (Flash und SRAM) auf dem gleichen Flächeninhalt und somit im gleichen IC-Gehäuse zur Verfügung bekommt. Es gibt meistens auch deutlich mehr Peripherie im gleichen Gehäuse im Vergleich zu den Urtypen (STM32F). Ich nutze die G431/441 gerne mit 170 MHz und habe auch diverse Tests zur Programmausführung bei der jeweiligen Geschwindigkeit gemacht – also wo die optimalen Einstellungen bzw. Einstiegspunkte bezüglich CPU-Frequenz, Core-Spannung (Boost) und Waitstates liegen, um aus der jeweiligen Einstellung möglichst immer maximal profitieren zu können. Die Ergebnisse präsentiere ich hier aber nicht – es ist aber nicht verboten, etwas Zeit, Hirnschmalz zu verwenden und es selbst herauszufinden. Auch die Veränderung der Corespannung bei der F4-Serie habe ich mal im Kontext der Einstellung untersucht – wir reden hier z.B. von Änderungen zwischen 1,15 und 1,3V in 50mV-Schritten. Ebenso sollte man auch selbständig in der Lage sein, die CPU-Frequenz so zu wählen, dass sie für das jeweilige Projekt angemessen ist. Bei einem simplen Uhr-Projekt, wo der µC nur mit ein paar 7-Segment-Anzeigen hantieren, ein paar Tasten bedienen muss und ansonsten nicht viel zu tun hat, könnte man auch problemlos auf 16 oder gar 8 MHz runtergehen, auch die PLL, die ja auch so einiges an Strom zieht, kann man in manchen Fällen ausgeschaltet lassen. Um aber die vollen 170 MHz problemlos nutzen zu können, sollte man sich auf jeden Fall an die Vorgaben und Richtlinien in den Datenblättern halten – dazu gehören vor allem die wichtigen Abblockkondensatoren an den jeweiligen Beinchenpaaren und ein gutes Layout der Leiterplatte. Auf meinen Schaltplänen (Jasinski) wirst Du immer mehr Abblockkondensatoren als üblicherweise in den Datenblättern vorgeschlagen wird vorfinden – als z.B. Kondensatorpaare wie 100nF + 10µF, um das Frequenzspektrum besser abdecken zu können.
:
Bearbeitet durch User
> Die STM32 lassen sich nicht besonders stark übertakten. Kühlung war > daher nie ein Problem. Ob und welche eine Kühlung nötig ist, ist nicht (allein) abhängig vom Überschreiten der spezifizierten Taktrate. Bei vielen Prozessoren wird bei der Taktangabe explizit eine Kühlung (Kühlkörper oder eben forced-air cooling) vorausgesetzt. Ist man weit oberhalb der 20°C (Nah am Verbrenner, direkte Sonneneinstrahlung) und ist vielleicht noch eingeengt in einem Gehäuse wo "die Luft steht" kann man das Überschreiten der junction Temperatur nur durch geringere Taktung verhindern. Und viel Wärme kann man durch geschicktes PCB-Layout "wegbekommen". Hat man das nicht, bleibt halt nur der Notnagel Taktbremse. > Die Ängste sind unbegründet – 170 MHz sind nichts besonderes für den > G431/441 Ja, den Eindruck hat man beim schnellen durch-googeln
Gregor J. schrieb: > Auf > meinen Schaltplänen (Jasinski) wirst Du immer mehr Abblockkondensatoren > als üblicherweise in den Datenblättern vorgeschlagen wird vorfinden – > als z.B. Kondensatorpaare wie 100nF + 10µF, um das Frequenzspektrum > besser abdecken zu können. Genau so macht man das, wenn man Abblockkondensatoren nicht verstanden hat. Bradward B. schrieb: > Ob und welche eine Kühlung nötig ist, Der G431 nimmt (bei meiner Anwendung) bei 235 MHz gegenüber 170 MHz ca. 35 mW mehr auf. Was schlägst Du vor? Wasserkühlung? Weltuntergang? Zur Erklärung: mW = Milliwatt MW = Megawatt
Gregor J. schrieb: > Es gibt meistens auch deutlich mehr Peripherie im gleichen Gehäuse Das ist mir auch aufgefallen. Der STM32G431 ist ja der kleinste aus der Familie, und der ist schon voll gestopft mit viel Peripherie. Dafür müsste man bei älteren Modellen einige Euro Aufpreis bezahlen. > Bei einem simplen ... könnte man auch problemlos auf 16 oder gar > 8 MHz runter gehen Das werde ich wahrscheinlich meistens so tun. Die 16 MHz reichen sogar für USB (wenn man den USB Port mit HSI48 taktet).
:
Bearbeitet durch User
> Der G431 nimmt (bei meiner Anwendung) bei 235 MHz gegenüber 170 MHz ca. > 35 mW mehr auf. Was schlägst Du vor? Wasserkühlung? Weltuntergang? Mal den Finger auf den µC und Schaltnetzteil legen. Wird den zu heiß freut man sich über einfache Möglichkeiten eine Kühlkörper anzubringen oder, wenn es ein lausiges Eval-board ist, einen kleiner Lüfter der daneben gestellt, über das Ganze bläst. Dann zeigt sich, auch ob man eine passende Stromversorgung für den Lüfter bereit hat oder nicht. Meldet der Finger keinerlei kritische Erhöhung kann man sich dennoch ne gute Begründung überlegen, warum man für eine (pure Annahme) "poplige" embedded Anwendung den Controller doppelt so schnell takten muß wie die Cores von Deep Blue, dem Rechner der vor 30 Jahren den Schachweltmeister schlug obwohl seine vielen Kerne lediglich mit 120 MHz Zahlen knackten. Und wenn man nach der EMV-Precompliance lange Gesichter macht, freut man sich auch über jede Möglichkeit mit Veränderungen an der Taktungen die Abstrahlung einzubremsen. OK, für ein bißchen Software-Gebastle ist das natürlich zu viel oder zumindest für Schönwetter-Büro-Informatiker ungewohnte Vorsicht.
Angehängte Dateien:
-
STM32C011F6P6_-_Eckdaten.png
140 KB -
STM32C011F6P6_-_keine_PLL.png
140 KB
Nemopuk schrieb: > Das ist mir auch aufgefallen. Der STM32G431 ist ja der kleinste aus der > Familie, und der ist schon voll gestopft mit viel Peripherie. Dafür > müsste man bei älteren Modellen einige Euro Aufpreis bezahlen. Das ist bei der neuen C-Serie so ähnlich – durch die Verkleinerung der Strukturbreite bekommt man mehr auf die Fläche und die Fläche wächst ja zum Quadrat, d.h. bei einer Halbierung der Strukturbreite bekommt man fast das Vierfache an Platz im Silizium. Rein theoretisch, denn in der Praxis ist es leider so, dass man z.B. für die Transistoren der Portausgänge immer noch relativ viel Platz benötigt, damit sie die 25mA liefern bzw. aufnehmen können ohne Schaden zu nehmen. Die Stromversorgungsschienen müssen ebenfalls immer noch relativ dick sein und nehmen daher immer noch viel Platz ein, die Flashspeicherzellen lassen sich auch nicht beliebig verkleinern, auch die Anordnung der Peripherie und Anbindung an den Kern oder zueinander kann nicht nach Belieben realisiert werden – dem sind also immer physikalische und konzeptionelle Grenzen gesetzt. Es gibt dementsprechend auch mal Abstriche bei den Konzepten der neueren Serien, also wo man etwas bewusst herausgenommen hat oder herausnehmen musste, weil es sonst nicht gegangen wäre – der STM32C011F6 hat beispielsweise keine PLL, dafür hat man dann den Pierce-Oszillator soweit optimiert, dass er auch mit Quarzen bis 48 MHz sicher laufen kann. Unbequem ist es aber trotzdem, da die PLL ein sehr nützliches Werkzeug ist; auch die Verwendung von Quarzen oberhalb von 24 MHz kann in diesem Zusammenhang zu Problemen führen. Beim Werben mit einem geringen Stromverbrauch ist andererseits das Fehlen der PLL natürlich von Vorteil, denn die muss ja normalerweise erstmal hochtakten, bevor wieder dividiert werden kann, und das verursacht hohe Schaltverluste, die dann einen höheren Stromverbrauch nach sich ziehen. Bei manchen Typen im kleinen Gehäuse hat man keine Möglichkeit mehr, für HSE einen externen Quarz anzuschließen – es bleibt dann nur noch der externe Quarzoszillator als Taktzufuhr, der wiederum auch Strom verbraucht. Bei Konzepten, wo es darauf ankommt, 5-10 mA an Mehrverbrauch nicht zu haben, kann das schon mal eine unüberwindbare Hürde darstellen. In der C- und G-Serie gibt es zum ersten mal – neben TSSOP20 mit 0,65mm und TQFP32 mit 0,8mm – auch einen STM32 im SO8-Gehäuse. Man bekommt also ein 32-bit-System in einem SO8 mit 1,27mm-Raster, wo wirklich relativ viel drin ist – vor 30-35 Jahren wäre das in der Form noch undenkbar gewesen, schon gar nicht zu diesen kleinen Preisen. Für was man so einen STM32 mit diesen wenigen Pins auch sinnvoll nutzen kann, ist natürlich eine ganz andere Frage, aber als Steuerung für eine WS2812-LED oder als Empfänger bzw. Dekoder eines Infrarotsingals einer Fernbedienung wäre er durchaus brauchbar. Für diese Aufgabe könnte man aber auch einen 8-bit-AVR in SOT23-6 nehmen, falls es von den Abmessungen her noch kleiner werden muss. Aber wie schon erwähnt, 170 MHz sind bei STM32 überhaupt kein Problem, denn der F411 kann bis 100 MHz, der F446 bis 180 MHz, die H7 können bis 400/480 MHz (Rev.V) hochtakten, darüberhinaus gibt es noch einige H7, die auch mal bis 550 MHz hochtakten können. Der G431KB in meinem aktuellen Projekt, wo er mit 170 MHz läuft, die PLL intern erstmal auf 338 MHz hochgetaktet wird, beide DMAs aktiv laufen, die I2S- und SPI-Schnittstelle permanent laufen und eine UART ebenfalls aktiv ist, bleibt der Chip quasi kalt – es gibt vielleicht ein paar Grad Celsius an Erwärmung, das ist aber nicht der Rede wert. So ab 250 MHz werden sich die Schaltverluste aber schon bemerkbar machen, so dass bei z.B. dem H7 mit 480MHz, wo quasi alles aktiviert wurde und auch hochgetaktet läuft, man die Temperaturerhöhung im Konzept berücksichtigen und nachprüfen sollte. Und je höher die IC-Temperatur, desto höher auch sein Stromverbrauch, was wiederum zu noch mehr Temperaturerhöhung führt – bei sehr ungünstigen Bedingungen treibt man den IC dann womöglich in einen sehr unstabilen Zustand. Eine hohe Siliziumtemperatur verkürzt auch signifikant die Dauer des Datenerhalts des Flashspeichers – die Kurve ist nicht linear, sondern nimmt immer mehr zu bei immer höherer Temperatur. Manche H7-Typen beinhalten deswegen auch einen Schaltregler anstelle des regulären linearen Spannungsreglers, der für die Corespannung zuständig ist, um die Wärmeentwicklung zu reduzieren – durch den hohen Wirkungsgrad des Schaltreglers lässt sich so einiges bewerkstelligen. Durch Veränderung des Verhältnisses der Feedbackwiderstände oder durch Beeinflussung der Referenzspannung kann hier die Ausgangsspannung ebenfalls leicht manipuliert werden, um die berühmten Skalierungsstufen, wo die letzte Stufe dann „Boost” als Werbeslogan genannt wurde, als Parameter zum Einstellen im CubeMX zu bekommen.
:
Bearbeitet durch User
Bradward B. schrieb: > Schönwetter-Büro-Informatiker Implementieren eine Power Management Engine welche den Prozessor je nach Situation dynamisch hoch- und runtertaktet um die Leistungsaufnahme und damit Wärmeentwicklung zu optimieren. Gregor J. schrieb: > Bei manchen Typen im kleinen Gehäuse hat man keine Möglichkeit mehr, für > HSE einen externen Quarz anzuschließen – es bleibt dann nur noch der > externe Quarzoszillator als Taktzufuhr, der wiederum auch Strom > verbraucht. Bei Konzepten, wo es darauf ankommt, 5-10 mA an > Mehrverbrauch kann man auch die internen RC-Oszillatoren nehmen, die sind mittlerweile ziemlich gut. Braucht man höhere Genauigkeit kann man den Quarzoszillator auch immer nur bei Bedarf aktivieren.
Wärme war weniger meine Sorge, sondern zuverlässige Funktion.
Nemopuk schrieb: > Wärme war weniger meine Sorge, sondern zuverlässige Funktion. Akkulebensdauer ist manchen Leuten auch wichtig
Nemopuk schrieb: > Wärme war weniger meine Sorge, sondern zuverlässige Funktion. Und du glaubst, dass der/die Hersteller die Maximalwerte auswürfeln, nur um µC.net mit sinnlosen Fragen zu beschäftigen?
Nick schrieb: > Und du glaubst, dass der/die Hersteller die Maximalwerte auswürfeln, Ich habe keine Ahnung und möchte nicht auf Basis wilder Vermutungen entscheiden. Deswegen schien es mir sinnvoll, zu fragen. Tut mir Leid, dich belästigt zu haben.
Nemopuk schrieb: > Wärme war weniger meine Sorge, sondern zuverlässige Funktion. Die meisten oder fast alle Fehler wird man später bei sich selbst suchen müssen, wenn man etwas entwerfen und schreiben wird, es gibt allerdings noch so etwas wie Siliziumfehler – ein Blick in die Errata des jeweiligen µControllers unter Berücksichtigung der eigenen Chip-Revision ist eigentlich immer Pflicht. Man sollte grundsätzlich die entsprechende Errata vorher wenigstens einmal quergelesen haben, um zu schauen, ob man bei dem, was man gerade coded, von den Irrtümern der Erbauer betroffen sein könnte, denn es ist dort quasi immer ein Konglomerat aus alten Fehlern, die einfach in die neueren Konzepte übernommen wurden, und den neuen, die dazugekommen sind oder anstelle der alten jetzt präsent sind. Es gibt natürlich Leute, die sich jahrelang mit ihrem Lieblings-µController beschäftigen, aber noch nie in seine Errata geschaut haben. Bei einem ATMEGA328P bleibt diese Ignoranz oder Faulheit folgenlos, bei den STM32 wird man eines Tages auf unerklärliches Verhalten seines „Lieblings” stoßen – das wünsche und prophezeie ich auch jedem, denn auf diese Weise lernt man (hoffentlich) was dazu und wird in diesem Kontext erfahrener. Wenn auf einmal der Interrupt nachweislich (weil gemessen und z.B. als Zahl per UART ausgegeben) doppelt so oft wie eigentlich vorgesehen angesprungen wird, dann könnte das einfach an einem der Irrtümer im Silizium liegen und nicht an einem selbst. An den 170 MHz wird es dann auch nicht liegen, denn das passiert auch bei niedrigerem Takt. Wenn ferner auf einmal irgendwelche Pins bei Resetauslösung wie von Geisterhand mit einem relativ harten Pull-Down auf Low gezogen werden, dann sollte man sich am besten das neueste Basisdatenblatt zu dem µC von ST herunterladen und genau nach dem Kleingedruckten diesbezüglich suchen – in den Datenblättern älteren Datums hat man diese Information einfach vergessen. Fehler passieren halt überall und sind in fast allen Geräten vorhanden.
Nemopuk schrieb: > Wärme war weniger meine Sorge, sondern zuverlässige Funktion. Hm, gelegentlich wird angedeutet, das man mögliche "funktionale Probleme" (damit sind wohl Datenverfälschungen insbesonders an dem Mem/Bus-Interface gemeint ?! Ober unerwarteter Re-Boot ?! ) die durch Übertakten entstehen könnten, kompensieren kann solange man "ausreichend" kühlt. Bei der heutzutage verwendeten dynamischen Schaltungstechnik hängt die aktuell zulässige Taktrate von mehreren Parameter (bspw. auch Core-Spannung) ab.
:
Bearbeitet durch User
Niklas G. schrieb: > kann man auch die internen RC-Oszillatoren nehmen, die sind mittlerweile > ziemlich gut. Braucht man höhere Genauigkeit kann man den Quarzoszillator > auch immer nur bei Bedarf aktivieren. Wenn man höhere Genauigkeit braucht, generiert man keine Pathologien und zusätzliche Fehlerquellen im System, sondern nimmt von Anfang an einen passenden µController, wo alles vorhanden ist, was benötigt wird. Das nennt sich Planung – wer das nicht kann oder Dinge immer umgekehrt macht, der darf seine komische Akrobatik selbstverständlich weiterhin tun und später auch jammern, wenn hin und wieder etwas nicht wie vorgesehen funktioniert. Wenn man z.B. auf ein UART-Zeichen wartet, wo die Übertragung auf mindestens einer Seite eine Quarzgenauigkeit benötigt und nicht bekannt ist, wann es ankommt, wird bei der Ankunft der fallenden Flanke des Startbits eh zu spät sein, den Haupttakt zu switchen, denn das ist intern immer mit Verzögerungen verbunden. Ein Risiko, dass bei dem Umswitchen etwas schiefläuft, etwas im System doch mal unerwartet aus dem Takt gerät oder einen Glitch bekommt, ist ebenfalls vorhanden – die STM32-µC sind hochkomplexe Gebilde, man sieht es auch daran, wieviele Erratas bis heute nicht ausgemerzt werden konnten, weil es halt extrem riskant ist, etwas an den Entwürfen zu verändern. Man lässt vieles lieber mit den bekannten Fehlern weiter produzieren, denn die sind wenigstens bereits aufgedeckt, bekannt und gut dokumentiert, es gibt meistens auch Workarounds – bei einer kleinen Veränderung würde man das erstmal gar nicht wissen bzw. einschätzen können und es geht auch um viel Geld und Haftung.
Gregor J. schrieb: > wird bei der Ankunft der fallenden Flanke des Startbits eh zu spät sein, > den Haupttakt zu switchen Manche STM32 können genau das vollautomatisch in Hardware. Die Baudrate ist dann aber begrenzt auf 9600. Allerdings müssen viele Anwendungen gar nicht ständig auf ankommende Zeichen warten, sondern z.B. nur dann wenn ein entsprechendes externes Modul aktiv ist. Den Rest der Zeit könnte man den (internen oder externen) Quarzoszillator abschalten. Das macht auch dann Sinn, wenn man das Projekt von Anfang an so geplant hat. Genau das machen übrigens die STM32WL55 mit dem TCXO, der nur bei Bedarf (für das SubGHz Modem oder manuell per Register aktiviert oder beides) automatisch eingeschaltet wird.
:
Bearbeitet durch User
Niklas G. schrieb: > Manche STM32 können genau das vollautomatisch in Hardware (...) > Genau das machen übrigens die STM32WL55 mit dem TCXO (...) Ne, machen gar nix gleich – mit dem Versuch „Äpfel mit Birnen” zu vergleichen versuchst Du Dir was zusammenzureimen, um jetzt noch irgendwie fein aus der Nummer rauszukommen oder sich selbst zu belügen. Wie ich bereits schrieb, mit dem manuellen Umswitchen des Haupttaktes generiert man Pathologien bzw. baut sich unnötig neue Fehlerquellen im System ein – es ist aber nicht mein Problem, wenn das jemand nicht verstanden hat. Ferner ist es auch nicht das Thema des Threads, insofern EOT diesbezüglich.
Gregor J. schrieb: > zusammenzureimen, um jetzt noch irgendwie fein aus der Nummer > rauszukommen oder sich selbst zu belügen Muss das sein? Wo wird hier gelogen? Gregor J. schrieb: > Wie ich bereits schrieb, mit dem manuellen Umswitchen des Haupttaktes > generiert man Pathologien bzw. baut sich unnötig neue Fehlerquellen im > System ein – es ist aber nicht mein Problem, wenn das jemand nicht > verstanden hat. Hat dann offenbar keiner der großen Prozessorhersteller verstanden, denn alle Desktop und Embedded Anwendungsprozessoren machen das, die gängigen Betriebssysteme nutzen das intensiv, viele Mikrocontroller können es, und entsprechende Software-Frameworks implementieren es. z.B. das ESP-IDF schaltet schon ganz automatisch den Prozessortakt um. Rein zufällig kenne ich ein Mikrocontroller-basiertes Gerät welches das ebenso intensiv nutzt und das jetzt über 10 Jahre im Feld bei wechselhaften widrigen Bedingungen absolut zuverlässig läuft ohne jeglichen manuellen Eingriff, Abstürze, Reboots, Updates usw. Da hat wohl jemand was überhaupt nicht verstanden, oder? Gregor J. schrieb: > insofern EOT diesbezüglich. Erst beschimpfen und dann "EOT", toll!
Niklas G. schrieb: > Rein zufällig kenne ich ein Mikrocontroller-basiertes Gerät welches das > ebenso intensiv nutzt Ich auch! Deinen Ratschlag, anstatt eines STM32G031 einen STM32L031 für meinen Datenlogger zu verwenden, habe ich zwar nicht befolgt (blöderweise nicht pinkompatibel), takte den Controller aber je nach Betriebsmodus zwischen 1 MHz (Minimum für 500 kBd von USART1), 4 MHz für ISR und 16 MHz mit PLL bei Datenkonvertierung und -Ausgabe. Das spart richtig Strom. Im Stop-Modus läuft nur die Uhr (RTC) mit 32,768 kHz LSE-Takt. Jetzt kennst Du zwei Geräte ;-) Zum eigentlichen Thema: Die STM32 konfiguriere ich normalerweise auf max. Geschwindigkeit - Zeit ist Geld! Andere Komponenten der Schaltung verbrauchen meist mehr Strom.
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.