Gibt es Standardtestmethoden für Bare-Metal-Code?

Das erste, was ich auf einem neuen Board überprüfe, ob es einen internen Oszillator oder einen externen Quarz verwendet, ist, dass ich die Taktfrequenz richtig eingestellt habe. Dies ist wichtig, da viele Peripheriegeräte wie UART, SPI, I2C und Timer davon abhängen.

Ich verifiziere es, indem ich ein Programm mit einer kurzen Schleife schreibe, entweder in Assembler, wo ich die Zyklen manuell zählen kann, oder in C, solange Sie eine Disassemblierungsliste erhalten und dasselbe tun können - und eine LED einschalten und aus. Ich habe eine Schleife so eingerichtet, dass sie einmal pro Sekunde ausgeführt wird. Ich führe den Code aus und überprüfe, ob die LED 60 Mal in einer Minute blinkt.

Was die Peripheriegeräte betrifft, so können Sie sie am besten mit einem Oszilloskop überprüfen, falls Sie eines haben, und sich die RX-Leitung für UART, die CLK-, MOSI- und Chipauswahlleitungen für SPI sowie die SDA- und SCL-Leitungen ansehen I2C, und überprüfen Sie, ob die Leitungen umschalten und das Timing korrekt aussieht.

Wenn Sie kein Oszilloskop haben, können Sie LEDs an diesen Leitungen anbringen und dann die Peripheriegeräte aktivieren oder deaktivieren. Wenn sie deaktiviert sind, sind die meisten Leitungen niedrig (LED aus), aber einige sind hoch, wie die RX-Leitung des UART (LED an). Wenn das Peripheriegerät aktiviert ist, sollten die meisten LEDs dimmen, da die Leitungen umschalten. Durch das Ausführen einer Schleife (deaktiviert/aktiviert) ist es einfacher, den Unterschied zwischen ein oder gedimmt zu erkennen.

Für den UART können Sie die TX-Leitung als Schleife mit der RX-Leitung verbinden. Sie können dann auch ein UART-zu-USB-Kabel anschließen und auf dem PC ein reales Terminal mit einem Programm wie RealTerm verbinden . Neben dem Testen der Schnittstelle wird dies später für andere Debugging-Aufgaben nützlich sein.

Für andere Codeteile verwende ich nach Bedarf mehrere LEDs, um anzuzeigen, dass verschiedene Pfade im Code ausgeführt werden. Wenn der UART funktioniert und mit einem PC verbunden ist, können Sie Ihren Code mit Aufrufen einer Unterroutine bestreuen, um eine Nachricht auszugeben, die anzeigt, welche Punkte das Programm erreicht hat (oder verwenden Sie printf, wenn Sie die Standard-C-Bibliotheken zur Verfügung haben). Aber wie Vladimir Cravero in einem Kommentar unten darauf hinweist, kann dies Ihren Code etwas verlangsamen (bei 115.200 Baud nicht zu viel, da die Zeit eines Zeichens < 10 µs beträgt). Aber in ISRs und anderem zeitkritischem Code verwenden Sie einfach LEDs.

Wie Al Bundy in einem Kommentar unten betont, können In-Circuit-Debugger auch nützlich sein, insbesondere wenn man mehrere Breakpoints setzen kann, und noch nützlicher, wenn man Breakpoints an einem Speicherort setzen kann, der geändert wird. Nicht alle Debugger haben diese Funktion.

Allerdings verwende ich Debugger nicht oft, es sei denn, ich muss zum Beispiel Bits in einem Peripherieregister betrachten; oder um einen Fehler aufzuspüren, den ich nicht durch Inspektion finden kann; oder zu einer rudimentären Code-Coverage-Analyse. Aber im Allgemeinen führe ich Programme gerne mit ihrer "normalen" Geschwindigkeit aus, da normalerweise viele Probleme auftreten, die möglicherweise nicht auftreten, wenn das Programm in Einzelschritten ausgeführt wird. Die meisten meiner Programme verwenden häufig Interrupts, was die Verwendung eines Debuggers stört.