Ich möchte wissen, ob Bare-Metal-Code, insbesondere Dinge wie der Initialisierungscode für Geräte / Peripheriegeräte, Testmethoden enthält, da beim Schreiben in Register nur wenig bis gar nichts schief gehen kann (sobald Sie wissen, dass alle Adressen korrekt zugeordnet sind). Außerdem hat diese Art von Code normalerweise nur sehr wenige Verzweigungen / Pfade, wenn das Gerät nur für eine einzelne Funktion konfiguriert wird. Welche Arten von Tests wären hier also erforderlich oder anwendbar?
Antworten:
Das erste, was ich auf einer neuen Karte überprüfe, ob sie einen internen Oszillator oder einen externen Kristall 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.
Die Art und Weise, wie ich es überprüfe, besteht darin, ein Programm mit einer kurzen Schleife zu schreiben, entweder in Assemblersprache, in der ich die Zyklen manuell zählen kann, oder C, solange Sie eine Demontage-Liste erhalten und dasselbe tun können - und eine LED einschalten und aus. Ich habe eine Schleife eingerichtet, die einmal pro Sekunde ausgeführt wird. Ich führe den Code aus und überprüfe, ob die LED 60 Mal pro Minute blinkt.
In Bezug auf Peripheriegeräte können Sie diese am besten überprüfen, indem Sie ein Oszilloskop verwenden, falls Sie eines haben, und die RX-Leitung für UART, die CLK-, MOSI- und Chip-Auswahlleitungen für SPI sowie die SDA- und SCL-Leitungen für überprüfen 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 diese Option deaktiviert ist, sind die meisten Leitungen niedrig (LED aus), aber einige sind hoch, wie z. B. die Empfangsleitung des UART (LED an). Wenn das Peripheriegerät aktiviert ist, sollten die meisten LEDs gedimmt sein, da die Leitungen umschalten. Durch Ausführen in einer Schleife (deaktiviert / aktiviert) ist es einfacher, den Unterschied zwischen Ein oder Dimmen 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 Terminal wie ein Programm wie RealTerm realisieren . Neben dem Testen der Benutzeroberfläche wird dies später für andere Fehlerbehebungen 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 printf verwenden, wenn Sie über die Standard-C-Bibliotheken verfügen). Aber wie Vladimir Cravero in einem Kommentar unten hervorhebt, kann dies Ihren Code etwas verlangsamen (bei 115.200 Baud nicht zu viel, da eine Zeichenzeit <10 µs ist). Verwenden Sie in ISRs und anderen zeitkritischen Codes nur LEDs.
Wie Al Bundy in einem Kommentar unten ausführt, können In-Circuit-Debugger auch nützlich sein, insbesondere wenn mehrere Haltepunkte festgelegt werden können, und noch nützlicher, wenn Sie einen Haltepunkt für einen zu ändernden Speicherort festlegen können. Nicht alle Debugger verfügen über diese Funktion.
Ich benutze Debugger jedoch nicht oft, es sei denn, ich muss zum Beispiel Bits in einem Peripherieregister betrachten. oder um einen Fehler aufzuspüren, den ich durch Inspektion nicht finden kann; oder zur rudimentären Codeabdeckungsanalyse. Aber im Allgemeinen mag ich es, Programme mit ihrer "normalen" Geschwindigkeit auszuführen, da normalerweise viele Probleme auftauchen, die möglicherweise nicht auftreten, wenn das Programm einstufig ist. Die meisten meiner Programme verwenden häufig Interrupts, was die Verwendung eines Debuggers beeinträchtigt.