Messen der Firmware-Leistung

Wenn Sie MPLAB verwenden, simulieren Sie einfach mit der Funktion „Stoppuhr“.

Sie können Breakpoints einfügen und den Code zyklusgenau profilieren. Sehr nützlich.

Natürlich können Sie sich die Speichernutzungsanzeige ansehen und die Codegröße sehen, wenn sie kompiliert ist.

Es ist auch nützlich, sich den disassemblierten Code anzusehen, wie andere vorgeschlagen haben, insbesondere bei engen ISRs.

In Bezug auf die Geschwindigkeitsleistung würde ich dringend empfehlen, den unbestrittenen König des Firmware-Benchmarkings zu verwenden: das Oszilloskop. Sie können wirklich kein professioneller Firmware-Entwickler sein, ohne Zugang zu einem zu haben.

Leistungsmessung Ihrer IDE oder Ihres Linkers kann nützlich sein, aber am Ende müssen Sie Ihr Timing immer noch in der realen Welt außerhalb der IDE testen und verifizieren.

Was ist Ihr Maß für "Leistung" - Abfragerate? Latenz etwas anderes? Wenn Leistung Abfragen pro Sekunde bedeutet, dh Sie möchten einfach die schnellstmögliche Schleife, können Sie ein Ausgangsbit umschalten und seine Frequenz mit einem Oszilloskop oder einem Handmessgerät messen, das die Frequenz messen kann.

Welche Details bekomme ich von der Demontage? Ich habe es noch nie gemacht

Erzeugt der Compiler wertvolle Daten, die überprüft werden müssen, oder sind es Debugger, denen ich vertrauen muss?

Sie müssen sich mit der Maschinensprache Ihres speziellen PIC vertraut machen, wenn Sie mit der Optimierung beginnen möchten. Ziemlich oft werden Sie Code sehen, der in C unschuldig genug aussieht, aber in Bezug auf die Anzahl der Anweisungen in Maschinensprache, na ja ...

Das kanonische Beispiel für die Leistungsfähigkeit des PIC24 XC16-Compilers:

_LATA0 ^= 1;            // toggle a bit

wird dies in Maschinensprache:

mov.b _LATA,W0
and.b W0,#1,W0
btg W0,#0
and.b W0,#1,W0
and.b W0,#1,W2
mov.w #0x02c4,W1
mov.b [W1],W1
mov.b #0xfe,W0
and.b W1,W0,W0
ior.b W0,W2,W0
mov.b W0,0x02c4

obwohl es eine Bit-Toggle-Maschinensprache-Anweisung btg gibt . Warum passiert das? C-Compiler nutzen spezielle Hardware in ihren Zielmikros oft nicht, es sei denn, die Compiler-Autoren zielen speziell auf diese Hardware ab.

Ihr erster Durchgang bei der Optimierung (vor dem Messen) sollte ein schnelles Durchsuchen der Demontage sein. Sehen Sie, welche C-Anweisungen in die meisten Maschinensprachenanweisungen übersetzt werden. Probieren Sie verschiedene Herangehensweisen an das Problem aus und sehen Sie, welche die wenigsten Anweisungen liefern. Sie werden schnell Erfahrungen damit sammeln, welche Codemuster Sie vermeiden und bei welchen Sie bleiben sollten.

Wie kann ich messen, welche Firmware am besten ist?

Welche gängigen Tools stehen zur Verfügung, um die Leistung einer Firmware zu messen?

Ist es mit einem Debugger wie Pickit3 /ICD3 möglich? Ich habe ein pickkit3 zur Hand.

Wie andere gesagt haben, sind die einfachsten Wege im Allgemeinen:

• durch physisches Umschalten einiger E/A-Leitungen und Messen mit einem Oszilloskop
• mit dem in MPLAB verfügbaren Simulator- und Stoppuhr-Tool

Sie „verpacken“ Ihren Zielcode mit den Bit-Umschaltern (oder Haltepunkten) und messen, wie lange die Ausführung dauert. Wenn Sie dann ein Leistungsproblem finden, gehen Sie zurück zu Ihrer Disassemblierung, finden Sie heraus, welcher Code viel Zeit in Anspruch nimmt, und refaktorisieren Sie ihn, und testen Sie ihn dann erneut.

Ich schaue gerne, ob mein System in der Zeit, die es hat, das tun kann, was es tun muss. Ich schalte an kritischen Stellen etwas um und stelle sicher, dass ich genügend Headroom habe, um eine Aufgabe zu erledigen. An anderen Stellen verwende ich großzügig Flags, um sicherzustellen, dass die Dinge für eine aufgerufene Routine in Ordnung sind, und sobald ich in der Routine bin, werde ich sie mit einem Fehlercode beenden, wenn dies nicht der Fall ist.

Bei eingebetteten Systemen ist das Großartige definitiv der Feind des Guten, wenn es um Optimierung geht. Die beste Firmware ist die Firmware, die A) funktioniert und B) das tut, was Sie tun müssen, während C) verständlich und einigermaßen unterstützbar bleibt. Eine darüber hinausgehende Optimierung kann eine Fehlleitung einer wertvollen Ressource sein.

Das ist sicherlich eine Übertreibung der Situation, vielleicht ist "hyperbolisch" ein guter Ausdruck dafür. In Kapitel 8 (Doing More With Less) von Elicia Whites großartigem O'Reilly-Buch „ Making Embedded Systems “ sagt sie:

Letztlich ist die Optimierung ein wirtschaftliches Problem. Sie beginnen mit einem Portfolio von Vermögenswerten, die mit Ihrem System verbunden sind ... Ihr liquidestes Kapital ist Entwicklungszeit, also stellen Sie sich das als Geld vor. Sobald Sie diese Vermögenswerte in Teile des Systems investieren (oder zuweisen) (sic), verlieren Sie die Möglichkeit, sie in anderen Systemen zu verwenden ....

Berücksichtigen Sie bei der Betrachtung verschiedener Optimierungsstrategien auch die hohen Opportunitätskosten, die mit der Anlage Ihres Vermögens einhergehen. Der Kauf von Futures ist fast immer billiger, als bis zur letzten Minute zu warten und zu erkennen, dass Sie ernsthaft verschuldet sind und keine einfache Möglichkeit haben, sich zu erholen.

Daher ist es der größte Teil des Kampfes, sicherzustellen, dass Sie mit genügend System beginnen, um die Arbeit zu erledigen, und wenn Sie dies gut genug machen, müssen Sie Ihr System nicht auf Leistung ausdehnen.