Hallo!
Ich habe bis jetz nur mit Arduino, Raspberry und STM32 Discovery
Erfahrungen gesammelt.
Bei Projekten geht die meiste Zeit flöten um nach fehlern im Code zu
suchen.
Da ich geschäftlich mit Softwareentwicklung zutun habe kenne ich zb.
Visual Basic oder VBA sowie Javascript. In allen diesen Sprachen kann
man mit den meisten Tools den Code an bestimmten Stelen anhalten und
dann sehen was die variablen für Werte haben oder was gerade passiert
ist.
Logischerweise geht das da ja der Code nur Software auf dem selben PC
ist. Die Mikrocontroller sind ja eigenständige Geräte welche dann
laufen.
Variablen können jeweils nur über "Serial.print" und so weiter dem
Benutzer gezeigt werden.
Gibt es per Zufall auch sowas für Mikrocontroller wo man direkt Zeilen
vom Code stoppen kann? Darf natürlich auch was kosten, denn ich habe in
den letzen Monaten ein grossteil der Zeit bei Mikrocontrollerentwicklung
für mühsame Fehlersuche verschenkt.
DPO schrieb:> Gibt es per Zufall auch sowas für Mikrocontroller wo man direkt Zeilen> vom Code stoppen kann?
Ja, kann jeder Cortex-M3, -M4 oder -M0. Gibt es sogar auf einigen
Arduino Boards drauf. AVR sind da teilweise deutlich eingschränkt -
außerdem braucht man da den Atmel ICE.
Programmer mit JTAG oder SWD gäbe es zum Basteln kostentlos (siehe
OpenOCD) oder in Devel-Boards integriert. Ich habe hier gute Erfahrungen
mit JLink Adaptern gemacht - die gibts original von Segger.
Nun. man muss seinen Code eben schon mit Debugging im Konzept planen.
Was man unbedingt vermeiden sollte ist blockiernder Code, wo man an
beliebig vielen Stellen stehen bleiben kann. Man spart sich extrem viel
Zeit, wenn man statt dessen mit einer Statusmaschine und strikt
nicht-blockierendem Code arbeitet, die genau an einem Punkt wartet,
naemlich im main. Dann kann man sich per seriellem Protokoll den Zustand
auslesen und weiss wo das Programm steht.
Erhoffe Dir aber nicht allzu viel Nutzen von so einem Debugger. Denn
viele Anwendungen funktionieren nicht mehr, wenn man das Programm
anhält.
Eine Waschmaschine wird zum Beispiel vielleicht mit Wasser überflutet,
und ein selbst fahrender Roboter fährt womöglich gegen die nächste Wand.
Vergiss Hardware Debugger. Wenn der auf einen Breakpoint auflaeuft ist
der externe Kontext kaputt. Wenn ich in einem laufenden Protokoll
stoppe, geht das externe System in einem Timeout. Was macht ein
Stellglied wenn der Debugger auf einen Breakpoint laeuft? Weiter heizen
?
> Vergiss Hardware Debugger.
So eine Aussage ist sehr dumm.
Natuerlich gibt es Faelle wo ein anhalten eher schlecht ist im Sinne von
ich gehe im Singlestep da durch. Aber selbst dann kann man sich noch mal
die augenblicklichen Variablen und Speicherinhalte anschauen und pruefen
ob die die eigenen Vorstellungen mit der Realitaet uebereinstimmen.
Und es ist auch ganz nett wenn man komplexere Algorithmen mal unit tests
unterziehen kann.
Ohne Debugger zu arbeiten ist eine grosse Zeitverschwendung.
Olaf
> Und es ist auch ganz nett wenn man komplexere Algorithmen mal> unit tests unterziehen kann.
Dazu gibt es Simulatoren, z.B. der im im AVR Studio integrierte.
Abgesehen davon kann man Algorithmen genau so gut auf einem PC testen.
Wenn der Code dort richtig funktioniert, wird er es auf einem µC ebenso
tun.
>> Ohne Debugger zu arbeiten ist eine grosse Zeitverschwendung.> So eine Aussage ist sehr dumm.
Flaschensammler Troll schrieb:> Vergiss Hardware Debugger. Wenn der auf einen Breakpoint auflaeuft ist> der externe Kontext kaputt. Wenn ich in einem laufenden Protokoll> stoppe, geht das externe System in einem Timeout. Was macht ein> Stellglied wenn der Debugger auf einen Breakpoint laeuft? Weiter heizen> ?
Das stimmt. Ich bin Entwickler bei SpaceX und musste schon einige male
in der Falcon 9 mitfliegen bis das Teil endlich heil landen konnte.
Durch die Debuggerbreakpoints ist das Ding meist schief auf der
Plattform gelandet und umgekippt. Elon hat total geflucht und einem
Kollegen sogar gedroht ihn demnächst zum Mond zu schiessen ...
Stefan U. schrieb:> Erhoffe Dir aber nicht allzu viel Nutzen von so einem Debugger. Denn> viele Anwendungen funktionieren nicht mehr, wenn man das Programm> anhält.
Ich bevorzuge daher das gute alte printf über die UART bei voller Fahrt.
Von einem Hardwaredebugger abzuraten ist schlicht unfug. Es erleichtert
einem die Arbeit ernorm. Wenn man weiß, an welchen stellen man nicht
stoppen darf, kann man trotzdem in der gesamten restlichen Lauzeit
stoppen und debuggen.
Die wenigsten werden auch an sensiblen Geräten werkeln, wo die Maschine
kaputt geht, wenn man mal stoppt. Wie man heutzutage noch auf IDE, +
Debugger im professionellen Bereich verzichten kann ist mir ein Rästel.
Niemand arbeitet und plant so vorrausschauend, dass man nie Fehler
macht. Aber einige tippen ihren Code auch noch ausschließlich im Notepad
und rufen eine Batch zum Kompilieren auf.
An den TO: Die meisten µC können heutzutage zu einem beliebigen
Zeitpunkt gestoppt werden, wobei man dann alle verfügbaren Variablen
sich betrachten kann. AUch Breakpoints sind natürlich kein Problem. In
der Regel braucht man hierfür spezielle, aber sehr günstige Hardware,
beim STM32 kostet diese z.B. keine 20€.
DPO schrieb:> auch sowas für Mikrocontroller wo man direkt Zeilen> vom Code stoppen kann?
Das Zauberwort heißt "In Circuit Emulator", schaust Du mal, ob es sowas
für Deinen Controller gibt.
Ich habe sowas mit der 6502-CPU benutzt, anstelle der CPU wurde eine
Stück Hardware per Kabel eingesteckt. Der angeschlossene PC hatte die
volle Kontrolle über Bits und Register - das war aber auch gehörig
teuer.
> Die wenigsten werden auch an sensiblen Geräten werkeln,> wo die Maschine kaputt geht
Mag sein, doch wie willst du z.B. so eine Motor-Regelung im laufenden
Betrieb anhalten ohne dass sie in diesem Moment gleich völlig versagt?
> Aber einige tippen ihren Code auch noch ausschließlich im> Notepad und rufen eine Batch zum Kompilieren auf.
Na und? Was ist daran falsch? Manche Leute sind stolz darauf, ohne
Stützräder programmieren zu können.
> Wie man heutzutage noch auf IDE, + Debugger im professionellen> Bereich verzichten kann ist mir ein Rästel.
Möglicherweise hast du das Arbeiten ohne Debugger nicht kennen gelernt.
Vor 30 Jahren war das noch überall nicht so einfach, wie heute.
Bei den ARM Cortex gibt es verschiedene Möglichkeiten, sogar LiveView im
laufenden Betrieb.
Ohne Debugger ist wie Autofahren ohne Sicherheitsgurt. Mir kann nix
passieren weil ich ja weiß wie man fährt. Fehler machen nur die anderen.
Jetzt fehlt nur noch W.S. Und seine Lerbetty.
Meine erste Aufgabe im industriellen Umfeld war die Erstellung eines
Debuggers für ein proprietäres System, damit haben wir den Markt
gerockt. Bis heute.
Stefan U. schrieb:>> Aber einige tippen ihren Code auch noch ausschließlich im>> Notepad und rufen eine Batch zum Kompilieren auf.>> Na und? Was ist daran falsch? Manche Leute sind stolz darauf, ohne> Stützräder programmieren zu können.
Ohne Stützräder? Also von Hand Maschinencode über eine Hex-Tastatur
eintippen? Assembler oder gar Compiler sind ja sowas von Stützräder.
> Ohne Stützräder? Also von Hand Maschinencode über eine Hex-Tastatur> eintippen?
Das meinte ich anders. Ich meinte, Code Eintippen ohne Intellisense
(oder wie auch immer andere Hersteller das nennen).
>> und rufen eine Batch zum Kompilieren auf.> Assembler oder gar Compiler sind ja sowas von Stützräder.
Wie gesagt rufen sie nach dem Editieren eine Batch (oder Make) zum
Compilieren auf. Von Compiler weglassen habe ich nichts geschrieben.
Stefan U. schrieb:> Möglicherweise hast du das Arbeiten ohne Debugger nicht kennen gelernt.> Vor 30 Jahren war das noch überall nicht so einfach, wie heute.
Na doch, genauso wie der TO als Anfänger. Anfangs immer mit UART
Textausgabe oder LED leuchten debuggt z.B. - irgendsowas halt. Bis ich
dann mal gesagt bekommen habe, dass ich mit einem Debugger + IDE auch im
laufenden Betrieb in die Variablen schauen kann - eine Erlösung.
Meine Arbeitskollegen sind froh, dass die Zeiten von damals vorbei sind,
wo man sich noch einen Katalog bestellen musste, statt PDF aus dem
Internet oder man nach einem einmaligen programmieren und Fehler gleich
einen neuen Prozessor auflöten durfte oder man eine Hextabelle von Hand
ohne Programmierer eintippen durfte...
Die Zeiten sind vorbei. Oder malst du deine PCBs auch noch auf nem Blatt
Papier (ich hoffe nicht)?
> Die Zeiten sind vorbei.
Ja, gottseidank.
Ich will ja nicht vom Debugging abraten, so ein Teil gehört heute klar
zur Standardausstattung. Aber wenn man vorher gewohnt ist, mit LED's und
printf() zu Arbeiten, dann sollte man eben nicht allzu viel neues Glück
vom Debugger erwarten.
Er bringt nur wenig zusätzliche Erkenntnisse, es ist eher ein
Komfort-Faktor. Aber nicht an jeder Stelle und nicht in jeder Anwendung.
Mir fällt gerade noch ein Beispiel ein, wo man so einen Debugger kaum
gebrauchen kann: Der ESP8266. Deswegen hat er wohl auch gar keinen
Debugger Anschluss.
Viel schlimmer finde ich, dass hier immer wieder leute auftauchen, die
irgendwelche Arduino Code-Fragmente zusammen copy-pasten und dann wenn
nichts geht, kommen sie nicht einmal auf die Idee, Serial.print() zu
benutzen. Dabei ist doch gerade das eine elementare Funktion im Arduino
Framework und wird schon bei der allerersten Hello-World Anwendung
geübt.
Stefan U. schrieb:> Mir fällt gerade noch ein Beispiel ein, wo man so einen Debugger kaum> gebrauchen kann: Der ESP8266. Deswegen hat er wohl auch gar keinen> Debugger Anschluss.
Auch hier zeigt eine spontane Google Suche, dass es scheinbar einige
Möglichkeiten gibt, diesen klassisch zu debuggen (also ich meine mit
Breakpoints und nicht mit LEDs).
Stefan U. schrieb:> Na und? Was ist daran falsch? Manche Leute sind stolz darauf, ohne> Stützräder programmieren zu können.
Mein erstes Programm auf einem µC (80C535) war in Assembler. Ich hatte
das Programm ohne vorhandene Hardware entwickelt und sogar im
Einzelschritt abgearbeitet. Letzteres ohne Strom mittels Ausdruck auf
Endlospapier. Das Programm war nicht groß - eine Art Ampelsteuerung für
Bogenturniere. Soweit ich mich erinnern kann (ist bereits über 30 Jahre
her) passte gerade in ein 2764 EPROM, also knapp 8kB.
Das Programm lief anschließend in der Hardware auf Anhieb. Darauf war
und bin ich immer noch Stolz.
Johannes S. schrieb:> Ohne Debugger ist wie Autofahren ohne Sicherheitsgurt.
Wer seinen eigenen Programmcode wirklich kennt und das Programm auch im
Kopf "simulieren" kann, braucht keinen Debugger. Ok, auf einem ARM und
einem komplizierteren Programm würde ich das sicherlich nicht mehr
können. Die 30 Jahre haben auch an mir Spuren hinterlassen.
Nils N. schrieb:> Die Zeiten sind vorbei. Oder malst du deine PCBs auch noch auf nem Blatt> Papier (ich hoffe nicht)?
Mit Klebe-Lötaugen auf Klarsichtfolie. Wie soll man denn mit nem Blatt
Papier belichten?
> Das Programm lief anschließend in der Hardware auf Anhieb. Darauf war> und bin ich immer noch Stolz.
Das kannst du auch. Programmieren war damals noch richtige
Knochenarbeit. Ich will gar nicht wissen, wie sich die Leute vor uns
ohne Hochsprachen oder gar ohne Assembler abgekämpft haben.
> Wie soll man denn mit nem Blatt Papier belichten?
Dazu gab es früher Spray, das machte normales Papier ausreichend
durchsichtig.
Brummbär schrieb:> Wer seinen eigenen Programmcode wirklich kennt und das Programm auch im> Kopf "simulieren" kann, braucht keinen Debugger.
Im Leben nicht. Ich unterscheide da zwischen Programmen die
funktionieren und anderen die robust sind. Selbst wenn auf Speicher
zugegriffen wird der nicht initialisiert ist, wenn auf einen Index zu
weit zugegriffen wird o. Ä. funktioniert ein Programm vielleicht. Aber
eine kleine Nebenbedingung
geändert und bämm.
Softwarequalität entsteht durch Erfahrung und Testen - nicht durch
Debuggen. Der Debugger ist lediglich ein praktisches Werkzeug, zu dem es
Alternativen gibt.
> Im Leben nicht....
Und dein Debugger hilft Dir dabei, diese Fehler zu vermeiden? Wie das
denn?
Egal, mit welchen Debugtools man arbeitet, ob per serieller
Kommunikation, oder per Hardware Breakpoint. Die Anwendung muss mit
Debuggen als Konzept geplant worden sein. Auch auf der Hardwareebene.
Man sollte etwas weiter denken wie an einen herstellergelieferten
Hardware debugger. Mit dem kann man Zahlen und Zustaende anschauen. Zu
einer anderen Zeit moechte man zB Prozessdaten haben, in Echtzeit. Fuer
solche Faelle hab ich mal einen 8-fach DAC auf eine Einstecklatine
gepackt. Der 8-fach DAC kann per SPI angesteuert werden, ein paar
Befehle, die kaum zusaetlich CPU Zeit benoetigen. So lassen sich bis zu
8 Werte parallel mit einen Oszilloskop verfolgen.
Das System bleibt an der Fehlerquelle stehen. Debugger dran und man
sieht im Quellcode warum. Und ooops, ja so sollte das eigentlich nicht
laufen. Eigentlich.
> Man sollte etwas weiter denken ...
Da bist du mir gerade zuvor gekommen. Ich wollte auch gerade drauf
hinweisen, dass manchmal der Verlauf von veränderlichen Zahlen (z.B.
Messwerte und Regelparameter) interessanter ist, als einzelne
Schnappschüsse eines Breakpoints.
> Das System bleibt an der Fehlerquelle stehen.> Debugger dran und man sieht im Quellcode warum.
Dafür sind diese Dinger wirklich hilfreich.
Man kann so etwas auch mit Textausgaben an strategisch günstigen Punkten
erreichen. Das ist allerdings mühsamer.
> Das System bleibt an der Fehlerquelle stehen.
So, so. Toll. Dann muss man ja nur noch den Zustand auslesen, und gut
ist. zB der Spurassistent hat ploetzlich links blockiert, das Fahrzeug
hat den Kreisel gemacht und ist dann den Abhang runter. Dann muessen die
Zeilen ja nur noch signiert sein, und ich hab den Schuldigen..
transparenter Flachtroll schrieb:> Das System bleibt an der Fehlerquelle stehen.>> So, so. Toll. Dann muss man ja nur noch den Zustand auslesen, und gut> ist. zB der Spurassistent hat ploetzlich links blockiert, das Fahrzeug> hat den Kreisel gemacht und ist dann den Abhang runter. Dann muessen die> Zeilen ja nur noch signiert sein, und ich hab den Schuldigen..
Richtig. Da musste man vorher überlegen ob man ein Release auf die
Menschheit losslässt. Heute ist das entspannter und man testet im Feld.
Johannes S. schrieb:> Ohne Debugger ist wie Autofahren ohne Sicherheitsgurt. Mir kann nix> passieren weil ich ja weiß wie man fährt. Fehler machen nur die anderen.
Es ist ein Trugschluß zu denken, mit Debugger dürfe man Fehler machen.
Fehler müssen sich nicht unmittelbar auswirken, sondern können zu
Zeitbomben werden.
Ein Debugger ist als Sicherheitsgurt gegen Fehler völlig untauglich. Man
muß trotzdem sorgfältig programmieren und vor allem planen.
Ich finde es erstaunlich wie engstirnig und dumm (oder unerfahren?)
manche Leute hier sind.
Selbstverstaendlich ist die Ausgabe von Fehlerzustaenden mit printf
Funktionen manchmal notwendig. Ich hab mir dazu schon vor vielen Jahren
eine eigene Funktion mit ein paar Besonderheiten geschrieben die ich
auch heute noch regelmaessig nutze.
Selbstverstaendlich ist eine Schnittstelle die in einem laufenden System
dauerhaft Daten nach aussen geben kann sehr sinnvoll und gehoert zu den
ersten Dingen die ich beim beginn eines neuen Projekts implementiere.
Aber genauso selbstverstaendlich ist es auch einen Debugger zu nutzen um
sich zu jederzeit mal schnell einen Einblick in ein System zu
verschaffen. Und es ist dabei piepegal ob das System danach noch
weiterlaufen kann. Mich interessieren nur Istzustaende und vieleicht mal
ein Dutzend Singlesteps um etwas zu ueberpruefen.
Und es ist auch sehr sinnvoll mal den gdb von Hand zu nutzen weil er
dann nochmal erheblich erweiterte Moeglichkeiten bietet. Ich hab so erst
letzte Woche einen interessanten Compilerbug gefunden.
Es ist sehr sinnvoll jede diese Moeglichkeiten parallel zu nutzen weil
es die Zeit zur Fehlersuche stark vermindert. Jede dieser Moeglichkeiten
hat naemlich ihre Vor und Nachteile.
Und gerade fuer Anfaenger die ja oft noch sehr dumme Fehler machen ist
ein Debugger ein echter Augenoeffner. Nicht nur weil sie damit sehr
schnell Fehler finden, ihnen wird bewusst das ihre Vorstellung von ihrem
Programm und der Realitaet oftmals etwas differieren. Ich kann die
reichliche Nutzung nur jedem sehr empfehlen.
Olaf
Mit einem Debugger.
Am der eher zweifelnden Haltung der vielen Atmel-Jünger zu dem Thema
kann man schon erkennen, dass die billigen AVR-Programmer hier
schwächeln ;-)
Es geht aber (Atmel-ICE), weshalb ich das Gegackere in der Form nicht
nachvollziehen kann.
Für PICs ist das ein PICkit3.
Für STM32 ein ST-Link, oder ein Discoveryboard.
Oft sieht man auch Segger J-Link. Primär für ARM, aber auch PIC32. Der
EDU ist billig für Bastler.
Eigentlich ist sowas fast jede Controllerfamilie verfügbar.
Für mich war das der Hauptgrund, den Arduion so schnell wie möglich
gegen etwas ordentliches zu tauschen. In meinem Fall PIC24 und teils
STM32. Da kann man in MPLABx (oder IAR beim STM32) Breakpoints im Code
setzen, die Variablen kontrollieren und ändern und durch den Code
steppen.
Ein Debugger ist aus meiner Sicht eine absolute Grundvoraussetzung für
vernünftiges Arbeiten, egal mit welchem µC.
Ein Simulator ist ein zweifelhafter Ersatz, denn da ist externe Hardware
natürlich unberücksichtigt. Bei vielen Dingen ist das dann nur
eingeschränkt brauchbar.
> Für mich war das der Hauptgrund, den Arduion so schnell wie möglich> gegen etwas ordentliches zu tauschen.
Yep. Deshalb bin ich vor >10Jahren von AVR weg zu Renesas gegangen.
Einfach weil die damals einen kostenlosen Debugger hatten der einfach so
ueber die serielle Schnittstelle funktioniert hat. Da war keine extra
Hardware notwendig. Gerade privat war das ein grosser Kostenvorteil.
> Ein Debugger ist aus meiner Sicht eine absolute Grundvoraussetzung für> vernünftiges Arbeiten, egal mit welchem µC.
Genau.
> Ein Simulator ist ein zweifelhafter Ersatz, denn da ist externe Hardware> natürlich unberücksichtigt.
Richtig. Dazu kommt noch das ein Programm manchmal auch erst eine Zeit
lang laufen muss damit Vorzustaende abgearbeitet werden die
Ausgangsdaten fuer eine Funktion liefert wo man einen Fehler vermutet.
Jede Methode hat ihre Vor und Nachteile. Deshalb muss man alles nutzen
wenn man Effizient sein will.
Olaf
Stefan U. schrieb:> Mag sein, doch wie willst du z.B. so eine Motor-Regelung im laufenden> Betrieb anhalten ohne dass sie in diesem Moment gleich völlig versagt?
Deswegen arbeitet man in der Entwicklung mit Modellen, gibt viele Firmen
die Hardware in the Loop (z.B. für das Steuergerät) anbieten, sowas
organisiert man sich bei einer professionellen Entwicklung.
Wer war natürlich frickelt für den kommt sowas nicht in Frage. Typisch
Schwaben halt...
DPO schrieb:> Gibt es per Zufall auch sowas für Mikrocontroller wo man direkt Zeilen> vom Code stoppen kann? Darf natürlich auch was kosten, denn ich habe in> den letzen Monaten ein grossteil der Zeit bei Mikrocontrollerentwicklung> für mühsame Fehlersuche verschenkt.
Kostet 2,50EUR für einen SWD-Debugger.
Damit kann man mit diversen IDEs direkt Break-Points im Code setzen,
Variablen anschauen, den Controller flashen usw.
Mampf F. schrieb:> Kostet 2,50EUR für einen SWD-Debugger.>> Damit kann man mit diversen IDEs direkt Break-Points im Code setzen,> Variablen anschauen, den Controller flashen usw.
Und bei besseren IDEs hält man den µC garnicht an, sondern kann sich im
laufenden Betrieb Variablen und Peripherie-Register ansehen und auch
verändern.
Hallo,
Freut mich zu hören, ich werden nun mal den ST-Link anschauen, da ich ja
auch STM32 einsetze :)
Man muss vieleicht noch sagen, das es bei meinen Anwendungen nicht so
"gefährlich ist" wie zb. bei Motorcontrollern etc.
Ich bin hauptsächlich mit Schaltungen unterwegs wo das plötzliche
Stoppen eines uC's nichts beschädigt.
Und hauptsächlich geht es mir um die wirklichen "Softwareteile". Ob ein
Pin ein High-Signal hat hängt selten von der Software ab. Aber wenn zb.
irgendwelche Funktionen nicht funktionieren liegt meist ein
Programmierfehler vor.
Bei Arduino kann man zb. das machen:
" if ( x = y) {}"
richtig währe aber
" if (x == y) {}".
Die IDE erkennt das nicht als Fehler, und wenn man viele neue Funktionen
ohne Testen einbaut dann kann man unter umständen schonmal lange nach
dem fehlenden = suchen.
Würde man mit dem Debugger bemerken das die Funktion garnicht ausgeführt
wird, käme man vermutlich schneller drauf
DPO schrieb:> richtig währe aber
"wäre" ohne h zu schreiben... ;)
DPO schrieb:> Die IDE erkennt das nicht als Fehler
Aber der Compiler sollte das erkennen. Schlimmer wirds, wenn man ein &
mit einem && verwechselt, was mir die Woche passiert ist. Da kann man
sich einen absuchen, mein lieber Schwan...
DPO schrieb:> " if ( x = y) {}">> richtig währe aber>> " if (x == y) {}".
Woher soll ein Compiler wissen, was du da machen willst?
Eine Zuweisung sollte ein "true" als Ergebnis liefern. Das Ergibnis wird
dann von der If-Abfrage ausgewertet.
Olaf schrieb:> Und gerade fuer Anfaenger die ja oft noch sehr dumme Fehler machen ist> ein Debugger ein echter Augenoeffner. Nicht nur weil sie damit sehr> schnell Fehler finden, ihnen wird bewusst das ihre Vorstellung von ihrem> Programm und der Realitaet oftmals etwas differieren...
Dem kann ich nur beipflichten. So ein Debugger hilft mir sehr oft
Diskussionen mit Studierenden, warum etwas nicht so nicht funktioniert
wie gedacht, erheblich zu verkürzen ;-)
Stefan U. schrieb:> Mir fällt gerade noch ein Beispiel ein, wo man so einen Debugger kaum> gebrauchen kann: Der ESP8266. Deswegen hat er wohl auch gar keinen> Debugger Anschluss.
Er hat. Nur ist das JTAG-Interface recht buggy/unzuverlässig.
Stefan U. schrieb:> Sobald der ESP8266 einen Breakpoint erreicht, fällt er aus.
Das dürfte - zusätzlich zum JTAG-bug an einem der beiden watchdogs
liegen. Den einen kann man leicht abschalten, den Radio-WD leider etwas
weniger gut, da er im ROM konfiguriert wird.
Ansonsten ist ein ICE die noch am geringsten intrusive Methode, um
Fehler im Programm oder der HW aufzuspüren. Durch einen printf verändert
man das Timing auch mal gehörig...
Peter D. schrieb:> Es ist ein Trugschluß zu denken, mit Debugger dürfe man Fehler machen.> Fehler müssen sich nicht unmittelbar auswirken, sondern können zu> Zeitbomben werden.
Richtig, aber ein Debugger hilft Fehler schneller oder überhaupt erst zu
finden. Und gerade bei 'Zeitbomben', Fehler die vielleicht alle paar
Wochen auftretetn. Da kann man 10x den Code lesen, die Fehlerhafte
Stelle (die vielleicht sogar ganz woanders liegt) überliest man jedesmal
wieder. Bis der Debugger dir hilft die Hand vor die Stirn zu klatschen.
Und man lernt was man überhaupt alles falsch machen kann. Das Beispiel
mit der Zuweisung in einer Bedingung wurde ja schon genannt. Eine IDE
wie die vom Arduino Framework erweist dem Anfänger da leider einen
Bärendienst indem sie versucht alles kompliziert zu verstecken. Als
Anfänger freut man sich das das Programm tut was es soll und Warnungen
sind egal. Mit etwas Erfahrung versucht man aber ein Programm auch frei
von Warnings zu übersetzen.
Dann hilft natürlich noch ein defensiver Programmierstil, bei den
Abfragen gibt es den einfachen Trick nicht 'if (x==42)' sondern 'if
(42==x)' zu schreiben. Wenn es richtig ist sind beide Fälle gleich, ein
'if (42=x)' führt aber zu einer Fehlermeldung. Aber auch da kommt man
leichter hin wenn man ein Programm wirklich mal mit dem Debugger
analysiert. Ein anderer typischer Fehler ist z.B. das man sich auf eine
Auswertereihenfolge verlässt. Kann lange gut gehen, bis eben andere
Variablenwerte zum Fehler führen. Mit dem Debugger kann schnell
verschiedene Zustände erzwingen und mehr Codepfade testen. Wenn man
schon zu faul ist für Unit Tests, aber schon keinen Debugger anpackt
macht das sicher noch weniger...
Daher habe ich Null Verständnis für die Ablehnung der Benutzung eines
Debuggers, vor allem wo das heute nix mehr kostet. Sowas wie einen HiTex
ICE konnten sich früher selbst Firmen kaum leisten, heute bekommt man
für wenige Euro die besten Möglichkeiten. Zumindest für die ARM Cortex,
aber das ist auch ein Grund warum die alten Atmel AVR bei mir in der
Schublade verstauben.
Strubi schrieb:> Durch einen printf verändert> man das Timing auch mal gehörig...
und den Stackbedarf, wenn das printf überhaupt läuft. Per SWD kann man
auch den kleinsten Cortex-M0 bei der Arbeit zusehen.
Johannes S. schrieb:> Dann hilft natürlich noch ein defensiver Programmierstil, bei den> Abfragen gibt es den einfachen Trick nicht 'if (x==42)' sondern 'if> (42==x)' zu schreiben.
Und statt 'if(x == y)' schreibt man besser 'if(y == x)' ;-)
Johannes S. schrieb:> Per SWD kann man> auch den kleinsten Cortex-M0 bei der Arbeit zusehen.
So ist es!
Auf den AVRs hatte ich bisher noch nie einen Debugger und hatte auch
keinen gebraucht.
Bei den STM32 bin ich froh, einen zu haben.
Die Programme sind ja in der Regel complexer/umfangreicher und da kann
man ansonsten ewig nach einem Fehler suchen xD
Volker S. schrieb:> So ein Debugger hilft mir sehr oft Diskussionen mit Studierenden,> warum etwas nicht so nicht funktioniert wie gedacht, erheblich> zu verkürzen ;-)
Man kann so aber nicht erklären, warum ein bestimmter Code korrekt
ist. Dann funktionierende Binärcode bedeutet nicht dass die Quelle
ein korrektes Programm darstellt.
Und das Ziel sollte immer eine korrekte Eingabe sein, nicht das
Komplement aus nicht-funktionierenden Binaries :-/
Für mich ist ein Debugger eher ein Werkzeug zum Reverse-Engineering, ein
Last-Resort Tool. Solide Software sollte immer auf vorwärts-Engineering
basieren. In diesem Sinne bin ich ganz auf der Linie von Lance Taylor:
> Michelangelo reportedly said that he could see a statue in a block> of marble, and that his goal as a sculptor was to carve away everything> which wasn't part of the statue. Some programmers appear to similarly> believe that programming means starting with a block of code, and> carving away everything which isn't part of the program. This is also> known as programming by debugging. It's a bad idea. Don't do it.
Das bedeutet nicht dass ich unterstelle, jemand betreibe "programming by
debugging". Aber an mir selber habe ich bemerkt, dass ich mit Debugger
bzw. mit der Möglichkeit zu Debuggen schlunziger bin. Seit mir das
auffiel, versuche ich Debugging zu vermeiden und mich auf Engineering zu
konzentrieren anstatt auf Reverse-Engineering.
Bei Bug in Fremdcode ist ds evtl. anders gelager, da kann es helfen, das
eigentliche Problem besser zu verstehen oder einzugrenzen (Beispiel: ein
Bug in einer 10 Jahre alten sicherheitskritischen Software mit 1E6 oder
mehr Zeilen Code). Aber selbst da ticke ich anders als Kollegen: Die
finden teilweise recht flott eine Stelle, wo der Bug "gefixt" werden
kann, und es ergeben sich dann ewige Diskussionen nach dem Muster:
Er: "Hier, diese Änderung fixt den Bug"
Ich: "Das kann man so nicht machen, weil es dann mit XXX Probleme
geben kann"
Er: "Aber meine Änderung funktioniert. Und die Fälle, die mit XXX
getestet wurden, gehen alle durch"
Bei AVR besteht die Einschränkung, das das Programm nur an Punkten
anhält, die man vorher festgelegt hat. Und nur im Haltezustand kann man
in den Speicher und die Register schauen.
Bei AVR ist es nicht möglich, einen Pause Knopf zu drücken.
Johann L. schrieb:> Für mich ist ein Debugger eher ein Werkzeug zum Reverse-Engineering, ein> Last-Resort Tool. Solide Software sollte immer auf vorwärts-Engineering> basieren.Sollte ;-)
Johann L. schrieb:> Solide Software sollte immer auf vorwärts-Engineering> basieren. In diesem Sinne bin ich ganz auf der Linie von Lance Taylor:
Sollte, popollte. Das habe ich jetzt schon öfters auch von ..sagen wir
mal recht "hochkarätig arroganten" Codern gehört, die mit
MISRA-Schlagwörtern nur so um sich schmissen und noch 2mal irgendwelche
Rational Rose-Tools haben drüber laufen lassen. Ein Problem trat
trotzdem auf...
Machen wir's kurz, das Aufspüren des Fehlers gelang per Simulation und
liess sich in der HW nur per ICE aufspüren, printf()-Debugging half
nicht, da es damit GERADE lief (wg. Memory-Layout).
Das sind dann die Fälle, wo teils schon nach Auslieferung des Produkts
sehr viel Geld verbraten wird und die Emotionen bei den Entwicklern so
hoch kochen, dass die Firmen intern das Problem nicht mehr lösen können.
Diejenigen, die da kategorisch den Debugger ablehnen und auf die
Fehlerfreiheit ihres C++-Code schwören, muss man dann einfach mal für
1-2 Tage von der Test&Verfification-Fete ausschliessen..
Leider erschreckend, wieviele 'Coder' sich weigern, einen Debugger
anzufassen, geschweige denn, sich mit den Interna der CPU (und
Assembler) zu beschäftigen.
Die ganzen Diskussionen vermeide ich inzwischen, indem ich den Code, die
HW UND die CPU in die VHDL-Co-Simulation stecke. Das läuft zwar ewig
lahm, aber so lassen sich Fehler oder korrekte Funktion beweisen, auch
die, die dem MISRA-Check durch die Lappen gehen. Das ist dann natürlich
stark abhängig von der CPU-Architektur. Und die Investition in die
Testbench für die div. Fehlerszenarien ist halt nicht ohne.
Das Mass an Schludrigkeit korreliert meist immer mit irgend einem
Test-Tool, a la "MISRA wird's schon richten". Da kommt der Debugger mE
meistens zuletzt. Am Schluss zählt für den Auftraggeber: in kurzer Zeit
ein möglichst stabiles/robustes Tool zu kriegen. Da hilft wohl nur:
- Möglichst viele non-intrusive Debug-Werkzeuge parat zu haben
- Kreativ in der Fehlersuche zu sein und die Emotionen der Coder-Egos
aussen vor zu lassen
Ich bin etwas irritiert. Das beste Feature etwas schnellerer Debugger
wurde noch nicht genannt: Tracing. Wie garantiert ihr sonst ne 100% Code
Abdeckung oder wie profiled ihr euren Code?
Flaschensammler Troll schrieb:> Wenn der auf einen Breakpoint auflaeuft ist> der externe Kontext kaputt. Wenn ich in einem laufenden Protokoll> stoppe, geht das externe System in einem Timeout.
Na und? Du musst halt an der richtigen Stelle anhalten, an der Stelle an
der das Entstehen des Fehlers vermutet wird, notfalls mit bedingten
Breakpoints und/oder etwas Instrumentierung im Code.
Was nach dem Fehler passiert ist doch dafür dann vollkommen
uninteressant, notfalls bringst Du irgendwelche Aktuatoren die Schaden
anrichten könnten noch in eine sichere Position bevor Du anhalten lässt.
STK500-Besitzer schrieb:> DPO schrieb:>> " if ( x = y) {}">>>> richtig währe aber>>>> " if (x == y) {}".>> Woher soll ein Compiler wissen, was du da machen willst?> Eine Zuweisung sollte ein "true" als Ergebnis liefern. Das Ergibnis wird> dann von der If-Abfrage ausgewertet.
Richtig. Das ist allerdings ein durchaus nerviges Element vieler
Programmiersprache, inkl. hoher Sprachen.
Glaube der Vertipper ist mir öfters passiert als dass ich das obige
Konstrukt eingesetzt habe.
Vorallem da dies durchaus als schlechter Stil an zu sehen ist, da es
schnell in Spagetticode und Unübersichtlichkeit endet.
Der Trick, zuerst den fest Wert zu schreiben ist in der Tat nicht
schlecht (sofern man halt nicht nur Variablen vergleicht natürlich)!
Johann L. schrieb:> Er: "Hier, diese Änderung fixt den Bug">> Ich: "Das kann man so nicht machen, weil es dann mit XXX Probleme> geben kann">> Er: "Aber meine Änderung funktioniert. Und die Fälle, die mit XXX> getestet wurden, gehen alle durch"https://i.imgur.com/HTisMpC.jpg
Jan K. schrieb:> Ich bin etwas irritiert. Das beste Feature etwas schnellerer Debugger> wurde noch nicht genannt: Tracing.
Das ist nicht zu verachten, aber leider meist teurer weil es
aufwändigere Haredware voraussetzt und auch die kostenlosen Tools hier
oft die Grenze zur Bezahlversion ziehen.
Ich gebe ja zu das ich hier grosskotzig die Debugger verehre, aber das
Preis-Leistungsverhältnis ist bei den Cortex-M heute eben einfach
traumhaft. Für HiTex oder Intel ICE hat man viel früher 6-stellige DM
Beträge hinlegen müssen. Und auch VxWorks was immer mit seinen tollen
Tools geworben hat kostete 5 stellig für einen Arbeitsplatz. Da sollte
man sich die paar Euro für eine Debugprobe einfach mal gönnen.
So, jetzt ist aber erstmal Weihnachten, Frohes Fest euch allen. Und
lange Beine damit ihr beim diskutieren auf dem Boden bleibt :-)
Jan K. schrieb:> Ich bin etwas irritiert. Das beste Feature etwas schnellerer Debugger> wurde noch nicht genannt: Tracing. Wie garantiert ihr sonst ne 100% Code> Abdeckung oder wie profiled ihr euren Code?
Tracing wird von vielen billigen Debuggern nicht unterstützt. Ich habe
ehrlich geasagt gar keine Erfahrung damit. Es geht (meines wissens nach)
weder mit ST-Link, noch mit einem PICkit3.
Was das "profiling" angeht:
Man kann (analog zu den Kontrollausgaben) Pins toggeln und die Zeit mit
dem Scope messen. Für solche Zwecke habe ich meist ein paar freie Pins
auf Testpunkte geführt.
Das PICkit3 kann man mittels "Stopwatch" die Laufzeiten zwischen
Brakpoints messen.
Letzteres ist deutlich eleganter.
Ich habe auch immer einen Timer für eine CPU-Last-Anzeige reserviert.
Der gibt mir einen Prozentsatz aus, den die CPU nicht idled. Man kann
sich sogar einen Fehler generieren, wenn die CPU-Last über 95% geht.
> Ich bin etwas irritiert. Das beste Feature etwas schnellerer Debugger> wurde noch nicht genannt: Tracing. Wie garantiert ihr sonst ne 100% Code
Weil wir zu arm fuer einen J-Link Trace sind. Den gibt es nur in der
Firma und auch da nicht auf jedem Schreibtisch.
Olaf
> Weil wir zu arm fuer einen J-Link Trace sind
Du vergisst, dass hier auch Hobby-Elektroniker unterwegs sind, für die
20 Euro das maximale Budget eines ganzen Monats sind, wenn man auf alles
andere verzichtet.
> > Weil wir zu arm fuer einen J-Link Trace sind> Du vergisst, dass hier auch Hobby-Elektroniker unterwegs sind, für die> 20 Euro das maximale Budget eines ganzen Monats sind, wenn man auf alles> andere verzichtet.
Haeh? Genau das hab ich doch da oben gesagt.
Ich hab auch keinen J-Trace und kenn die Dinger nur aus der Firma. Und
auch wenn ich mir so ein Dingen vielleicht leisten koennte wenn ich
unbedingt wollte, aber da ist dann irgendwann auch die Grenze
ueberschritten.
Olaf
Jan K. schrieb:> Ich bin etwas irritiert. Das beste Feature etwas schnellerer Debugger> wurde noch nicht genannt: Tracing. Wie garantiert ihr sonst ne 100% Code> Abdeckung oder wie profiled ihr euren Code?
gprof fürs Funktionale, Simulator für den Rest.
PC-Profiling via JTAG ist oft ein Spiel mit Artefakten..
Die meisten Trace-Debugger sind leider Augenwischerei und bringen nur
auf speziell dafür ausgelegten Architekturen (z.B. Blackfin, ARM sehr
bedingt) was. Und auch da muss man sich fragen, ob sich die vermutlich
immer noch >10k€ für einen Lauterbach rechnen.
Im Endeffekt ist es doch meist so, dass man sich seine eigene Trace-Unit
für den ganz spezifischen Zweck herrichtet um einem gewissen Problem auf
die Schliche zu kommen. Oder man hängt eben doch ganz pragmatisch den
Oszi/LA an..
Stefan U. schrieb:> Du vergisst, dass hier auch Hobby-Elektroniker unterwegs sind, für die> 20 Euro das maximale Budget eines ganzen Monats sind, wenn man auf alles> andere verzichtet.
Die machen das durch Kreativität und cleveres Improvisieren wieder wett.
Auch sind sie im Hobby nicht an tödliche Deadlines gebunden, haben keine
rechtlichen Damoklesschwerter über sich schweben, haben keinen Stress
mit utopischen Vorgaben und können meist immer fünfe grade sein lassen
und notfalls binnen 5 Minuten einen Kompromiss mit sich selbst schließen
mit dem alle Beteiligten sofort zufrieden sind.
Also reicht meist auch ein 5€ STLink-Klon vom Chinamann denn man in
einer langen Nacht auf CMSIS-Dap oder Black-Magic umgeflasht und sogar
noch Spaß dabei gehabt hat.
> gprof fürs Funktionale, Simulator für den Rest.
Interessant. Wie machst du das mit einem Embedded Device? Mit
semihosting? Kannst du da mal mehr zu sagen?
Olaf
> Debugger sind alternativlos.
Dann muss ich geträumt haben, als ich in den 80er Jahren das
Programmieren lernte. Denn da gab es diese Geräte noch gar nicht.
Stefan U. schrieb:>> Debugger sind alternativlos.>> Dann muss ich geträumt haben, als ich in den 80er Jahren das> Programmieren lernte. Denn da gab es diese Geräte noch gar nicht.
Dein Ironiedetektor ist kaputt.
Stefan U. schrieb:> Dann muss ich geträumt haben, als ich in den 80er Jahren das> Programmieren lernte. Denn da gab es diese Geräte noch gar nicht.
Und heute bekommt man sie geschenkt.
Und in den 30er Jahren hat noch überhaupt keiner programmiert,
geschweige denn debuggt, also braucht man das alles sowieso überhaupt
nicht.
Olaf schrieb:> gprof fürs Funktionale, Simulator für den Rest.>> Interessant. Wie machst du das mit einem Embedded Device? Mit> semihosting? Kannst du da mal mehr zu sagen?>
Das 'embedded device' läuft als VHDL-Modell in der Simulation (GHDL).
Oder im qemu, der mit der Simulation quatscht.
Wenn HW co-verifiziert werden soll ist semihosting sicher auch nicht
schlecht, habe aber mit ARM das Spiel nicht durch.
Sowas in der Art läuft hier dann einfach über JTAG-gesteuertes stop/go.
Hier habe ich noch ein paar olle flash-screencasts dazu:
http://section5.ch/index.php/dokumentation/masocist-soc/virtualchip/
Stefan U. schrieb:>> Haeh? Genau das hab ich doch da oben gesagt.>> Ach so, ich hatte deinen Satz als ironisch gemeint aufgefasst.Axel S. schrieb:>> Dann muss ich geträumt haben, als ich in den 80er Jahren das>> Programmieren lernte. Denn da gab es diese Geräte noch gar nicht.>> Dein Ironiedetektor ist kaputt.Stefan U. schrieb:> Oh, schon wieder. Misst.
Du musst deinen Ironiedetektor mal wieder debuggen.
Strubi schrieb:> Das 'embedded device' läuft als VHDL-Modell in der Simulation
Du hast VHDL-Modelle der von Dir verwendeten Microcontroller samt all
ihrer verbauten Peripherie mit all ihren subtilen und teilweise sogar
undokumentierten Verhaltensweisen? An sowas kommt nicht jeder ran.
Er schrieb "oder in der Simulation", denke für komplexe Controller ist
eher das gemeint oder?
Btw, weiß jemand, wie gut die Modelle zb von der stmf10x Reihe in Keil
mdk sind? Kann man damit wirklich zuverlässig auf die spätere Funktion
schließen? Wie gesagt, bisher nutzen wir eher den echten core mit
Tracing.
STK500-Besitzer schrieb:> DPO schrieb:>> " if ( x = y) {}">>>> richtig währe aber>>>> " if (x == y) {}".>> Woher soll ein Compiler wissen, was du da machen willst?
Das weiß er, weil das in aller Regel ein Tippfehler ist. Deswegen
compiliert der Profi mit -Wall und -Werror, dann spart man sich nämlich
das Debuggen solcher Konstrukte.
Stefan U. schrieb:>> Debugger sind alternativlos.>> Dann muss ich geträumt haben, als ich in den 80er Jahren das> Programmieren lernte. Denn da gab es diese Geräte noch gar nicht.
ck
Heute hat ein Microcontroller schon mal 512kByte Programmspeicher, in
den 80ern halt nicht.
Die Komplexität normaler µC-Projekte ist halt auch dementsprechend
höher.
Dafür gibts heute halt auch bessere Werkzeuge.
Das ist halt die normale technische Entwilung.
Da kann man jetzt die beleidigte Leberwurst spielen, sich dem
verweigern, und alle als "faul" verunglimpfen, die solche Werkzeuge
nutzen, oder man geht mit der Zeit.
Meiner Meinung nach steckt dahinter die Angst, das eigene Wissen könnte
nichts mehr wert sein.
Quasi die faule Jungentwickler, die mit ihren neumodischen Blinkekram
(=Debugger) den alten Entwicklern "von echtem Schrot und Korn" die "in
der guten alten Zeit (TM) Maschinencode in Lochstreifen gestanzt haben"
die Butter vom Brot :-)
> Da kann man jetzt die beleidigte Leberwurst spielen, sich dem verweigern
Tut doch keiner. Ich verweigere jedoch, Debugger als unverzichtbar
darzustellen und Leute herab zu würdigen, die meinen, ohne Debugger
auszukommen.
Das ist wie Akkuschrauber. Ich bin 43 und besitze immer noch keinen. Ich
kann ohne Akkuschrauber bauen und ich tue es immer noch, weil ich es so
gewohnt bin. Trotzdem wäre ich der Letzte, der sagen würde,
Akkuschrauber seinen unnützes Zeug.
Da kommt es aber irgendwo auch auf die Effizienz an.
Wenn Debugger den entwicklungsprozess beschleunigen, kann man davon
ausgehen dass man im Beruf, ohne, eher schlechte Karten hat...
> Wenn Debugger den entwicklungsprozess beschleunigen> kann man davon ausgehen dass man im Beruf,> ohne, eher schlechte Karten hat.
Wenn sie den Prozess beschleunigen, dann ja. Aber ist das der Fall? Auch
bei den Leuten, die ihr Handwerk ohne Debugger gelernt haben? Bevor ich
mir bei einer Maschine mit gesteuerten Motoren überlege, wie ich sie
schadlos Debuggen kann, nekomme ich die gewünschten Infos oft viel
schneller anhand von Logmeldungen. Wohlgemerkt: oft - nicht immer.
Nur mal so zum Vergleich: Mein Ausbilder hatte stumpfe Bohrer mit einer
Schlüsselfeile und bloßen Händen schneller wieder gut gemacht, als mein
Weg zum Materiallager dauerte.
Meine Mutter kann die meisten alltäglichen Matheaufgaben im Kopf
schneller lösen, als ich den Taschenrechner bediene.
Ich tippe mit Zwei-Finger-Suchsystem schneller, als meine Frau und meine
Tochter, die es beide "richtig" gelernt haben.
Die Star-Köche im Fernsehen schneiden mit einem simplen Messer Kräuter
und Gemüse so schnell, dass der Einsatz einer modernen Küchenmaschine
extrem albern wirkt.
Nicht jedes Werkzeug, das einem heute unverzichtbar vorkommt, ist für
alle anderen Menschen ebenso unverzichtbar.
Stefan U. schrieb:>> Wenn Debugger den entwicklungsprozess beschleunigen>> kann man davon ausgehen dass man im Beruf,>> ohne, eher schlechte Karten hat.>> Wenn sie den Prozess beschleunigen, dann ja. Aber ist das der Fall?
Manchmal ja, manchmal nein.
> Auch bei den Leuten, die ihr Handwerk ohne Debugger gelernt haben?
Gut, wenn die erst einmal lernen müssen, wie man einen Debugger benutzt,
dann natürlich nicht. Aber dieser Aufwand fällt ja nicht jedes mal an.
> Bevor ich mir bei einer Maschine mit gesteuerten Motoren überlege, wie> ich sie schadlos Debuggen kann, nekomme ich die gewünschten Infos oft> viel schneller anhand von Logmeldungen. Wohlgemerkt: oft - nicht immer.
Du immer mit deinen Motoren. Machst du mit µC denn nur (bzw. fast nur)
Motorsteuerungen, die sich sofort in ihre Einzelteile zerlegen, wenn der
µC mal stehen bleibt?
Bernd K. schrieb:> Strubi schrieb:> Das 'embedded device' läuft als VHDL-Modell in der Simulation>> Du hast VHDL-Modelle der von Dir verwendeten Microcontroller samt all> ihrer verbauten Peripherie mit all ihren subtilen und teilweise sogar> undokumentierten Verhaltensweisen? An sowas kommt nicht jeder ran.
Nur bedingt, wären ausserdem eher Verilog-Modelle. Aber mit offenen
Kernen lässt sich einiges machen. Ist halt eine gewisse Kette des
Vertrauens (Core, GCC, Simulator toolchain selbst). Auch bei fmf.org
findet sich einiges, den Rest muss man sich halt selber schreiben.
Auf dem klassischen Trace-Debug-Level muss man nicht zwingend
zyklengenau das ganze HDL-modell durchnudeln, da tuts eben auch ein
qemu.
Die Toolchains von Cadence und Konsorten können das natürlich schon
lange, aber unsereiner behilft sich halt mit Opensource..
>> Auch bei den Leuten, die ihr Handwerk ohne Debugger gelernt haben?> Gut, wenn die erst einmal lernen müssen, wie man einen Debugger benutzt,> dann natürlich nicht. Aber dieser Aufwand fällt ja nicht jedes mal an.
Es geht mir doch gar nicht um diese Lernzeit. Für MICH ist ein Debugger
offensichtlich viel weniger hilfreich als für dich, weil ich daran
gewöhnt bin, ohne Debugger zu arbeiten.
Ich benutze ihn einfach viel seltener als du (denke ich). Dabei vermisse
ich ihn nicht und ich bin ganz sicher, dass meine Arbeiten dadurch
keinesfalls beeinträchtigt werden. Weder in der Qualität noch in meiner
Arbeitsgeschwindigkeit.
Ab und zu hole ich ihn doch mal raus. Aber wirklich nur ab und zu.
> Du immer mit deinen Motoren. Machst du mit µC denn nur Motorsteuerungen?
Die haben etwa 30% Anteil und spielen daher für mich eine große Rolle.
Rolf M. schrieb:> Du immer mit deinen Motoren. Machst du mit µC denn nur (bzw. fast nur)> Motorsteuerungen, die sich sofort in ihre Einzelteile zerlegen, wenn der> µC mal stehen bleibt?
Das Verhalten ist bei Bluetooth oder USB (Mass Storage) ganz ähnlich
wenn der µC es selber macht - die Kommunikation geht verloren. Dann ist
printf()-style Debugging nötig - oder Oszi/LA mit Wackeln von Port Pins.
Ja aber der Debugger ist doch alternativlos und alle anderen Methoden
sind pauschal unprofessionell :-)
Wer interessiert sich schon für Motoren, USB und Funknetze? Als ob das
ein Anwendungsfeld für Mikrocontroller sei? Mach man das nicht eher mit
einem Raspberry Pi? :-)
Printf + uart is aber so lahm. Durch den Debugger kannst du, zumindest
beim cortex m per itm viel schneller Nachrichten/debug Infos schicken
und per live view und PC sampling hast du sogar Echtzeit "Oszilloskop"
view beliebiger variablen im RAM. Kp wie man darauf verzichten möchte.
Normale serielle Ports schaffen auch mindesten 1 Mbit, oft gar mehrere
Mbit. Was will man mehr?
Bei ITM sollte man bedenken, dass die kostenloses Entwicklungsumgebungen
diese nur sehr eingeschränkt, teilweise gar nicht unterstützen.
Stefan U. schrieb:> Bevor ich> mir bei einer Maschine mit gesteuerten Motoren überlege, wie ich sie> schadlos Debuggen kann, nekomme ich die gewünschten Infos oft viel> schneller anhand von Logmeldungen.
Lässt Du den Motor die Logs per Morsecode ausgeben oder wie? Natürlich
kann man das machen, aber es ist extrem nervig. Deshalb immer zusehen
daß man bei Bedarf mit nem Debugger drankommt bevor man sich später
einen Wolf frickeln muss um sich den fraglichen Inhalt eines 16-bit
Zählers an der Power-LED rausblinken zu lassen oder ein software-UART
dranflicken muss und das passende Gegenstück dazu auf PC-Seite oder
dergleichen.
Hi,
Strubi schrieb:> Ansonsten ist ein ICE die noch am geringsten intrusive Methode, um> Fehler im Programm oder der HW aufzuspüren. Durch einen printf verändert> man das Timing auch mal gehörig...
DANKE DANKE DANKE!
Genau das ist es womit man die ganzen Pseudo-Experten aka "Nicht und
Niemalsdebuggerbenötiger da Profi" als Pseudos entlarvt!
Natürlich KANN man ohne Debugger funktionierende Firmware Schreiben.
Natürlich KANN man auch mit Printf und Pegelsetzen beim Debuggen oft
weiterkommen.
NATÜRLICH gibt es Situationen wo ein Printf-Debugging Sinn macht und ein
Breakpoint Debugging Dagegen überhaupt nichts bringt.
Ein Debugger ist ein schlicht ein NÜTZLICHES WERKZEUG.
Nicht mehr, aber auch NICHT WENIGER!
Und wie bei jedem anderen Werkzeug muss man für den sinnvollen Einsatz
wissen wann man es wozu einsetzen kann und wann man ein anderes Werkzeug
verwendet muss.
Und wie ein guter Handwerker hat ein guter "Programmierer" nicht nur ein
Werkzeug in seinem Koffer sondern verschiedene und er weiß damit
umzugehen.
Er weiß wann ein Breakpoint Debugging oder Tracing Sinnvoll ist und auch
wann er es NICHT Sinnvoll verwenden kann oder gar nicht verwenden darf!
Genauso wie er das Printf (oder vergleichbares) Debuggen kennt und auch
da weiß wann er es anwenden kann und was es leistet, aber auch wann es
Kontraproduktiv ist!
Und es ist wie geschrieben genau so das ein ICE oder ICD das einzige der
Werkzeuge ist das den Code und damit sowohl die Speicherbelegung wie
auch die Ausführungszeit nicht verändert! Das Originalprogramm bleibt
Original und die Ausführung ist bis zum Breakpoint exakt so wie es im
Endprodukt auch abläuft. Die Printf oder PegelToggle Variante hingegen
greifen massiv in Programm und Timing ein!
Mal ganz davon abgesehen was Sache ist wenn der (bzw. bei größeren
Bausteinen alle) verfügbaren UART im Programm schon verwendet werden
oder was gerade bei kleineren µC auch im Hobbybereich nicht selten ist
alle IOs bereits mit Funktionen belegt sind. Dann scheidet dieses von
vorneherein aus. ODer wenn der Programmspeicher bzw. Ram knapp wird usw.
Klar -ein Breakpoint zerstört in gewissen Anwendungen manchmal den
externen Kontext. Aber bis zum Breakpoint ist das Programm 100% im
Normalzustand.
Also muss ich abwägen ob ein Breakpoint oder ein printf sinnvoller ist.
Und falls ich zu dem Schluss komme das ein Breakpoint Sinn macht muss
man überlegen an welcher Stelle man welche Werte kontrollieren will.
Und wenn der µC eine kritische Komponente in einem echten System
überwacht und dessen Stop die Gefahr von Schäden birgt, dann muss ich
halt auf den Breakpoint verzichten oder schauen ob ich einen sicheren
Zustand garantieren kann. (Allerdings hoffe ich das niemand wirklich auf
die Idee kommt Experimentelle Fahrassistenzsysteme oder ähnliches in
einer Phase wo noch Debugging notwendig ist ohne weitere
Absicherungsmaßnahmen am "bewegten" Objekt zu entwanzen. Aber ein
einfacher Boost-Converter der vom µC gesteuert wird iwrd wohl häufiger
vorkommen. Und wenn da die Pulserzeugung rein durch das Programm
geschieht und dieses an der falschen Stelle stopp reicht das schon für
einen Schaltungsdefekt...
Aber auch da gibt es Maßnahmen.
ODer als Beispiel:
Ich musste Anfang des Monats einen nervigen Fehler in einer USB
Applikation Debuggen. Debugger Rausgekramt und erst einmal versucht den
fehlerhaften Programmteil einzugrenzen. Keine zwei Minuten Später hatte
ich die Stelle und nach insgesamt 5 Minuten war der (sehr peinliche,
muss ich zu meiner Schande leider zugeben) Fehler gefunden.
Klar- bis dahin ist die USB Verbindung ebenfalls vielleicht 5-10mal
abgebrochen weil der Breakpoint erreicht wurde.
Aber who cares?
Die Information war gewonnen, konnte bewertet werden und der nächste
Punkt für den Breakpoint daraufhin ausgesucht. Und zumindest die
jeweilige Funktion konnte ich ja noch durchsteppen...
Dann in der IDE den Reset ausgelöst und weiter gings.
Mit Printf hätte ich an verschiedenen Stellen immer wieder den Code
editieren müssen, neu kompilieren und Übertragen. Das hätte einiges
länger gedauert! Und all die anderen "Nebenwirkungen" die da passieren
können, vom versehentlichen und unbemerkten verändern gewollter
Codezeilen bis zu veränderten Verhalten mal ganz abgesehen.
Das einzige wo ich zustimme ist das der Debugger KEIN Allheilmittel ist.
Er ist ein nützliches Werkzeug das bei den heutigen Preisen ein sehr
sehr gutes Preis-/ Leistungsverhältnis hat.
Und spätestens wenn man einige Erfahrung hat sinken die Situationen wo
man einen Debugger benötigt massiv. Für dieses JAhr kann ich die fast
noch alle an einer HAnd abzählen. Aber wenn man an dem Punkt ist, so ist
der nahezu unbezahlbar!
Stefan U. schrieb:>> Man sollte etwas weiter denken ...>> Da bist du mir gerade zuvor gekommen. Ich wollte auch gerade drauf> hinweisen, dass manchmal der Verlauf von veränderlichen Zahlen (z.B.> Messwerte und Regelparameter) interessanter ist, als einzelne> Schnappschüsse eines Breakpoints.
Klar gibt es die! Es behauptet ja auch niemand etwas Gegenteiliges.
Aber genauso gibt es VIELE Fälle wo der Schnappschuss des Zustands bei
unmanipuliertem Code mit der Möglichkeit sich nacheinander beliebige
Speicherinhalte ansehen zu können viel Aussagekräftiger ist als eine
hineingestopfte Printf Ausgabe.
Stefan U. schrieb:>> Und es ist auch ganz nett wenn man komplexere Algorithmen mal>> unit tests unterziehen kann.>> Dazu gibt es Simulatoren, z.B. der im im AVR Studio integrierte.>> Abgesehen davon kann man Algorithmen genau so gut auf einem PC testen.> Wenn der Code dort richtig funktioniert, wird er es auf einem µC ebenso> tun.
Ähh...
Weiter oben schreibst du das ein Debugger nur begrenzt Sinnvoll ist weil
der µC am Breakpoint anhält und damit die Funktion einstellt.
Mit der Folge das (wie von jmd. anderen geschrieben) der externe Kontext
verloren geht und beispielsweise Datenverbindungen abbrechen oder die
Regelung aussetzt.
Aber als Alternative schlägst du den Simulator im Atmel Studio vor wo
der externe Kontext überhaupt nicht vorhanden ist oder wenn überhaupt
nur marginal nachgebaut werden kann. Oder gar das Testen in einer völlig
anderen Ausführungsumgebung wo weder die Controllerspezifische
Peripherie noch irgendwie die Register- /Speicherbelegung das geringste
mit der Zielplattform zu tun haben.
Irgendwie ziemlich widersprüchlich oder?
(Klar, es gibt Fälle wo man Codeteile auch auf dem PC mit einem C
Compiler hinreichend prüfend kann. Aber die sind doch sehr begrenzt)
Stefan U. schrieb:>> Ohne Debugger zu arbeiten ist eine grosse Zeitverschwendung.> So eine Aussage ist sehr dumm.
In ihrer Absolutheit mag die Aussage tatsächlich nicht korrekt sein!
Für sehr sehr viele Anwendungsfälle hat Olaf aber bezogen auf
Totalverweigerer dennoch absolut recht!
Gruß
Carsten
(Der in seiner (Ausbildungs-) Abschlussprüfung Anfang dieses
Jahrtausends sogar noch ein Programm mit A4 Papierassembler in
Hex-Übersetzen und eingeben musste und seine erste eigenen Schritte mit
µC in den späten 90er mit DOSEDIT, MPASM als Command Line Tool und einem
selbstgestrickten Programmiertool für die Serielle Schnittstelle gemacht
hat und sehr froh ist zwar den Hintergrund und das Innenleben der µC vom
Prinzip zu kennen und verstanden zu haben, aber im täglichen Job mit
aktuellen Werkzeugen arbeiten zu können)
Stefan U. schrieb:> Ihr drängt mich in die Ecke, ich habe keine Lust mehr mit euch über> dieses Thema zu diskutieren.
Nöö, in die Ecke hast du dich selber gestellt.
Wir bewerfen dich dafür jetzt nur mit Papierknödeln... ;-)
>Wir drehen uns ohnehin nur im Kreis.
Genau!
Gib einfach zu das wir recht haben und du darfst wieder mitspielen.
Zumindest sobald uns das Papier für die Papierbälle ausgegangen ist!
Gruß
Carsten
Ich kann dazu nur sagen, man muß alles mal im Leben gemacht haben. Dazu
gehört auch der, ach, so verpönte Debugger. Und diese Erfahrung zu
machen kostet heutzutage kaum Geld.
Eine billige STM32 Bord irgendeiner Art mit integralem StLink und eines
der freien Werkzeuge wie z.B. Atollic und Co. und man kann sich ein
eigenes Bild davon machen ohne von den Vorurteilen anderer zu sehr
beeinflußt zu werden:-)
Ich finde die Möglichkeit, eine gute Debugging Möglichkeit im Werkzeug
parat zu haben, durchaus als angenehm. wenn man mal wirklich nicht
versteht warum das Programm nicht das tut was es soll, oder man selber
mal blöde auf der Leitung steht, dann kann der Debugger schnell die
notwendige Klarheit verschaffen um den Balken vorm Auge wegzuschieben.
Deshalb sind uC wie z.B. STM32 und Cortex Co. durchaus eine gute
Alternative zu einfacheren uC ohne gutes JTAG Debug Interface.
Und sooo schwer zu beherrschen sind die Cortex Dinger dann nun beileibe
wirklich nicht. Wenn auch selektierte AVRs JTAG besitzen sind die JTAG
Tools im Vergleich zu Cortex JTAG viel teurer. Bei vielen Cortex Bords
sind jene frei mitintegriert und lassen sich mit externen eigenen
Schaltungen mitverwenden.
Ist nur meine Ansicht.
Whatever works...
Hier ist doch gar kein Total-Verweigerer!
Ich habe nur geschrieben, dass Debugger nützlich sind, aber manchmal
nicht so gut geeignet. Und dafür habe ich das Beispiel mit der
Motorsteuerung gebracht.
Und ich habe widersprochen, dass Leute die ohne Debugger klar kommen,
alleine deswegen schon schlechte ineffiziente Entwickler seien und
mangelhafte Programme erzeugen.
> Lässt Du den Motor die Logs per Morsecode ausgeben oder wie?
Bernd, wenn du das aus meinen Aussagen heraus gelesen hast, dann sollten
wir uns voneinander fern halten. Wer weiß, was sonst noch passiert.
