Remote-Debugging von stm32f4

Ich bin auf dem Gebiet der Mikrocontroller eher unerfahren, ich komme aus einem Java-Hintergrund, daher mag die Frage ein bisschen noob erscheinen, aber ich habe nicht viele Informationen darüber gefunden.

Ist es also möglich, ein STM32F4-Board über Bluetooth zu debuggen (mit Eclipse oder einer anderen IDE)? Und wenn ja, könnten Sie mir einige Links schicken, die helfen könnten? Wir bauen ein Roboterauto, das von einem Discovery Board gesteuert wird, und das Debuggen mit einem USB-Kabel ist nicht wirklich eine Option, wenn wir nicht jedes Mal das ganze Zeug zerlegen wollen, wenn etwas schief geht. Daher wäre dies wirklich praktisch. Daher ist jede Hilfe willkommen

Antworten (3)

Ich empfehle das printf-Debugging für diese Art von Anwendungen. Es dauert eine Weile, bis man den Dreh raus hat, aber es ist ein sehr mächtiges Werkzeug, da man nur eine serielle Schnittstelle braucht und es den Programmfluss nicht unterbricht. Ich habe eine Zeit lang in einem Robotikprojekt Breakpoint-Debugging durchgeführt, und es war ein echter Schmerz. Die Art und Weise, wie der Motorantriebscode geschrieben wurde, wenn Sie einen Haltepunkt erreichten, stoppten die Motoren nicht, sodass jemand den Roboter greifen musste, damit er nicht abstürzte. Sie haben dieses Problem nicht mit printf-Debugging. Ein Paar XBee-Module reichte aus, um die seriellen Daten zur Überprüfung an einen Computer zu übertragen. Es sollte auch mit Bluetooth möglich sein, aber das bedeutet auch mehr Aufwand, um die Module richtig zu konfigurieren und mit Ihrem Computer zu koppeln.

Ich habe das Debugging im Breakpoint-Stil nie verstanden, und ich kann mir nicht vorstellen, dass es für zeitkritische Prozesse oder Prozesse mit Ereignisinteraktionen von großem Nutzen ist. Meiner Erfahrung nach ist printf (oder eher std::cout, weil ich C++ bevorzuge) DER Weg für diese Art von Systemen.
Wow, ich habe nicht wirklich darüber nachgedacht, was die Motoren stoppt ... Hm, du hast Recht, ich denke, es ist einfach nicht das richtige Werkzeug für den Job. Danke für die Warnung.
Das Debugging im Breakpoint-Stil erfordert einen Debugger, Compiler-Unterstützung für den Debugger, das richtige Schnittstellenkabel zum Ziel, viel Konfiguration usw. usw. Und es ist sehr aufdringlich und kann seltsame Probleme mit Peripheriegeräten verursachen. Es ist nicht schlecht für High-Level-Code, der auf einem PC läuft, aber für Echtzeit-Sachen ist es Mist. Für Echtzeit-Sachen ist passive Instrumentierung der richtige Weg. Ich habe sogar einen Logikanalysator verwendet, um die Codeausführung zu verfolgen, weil er weniger aufdringlich ist als ein Debugger.
Ein gutes Beispiel ist, wenn Ihre MCU über USB verfügt und Sie einen Haltepunkt erreichen, wird die USB-Kommunikation unterbrochen (USB hat regelmäßige Keepalives). Es gibt tatsächlich eine Reihe von Atmel-App-Hinweisen darüber, dass interaktives Debuggen auf Geräten mit USB-Schnittstellen nicht verwendet werden kann.
@Wouter van Ooijen: Es kommt wirklich darauf an, ich habe an einigen ereignisbasierten Sachen gearbeitet und das Einfügen von printf hat das System einfach zu sehr verlangsamt. Bei Breakpoints haben Sie die Möglichkeit, das Programm sofort nach dem Erreichen des Breakpoints fortzusetzen und nur benachrichtigt zu werden, dass es erreicht wurde.
@ConnorWolf Zumindest in gdb würden Sie dem Haltepunkt einen Befehl hinzufügen, damit er nur das ausgibt, was Sie wollen, und dann fortfahren. Auf diese Weise ist es immer noch schnell genug, um USB zu verwenden.

Ich denke, das iSYSTEM iONE.BT könnte etwas sein, das Sie verwenden könnten. Es unterstützt das Debuggen in Eclipse.

Ich würde einige davon in Kommentare schreiben, aber mein Ruf ist nicht hoch genug.

Ich verwende nie (sehr selten) printf-Debugging. Nach meiner Erfahrung hat es einen ziemlichen Einfluss auf die Leistung und das Design. Beispielsweise fordern Formatierung und Serialisierung von Werten über die Kommunikationsschnittstelle ihren Tribut. Außerdem benötigen Sie Standardbibliotheken und eine minimale Implementierung von Systemaufrufen (-lnosys wird in GCC nicht ausgeführt), die Sie in Ihrer Firmware möglicherweise nicht benötigen. Außerdem ist der Kontext mit Debugger so viel reichhaltiger als mit printf.

Es besteht natürlich die Angst vor unvorhersehbarem Verhalten der Peripheriegeräte beim Stoppen. STM hat jedoch ein konfigurierbares Peripherieverhalten, wenn die CPU gestoppt wird. Jedes Peripheriegerät kann mit CPU gestoppt oder weiterlaufen gelassen werden. iSYSTEM-Tools unterstützen die gemeinsame Konfiguration dieser. Ich habe den kostenlosen iTAG-Debugger von iSYSTEM mit meinem STM-USB-Referenzprojekt verwendet und hatte keine Probleme mit USB, während ich die CPU stoppte.

Darüber hinaus unterstützen professionelle Tools Scripting, mit dem Sie Ihre Peripheriegeräte konfigurieren können, wenn die CPU gestoppt ist. ZB Python-Skript, das den Laufstatus abfragt und Änderungen (mit Speicherschreibvorgängen, kurzen Monitorausführungen usw.) beim Stoppen und Ausführen anwendet.

Noch etwas: Möglicherweise müssen Sie Ihren Code testen und/oder überprüfen. Mit Instrumenten geht das nicht. Instrumentierung bedeutet im Grunde, Ihren Code zu Debug-Zwecken zu ändern. Aber die Release-FW ohne printfs ist nicht dasselbe wie die getestete Debug-Version mit ihnen. Oder Sie könnten printfs in Release FW belassen :).

Ich empfehle C über C++ für eingebettete Projekte. C++ benötigt mehr Ressourcen als C. Compiler müssen nichts über den Debugger wissen. Es ist anders herum. Sie können nicht über WLAN nachverfolgen, da nicht genügend Bandbreite vorhanden ist. Obwohl ich Trace-Pins (falls auf Ihrem Paket verfügbar) frei lassen würde, falls Sie das Trace-Port-Analysator-Tool irgendwann in der Zukunft anschließen möchten.

Für Cortex-M ist ein Bluetooth-Debugger verfügbar. Vor kurzem wurde auf embedded.com ein Artikel darüber veröffentlicht: http://www.embedded.com/electronics-products/electronic-product-reviews/debug-and-optimization/4422586/iSYSTEM-introduces-wireless- Debugger

Remote-Debugging von stm32f4
AntwortenHierDatenschutz-Bestimmungen1y, 0v