welcher Debugger für 8bit Controller (AVR etc.) ?

https://www.microchip.com/en-us/tools-resources/debug/programmers-debuggers

https://www.microchip.com/en-us/development-tool/PG164100

Kannst bei Reichelt oder viel günstiger bei Mouser kaufen.

Wenn es die modernen AVR mit UPDI Interface sein sollen, besorge dir ein ATTINY CURIOSITY NANO EVALUATION KIT. Die gibts für 15€-35€, je nach Quelle. Ist billig, macht das was du gefordert hast, aber ohne anständiges Gehäuse.

Sherlock 🕵🏽‍♂️ schrieb:

Dann wirst du wohl [auf] MPLAB X wechsel[n] müssen, denn der billigere MPLAB® SNAP wird vom Atmel/Microchip Studio nicht unterstützt.

Doch, doch, der Snap-PG164100 läuft schon unter Atmel Studio, man muss nur etwas Voodoo betreiben, damit die Version vom Atmel Studio zu der Firmware vom Snap passt, und dann läuft der astrein, sogar besser als der MKII, weil dieser die Tendenz hat, sich manchmal aufzuhängen. Man muss nach der Lösung aber nicht mehr selbst suchen, denn das hat schon jemand längst getan:

Beitrag "Re: MPLAP Snap halb im Nirvana"

Sherlock 🕵🏽‍♂️ schrieb:

Moment mal, der Atmel MkII ist nur ein Programmieradapter ohne Debugging Funktion. Der TO möchte aber debuggen.

Wenn man debuggen möchte, geht es mit dem MKII nicht, um den ging es aber gar nicht – den habe ich nur nebenbei erwähnt.

Gemäß https://www.microchip.com/en-us/tools-resources/debug/programmers-debuggers erfordert das Debugging mit dem MPLAB Snap die MPLAB X IDE.

Ich debugge mit dem Snap unter Atmel Studio z.B. die Sessions mit einem AVR128DB über UPDI – bei ATMEGAs (und dann auch noch nur bei den größeren) müsste man das wohl über die JTAG-Schnittstelle machen oder es versuchen, denn sich verbinden und programmieren geht definitiv auch mit dem Snap auch über JTAG unter Atmel Studio. Der Snap kann oder sollte eigentlich alle Schnittstellen bedienen können, egal ob JTAG, ISP, TPI, PDI oder UPDI. JTAG, ISP und UPDI geht auf jeden Fall, denn das habe ich bereits ausprobiert und verwende ISP und UPDI täglich. JTAG ist als Pinfresser nicht so mein Geschmack.

Nachtrag: im Anhang noch ein Screenshot aus dem Datenblatt des Snaps mit den Schnittstellen und das mit den Schnittstellen habe ich auf meiner Adapterplatine bereits auf entsprechende Pinheader sortiert und verfügbar gemacht (kann man auch unbestückt von mir erwerben) – damit wird dann programmiert oder auch mal debugging gemacht

Von eHajo (der müsste auch noch hier sein, jedenfalls war er das früher), der funktionierte früher ganz toll. https://www.ehajo.de/products/usp-mkii-avr-programmer

Frank O. schrieb:

der funktionierte früher ganz toll

Programmieren != Debuggen

Ich empfehle ebenfalls den MPLAB Snap, auch, weil er nicht mit einem fuddeligen Flachbandkabel im Winz-Raster angeschlossen wird, sondern über eine 8-polige Buchsenleiste im 0.1"-Raster. Da kann man entweder Gregors Adapterplatine verwenden, oder sich aus "Dupont"-Steckverbindern zum Selbstcrimpen die drei, vier meistbenötigten Adapterkabel selbstmachen.

(Man braucht halt Kontakte für Buchsen und Stiftleisten und Leergehäuse 1x8 sowie die für die Zielanwendung gebräuchlichen, meist 2x3 oder 2x5).

Noch funktioniert Microchip Studio, auch wenn es wohl nicht weiterentwickelt wird.

Frank O. schrieb:

Von eHajo (der müsste auch noch hier sein, jedenfalls war er das früher), der funktionierte früher ganz toll.

Einfach mal wieder bisschen Schrott reinwerfen, gell?

Siegfried G. schrieb:

und auch debuggen (code durchsteppen)

Sherlock 🕵🏽‍♂️ schrieb:

Moment mal, der Atmel MkII ist nur ein Programmieradapter ohne Debugging Funktion. Der TO möchte aber debuggen.

Harald K. schrieb:

Programmieren != Debuggen

Siegfried G. schrieb:

Hallo, ich möchte über Microchip Studio ein paar 8bit µC flashen (vor allem tinyAVR und MegaAVR)

Ich hatte das mit dem debuggen als nachrangig betrachte (ICE zu teuer).

Aber hast natürlich recht. Das geht nicht damit.

Ich habe jetzt eben mal noch meine Platine mit dem ATMEGA324P angeschlossen, um zu schauen, ob das mit dem Debuggen über JTAG und Snap unter Atmel Studio geht (finale Version as-installer-7.0.2594-full.exe). JA, so wie es aussieht, tut es das und das habe ich auch so in Erinnerung, dass es gegangen ist, denn wie gesagt, JTAG nutze ich normalerweise bei ATMEGAs nicht – ich kann auch ganz anders debuggen, komplett ohne Debugger und solche Methoden sollte man sich am besten auch aneignen, denn die wird man früher oder später brauchen. Langer Rede kurzer Sinn: also man kommt hier in Atmel Studio mit dem Snap über JTAG an die Register-, SRAM-, Flashinhalte, die Breakpoints funkionieren und Variableninhalte werden angezeigt. So etwas wie Fuses programmieren geht selbstverständlich auch – wird in Atmel Studio auch schön aufgeschlüsselt und beschrieben angezeigt – man muss hier keine Akrobatik mit irgendwelchen unsichtbaren Werten und Umrechnereien vollführen, was man hier im Forum leider immer wieder zu sehen bekommt, dass das so manch einen an den Rand der Verzweiflung bringt.

JTAG ist leider bei den Mega, zumindest von mir verwendeten Modellen, nicht brauchbar, da leider grad auf den von mir fuer die Anwendung benutzten Pins. Da sind die PIC besser, die haben 2 Pins fuer eine eignene JTAG implementation reserviert. Wie Gregor ausfuehrte sollte man sich Debuggen ohne Debugger angewoehnen, man braucht es sowieso ab einem Punkt.

Gregor J. schrieb:

ich kann auch ganz anders debuggen, komplett ohne Debugger und solche Methoden sollte man sich am besten auch aneignen, denn die wird man früher oder später brauchen.

Aber dennoch nur ziemlich selten. Bei sehr vielen Problemen ist Step-By-Step-Debugging sehr hilfreich und spart einfach enorm viel Zeit. Daher würde ich das wann immer möglich nutzen. Bei vielen (größeren/moderneren) Controllern ist das mit den Pins auch kein Problem, und bei ARM gibt's ja auch SWD mit 2 Pins (plus Reset).

Pandur S. schrieb:

Wie Gregor ausfuehrte sollte man sich Debuggen ohne Debugger angewoehnen

Man kann es bei Bedarf lernen, aber sich angewöhnen alles ohne Debugger zu machen ist einfach Zeitverschwendung

Wie Gregor ausfuehrte sollte man sich Debuggen ohne Debugger angewoehnen, man braucht es sowieso ab einem Punkt.

Selten so ein Unsinn gelesen. Ein Debugger ist mit das wichtigste was man zum programmieren braucht und je weniger Ahnung man hat und umso mehr Anfaenger man ist um so wichtiger ist das. 90% Ah...es geht nicht Fragen die hier auftauchen waeren nicht da wenn du Leute einmal im Singlestep durch ihr Programm gingen und testen wuerden ob das was sie da sehen mir ihrem Glauben uebereinstimmt.

Vanye

Sherlock 🕵🏽‍♂️ schrieb:

Wie haben wir früher bloss ohne Debugger arbeiten können?

Im Wesentlichen: Langsam.

Sherlock 🕵🏽‍♂️ schrieb:

Nun, ich bin ohne einen aufgewachsen, aber das wollen die jungen hippen nicht lesen.

Solche Geschichten von Damals sind zwar süß aber das heißt nicht dass man heutzutage auch so arbeiten muss. Bei MS-DOS war ja DEBUG.COM mitgeliefert; viele "junge" Leute (U50) sind also mit Debugger aufgewachsen und konnten diesen von Anfang an nutzen.

Ich Jungspund habe auf dem hippen neumodischen Windows 98 programmieren gelernt und dabei natürlich sofort den Debugger mitgenutzt, das hat sich einfach angeboten und war intuitiv verständlich.

Ich habe geschrieben, dass man sich Methoden zu debuggen AUCH ohne Debugger ANEIGNEN sollte, und nicht, dass man unbedingt immer ohne Debugger auskommen sollte, aber auch das zu können ist immer ein Gewinn, denn jede neue, weitere Methode, debuggen zu können, bringt immer nur einen Vorteil mit sich und wirkt sich auf das bis dato Gelernte generell nicht negativ aus – bitte nicht wieder meine Worte nach Gutdünken verdrehen und ihnen eine andere Bedeutung geben. Dieser Weckruf gilt besonders für die ganzen Giftmischer auf µC.net, die hier anonym agieren und sich dadurch vermeintlich sicher fühlen. Solche armselige Kreaturen und dunkle Gestalten werden in der Regel immer auch von Neid und Hass geleitet, insofern wird das immer wieder auftauchen.

Zitat: Gregor J. schrieb im Beitrag #7806572:

ich kann AUCH ganz anders debuggen, komplett ohne Debugger und solche Methoden sollte man sich am besten AUCH ANEIGNEN, denn die wird man früher oder später brauchen.

Im Anhang noch ein Foto und Scrennshots mit der eigentlichen Programmerverbindung für meine Platinen mit den ATMEGAs – ISP über die Standardanordnung 2x3, die schnell gecrimpt werden kann und dann in die Wannenstecker meiner Adapterplatine für den Snap sofort passt. Die UPDI-Verbindung für z.B. AVR_DB/DA oder die neueren ATTINY-µC befindet sich dort mittig zwischen JTAG und ISP, ist also auch explizit separat herausgeführt. Vielleicht noch diese Info: wichtig für die Debugverbindung in Atmel Studio ist, dass man diese in den Projekteingenschaften so wählt (z.B. JTAG) und abspeichert (Sternchen wegmachen), weil sonst eine Fehlermeldung kommen kann. Eigentlich kann man mit dem Snap und Atmel Studio in der Finalversion so gut wie alle AVRs ansprechen und bedienen, das einzige, was er nicht kann, ist die 12V-Programmierung, aber das ist vielleicht auch besser so, denn falsch eingesetzt kann damit auch viel kaputtgemacht werden.

Gregor J. schrieb:

Ich habe geschrieben, dass man sich Methoden zu debuggen AUCH ohne Debugger ANEIGNEN sollte

Je nachdem, wieviele und welche Pins frei sind, nutze ich im einfachsten Fall LEDs oder serielle Ausgaben über UART. Wenn sowieso ein LCD vorgesehen ist, auch darüber.

Icke ®. schrieb:

Je nachdem, wieviele und welche Pins frei sind, nutze ich im einfachsten Fall LEDs oder serielle Ausgaben über UART. Wenn sowieso ein LCD vorgesehen ist, auch darüber.

Das mache ich grundsätzlich auch, über UART kann ich jederzeit nicht nur ein Byte, sondern gleich seitenweise Infos in ASCII als lesbaren Text ausgeben (egal was), weil ich mir mittlerweile schon ordentliche Bibliotheken dazu geschrieben habe – sowohl für AVR als auch für STM32. Außerdem wird ja das Oszilloskop quasi immer beim Prototypen und Entwickeln benutzt und hier hat man dann auch die Möglichkeit um die Ecke „zu Debuggen” und was auch enorm wichtig ist – das Timinig des µControllers, des Programms oder der Hardware generell zu untersuchen und exakt zu vermessen. Auch Einsprünge und das Verlassen der Interrupts, die Ausführungszeit von Subroutinen oder generell irgendwelchen komplexen Berechnungen kann man so in Echtzeit sehr genau vermessen, was z.B. sehr wichtig ist, um festzustellen, wie lange die CPU in einem Interrupt verweilt und ob es dazwischen noch genügend Zeit gibt, bevor der nächste passiert – mit dem Debugger einer IDE geht das alles naturgemäß nicht immer so in Echtzeit, manches läuft, manches wird gestoppt, manches muss explizit zum Laufen gebracht werden (es gibt spezielle Register dafür), es gibt teilweise große Verzögerungen, weil immer Daten über die Debugverbindung hin und her geschaufelt werden müssen. Alles hat seine Vor- und Nachteile – insofern sollte man den echten Debugger niemals abschreiben, denn den wird man auch mal brauchen.

Gregor J. schrieb:

weil ich mir mittlerweile schon ordentliche Bibliotheken dazu geschrieben habe – sowohl für AVR als auch für STM32

Na auf dem STM32 ist das nur eine Zeile mit der HAL, da braucht es keine Bibliothek.

Gregor J. schrieb:

Auch Einsprünge und das Verlassen der Interrupts, die Ausführungszeit von Subroutinen

... kann man auf dem ARM auch mit dem Cycle-Counter in Software messen, ist nicht langsamer als Pins zu togglen.

Gregor J. schrieb:

es gibt teilweise große Verzögerungen, weil immer Daten über die Debugverbindung hin und her geschaufelt werden müssen.

Nur wenn man das Programm anhält. Wenn man es laufen lässt, läuft es normal in Echtzeit. Man kann also problemlos über zeitkritische Abschnitte "hinwegspringen" und Breakpoints auf fehlerhafte Codeabschnitte danach setzen.

Auch innerhalb zeitkritischer Abschnitte kann man einen Breakpoint setzen, den Zustand analysieren, den alten Breakpoint löschen, einen neuen Breakpoint auf später setzen und neu starten. So kann man sich bis zum Fehler durchhangeln ohne mit Massen an printf() oder LED-Toggle herum hantieren zu müssen, welche das Timing ja auch beeinflussen.

Gregor J. schrieb:

denn den wird man auch mal brauchen.

Eben nicht nur "mal", er ist sehr oft sehr nützlich, und manchmal nahezu unumgänglich.

Niklas G. schrieb:

Na auf dem STM32 ist das nur eine Zeile mit der HAL, da braucht es keine Bibliothek.

HAL enthält – genauso wie die IDE in ihrem vollen Umfang selbst – Fehler. Es kommt nicht oft vor, aber man wird irgendwann mal die eine oder andere Überraschung erleben und die wünsche ich jedem HAL-Gläubigen oder HAL-Verliebten. Ich nutze selbst HAL, LL, aber auch gerne mal selbstgeschriebene Registerzugriffe, um solche Fehler und Unsicherheiten zu umgehen – das nur so, falls man mir gleich wieder unterstellt, ich sei ein HAL-Gegner. Diese kurze, aber wertvolle Info von mir war aber nur so nebenbei aus Höflichkeit. Falls Du hier mit mir einen Krieg nach Ping-Pong-Art anfangen möchtest, was besser ist, also ob mit oder ohne Debugger zu debuggen, dann bist Du bei mir definitiv an der falschen Adresse gelandet und musst Dir leider jemand anders dafür suchen. Solche Kriege erinnern mich immer an die sinnlosen Kriege, welcher Computer z.B. besser ist – Atari XL/XE oder Commodore 64 etc. Ich wünsche auch Erfolg bei der Suche nach dem passenden Spielgefährten.

Gregor J. schrieb:

Es kommt nicht oft vor, aber man wird irgendwann mal die eine oder andere Überraschung erleben und die wünsche ich jedem HAL-Gläubigen oder HAL-Verliebten.

Erst mit solchen Formulierungen um sich werfen und dann über sinnlose "Kriege" herziehen? Soso.

Die HAL kann jedenfalls ganz wunderbar mit UART+DMA große Datenblöcke übertragen.

Viele Debugger müssen aber das Programm anhalten, um eine Variable zu lesen. Z.B. eine Regelung wird dann sofort in den Wald laufen oder eine Lastüberwachung wird den Transistor abrauchen lassen. Ich habe daher Funktionen, die in der Mainloop Werte ausgeben oder setzen können, ohne daß die Applikation nennenswert ausgebremst wird.

Peter D. schrieb:

Ich habe daher Funktionen, die in der Mainloop Werte ausgeben oder setzen können, ohne daß die Applikation nennenswert ausgebremst wird

Über welches Interface kannst du einen Wert so schnell ausgeben? QSPI, SDIO?

Peter D. schrieb:

Viele Debugger müssen aber das Programm anhalten, um eine Variable zu lesen

Das ist eher ein Problem vom GDB. Andere Debugging-Softwares können das auch ohne Anhalten. Das automatische Anhalten+Auslesen+Fortfahren dürfte aber ähnlich schnell gehen wie eine Ausgabe per UART o.ä.

Niklas G. schrieb:

Über welches Interface kannst du einen Wert so schnell ausgeben?

Ich muß nichts schnell ausgeben, der Mensch soll es ja lesen können. Es sind einfach nur zusätzliche CAN-Pakete, die geparst und deren Antworten mit in den CAN-Puffer gestellt werden. Und irgendwann gelangen sie dann über Ethernet in den PC zur Anzeige. Aus Bequemlichkeit haben wir auch den CAN-Bus von binär auf Text umgestellt. Das gibt zwar mehr Traffic, aber erleichtert das Debuggen ungemein.

Peter D. schrieb:

Ich muß nichts schnell ausgeben, der Mensch soll es ja lesen können

Wenn es langsam ist, sollte es auch kein Problem via Debugger sein. z.B. Segger J-Scope:

"This allows non-intrusive analysis of the data without breaking any real-time behaviour of the target application."

Man sieht es auch oft bei Anfängern, daß statt Überlegen, Konzept erstellen und dann erst Programmieren, sehr schnell zu Trial & Error übergegangen wird. Man kann ja jede Änderung sofort im Debugger laufen lassen und sich die Auswirkungen anschauen. Natürlich sieht dann ein Programm, was dabei herauskommt, einfach nur gruselig aus. Verstehbarkeit, Prüfbarkeit, Wartbarkeit und Erweiterbarkeit fallen komplett hinten runter.

Peter D. schrieb:

Man kann ja jede Änderung sofort im Debugger laufen lassen und sich die Auswirkungen anschauen

Ich finde das gut. So bekommt man ein Gefühl dafür, was da so passiert und wie der Computer "denkt", und lernt sich die Abläufe vorzustellen.

Peter D. schrieb:

Verstehbarkeit, Prüfbarkeit, Wartbarkeit und Erweiterbarkeit fallen komplett hinten runter.

Das kann man anderweitig immer noch lernen. Gerade auch weil man dank Debugger mehr Zeit dafür hat.

Niklas G. schrieb:

Das kann man anderweitig immer noch lernen.

Könnte man in der Theorie. Praktisch wird aber das sofort verkauft, sobald es auch nur den Anschein erweckt, zu funktionieren. Und dann beginnt das große Jammern, sobald die ersten Mängelreports eintrudeln. Dann kann man nur noch alles wegschmeißen und nochmal ganz von vorne anfangen. Oder Konkurs anmelden.

Einen untauglichen Programmierstil anzugewöhnen ist quasi, wie erstmal Babysprache zu lernen. Es kostet nur unnötig Zeit.

Schlechter Programmierstil hat doch wohl nichts mit der Benutzung eines Debuggers zu tun. Ich kenne es eher anders herum: ein Programm macht gerade eben was es soll, aber mit Debugger würde man noch Fehler oder Probleme bei etwas anderer Nutzung erkennen. Debugger verteufeln ist für mich Faulheit sich da nicht einarbeiten zu wollen. Und das schrittweise Debuggen ist nur ein Messer in der Werkzeugsammlung, es gibt noch Live View, Traces und auch printf oder testpins für LED oder Logic Analysator. Jedes Werkzeug hat da seine Daseinsberechtigung.

J. S. schrieb:

Schlechter Programmierstil hat doch wohl nichts mit der Benutzung eines Debuggers zu tun.

Habe ich auch nicht behauptet. Meine Aussage war, daß extensiver Gebrauch des Debuggers Anfänger zu schlechtem Programmierstil verleiten kann.

Peter D. schrieb:

Ich muß nichts schnell ausgeben, der Mensch soll es ja lesen können.

Kindchen, Du sitzt ja immer noch im Sandkasten. Um Oszilloskope solltest Du einen weiten Bogen machen. Die Ausgabe von irgendwelchen Variablen ist ja ganz nett. Nur kommt man garnicht dorthin, wenn ein Programm beim Start schon hängen bleibt ;-) Die SWD-Schnittstelle bei ARM empfinde ich als einen Segen! Zu jeder (Lauf-)Zeit in den Controller sehen zu können hilft ungemein.

Wulf D. schrieb:

Wenn es die modernen AVR mit UPDI Interface sein sollen, besorge dir ein ATTINY CURIOSITY NANO EVALUATION KIT.

Das würde ich auch vorschlagen.

Mir hat das Debuggen noch nie geholfen. Warum? Ganz einfach: Weil ein Mikrocontroller aus viel mehr Komponenten als nur der CPU und dem RAM besteht, und viele dieser Komponenten sind asynchron. Darüber hinaus interagiert der Mikrocontroller mit der Außenwelt.

Das ist der Unterschied zwischen einem Mikrocontroller und einem Mikroprozessor.

Georg M. schrieb:

Mir hat das Debuggen noch nie geholfen.

Um EPROMs zu brennen braucht man das auch nicht. Offensichtlich schreibst Du Programme, die auf Anhieb laufen, oder die Du gleich wieder entsorgst. Dazwischen gibt es nichts.

Peter D. schrieb:

Könnte man in der Theorie. Praktisch wird aber das sofort verkauft, sobald es auch nur den Anschein erweckt, zu funktionieren

Anfänger fangen normalerweise mit akademischen- oder Privatprojekten an. Da wird nix verkauft.

Peter D. schrieb:

Einen untauglichen Programmierstil anzugewöhnen ist quasi, wie erstmal Babysprache zu lernen

Genau, daher sollte man direkt sauber in einer modernen Sprache wie Python oder Kotlin lernen und keine Zeit darauf verschwenden Debug-Ausgaben zu machen und das Debuggen mit dem Debugger machen.

J. S. schrieb:

mit Debugger würde man noch Fehler oder Probleme bei etwas anderer Nutzung erkennen

Genau. Da gab es doch hier diesen schönen Thread wo einer der diversen Debugger-Verweigerer hier seinen Code anpries, wo er aber seit Jahren bestimmte Bugs nicht gefunden hatte und kuriose Workarounds braucht... Mithilfe des Debuggers habe ich zufällig innerhalb von Minuten den Bug gefunden und behoben.

Peter D. schrieb:

Meine Aussage war, daß extensiver Gebrauch des Debuggers Anfänger zu schlechtem Programmierstil verleiten kann.

Das kann ich nicht unterschreiben, und selbst wenn, das können sehr viele Dinge. Der Nutzen des Debuggers wiegt das wieder auf.

Georg M. schrieb:

Weil ein Mikrocontroller aus viel mehr Komponenten als nur der CPU und dem RAM besteht, und viele dieser Komponenten sind asynchron

Auch da hilft der Debugger. z.B. setzt man Breakpoint in ISRs und schaut sich an wo da falsch reagiert wird. Kann zwar sein dass die Hardware asynchron weiter gelaufen ist; dann muss man halt den Breakpoint woanders hin setzen und resetten. Außerdem gibt es oft noch komplexe Algorithmen und Verwaltungsaufgaben, die man debuggen muss.

Ich arbeite mit recht komplexen Bare-Metal-Anwendungen, die natürlich asynchron mit Peripherie und externen Komponenten kommunizieren, und der Debugger spart mir täglich viel Zeit.

Viele Debugger müssen aber das Programm anhalten, um eine Variable zu lesen. Z.B. eine Regelung wird dann sofort in den Wald laufen oder eine

Die Tatsache das es in aller Regel klueger ist einen Debugger zu verwenden bedeutet ja nicht das man manchmal nicht auch was anderes verwenden kann.

Allerdings...

Lastüberwachung wird den Transistor abrauchen lassen. Ich habe daher Funktionen, die in der Mainloop Werte ausgeben oder setzen können, ohne daß die Applikation nennenswert ausgebremst wird.

...mein Debugger (J-Link) kann auch zur Laufzeit Speicheradressen auslesen und ich hab mir extra mal fuer solche Faelle ein kleines Tool geschrieben das vom Compiler die Variablenadressen einliest und es so erlaubt Variablen, auch grafisch ueber der Zeit, anzuzeigen.

Und ja, manchmal gebe ich auch nur Sachen ueber eine serielle auf einen VT100 Terminalemulator aus und nutze dabei auch die xy-Positionierung. Aber Debugger ist immer das erste und wichtigste Tool.

Vanye

Niklas G. schrieb:

Auch da hilft der Debugger. z.B. setzt man Breakpoint in ISRs und schaut sich an wo da falsch reagiert wird.

Wieso ISR?

Georg M. schrieb:

Wieso ISR?

Wenn du es schaffst dein gesamtes Programm über das Event-System abzuhandeln, kannst du auch schlecht printf() machen. Aber über JTAG sollte man doch den internen Zustand von dessen Registern sehen können (wie bei FPGA).

Niklas G. schrieb:

Peter D. schrieb:

Könnte man in der Theorie. Praktisch wird aber das sofort verkauft, sobald es auch nur den Anschein erweckt, zu funktionieren

Anfänger fangen normalerweise mit akademischen- oder Privatprojekten an. Da wird nix verkauft.

Ihr habt beide recht. Ich hatte früher, vor den Mikrocontrollern, auch mal etwas mit Datenbanken gemacht und da ich schon ein bisschen geübt hatte, vollmundig angekündigt, dass ich auch das anbieten kann. Nächte, viele Nächte habe ich vor den Problemen gesessen. Das war letztlich (nicht weil ich da kein Geld mit verdient hätte oder gar Pleite war) der Grund mein kleines Unternehmen wieder aufzugeben. Ich hatte ja schon einen gut bezahlten Hauptberuf.

Bei den Mikrocontrollern war und ist es aus Spaß an der Sache. Nachdem ich dann "Blinken" konnte, habe ich mich direkt an mein erstes Projekt gewagt. Auch sofort in C und mit dem Atmel Studio. Ich dachte, dass ich alles richtig gemacht hatte. Da wusste ich noch nichts vom Debuggen (doch natürlich, nur nicht wie das bei den Mikrocontrollern funktioniert) und habe geglaubt, dass mein Programm nicht funktioniert. Doch, das tat es. Nur so wahnsinnig schnell, wie ich es nicht erwartet hatte. Ich fügte dann immer eine kurze Blinksequenz ein und konnte sehen, dass das funktioniert. Das habe ich im Grunde bis heute bei behalten. Dann hatte ich das mit dem Debuggen im Studio gesehen und dadurch auch viel besser verstanden wie die Mikrocontroller arbeiten. Ich glaube der Grund, warum man kaum solche Debugger benutzt hat, weil das Zeug damals irre teuer war. Mit dem Dragon konnte man das, aber auch längst nicht mit jedem Controller. Heute sind selbst solche Dinger, wie der ICE, bezahlbar. Daher bin ich heute eher bei Niklas G. und würde sogar so weit gehen, dass ich dazu raten würde, auch bewusst Fehler in Kauf zu nehmen. Der Mensch lernt viel, aber erst richtig aus Fehlern.