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