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.
Klar, nennt sich debugger. Ist für jede controllerfamilie spezifisch
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.
> Atmel ICE > Was ist das denn bitte??? Hallooooo??? Finde es selbst heraus.
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...
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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
> Haeh? Genau das hab ich doch da oben gesagt.
Ach so, ich hatte deinen Satz als ironisch gemeint aufgefasst.
Stefan U. schrieb: > Der Debugger ist lediglich ein praktisches Werkzeug, zu dem es > Alternativen gibt. Debugger sind alternativlos.
> 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)
:
Bearbeitet durch User
Ihr drängt mich in die Ecke, ich habe keine Lust mehr mit euch über dieses Thema zu diskutieren. Wir drehen uns ohnehin nur im Kreis.
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...
:
Bearbeitet durch User
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.
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.