Frage:
Testen des Lebenszyklus von Software für eingebettete Anwendungen
Ahmed Saleh
2014-03-26 13:34:10 UTC
view on stackexchange narkive permalink

Ich habe kein JTAG und kann es mir für meinen ARM Cortex M3 Chip nicht leisten.

Ich frage mich, wie Profis ihre Anwendungen debuggen?

  1. Flashen Sie Ihre uC jedes Mal häufig, dann führen Sie sie aus, testen sie und ändern sie dann? Ist das eine schlechte Praxis?
  2. Verwenden Sie UART oder LCD nur zum Schreiben von Protokollen auf dem Bildschirm?
  3. ol>

    Ich benötige Tipps und Tricks von Fachleuten :)

Es hängt davon ab, was Sie zur Verfügung haben. Ein JTAG ist nett. UART funktioniert auch. Durch einfaches Blinken einer LED kann verwendet werden. Was auch immer die Arbeit erledigt.
@PeterKarlsen Ich habe nur LCD, UART kann nicht verwendet werden, es wird mit dem LCD FSMC-Bus geteilt. Ich habe auch kein JTAF, ich denke JTAG würde den Prozess einfacher machen?
Ein JTAG würde es wahrscheinlich einfacher machen. Sie befinden sich in der gleichen Situation wie früher. Ich hatte viele Jahre keinen JTAG. Ich hatte ein Oszilloskop, also habe ich es so oft an ein paar Ersatzanschlüsse des Geräts angeschlossen, an dem ich gearbeitet habe. Dann würde ich die Port-Bits für bestimmte Ereignisse in meinem Code umschalten, um eine Vorstellung davon zu bekommen, was los war. Sie können wahrscheinlich das LCD verwenden, aber es ist nicht einfach, das Timing zu erfassen, wenn Sie das LCD verwenden.
@PeterKarlsen Das Problem ist, dass ich eine grafische Anwendung wie einen 3D-Renderer erstelle und dass viele Tests erforderlich wären: /
So etwas wie ein 3D-Renderer sollte gut getestet werden, bevor man sich der eingebetteten CPU nähert.
@BrianDrummond +1 Das ist ein guter Punkt. Ich werde eine SDL-Anwendung schreiben, die über ANSI-C auf den Frame Buffer usw. zugreifen kann, und sie dann direkt auf die uC portieren. Eigentlich habe ich das gemacht und es hat für eine Dreiecksrasterung funktioniert.
Nicht direkt zum Thema, aber ... viele Evaluierungsboards haben JTAG / SWD eingebaut. Die STM32F4 Discovery-Evaluierungskarte enthält beispielsweise ein eingebettetes STLINK v2 USB JTAG-Modul und kostet nur etwa 15 US-Dollar. Der JTAG / SWD ist langsam, aber perfekt funktionsfähig und kann von der Bewertungskarte auf ein anderes Zielgerät umgeleitet werden. Das könnte zumindest Ihr Problem lösen, das Sie sich nicht leisten können.
Fünf antworten:
#1
+9
markrages
2014-03-26 22:18:36 UTC
view on stackexchange narkive permalink

Dies ist eher ein Blog-Beitrag, aber hier ist:

Wenn Sie in C schreiben, können Sie Ihren Code kompilieren und auf Ihrem Desktop ausführen. Dadurch werden die Hardwaretreiber auf niedriger Ebene nicht getestet, es kann jedoch der gesamte Logikcode getestet werden.

Empfehlungen zu diesem Ansatz:

  1. Wenn Sie ARM verwenden, können Sie für beide Zwecke denselben Compiler (gcc) verwenden. Dann funktionieren alle compilerspezifischen Erweiterungen weiterhin.
  2. Compilerspezifische Erweiterungen sind jedoch unerwünscht. Daher können Sie die Desktop-Version stattdessen mit Clang / LLVM kompilieren (mit dem Vorteil besserer Fehlermeldungen).
  3. Mein Desktop ist ein Linux-PC. Nichts in diesem Ansatz ist Linux-spezifisch. Aber Linux macht sicher eine schöne C-Entwicklungsumgebung.
  4. Verwenden Sie stdint.h und Typen wie uint64_t anstelle von " unsigned long int ". Auf diese Weise erhalten Sie das gleiche Verhalten, wenn Sie auf verschiedenen Systemen kompiliert werden.
  5. Achten Sie jedoch auf die Ganzzahl-Promotion von C. Verwenden Sie nach Möglichkeit (auf ARM) einen 32-Bit-PC zum Testen des 32-Bit-ARM-Codes.
  6. In Bezug auf Hardwaretreiber habe ich zwei Ansätze als vorteilhaft befunden ein Live-Prototyp auf dem PC. Der PC verfügt über eine Echtzeituhr und eine Netzwerkverbindung sowie ein Display und Eingänge, sodass für diese gesorgt ist. (Mein PC verfügt sogar über einen Beschleunigungsmesser.) Mit libSDL können Sie ein Bild Ihres Endprodukts animieren und Tastendrücke empfangen. Schließen Sie für andere Funktionen Ihres Boards Entwicklungsboards an oder fälschen Sie es. Der Vorteil dieses Ansatzes besteht darin, dass Sie ihn im Live-System verwenden und sich die Mühe ersparen können, Hardware herzustellen, wenn Sie feststellen, dass er das zu lösende Problem nicht löst.
  7. Erstellen Sie einen toten Prototyp, der Eingabeereignisse aus einer Datei liest und Ausgabeereignisse in eine Datei schreibt. Zum Testen können Sie jetzt Ereignisse aufzeichnen (oder synthetisieren), die bestimmten Szenarien entsprechen, die Sie testen möchten. Und dann können Sie überprüfen, ob die richtigen Dinge in die Ausgabe geschrieben wurden. Dies hat den Vorteil, dass eine vollautomatische Testsuite übrig bleibt, die Sie zur Erstellungszeit ausführen können, um Regressionen abzufangen.
  8. ol>
  9. Verwenden Sie die Compileroptionen -Wall -Wextra -Werror und behalten Sie Ihre Code ohne Warnung. Sie werden einige Zeit damit verbringen, Warnungen zu patchen, aber dies beschleunigt die Codierung, indem die Debugging-Zeit verkürzt wird.
  10. Kompilieren Sie die PC-Version mit Schmutzfängern. Dies fängt eine Menge Zeiger Unfug. Einige Leute empfehlen Valgrind, aber es ist nicht so nützlich für Code, der niemals malloc () oder free() verwendet. Li
  11. Verwenden Sie zum Debuggen von PCs GDB oder DDD oder printf () nach Geschmack. Es gibt eine große Auswahl an ausgereiften und nützlichen Desktop-Debugging-Tools.
  12. Auch wenn ich nicht das vollständige PC-Debug-Setup durchführe, werde ich häufig einen main () für Unit-Tests einbinden Code> Funktion am Ende einer Datei, die #define ist. Dieser main () probiert alle kniffligen Funktionen in der Datei aus und gibt 0 für All-Pass oder asserts () für Fail zurück. Dann füge ich dem Makefile ein "Test" -Ziel hinzu, das die Tests der einzelnen Dateien kompiliert und ausführt.
  13. Es gibt viele Unit-Test-Plattformen, die Sie verwenden können. Es gibt so viele, weil sie sehr einfach zu schreiben sind. Ich benutze sie nicht. Ich möchte keinen schönen Bericht über "Prozent Tests bestanden". Ich möchte, dass mein Test beim ersten Fehler stirbt. Visual Basic hatte früher eine lächerliche Funktion namens " bei nächsten Fehlern". Ich weiß nicht, warum Sie diese Funktion für Komponententests benötigen.
  14. ol>

    Wenn Sie auf diese Weise eigenständige Unit-Tests durchführen, werden Sie feststellen, dass Sie nur sehr wenig On-Chip-Debugging benötigen. Darüber hinaus ist die Portierung auf verschiedene Hardwareplattformen viel einfacher, da die Kernlogik und die Hardwaretreiber gut voneinander getrennt sind.

#2
+4
Rev1.0
2014-03-26 14:01:02 UTC
view on stackexchange narkive permalink

    Bei der Arbeit mit eingebetteten Systemen ohne Betriebssystem oder Remote-Konsole wird häufig häufig geflasht, um Änderungen zu testen. Wenn Sie ein Linux-basiertes System haben, können Sie möglicherweise einfach einen Python-Skriptcode im laufenden Betrieb ändern.

  1. Ich persönlich finde eine UART-Konsole für die Debug-Ausgabe und die Ausführung von Debug-Befehlen von unschätzbarem Wert. Dies ist eine gute Möglichkeit, den Programmablauf zu verfolgen und bestimmte Funktionen auszulösen.
    Ich verwende in der Regel unterschiedliche Debug-Ebenen, damit ich zwischen der Anzeige nur von Fehlern und der Aktivierung der ausführlichen Protokollierung wechseln kann, um beispielsweise alles im Detail zu verfolgen.

  2. ol>

    In Bezug auf JTAG / beim System-Debugging: Auch wenn JTAG verfügbar ist, verwende ich es nur zum Aufspüren von Algorithmusproblemen (nach der Berechnung) oder zum Überprüfen von Register- / Hardwarekonfigurationswerten. Ich benutze es selten, um dem Programmablauf zu folgen. Ich finde das einfacher und schneller mit der Debug-Konsolenausgabe.

#3
+1
Dejvid_no1
2014-03-26 18:05:57 UTC
view on stackexchange narkive permalink

Meine 5c.Somethings werden mit JTAG-Debuggern schneller erledigt: Mehrere Variablen gleichzeitig betrachten, den Code durchgehen, Haltepunkte hinzufügen. Größere Speicherorte anzeigen. Dumme Fehler abfangen: Dieser Interrupt, den Sie vergessen haben, zu deaktivieren.

#4
  0
John U
2014-03-26 20:10:33 UTC
view on stackexchange narkive permalink

Sie können mit fast keinem E / A zum Debuggen auskommen, aber die Schwierigkeit ist umgekehrt proportional zum verfügbaren E / A - das Debuggen eines E / A-Pins mit einem Bereich dauert viel länger als das Debuggen eines JTAG oder eines ähnlichen Debuggers, der die CPU stoppen kann & untersucht alles, tritt durch, verfolgt usw.

Für grundlegende Dinge benötigen Sie nicht viel Debugging, für sehr komplexe Dinge gilt: Je mehr, desto besser.

#5
  0
JRobert
2014-03-27 01:15:43 UTC
view on stackexchange narkive permalink

Für Systeme, die mit voller Geschwindigkeit ausgeführt werden mussten (z. B. die Steuerung von Objekten, die nicht an einem Haltepunkt angehalten werden konnten und nicht unkontrolliert ausgeführt werden dürfen) und die die erforderliche serielle Datenrate während der Ausführung nicht tolerieren oder erreichen konnten, Ich habe Rohproben in ein Array gestopft, um sie am Ende des Laufs zu sichern und offline zu interpretieren. Es wird eine minimale Ausführungszeit auf Kosten des Speicherplatzes hinzugefügt.



Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...