CPU-Auslastungsmethoden

Um Kundenwünsche zu erfüllen und Kundenberichte über das Gerät auszufüllen, gibt es auch einen Abschnitt über die CPU-Auslastung. Da ich eine solche Aufgabe noch nie gemacht habe, habe ich einige Artikel zur "Google-Suche" im Überblick. Viele der Artikel stehen in direktem Zusammenhang mit der Linux-Programmierung, viele sprechen allgemein über CPU-Auslastung (nur theoretisch) und ich habe keinen Artikel über die Methode gefunden, wie das gemacht werden kann. Ok, es gibt einige: embedded.com .

Mich interessiert, wie DU solche Task-Timing-Jobs schon einmal gemacht hast? Mich interessiert die Methode und auch womit welches Tool gemacht wurde? Mit einer direkten Messung auf dem Oszilloskop (oder Logikanalysator) oder der Erfassung von Daten vom Oszilloskop und deren Nachbearbeitung? Welchen Zeitrahmen muss die CPU-Auslastung berechnen - der "geschäftigste Moment", wenn alle Interrupts vorhanden sind, da in diesem Fall die CPU-Auslastung viel größer ist als vielleicht 1 Millisekunde oder 1 Mikrosekunde später, wenn nur die Hintergrundschleife ausgeführt wird?

Vielleicht als Referenz, wie ich meinen ersten Ansatz zur CPU-Auslastung gemacht habe (ich weiß nicht, ob es der richtige Ansatz ist): Jeder Interrupt beim Start der Ausführung hat eine dedizierte PIN, die hoch geht, wenn der Interrupt beginnt, und niedrig wird, wenn der Interrupt endet. Es gibt auch die gleichen Ausbreitungsverzögerungen. Ich exportiere diese Signale über das Oszilloskop in eine Datei und bearbeite sie mit Oktave. Es ist immer noch ein Problem, welcher Zeitrahmen zu nehmen ist.

Bei Fragen schreiben Sie bitte in den Kommentarbereich

Welche MCU-Plattform verwenden Sie? Welche Art von Debugging-Schnittstelle hat es? Einige Mikrocontroller unterstützen erweiterte Tracing-Mechanismen, mit denen Sie die Nutzung der MCU über die Debugging-Schnittstelle profilieren können. Beispiel für STM32
Es ist eine MSP430 MCU. Wir verwenden die IAR-Version 5.40.3. Ich glaube also, dass ein solches Tool nicht enthalten ist, vielleicht in den neuen Versionen?
Es gibt viele mögliche Methoden, verwenden Sie alles, was Ihrem Designteam und/oder dem Kunden das Vertrauen gibt, dass Ihre Software immer funktioniert. Sie werden oft in zwei Kategorien unterteilt, Aufgaben mit hoher Priorität, die in einem bestimmten Zeitrahmen ausgeführt werden müssen (ich habe ein GPIO verwendet, wie Ihr Interrupt-Beispiel dafür); und Aufgaben mit niedrigerer Priorität, die niemals zu weit ins Hintertreffen geraten dürfen. Ich hatte oft eine "Reserve-Durchsatz" -Anforderung für letzteres, die Software kann dies leicht selbst berechnen, wenn sie die Timer-Zählungen verfolgt, wenn sie in den Leerlauf geht.
@Pukaai Ich weiß nichts über v5, aber anscheinend verfügt IAR v7 über eine Funktionsprofilerstellung unter der EnergyTrace-Funktion. Benutzerhandbuch
Danke Bora! Ich kannte EnergyTrace nicht, ich muss mal schauen, ob ich es verwenden kann (einige Beispiele und fragen Sie den Chef nach der Aktualisierung des IAR). Auf diesem Videolink habe ich auch bemerkt (44:15), dass "EnergyTrace++ keine digitale Hochgeschwindigkeitsspur ist. Die typische Geschwindigkeit beträgt 1 kHz bis 4 kHz ...". Einer meiner Interrupts muss in maximal 100 us ausgeführt werden - wird also wahrscheinlich nicht meinen Anforderungen entsprechen. Danke Bora!

Antworten (1)

Die CPU-Auslastung ist wirklich nur ein grobes Maß für die Gesamtausfallsicherheit eines Echtzeitsystems. Daher ist die Antwort auf Ihre Frage, dass es sich in der Regel um einen langjährigen Durchschnittswert handelt.

Das eigentliche Kriterium ist, ob alle Softwareaufgaben ihre Fertigstellungstermine einhalten. Beachten Sie, dass dies sowohl Aufgaben umfasst, die durch Interrupts ausgelöst werden, als auch Aufgaben, die durch andere Arten von Ereignissen ausgelöst werden. Wenn sich die CPU-Auslastung 100 % nähert, wird die Zeit für die Ausführung von Aufgaben mit niedrigerer Priorität tendenziell willkürlich groß.

Die Verwendung von GPIO-Pins zur Angabe der Laufzeit einzelner Aufgaben ist eine gute Möglichkeit, um zu überprüfen, ob diese Fristen jemals überschritten werden.

Ein anderer Ansatz besteht darin, den Code selbst zu instrumentieren. Wenn Sie Zugriff auf einen freilaufenden Zähler haben (vielleicht ein Ersatz-Hardware-Zähler/Timer-Modul), können Sie zu Beginn jeder Aufgabe einen Schnappschuss seines Werts machen und am Ende der Aufgabe einen weiteren Schnappschuss machen und berechnen Sie die Differenz. Wenn dies jemals den erforderlichen Wert für diese Aufgabe überschreitet, geben Sie einen Fehler an.


Eine etwas andere Frage wäre, die erwartete CPU-Auslastung eines Systems zu berechnen, bevor es implementiert wird.

In diesem Fall betrachten Sie jede Aufgabe einzeln und schätzen, wie lange sie ausgeführt wird, wenn sie ausgelöst wird, und wie oft sie ausgelöst wird. Die Laufzeit dividiert durch die Auslöseperiode ergibt die CPU-Auslastung für diese Aufgabe allein.

Wenn Sie alle einzelnen Auslastungswerte addieren und einen Wert erhalten, der 100 % erreicht oder überschreitet, müssen Sie über Möglichkeiten nachdenken, die Arbeit neu zu verteilen – schnellere CPU, mehr CPUs, dedizierte Hardware für einige Aufgaben usw.

Danke David! Ich habe bereits Zähler für jede Aufgabe implementiert - das Problem ist, dass Aufgabe 3 länger ist, weil Aufgabe 2 Vorrang vor Aufgabe 3 hat, und Aufgabe 2 länger ist, weil Aufgabe 1 höhere Priorität als Aufgabe 2 und Aufgabe 3 hat ... also kurz: T1 (höchste Priorität) > T2 > T3 (niedrigste Priorität). Was ich also bekomme, sind die maximalen Zeiten der einzelnen Aufgaben, und ich habe keine Lösung gefunden, wie der Timer abgebrochen werden kann, wenn eine neue Aufgabe mit der höheren Priorität einsetzt. Im zweiten Teil haben Sie über "Echtzeitplanung -> Monotonischer Ansatz" gesprochen? Ich brauche echte Timing-Ergebnisse (Zeiten mit niedrigerer Priorität sind nicht echt).
Also ist es vielleicht am einfachsten, am Oszilloskop den längsten zu triggern, zum Beispiel "Task 2" und Minus-Interrupts von "Task 1", und ich bekomme die "echte Zahl", nur dass durch Messen einige Abweichungen auftreten können. So bekomme ich die Zeitzahlen und kann "Real Time Scheduling" berechnen
Aber Sie möchten den Timer nicht "abbrechen", wenn eine Aufgabe mit höherer Priorität ausgeführt wird - der springende Punkt ist, dass die Aufgabe mit höherer Priorität direkt zur Fertigstellungszeit der Aufgaben beiträgt, die sie unterbricht. Wenn also die Fertigstellungsfrist für T2 nicht größer ist als die tatsächliche Laufzeit von T2 PLUS die von T1, dann haben Sie ein Problem!
Ich glaube, ich verstehe dich :) Danke! Eine Frage ... kann ich in diesem Fall sogar "Real Time Scheduling -> Rate Monotonic Approach" verwenden (ich verwende MSP430), oder gilt dies nur für zB Linux Embedded-Systeme? Denn in meinem Fall gibt es drei Aufgaben: Aufgabe 1 (höhere Priorität) > Aufgabe 2 > Hintergrund (niedrigste Priorität)
Ich bin mir nicht sicher, worauf Sie sich beziehen, da ich in dem von Ihnen verlinkten Artikel keine solche Überschrift sehe. Aber vorausgesetzt, es ist etwas Ähnliches wie die Wikipedia-Beschreibung , Sie haben nicht genügend Informationen über die Aufgaben in Ihrem System bereitgestellt, um zu wissen, ob sie die dort beschriebenen Kriterien erfüllen. Ich kann sagen, dass es nicht nur für Linux-basierte Systeme gilt.
David Danke! Entschuldigen Sie die fehlenden Informationen, aber Sie haben den richtigen Link bereitgestellt - genau das habe ich im Sinn. Danke! Über Tasks ... die kürzesten haben die höchste Priorität und so weiter - Round Robin mit Interrupts
Soll ich bei der Berechnung des ratenmonotonen Ansatzes und seiner spezifischen Grenze auch die Hauptschleife in diese Berechnung als Task einbeziehen oder nicht, da sie nur im Leerlauf ausgeführt wird? Ich habe einige Quellen gelesen und eine davon sagt: "Die mathematische Analyse der monotonen Planung der Rate bestimmt, dass Echtzeitaufgaben (dh Aufgaben mit bestimmten Echtzeitterminen) planbar sind, wenn die Auslastung unter etwa 70% liegt" - also hat die Hintergrundschleife keine Frist, liege ich falsch?