Warum ist dies auf einem Mikrocontroller scheinbar in Ordnung, auf einem Mikroprozessor jedoch normalerweise nicht erwünscht?

Aus dem gleichen Grund ist es auch auf einem Mikrocontroller unerwünscht: Es verschwendet Strom.

Habe ich Recht, wenn ich denke, dass der ATmega tatsächlich zu 100% läuft

Richtig.

und dass es, weil es so schwach ist, keine offensichtlichen Hitzeprobleme verursacht?

Richtig. Wenn Sie Ihren Mikrocontroller jedoch mit batteries betreiben, müssen Sie wirklich gründlich darüber nachdenken, keine Energie zu verschwenden. Auf einer winzigen CPU wie AtMega328P verursacht es keine Hitzeprobleme, verkürzt aber definitiv die Akkulaufzeit.

Alle CPUs, ob Desktop-Kraftpakete oder winzige Mikrocontroller, verwenden dieselben Methoden:

1- Reduzieren Sie die Taktrate oder Spannung.

2- Fahren Sie nicht benötigte Hardware herunter.

3- Gehen Sie in den Ruhezustand und wachen Sie bei einem Ereignis auf (dies ist ein Sonderfall beim Herunterfahren nicht benötigter Hardware, in diesem Fall wird die CPU heruntergefahren).

Im AtMega328P können Sie dies auch implementieren. Sie können eine langsamere Uhr verwenden, wenn Sie nicht die unglaubliche Leistung des 8-Bit-Kerns benötigen, nicht benötigte Peripheriegeräte herunterfahren können ... und das Wichtigste ist der Ruhemodus.

Einzelheiten sollten Sie im Handbuch lesen, da es verschiedene Schlafmodi gibt, die sich in den Wecklatenzen unterscheiden, welche Peripheriegeräte online bleiben und die CPU aufwecken können, ob RAM-Daten erhalten bleiben oder verloren gehen usw. Aber im Grunde die Idee ist: Im Schlafmodus wird die CPU gestoppt, sodass sie viel weniger Strom verbraucht. Wenn ein Interrupt auftritt, wird die CPU aufgeweckt und der Interrupt verarbeitet.

Natürlich müssen Sie den richtigen Ruhemodus verwenden und richtig konfigurieren, damit das Peripheriegerät, das die CPU aufwecken muss (z. B. ein Timer oder ein GPIO-Interrupt), nicht heruntergefahren wird. Wenn alles heruntergefahren ist, müssen Sie NMI oder sogar Reset verwenden, um es zu aktivieren, im letzteren Fall durch Neustart.

Wenn Ihre Anwendung nur auf Interrupts wartet, wie z. B.:

• Pin Change Interrupt (PCI) zur Erkennung eines Tastendrucks oder eines eingehenden Signals

• Timer

• Von UART oder USB empfangene Daten

• usw.

Dann müssen Sie die Hauptschleife nicht drehen.Nachdem Sie beim Booten alles konfiguriert haben, starten Sie die Hauptschleife mit der Anweisung "Go to Sleep".Der nächste Befehl wird ausgeführt, nachdem die CPU aufgewacht ist, verarbeitet alle ausstehenden Interrupts und kehrt zur Hauptschleife zurück.Dann kann die Hauptschleife bei Bedarf etwas gegen die empfangenen Ereignisse unternehmen, wenn sie nicht vollständig vom Interrupt-Code behandelt wurden ... und dann wieder in den Ruhezustand wechseln.

Selbst wenn Sie keine Batterien verwenden, kann ein Netz mit niedrigem Standby-Strom das Schaltnetzteil mit Strom versorgen, um Zyklen zu überspringen und auch viel weniger Strom zu verschwenden.

Auf einem Mikrocontroller (genauer gesagt auf einer Arduino Uno-Karte mit dem ATmega 328P-Mikrocontroller) würde ich normalerweise eine Endlosschleife verwenden, um nach Eingaben usw. zu suchen (im Arduino-Land ist dies normalerweise die Funktion loop ()). Wenn ich diese Funktion jedoch leer lasse, verursacht dies keine Probleme.

Klassisches Programmiermuster mit einer Hauptschleife…

Auf einem Desktop / Laptop mit einer Intel i7-CPU usw. würde eine ähnliche Endlosschleife (mit nichts oder sehr wenig zu tun) die CPU auf ~ 100% fixieren und im Allgemeinen die Lüfter usw. hochfahren ( Eine Verzögerung könnte hinzugefügt werden, um dies beispielsweise zu verhindern.

… wir schreiben möglicherweise verschiedene Hauptschleifen.

Dieselbe Hauptschleife wäre auch auf einem Mikrocontroller eine schlechte Praxis, da dadurch auch die CPU der Volllast ausgeführt wird - was Strom verbraucht. Tun Sie das nicht, besonders wenn Sie im Akkubetrieb sind.

Moderne CPU-Kerne verfügen über Synchronisationsmechanismen. Auf diese Weise können Benutzer etwas implementieren wie "Lassen Sie die Ausführung dieser Schleife ruhen, bis 1 ms vergangen ist oder bis sich diese Bedingung geändert hat".

Das ist im Grunde das Herzstück eines jeden Multi-Task-Betriebssystems - und im Grunde sind es mittlerweile alle Betriebssysteme, die diesen Namen verdienen. Auf Mikrocontrollern finden Sie häufig sogenannte RTOSes (Echtzeitbetriebssysteme), die garantieren, wie sicher Sie sein können, dass die Ausführung von etwas nach so vielen Nanosekunden begonnen hat, da dies typisch für den Anwendungsfall ist von Mikrocontrollern, während auf Desktops und Server-CPUs normalerweise vollwertige simultane Multiprozessor-Betriebssysteme zu finden sind, die weniger Garantien für das Timing bieten, aber einen viel größeren Satz an Funktionen sowie eine Abstraktion der Hardware- und Softwareumgebung bieten.

Ich kenne die Arduino-Ausführungsumgebung nicht gut genug, um tatsächlich qualifizierte Aussagen darüber zu machen. Ich recherchiere dies, während ich schreibe: Arduino scheint nicht dafür ausgelegt zu sein - es erwartet wirklich, dass Sie sich nur geschäftig drehen. Da es keine "Yield" -Funktionalität gibt, kann das "Housekeeping", das zwischen Aufrufen Ihrer -Schleife durchgeführt wird, nicht aufgerufen werden, wenn Sie die integrierte delay -Funktion verwenden. Pfui! Schlechtes Design.

Was Sie in einem leistungs- und / oder latenzbewussten Design tun würden, würden Sie ein RTOS für Ihren Mikrocontroller verwenden - FreeRTOS ist ziemlich beliebt, für die ARM Cortex-M-Serie hat mbed viel Traktion, ich persönlich wie ChibiOS (aber ich denke nicht, dass dies eine gute Wahl ist, wenn von Arduino-Skizzen gewechselt wird), treibt die Linux Foundation Zephyr voran (worüber ich in Konflikt gerate); Es gibt wirklich eine Fülle von Möglichkeiten, und der Hersteller Ihres Mikrocontrollers unterstützt normalerweise eine oder mehrere über seine IDEs.

Warum ist dies auf einem Mikrocontroller scheinbar in Ordnung, auf einem Mikroprozessor jedoch normalerweise nicht erwünscht?

Es ist nicht wirklich in Ordnung, es ist in der Tat ein ungewöhnliches Entwurfsmuster für Mikrocontroller, die normalerweise in regelmäßigen Abständen Dinge tun oder auf externe Reize reagieren. Es ist nicht üblich, dass Sie "so viel CPU wie möglich" auf einem Mikrocontroller kontinuierlich verwenden möchten.

Es gibt Ausnahmen zu diesem Muster, und sie existieren sowohl in der MCU als auch in der Server- / Desktop-Prozessor-Welt. Wenn Sie wissen, dass Sie praktisch immer z. Netzwerkdaten, die in einer Switch-Appliance verarbeitet werden sollen, oder wenn Sie wissen, dass Ihr Spiel immer schon ein Stück Welt vorberechnen kann, das Sie möglicherweise in wenigen Augenblicken benötigen oder nicht, finden Sie diese Spin-Loops. In einigen Hardwaretreibern finden Sie "Drehsperren", was bedeutet, dass die CPU kontinuierlich einen Wert abfragt, bis er sich geändert hat (z. B. ist die Hardware eingerichtet und kann jetzt verwendet werden), aber es handelt sich im Allgemeinen nur um eine Notfalllösung, und Sie müssen erklären, warum Sie das tun, wenn Sie beispielsweise versuchen, solchen Code in Linux zu integrieren.

Habe ich Recht, wenn ich denke, dass der ATmega tatsächlich zu 100% läuft und dass er aufgrund seiner geringen Leistung keine offensichtlichen Hitzeprobleme verursacht?

Ja. Der ATMega ist nach modernen Maßstäben nicht stromsparend, aber stromsparend genug, damit die Hitze kein Problem darstellt.

Habe ich Recht, wenn ich denke, dass der ATmega tatsächlich zu 100% läuft, und dass, weil es so wenig Strom hat, es keine offensichtliche Hitze verursacht Probleme?

Ja, es läuft normalerweise die ganze Zeit zu 100%, ist aber so schwach, dass es sich nicht wesentlich erwärmt.

Auf einem Desktop / Laptop mit einer Intel i7-CPU usw., wenn ich eine ähnliche ausgeführt habe Endlosschleife (mit nichts oder sehr wenig zu tun) würde es stecken die CPU bei ~ 100% und im Allgemeinen drehen Sie die Lüfter usw.

Je schneller eine CPU getaktet wird, desto mehr Strom verbraucht sie, da jedes Mal, wenn sich ein Logikpegel ändert, die Kapazitäten der Transistoren in den Gates aufgeladen werden müssen. Moderne CPUs sind so konzipiert, dass sie so schnell wie möglich laufen - tatsächlich schneller als möglich. Selbst wenn die Transistoren so klein wie möglich gemacht werden, die niedrigstmögliche Spannung verwendet und ein riesiger Kühlkörper angelegt wird, können sie immer noch nicht schnell genug laufen, um das "Bedürfnis der PC-Benutzer nach Geschwindigkeit" zu befriedigen. Sie verlassen sich daher auf die Tatsache, dass das Betriebssystem und die Anwendungsprogramme die meiste Zeit darauf warten, dass etwas passiert (Benutzereingaben, Peripheriegeräte usw.).

Wenn Sie versuchen würden, alle Kerne in einem i7 kontinuierlich mit maximaler Frequenz zu betreiben, würde dies schmelzen. Um dies zu verhindern, werden nicht verwendete Kerne ausgeschaltet, und wenn keine maximale Geschwindigkeit erforderlich ist (dh die meiste Zeit), laufen die aktiven Kerne mit einer niedrigeren Frequenz. Im Leerlauf führt das Betriebssystem nicht nur eine Besetztschleife aus, die kontinuierlich Anweisungen ausführt, sondern versetzt die CPU in einen verlangsamten oder angehaltenen Zustand, während sie auf Interrupts usw. wartet. Verschiedene Teile der CPU können auch ausgeschaltet werden, wenn sie nicht verwendet werden.

Der ATmega kann auch in einen Energiesparmodus versetzt und einzelne Peripheriegeräte ausgeschaltet werden, wenn sie nicht benötigt werden. Wenn der Systemtakt auf eine niedrigere Frequenz wie 32,678 kHz geändert wird und alle unnötigen Peripheriegeräte ausgeschaltet sind, kann er (langsam) mit nur wenigen μA betrieben werden - nicht um die Temperatur zu senken, sondern um mit einer kleinen Batterie länger zu halten.

Es ist auch möglich, viele Atmega-Chips zu übertakten.Ich habe einen ATmega1284p (für maximal 20 MHz bei 5 V ausgelegt) mit 30 MHz betrieben und es hat gut funktioniert, wurde aber ziemlich warm.

Hängt davon ab, ob Ihr ATmega-System mit Wechselstrom oder kleinen Batterien betrieben wird.

Wenn keine kleinen Batterien mehr vorhanden sind, macht eine Arduino-Schleife einen signifikanten Unterschied darin, wie oft Sie diese Batterien ersetzen oder aufladen müssen.Vielleicht Stunden gegen Monate.Ein ernstes Problem, wenn der Zugriff auf Ihr eingebettetes System schwierig ist.Eine übliche Lösung besteht darin, einen zeitgesteuerten Schlafmodus mit geringerer Leistung innerhalb der Endlosschleife oder einen Schlafmodus plus einen Weckinterrupt von einer externen Quelle zu verwenden.

Auf einem modernen Mikroprozessor schreiben Sie höchstwahrscheinlich eine grafische Benutzeroberfläche, die Ihre Arbeit erledigt. Die GUI verfügt über eine eigene Ereignisschleife, in der beispielsweise Mausklicks, Neuzeichnungen usw. verarbeitet werden. Der größte Teil Ihrer Funktionalität befindet sich in einem Ereignishandler, an den die Hauptereignisschleife delegiert.

Wenn Sie also in einem solchen Ereignishandler eine Endlosschleife starten, wird die übliche Ereignisverarbeitung unterbrochen, da Sie nach relativ kurzer Zeit zur Ereignisschleife zurückkehren müssen, damit die Benutzeroberfläche erhalten bleibt reaktionsschnell. Zumindest reagiert Ihre eigene Anwendung nicht mehr, wenn Sie eine Endlosschleife haben (Mausklicks bewirken nichts, Grafiken werden nicht mehr aktualisiert).

Multitasking als solches (und damit die anderen Prozesse) leiden normalerweise nicht darunter, da der OS-Kernel dennoch auf andere Prozesse umschaltet.

Es ist also nicht "böse", eine Endlosschleife auf einem Mikroprozessor zu haben, aber es verstößt gegen User Experience-Standards, zumindest für grafische Anwendungen. Für eine Konsolenanwendung kann es jedoch durchaus vorkommen, dass Sie eine Endlosschleife ohne Schaden haben, z. B. wenn Sie pi mit bis zu 1 Million Stellen berechnen (und schließlich das Ergebnis an die Konsole senden) oder ähnliches, da der Benutzer normalerweise ( Worst-Case) für Konsolenanwendungen vorbereitet, deren Ergebnisse fast ewig dauern.