Ich mache z.Zt hobbymäßig recht viel mit dem Atmel Mega8, recht komplexe
Sachen. Meine "Toolchain" sieht folgendermaßen aus:
- irgendein Editor
- Makefiles
- WinAVR für Compiler und Libs
- PonyProg zum Brennen
Bin soweit zufrieden damit. Wenn ich debuggen muß (bei relevanten
Änderungen immer) kann ich den Code noch für einen ganz anderen,
größeren Controller compilieren, dank meiner dünnen
Hardwareabstraktionsschicht. Dann habe ich Source Level Debugging,
Breakpoints, kann Variablen angucken, Traces schreiben, etc.
Falls es nur auf dem Atmel klemmt muß ich zu "LED-Debugging" greifen,
das ist dann unangenehm, brauche viele Iterationen um mich an das
Problem ranzuarbeiten, ist aber recht selten.
Mit AVR Studio habe ich mich nicht recht angefreundet. Ein Simulator
hilft mir auch wenig, weil die Applikation sehr eventgetrieben arbeitet,
durch äußere Interrupts angestoßen, braucht die "Umwelt". Einzeln tut
sich nichts.
Mit einem Mega88 hätte ich ja pinkompatibel das DebugWire Feature, müßte
die Software vielleicht ein wenig umschreiben oder nur neu kompilieren.
Lange Einleitung, nun die Fragen:
- Muß das Hardwaredesign darauf Rücksicht nehmen, oder läuft das über
den vorhandenen ISP-Stecker?
- Was für Tools brauche ich dafür? Gibt es was freies (z.B. gdb),
möglichst mit GUI? Kann ich den liebgewonnenen avr-gcc weiter verwenden?
Vielen Dank
Auf der Kostenlos-Alles-Umsonst-Strasse wirst du kaum Tools finden.
Wenn du investieren willst, findest du bei Atmel die passenden Tools.
Alleine mit Software geht da wenig.
Stimmt, Hardware braucht man auch, ich vergaß noch mein selbstgelötetes,
passives ISP-Kabel am Druckerport. ;-)
Ich plane, mein Zeug demnächst als Open Source zu veröffentlichen. Daher
soll die Entwicklungsumgebung so (hürden)frei wie möglich sein.
Ist also keine Schnorrertour, sondern warscheinlich mehr Geben denn
Nehmen. (Für das andere uC-Board habe ich auch Geld bezahlt, aber das
ist für Andere nicht praktikabel.)
> Ich plane, mein Zeug demnächst als Open Source zu veröffentlichen. Daher> soll die Entwicklungsumgebung so (hürden)frei wie möglich sein.
Mein Tip: Verkaufe die Tools für wenig Geld. Du wirst zwar im Geizgeilen
Deutschland nur wenig Kunden finden, das sollte dich aber nicht davon
abhalten. Meine größte Kundschaft sitzt auch im Ausland.
OpenSource hilft nur selten der Verbreitung.
dW geht mit dem JTAG-ICE2 und dem AVR-Dragon und kompatiblen
Prozessoren.
einzige Voraussetzung ist ein ISP Header (der muß eh vorhanden sein, da
man dW erst per Fuse aktivieren muß). Allerdings muß das dW volle
Kontrolle über den Reset Pin haben. Das heißt, am Reset darf beim
Debuggen kein Pull-Up oder Kondesator dran hängen. Also muss man diese
Entweder Ab-Jumperbar machen oder weglassen.
Ich debugge dann immer direkt ausm AVR-Studio mit GCC
Gruß
Fabian
ISP-Header habe ich, am Reset habe ich nur einen 100k Pullup. Wäre das
OK? Ist ja so gut wie nichts. Was sollten das für schlappe Treiber sein,
die nicht gegen 100k Ohm ankommen...
Wie komfortabel ist das Debuggen via DebugWire? Geht "echtes"
Source-Level Debugging, automatische und statische Variablen
angucken/ändern, Step in/over/out, Breakpoints, vielleicht gar
Watchpoints?
Hi
Also wenn du nicht weisst was debugWire ist, bzw. was man damit machen
kann, bist du noch nicht sehr weit gekommen. Vielleicht solltest du
erst mal beschreiben,was auf deinem 'Mist' gewachsen ist,und was du
eigentlich verkaufen willst.
Noch mein persönlicher Eindruck: Ich glaube du überschätzt dich etwas.
MfG Spess
spess53 wrote:
> Hi>> Also wenn du nicht weisst was debugWire ist, bzw. was man damit machen> kann, bist du noch nicht sehr weit gekommen. Vielleicht solltest du> erst mal beschreiben,was auf deinem 'Mist' gewachsen ist,und was du> eigentlich verkaufen willst.
Ich vermute, hier liegt ein Missverständnis vor.
Wenn ich richtig gelesen habe, will Jörg nicht den Debug-Wire-Krams als
Open-Source zur Verfügung stellen ("verkaufen"), sondern die damit
realisierten AVR-Projekte.
> Noch mein persönlicher Eindruck: Ich glaube du überschätzt dich etwas.
Ich weiß auch (noch) nicht, wie Debug-Wire funktioniert und habe deshalb
keine Bauchschmerzen...
...
> Wenn ich richtig gelesen habe, will Jörg nicht den Debug-Wire-Krams als> Open-Source zur Verfügung stellen ("verkaufen"), sondern die damit> realisierten AVR-Projekte.
Verstehe ich nicht. Die Software wird doch schon im AVR-Studio
mitgeliefert. Man stöpselt seine gekaufte Hardware dran, setzt die
DW-Fuses und legt los. Es ist kein zusätzlicher Code notwendig.
Wo greift jetzt das Projekt an? Geht es um einen selbstgeschriebenen
Debugger? Selbstgelötete Hardware?
Jörg wrote:
> ISP-Header habe ich, am Reset habe ich nur einen 100k Pullup. Wäre das> OK? Ist ja so gut wie nichts. Was sollten das für schlappe Treiber sein,> die nicht gegen 100k Ohm ankommen...>
Laut Datenblatt Tiny24 sind 10 bis 20k externer Pullup erlaubt (und mehr
dürften auch nicht schlimm sein). Der interne Pullup ist sowieso aktiv.
Das ganze läuft als "wire-AND (open-drain) bi-directional I/O pin with
pull-up enabled", also etwa so wie 1wire.
Nur Kondensatoren dürften nicht an der Leitung hängen.
OK, man braucht also AVR-Studio und JTAG-ICE2 / AVR-Dragon. Keine
anderen Alternativen bekannt?
Mit AVR-Studio kann mal auch gcc-Code im Source debuggen?
Sorry für Mißverständnisse:
Nein, ich will keinen Debugger bauen und nichts verkaufen, weder hier
noch im Ausland. ;-)
Und ich bin schon sehr weit gekommen und weiß bei meinem Code durchaus,
was ich tue. Für mich ist die Sache quasi abgeschlossen, nun geht es
drum wie andere das nutzen könnten, ohne große Einstiegshürden.
Ich habe ein paar Hardwarekomponenten gebaut (mit Mega8, alternativ
könnte man Mega88 bestücken) und die Software dazu. Zum Debuggen habe
ich einen alternativen, etwas exotischen Aufbau verwendet, mit einem
ganz anderen Controller. Hatte ich gerade da. Das ist für Dritte nicht
gangbar, Debugging auf der "echten" Hardware wäre angesagt. Nun will ich
mich schlau fragen wie das aussähe.
Kann ein DebugWire-User mal beschreiben, was man da für Möglichkeiten
hat?
Vielen Dank!
> OK, man braucht also AVR-Studio und JTAG-ICE2 / AVR-Dragon. Keine> anderen Alternativen bekannt?
Ja
> Mit AVR-Studio kann mal auch gcc-Code im Source debuggen?
Ja
mfg Robert
du hast mit dW alle Debugmöglichkeiten:
-breakpoints
-watches
-sram verändern
-eeprom verändern
-step-by-step execution
-cpu flags ändern
-timer flags / einstellungen ändern
usw.
alles was ein Debugger halt kann.
Mit dem JTAG-ICE2 geht das auf allen AVRs, mit dem Dragon nur bei AVRs
<= 32k Flash-Size.
Da dW von Atmel nicht offen gelegt wurde gibts auch keine Nachbauten wie
beim JTAG Debugger (ICE 1 clones)
Gruß
Fabian
Danke Fabian!
Keine guten Nachrichten, aber nun weiß ich immerhin Bescheid. Der
ATJTAGICE2 ist ja ein ziemlich teures Kästchen, über 300€.
Allerdings hat Google bei Digikey ein Bundle aus dem und einem
STK500-Board gefunden, für $150 plus Übersee.
Gibt es sonst noch Bezugs-Tipps?
Nope... das ist ne Aktion von Digikey... hier in D war es zeitweilig
auch für 116€ gelistet, kostet jetzt aber wieder 255€.
Digikey hat aber derzeit schwirigkeiten, wobei diese sich wohl eher auf
das gebundelte STK500 beziehen... meine Order ist jedenfalls "on hold"
Aber wenn du speziell dW willst, sind das ja eh die kleineren
Devices...also kannste auch getrost den Dragon nehmen...der kostet so
60€ rum.
Gruß
Fabian
Robert Schilling wrote:
>> OK, man braucht also AVR-Studio und JTAG-ICE2 / AVR-Dragon. Keine>> anderen Alternativen bekannt?>> Ja
es gibt avarice, das kann (teilweise) auch mit dem mk2 / Dragon. Als ich
das vor ein paar Monaten ausprobiert hab hatte ich allerdings nicht
allzu viel Erfolg und bin dann wieder aufs AVR Studio / Windows
umgestiegen.
Hmm, möglicherweise der falsche thread, aaaber ;) Kurze Frage, ich habe
einen USB-Spider programmer, gedacht für ARM's - bekomme ich damit
einen ATtiny 45 gebrannt? Bin neu bei den AVRs und werd 32bit mathe
vermissen, aber die avisierte Anwendung sollte möglichst günstig werden
und ist nicht wohl nicht aufwendig... (asm)
DAAANKE!! ;)
