Mich fragte jemand wie ich meine Software teste — das brachte mich auf die Idee, ein paar Kleinigkeiten hier mal öffentlich niederzuschreiben.

Viele Tests mache erledige ich über kleine Codeanpassungen und die Skriptfähigkeit von AVRDebug.

Damit lassen sich sehr verschiedenartige Aufgaben lösen und auch umfangreiche Tests gut automatisieren.

1. Timing, Kommunikation

Häufig reicht es nicht aus, dass ein Programm aus bestimmten Eingangswerten die richtigen Ergebnisse berechnet. Es kommt auch auf die Laufzeit des Programms an oder darauf, dass verschiedene Programmteile interruptgesteuert in der richtigen Reihenfolge ausgeführt werden, obwohl es asynchrone Ereignisse gibt. Noch schwieriger wird es, wenn sich mehrere Controller miteinander unterhalten. Es gibt sehr viele Beispiele, in denen man um eine wirkliche Messung nicht herumkommt.

1.1. Einfache Messungen mit Multimeter etc.

In vielen Anwendungen gibt es periodisch auszuführenden Code. Wenn man davon ausgeht, dass dieser Code korrekt in einem bestimmten zeitlichen Abstand gestartet wird, kann man dessen Ausführungszeit recht einfach mit einem Multimeter messen: zu Beginn von diesem Code setzt man einen (ansonsten unbenutzten) Portpin, am Ende setzt man ihn zurück. Angenommen, der Portpin gibt high=5V und low=0V aus und das Multimeter zeigt 1,15V an: der Code belegt 1,15V/5V=0,23=23% der zur Verfügung stehenden Zeit.

Falls dieser Code von anderen Dingen (z.B. Interrupt-Service-Routinen) unterbrochen wird, wird deren Laufzeit natürlich mitgemessen! Evtl. ist das erwünscht, ansonsten muss man die Messung und/oder den Code aufwendiger gestalten.

Manche Multimeter bieten auch die Möglichkeit der Frequenzmessung und duty-cycle-Messung. Damit hat man in dem beschriebenen Fall (feste Periodendauer, ein einziger Abschnitt mit Portpin=high) die Möglichkeit, die Laufzeit vom Code genauer zu bestimmen und außerdem auch die Periodendauer zu prüfen.

In allen Fällen sieht man jedoch nur Mittelwerte (Spannungsmessung); bei der Frequenz- und duty-cycle-Messung hängt es vom Messgerät ab, ob ein Mittelwert oder einzelne Messwerte angezeigt werden.

Man kann nicht prüfen, ob die Bedingungen gegeben sind, unter denen diese Messmethode gültige Ergebnisse liefert!

1.2. Messen durch Code: Timer auslesen

Manches kann auch durch den Microcontroller selbst gemessen werden: man kann z.B. die Laufzeit als Differenz eines durchlaufenden Timers vor und nach einem Codeabschnitt berechnen.

Ebenso kann man prüfen, wieviel "Luft" ein Programmabschnitt noch hat, der bis zu einem bestimmten Zeitpunkt (Timerstand!) seine Rechnung beendet haben muss.

Dabei gilt jedoch immer, dass das Ergebnis nur so korrekt ist wie der Code. Im Zweifelsfall macht man bei einer Messung mit einem ordentlichen Messgerät weniger Fehler und sieht besser, ob sich der Code immer wie gewünscht verhält.

1.3. Abzählen von Befehlen

In sehr einfachen Fällen kann man auch einfach Assemblerbefehle zählen; z.B. beim AVR ist die Auführungszeit nur vom Befehl abhängig, es gibt fast keine Pipeline-Effekte.

1.4. Soundkarten-Oszi

Wenn man es besser wissen möchte, ist die nächstaufwendige Möglichkeit das "Soundkarten-Oszi": man kann spezielle Software benutzen oder einfach irgendein Programm zur Aufnahme von Audiodaten. Damit kann man immerhin zwei Kanäle (leider AC-gekoppelt) mit mindestens 44kHz abtasten.

Für manche Anwendungen reicht das; ich habe damit praktisch keine Erfahrung.

1.5. Eigenbau-Messelektronik

Bei mir ist ein Eigenbau mit folgenden Eigenschaften im Einsatz:

  • Anschluß am PC per USB zur Parametrierung, Aufzeichnung, Auswertung und Darstellung der Messwerte

  • sechs Digitaleingänge, ein Analogeingang (8 Bit)

  • verschiedene Eingangskonfigurationen möglich (1x digital bis 6x digital, analog, analog+2x digital, …)

  • die Samplerate ist abhängig von der Eingangskonfiguration. Üblicherweise erreicht man gut 500kHz bei Endlosaufzeichnung, teilweise auch erheblich mehr.

  • AVRMega mit FTDI-Chip zur Wandlung USB<→parallel, schneller externer ADC

  • durch die Endlosaufzeichnung auf dem PC können auch sehr lange Vorgänge untersucht werden und es können aufwendige Untersuchungen der Messwerte gemacht werden (man muss es halt programmieren…)

1.6. Ein "echtes" Speicheroszi

…ist prima, kann ich mir allerdings nicht leisten.


Letzte Änderung: 24.06.2010 00:00
Jens W. Wulf

Impressum
Datenschutzerklärung