Forum: Mikrocontroller und Digitale Elektronik Hilfe! Frust bei AVR-Entwicklung mit AVR-Studio+Simulator und IAR. *grrr*


von Alexander I. (daedalus)


Lesenswert?

Hallo zusammen,

ich hab seit wenigen Tagen einen AVR Dragon und möchte damit einen 
ATtiny26 betüdeln. So rein per ISP klappt das auch wunderbar. In der 
Arbeit nutze ich seit etwa einem Jahr einen ATtiny84 mit MK2-Debugger 
und IAR EWB V5.3. Hab also durchaus etwas Ahnung von der ganzen Sache 
und bin den Komfort vom JTAGICE MK2 gewohnt: Anschalten und geht.

Hier zu Hause habe ich aber nur den Dragon, IAR Kickstart und 
AVR-Studio. Also alles etwas weniger komfortabel. Dennoch möchte ich 
jetzt ein kleines C++-Projekt für einen ATtiny26 realisieren. Ja, C++ 
klingt vielleicht etwas oversized für einen ATtiny, aber ich möcht das 
einfach mal ausprobieren.

Hier meine kleine Odyssee:
Als erstes habe ich mein Glück mit neuestem AVR-Studio versucht, was 
zunächst auch wunderbar geklappt hat, doch irgendwann hat der Simulator 
angefangen Mist zu machen (PC stand z.B. immer auf Ende von der 
main-Schleife oder ist wild im Code herumgesprungen... Problem mit C++?) 
. Kurze Zeit später liefen dann auch die damit erzeugen HEX-Dateien 
nicht mehr im ATtiny. Es sind auf der Zielschaltung einige LEDs, die ich 
als Checkpunkte immer mal so mal so ansteuere und das klappte dann 
irgendwann nicht mehr.

Daraufhin habe ich das gesamte Projekt in IAR-Kickstart portiert, da ich 
IAR ja gut von der Arbeit kenne. Es lies sich alles einwandfrei 
kompilieren, lief im IAR-Simulator wunderbar. Damit kam ich zunächst gut 
klar und irgendwann wollte ich dann wiedermal aufs Device laden, um ein 
paar Tests durchzuführen. Da sagt mir IAR doch glatt: "This CPU is not 
supported with the JTAGMK2-Driver". Es scheint, als hätte sich IAR die 
Mühe gespart und für den AVR Dragon nur einen halbherzigen Wrapper 
gebaut, der auf dem MK2-Treiber basiert. Fazit: Nix geht, nicht mal 
Fuses kann ich einstellen, kein ISP-Download aufs Target und debugWire 
sowieso nicht! Sehr ärgerlich! Jetzt habe ich mir damit ausgeholfen, 
dass IAR auch HEX-Dateien erzeugen kann. Selbige lade ich dann mit 
AVR-Studio hoch. Dann läuft auch mein Code im Target. Vom gewohnten 
MK2-dW-Komfort aus der Arbeit ist das aber meilenweit entfernt.

Nunja, damit könnte ich leben. Nun kommen aber die ersten ISRs (konkret: 
Timer1_OVF) hinzu und ich möchte ein bisschen Zeiten messen, Variablen 
hochzählen lassen (quasi Systemzeit) usw. Da merke ich, dass der 
IAR-Simulator zwar so ganz gut flutscht, aber Interrupts muß man 
irgendwie total umständlich erzeugen lassen mit dem Simulator. Einfach 
den Timer1 anknipsen und dann aufs OVF-Flag warten ist nicht, denn der 
Timer scheint gar nicht loszulaufen (TCNT bleibt unverändert)! Wenn ich 
den Code aber ins Target lade, seh ich an den blinkenden LEDs den 
Beweis, dass der Timer läuft. Was soll denn der Quatsch?!

Irgendwie ist das alles echt total unproduktiv und ich fummel jetzt seit 
3 Tagen jeden Feierabend hier rum, nur um mir ein einigermaßen 
taugliches und effizientes Entwicklungsumfeld zu schaffen aber irgendwie 
ist das doch totale Grütze so!

Um hier nich nur Frust abzulassen, noch ein paar Fragen an euch:
1. Warum kann IAR keinen ATtiny26 mit AVR-Dragon? evtl. Workaround?
2. Was hat der AVR-Studio-Simulator für ein Problem? Kann der nur C-Code 
und versteht kein C++?
3. Was gibt es noch für eine Möglichkeit hier etwas produktiver Arbeiten 
zu können? Wie debuggt ihr denn eure komplexer werdenden Applikationen?

von Alexander I. (daedalus)


Lesenswert?

OK, Frage 2 konnte ich klären, der AVR-Simulator schein nicht mit 
globalen Objekten von Klassen zurechtzukommen. Wenn ich die Objekte 
innerhalb von main erzeuge, klappt es ...

von Gast (Gast)


Lesenswert?

Wenn du schon Dragon hast dann nutze doch eine ATtiny mit debugWIRE 
(z.B. ATtiny261). Da sparst du dir den ganzen Simulator Mist der sowieso 
nichts bringt und kannst ordentlich debuggen.

von Alexander I. (daedalus)


Lesenswert?

Tja, das hab ich komplett übersehen, dass der Kamerad kein dW hat. 
Dachte irrtümlicherweise, die Tinys hätten das alle. Na gut, mit dem 
AVR-Simulator komm ich jetzt einigermaßen klar, wenigstens simuliert er 
auch Interrupts so wie ich mir das wünsche.

von Peter D. (peda)


Lesenswert?

Alexander I. schrieb:
> Es scheint, als hätte sich IAR die
> Mühe gespart und für den AVR Dragon nur einen halbherzigen Wrapper
> gebaut, der auf dem MK2-Treiber basiert. Fazit: Nix geht, nicht mal
> Fuses kann ich einstellen, kein ISP-Download aufs Target und debugWire
> sowieso nicht! Sehr ärgerlich!

Sehr ärgerlich ist höchstens, daß Du nichtmal ins Datenblatt schaust, 
der Tiny26 hat kein debugWire.
Also bist Du selber schuld und nicht IAR.

Dann geht nämlich auch ein Seifensieder auf, daß der 26 zu den älteren 
AVRs gehört:
"Not recommended for new designs: replaced by ATtiny261"

Das Dragon-Board ist auch relativ neu, da kann ich mir gut vorstellen, 
das bald abgekündigte ICs nur unlustig implementiert werden.


Mit C++ kenne ich mich nicht aus, das ganze Vererbungsgedöns ist mir ein 
Buch mit 7 Siegeln, keine Ahnung, wozu das nütze ist. Ich schau in C++ 
Code, wie ein Schwein ins Uhrwerk.

Ich benutze den AVR-GCC, hauptsächlich deshalb, weil er problemlos auf 
verschiedenen PCs läuft ohne sich mit Verdongelung rumplagen zu müssen.
Die Integration ins AVR-Studio finde ich gut gelungen.
Da sind auch 2 Kollegen sofort mit klargekommen, die vorher noch nie was 
mit AVRs gemacht haben.

Debuggen mache ich auf herkömmliche Weise (UART- oder Displayausgaben).
Unterfunktionen kann man aber auch gut simulieren oder in einem 
PC-C-Compiler testen.
Hardwarefunktionen halte ich für weitgehend sicher zu implementieren: 
Ich gehe dann ins Datenblatt, z.B. ADC, Register Description und 
klappere dann alle Register ab.
Als Anfänger schadet es aber nicht, mal in Ruhe die Prosa vor der 
Register Description zu lesen.

Ich hatte z.B. im ATTiny25 mit dem ADC die interne Band-Gap gelesen und 
Probleme gehabt. Ich hab dann mit SW-UART 20 Werte ausgegeben und damit 
den Bug gesehen, daß die Band-Gap erst nach der Dauer von etwa 8 
Messungen gültig ist:

http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=80458&highlight=

Mit debugWire hätte man das nicht feststellen können, durch die 
Zeitverzögerung beim Debuggen.


Ich bin auch ein Funktions-Junkie, d.h. ich schreibe selbst für kleinste 
Aufgaben ne eigene Funktion.
Der AVR-GCC inlined ja eh alle Funktionen, die nur einmal aufgerufen 
werden, mit dem Optimierungsschalter "--combine -fwhole-program".
Zum Ansehen des Listings nehme ich den deshalb heraus.


In jedem Fall muß man beim Programmieren das Datenblatt des jeweiligen 
AVRs aufschlagen, bei der hardware gibt es doch einige Unterschiede.


Peter

von Alexander I. (daedalus)


Lesenswert?

Tja, es kann nicht die Rede davon sein, dass ich nicht ins Datenblatt 
geschaut hätte, denn sonst hätte meine selbstgeätzte Schaltung 
vermutlich nicht funktioniert. Ich habs schlichtweg übersehen und war im 
Irrglauben, alle Tiny's hätten dW. Falsch gedacht.

Ich finde C++ ist eine feine Sache. Die Portierbarkeit von Code ist bei 
richtiger Implementierung sehr schön zu handhaben. Inzwischen ist es 
glaube ich mehr eine Geschmacksfrage ob man C oder C++ bevorzugt. Wenn 
man natürlich die tollsten Vererbungs- und Templatekonstrukte auf nem 
Tiny anwendet, wird die Luft ziemlich schnell dünn.

AVR-Studio ist im Grunde genommen schon okay, aber der Teufel steckt im 
Detail. z.B. das nach dem Debuggen die "Undo"-History gelöscht wird. Ist 
nicht schlimm, aber nervig. Dann ab und zu die unvorhersehbaren Abstürze 
und die marode Projektverwaltung sowie fehlendes Syntaxhighlighting. Ist 
alles irgendwie ein bisschen hakelig, aber dafür kostenlos ...

Was ist denn von dem AVR-Plugin für die Eclipse zu halten?

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
Noch kein Account? Hier anmelden.