Hallo, ich debugge ein Eclipse Template-Projekt (STM32F4xx StdPeriph C/C++ Project) mit openocd und arm-none-eabi-gdb auf einem STM32F429 Discovery. Das Beispiel ist ein Ledblinker mit fprint-Ausgabe. Das Projekt ist von Eclipse generiert ohne irgendwelche Anpassungen meinerseits. Die LED blinkt und zu den Breakpoints springen klappt auch. Nur die printf-Debugausgaben kommen nicht an. Weil ich nichts konkretes finde, war meine naive Annahme, dass die Ausgaben im log des Openocd-Daemon auftauchen sollten. Tun sie nicht. Kann mir jemand erklären, wie das mit den printf-Ausgaben beim debuggen funktioniert?
Wozu brauchst du noch UART-Ausgaben, wenn du in deiner IDE debuggen kannst?
Natalia schrieb: > Kann mir jemand erklären, wie das mit den printf-Ausgaben beim debuggen > funktioniert? Du haettest es leider kaum schlechter spezifizieren koennen. Also es gibt drei wesentliche Ansaetze, um printf auf einem Mikrocontroller nutzen zu koennen. 1. Du setzt printf auf einen UART Kanal, der dann entweder direkt mit einem Levelshifter an den COM Port deines Computers angeschlossen wird oder ueber einen UART/USB Adapter mit dem PC verbunden wird. 2. Du schliesst den Mikrocontroller zusaetzlich als USB Geraet an dem Computer an und emulierst einen virtuellen COM Port. Dafuer benoetigst du aber zusaetzliche Software auf dem Mikrocontroller. 3. Du verwendest Semihosting, welches dann ueber deinen Debugger laeuft (in deinem Fall openOCD). In jedem Fall musst du printf mit deinem gewuenschten Output zuweisen (das geschieht nicht von alleine!). Am Besten funktioniert normal die erste Variante. Die zweite Variante ist mit aufwand verbunden und die dritte Variante ist irgendwie nicht so schoen und ich wuerde generell davon abraten, wenn es nicht noetig ist. Ich nehme jetzt aber mal an, dass du die dritte Variante oder gar keine Variante verwendest. Falls du es nun also auf die dritte Variante anlegst, dann sollte dir der folgende Link helfen koennen: https://plus.google.com/+AndreyYurovsky/posts/5rupuziHKGC
Genau, Semihosting, danach hatte ich gesucht. Es geht darum, beim Entwickeln ein serielles Monitoring zu haben. Warum findest du die Variante unschön? Wenn ich dich richtig verstehe, kann ich doch später einfach printf auf den UART (Variante 1) umbiegen. Dank dir für den Link!
Ok, glaube verstanden zu haben, warum du Semihosting nicht so schön findest. Korrigier mich bitte: Eine mit Semihosting kompilierte/gelinkte Firmware kann praktisch nicht eigenständig ohne den Debugger laufen, weil sie bei IO-Operationen in eine Exception läuft, die nur vom Debugger aufgelöst werden kann?
Natalia schrieb: > Wenn ich dich richtig verstehe, kann ich doch später > einfach printf auf den UART (Variante 1) umbiegen. Ja, einfach den UART initialisieren und die eine Funktion zum Schreiben der Zeichen austauschen. Ich hab mir dafuer ein paar von denen hier gekauft: http://www.ebay.de/itm/USB-2-0-an-RS232-TTL-UART-Module-Konverter-6PIN-Serial-/251125751211?pt=DE_Computing_USB_Kabel_Hubs_Adapter&hash=item3a7842ddab Damit kannst du einfach und guenstig ein Mikrocontroller mit Putty, HTerm, CoolTerm oder was auch immer debuggen. Ein Vorteil dabei ist, dass du die COM Verbindung nur einmal aufbauen musst und wenn du den Mikrocontroller neu startest, dann ist das andere Programm immernoch verbunden. Natalia schrieb: > Genau, Semihosting, danach hatte ich gesucht. Es geht darum, beim > Entwickeln ein serielles Monitoring zu haben. Die Ausgaben ueber UART koenntest du theoretisch auch im Code lassen und spaeter am fertigen Produkt noch fuer Kontrollen nutzen. Natalia schrieb: > Ok, glaube verstanden zu haben, warum du Semihosting nicht so schön > findest. Korrigier mich bitte: Eine mit Semihosting kompilierte/gelinkte > Firmware kann praktisch nicht eigenständig ohne den Debugger laufen, > weil sie bei IO-Operationen in eine Exception läuft, die nur vom > Debugger aufgelöst werden kann? Ja, nein ^^ Also es ist einer der Effekte, den ich nicht mag. Danach kommt dann aber auch noch die Frage, wie die Daten aus dem Chip an den PC kommen. Der Debugger muss dafuer massiv in die Programmausfuehrung eingreifen. Der Effekt sind dann ganz wilde Ausfuehrungszeiten, auf die du dich nicht mehr verlassen kannst. Planst du hingegen eine UART Ausgabe ein, so kannst du dich eher auf das Verhalten verlassen (sowohl mit, als auch ohne Debugger).
Du hast das Thema schon mal sehr aufgehellt für mich. Danke. So einen UART-RS232-Konverter hab ich irgendwann mal zusammengelötet. Muss den nur finden :) Scheint mir auf jeden Fall jetzt auch als bessere Lösung.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.