Hallo Leute! Leider seh ich trotz googlen immernoch nicht ganz durch. Kann das STK 500 nun debuggen oder nicht? MfG Marc
> Kann das STK 500 nun debuggen oder nicht? Wenn Du debuggen kannst, kannst Du die LEDs des STK500 als Debugausgabe verwenden. JTAG oder Debug-Wire unterstützt das STK500 allerdings nicht (nachzulesen in der Hilfe des AVR-Studios, Tools->STK500). Es gibt aber auch Alternativen zur Programmiermethode "Versuch und Irrtum", da kommt man auch ohne JTAG/DW aus. ...
Ok danke! Könnt ihr da etwas anderes empfehlen? Diese selbstbau-Lösungen sind bei einigen ja doch umstritten... aber interessieren tutsmich schon.
> Könnt ihr da etwas anderes empfehlen? Ja, mach Dich sachkundig (Architektur) und programmiere systematisch. Dann brauchst Du keinen Debugger. Ansonsten gibt es Debugger-Tools original von ATMEL, die Hilfe des AVR-Studios gibt auch hier Auskunft, da sind alle verfügbaren und unterstützten Geräte aufgelistet und ausgiebig erklärt. ...
Naja ok, aber ich habe z.B. z.Z. Probleme bei einer I2C Verbindung zwischen mehreren Attinys (in C programmiert). Da wäre debuggen schon schön. Theoretisch müsste es ja auch gehen :-) LOL Ich werd mal in der Hilfe nachsehen. Kann eben nur nicht die 300€ für einen original debugger ausgeben. Trotzdem Danke für die Antworten!
>Naja ok, aber ich habe z.B. z.Z. Probleme bei einer I2C Verbindung >zwischen mehreren Attinys (in C programmiert). Da wäre debuggen schon >schön. Die Tinies lassen sich i.d.R. nur per Debug-Wire debuggen. Das Dragon-Board wäre vielleicht eine Möglichkeit für dich. Andererseits sollte man solche Sachen wie I2C einzeln testen indem man die erst mal nur die Kommunikation ansich testet (Ausgabe per USART). Wenn man sich damit fühlt, dann kann man das Drumherum aufbauen bzw. diesen Teil zur Anwendung hinzufügen, und auf diesem Weg wieder eine Fehlerquelle ausschliessen.
Hannes Lux wrote: >> Könnt ihr da etwas anderes empfehlen? > > Ja, mach Dich sachkundig (Architektur) und programmiere systematisch. > Dann brauchst Du keinen Debugger. Seh ich auch so... fuer die AVRs habe ich einen Debugger bisher noch nicht vermisst. Das ist aber auch ein bisschen Erfahrung mit Programmierung und man sollte die verwendete Sprache gut beherrschen. Und fuer die AVRs kann ein Oszi dann noch ganz nuetzlich sein, dass man die Programmfunktion verifizieren kann.
Die kleinen Controller bis zum ATmega328 haben zum Debuggen das debugWire Interface. Dieses kann man mit dem ATMEL Teil AVRDRAGON bedienen. Rund 50€ aber das ist die Sache wirklich wert. AVRDRAGON beherrscht alle Programmierarten der AVRs aber man kann nur bis 32k Debuggen.
Noch ein Nachtrag zum Debuggen. Da die überwiegende Mehrzahl der hier schreibenden aus monetären Gründen keine Debugger Hardware besitzt wird immer wieder das Märchen von der Überflüssigkeit richtigen In-Circuit Debuggens erzählt. Das ist abgrund-grotten-kranker Quatsch und kann nur von denen erzählt werden die keine Erfahrung mit dem In-Circuit Debuggen haben. Ein AVRDRAGON mit einem 15€ Billigboard sind tausendmal nutzbringender als ein STK 500 für 85€ mit LED Debugging.
Marc wrote: > Naja ok, aber ich habe z.B. z.Z. Probleme bei einer I2C Verbindung > zwischen mehreren Attinys (in C programmiert). Da wäre debuggen schon > schön. Da könnte vielleicht ein I2C-Sniffer wesentlich besser helfen (siehe Codesammlung). Moderne Oszis können oftmals auch serielle Protokolle mitsniffen, sind aber wesentlich teurer. Peter
Henry wrote: > Das ist abgrund-grotten-kranker Quatsch und kann nur von denen erzählt > werden die keine Erfahrung mit dem In-Circuit Debuggen haben. Auch wenn es durchaus Spezialfälle geben mag, wo In-Circuit Debuggen Vorteile hat, ist das noch lange kein Grund, alle Nichtbenutzer pauschal zu beleidigen. Peter
Ob man einen Debugger braucht oder nicht kommt auf die Anwendung und ihre Komplexität an. Aber auch darauf, ob man seinen Code nochmal checken möchte. Denn wenn geschriebener Code funktioniert, heisst es noch lange nicht, dass der Code optimal und fehlerfrei ist. Manches sieht man mit einem Debugger schnell und einfach - ohne Debugger würde man manchen (nicht jeden!) suboptimalen Code nie oder nur per Zufall finden. Für den Hobbybereich gehts aber allemal ohne...
@Peter: Wenn man keinen Debugger besitzt/einsetzt, ist man prinzipiell eher zu Systematik gezwungen. Logisch gut strukturierter Code ist ohne Debugger unabdingbar. Und im Fehlerfall denkt man tiefer über die genauen Abläufe nach, dass ist m.M. nach eher von Vorteil. Wenn man Code im Single-Step-Modus durchlaufen kann, verleitet das eher zu Trial&Error.
Henry wrote: > Das ist abgrund-grotten-kranker Quatsch und kann nur von denen erzählt > werden die keine Erfahrung mit dem In-Circuit Debuggen haben. Das sehe ich so ähnlich. Ich wundere mich überhaupt, mit welcher Inbrunst in Kreisen der Embedded System Leute die Not zur Tugend hochgebetet wird. Tatsache ist - leider - daß die meisten Debugger für Microcontroller nicht gerade zur Avangarde ihrer Branche gehören. Peter Dannegger: > Auch wenn es durchaus Spezialfälle geben mag, wo In-Circuit Debuggen > Vorteile hat, ist das noch lange kein Grund, alle Nichtbenutzer pauschal > zu beleidigen. Wo Henry jemanden beleidigt haben soll, solltest du schon erstmal belegen, ehe du dein Moralfähnchen hißt.
Hmm... wrote: > Wenn man keinen Debugger besitzt/einsetzt, ist man prinzipiell eher zu > Systematik gezwungen. Logisch gut strukturierter Code ist ohne Debugger > unabdingbar. Das ist mit Debugger auch nicht anders. Unstrukturierter, unausgegorener Code wird auch mit einem guten Debugger nicht besser. > Wenn man Code im Single-Step-Modus durchlaufen kann, verleitet das eher > zu Trial&Error. Na ja, das hat dann wohl weniger mit Trial&Error, als mit Unlust, oder gar Unfähigkeit zu tun. Daß da nicht viel gescheites dabei heraus kommt, ist eigentlich zu erwarten.
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.