Hallo, habe erfolglos versucht, mit der "gnu-toolchain" (arm-elf-gcc et al, hier: GNUARM und WinARM 4/2005) ein Programm fuer einen Philips LPC2106 (ARM7TDMI) in C++ zu erstellen ("reines C" bereitet keine Probleme). Der kaputte Versuch findet sich im Anhang - hoffentlich auf ein Minimum gekuerzt. Der Compiler selbst meckert nicht, aber das "Disassembly" enhaelt scheinbar keinen Code fuer die Member-Funktionen. Bin mir zumindest ziemlich sicher, dass im Linker-Skript und Startup-Code einiges anzupassen ist (z.B. ctors). Etwas Code fuer einen ST ARM7 aus einer kommerziellen IDE laesst darauf schliessen. Aber habe das noch nicht weit genug verstanden, um herauszufinden was genau zu tun ist. Jeder Hinweis willkommen, was zu aendern/zu tun ist, "damit's mit C++ klappt". Komplette Beispiele inkl. Linker-Script und Startup-Code für LPC2xxx unter "arm-elf-g++" würden ebenfalls sehr weiterhelfen. Martin Thomas
Hallo Martin! Das scheint in irgend einer Weise mit der Optimierung des Compilers zusammen zu hängen. Wenn ich -O0 einstellen (also Optimierung abschalte), dann erhalte ich den Code...
Hm, es könnte auch daran liegen, wie Du die Klasse implementierst. Folgender Code (nach den ersten 5 Kapiteln aus "Thinking in C++" erzeugt auch brauchbaren Code: class LED_Handler { public: void init(); void off(); void on(); } void LED_Handler::init(void) { IODIR |= (1 << LEDPIN); IOSET = (1 << LEDPIN); } void LED_Handler::off(void) { IOCLR = (1 << LEDPIN); } void LED_Hander::on(void) { IOSET = (1 << LEDPIN); } ...im main dann: [..] LED_Handler lh; lh.init(); lh.on(); lh.off(); [..]
Erstmal Danke Patrick, das bringt doch schon ein Stück weiter. Vielleicht liegt es tatsaechlich an den "inline-Member-Funktionen" und einer "übertriebenen" Optimierung, da im Beispiel innerhalb der Funktionen nur auf I/O-Register zurueckgegriffen wird. Koennte sein, dass das volatile bei den "Registermakros" bei der "C++-Optimierung" noch ignoriert wird. Die Implementierung ausserhalb der Klassendeklaration (wie in Deinem Codefragment) ist wenn recht erinnert nicht implizit inline. Unpraktisch waer's schon, wenn grade das ("inline"+volatile) nicht funktionieren wuerde, aber mglw. muss "nur" eine Compiler/Linker-Option richtig gesetzt werden. Eigentlich sollte das "Problem" dann in der Form auch auf anderen Plattformen (nicht nur arm-elf "Targets") auftreten.
Es ist aber schon so, daß der Code gar nicht funktioniert, also auf dem Target die LED nicht an/ausschaltet, oder hast Du das gar nicht getestet?
Danke nochmal. Partielle Blindheit und zu wenig Ahnung von ARM-Assembler, um das Disassembly richtig zu interpretieren, waren die Hauptursache. Tatsaechlich sind wohl alle Teile des "Beispiel-Codes" umgesetzt, d.h. "es blinkt". So man ein Objekt der Klasse im "global-scope" anlegt, gab es Probleme mit dem Konstruktor, wurden aber behoben. Kleines Beispiel mit makefile/startup/linker-script f. LPC2106 mit "g++" auf: http://www.siwawi.arubi.uni-kl.de/avr_projects/arm_projects/
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.