C++, VMLAB, Atmega32

[Thomas M. (tmartin)]

Liebe Kollegen,

dies ist mein erster Beitrag zu einem Diskussionsforum - überhaupt.
Seit ca. 8 Monaten arbeite ich an meinem ersten embedded Projekt,
dieses und andere Foren waren dabei häufig nützliche Quellen. Dafür all
denen, die konstruktive und kompetente Beiträge geliefert haben zunächst
genauso viel Dank wie denen, die die richtigen Fragen gestellt haben.

Mittlerweile ist mein Projekt praktisch komplett (HW und SW).
Allerdings hat mein Programm im Atmega32 kaum noch Luft zum Atmen -
will sagen: SRAM wird sehr knapp. Das ist wahrscheinlich der Grund für
gelegentliche Resets, die - je nach Programmbedienung - auch an Stellen
passieren können, die sonst tagelang perfekt funktionieren.
(Selbstverständlich stehen Strings, konstante Arrays, etc im Flash.)

Gerne würde ich die gesamte SW in einer geeigneten Umgebung debuggen.
Leider habe ich kein JTAG. Mit AVR Studio kann ich zwar durch den
Sourcecode steppen (wenn alle Interrupts disabled sind !?), die
Peripherie (z.B. LCD 44780 4x20) wird dabei allerdings ausser Acht
gelassen. (Ich habe AvrLcd.msi entdeckt, aber damit nichts 44780
Ähnliches zustande gebracht). Simulavr scheint völlig ungeeignet.

VMLAB schien sehr vielversprechend - besonders, da die Vollversion
z.Zt. kostenlos angeboten wird und es sehr schön mit WinAVR kooperiert.
- VMLAB benötigt allerdings offensichtlich .cof Files mit stabs
debugging Info. COFF ist wohl älter als C++ und kann daher die
erfoderlichen Infos nicht generieren.


Endlich meine Frage:
Gibt es eine Simulationsumgebung - ähnlich VMLAB oder AVR Studio - in
der ich das Laufzeitverhalten (z.B. RAM Konsum) meiner - in C++
kodierten - SW beobachten debuggen kann.

Vielen Dank vorab!
Thomas

ps: Bitte verzichtet im Zweifel auf Bemerkungen wie "Programmiere doch
in Assmbly dann passt auch Alles ins RAM". Abgesehen davon dass diese
Behauptung in meinem Fall sehr wahrscheinlich falsch wäre, hilft solch
"RAT" nicht sehr viel weiter. - Selbstverständlich fürchte ich, dass
auch mein "Beitrag" wieder die alte "Warum C++ auf einem MC?" Frage
provoziert. Dazu gibt es in diesem Form jedoch bereits wirklich
ausreichend viele Antworten. Mir geht es in erster Linie um die
einfache Wartbarkeit (sprich Veränderbarkeit) meiner recht komplexen
Anwendung. Wer C++ und dessen Designphilosophie "Don't pay for what
you don't use!" gut kennt, wird mit diesem Werkzeug übrigens
mindestens genau so effizienten aber vielleicht sogar redundanzärmeren
Kode konstruieren können wie in ANSI-C (inline Assembly bleibt sehr
lokal immer eine Option für bit-genaue Optimierung).

[Jörg W. (dl8dtl) (Moderator)]

Du wirst wohl drauf warten müssen, bis VMLAB endlich ELF/DWARF-2
kann.