avr-g++ Klasse, programm zu klein

[Marcel (Gast)]

Hallo,

ich möchte gerne eine Klasse schreiben, bzw. bereits getan.

Die Klasse (zum Ansteuern einzellner oder mehrerer LCDs) erscheint mir 
sehr korrekt, es gibt keine Fehler beim Kompillieren und der Code hat 
als C Variante (also ohne Klasse) funktioniert.

Das Problem ist: nach Erstellung des Programms ist die .hex Datei für 
den Programmspeicher nur etwa 189 Bytes groß und das ist definitiv zu 
wenig.

Ich hab's probiert und das "Programm" läuft nicht.


Ich benutze idR Makefiles, würde aber auch die Kommandozeile benutzen, 
würde ich denn die korrekten Optionen für meinen Fall wissen.


Hier mal das Makefile (von Avr Studio):

###############################################################################
# Makefile for the project lcd-class
###############################################################################

## General Flags
PROJECT = lcd-class
MCU = atmega8
TARGET = lcd-class.elf
CC = avr-gcc

CPP = avr-g++

## Options common to compile, link and assembly rules
COMMON = -mmcu=$(MCU)

## Compile options common for all C compilation units.
CFLAGS = $(COMMON)
CFLAGS += -Wall -gdwarf-2 -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums
CFLAGS += -MD -MP -MT $(*F).o -MF dep/$(@F).d 

## Assembly specific flags
ASMFLAGS = $(COMMON)
ASMFLAGS += $(CFLAGS)
ASMFLAGS += -x assembler-with-cpp -Wa,-gdwarf2

## Linker flags
LDFLAGS = $(COMMON)
LDFLAGS +=  -Wl,-Map=lcd-class.map


## Intel Hex file production flags
HEX_FLASH_FLAGS = -R .eeprom -R .fuse -R .lock -R .signature

HEX_EEPROM_FLAGS = -j .eeprom
HEX_EEPROM_FLAGS += --set-section-flags=.eeprom="alloc,load"
HEX_EEPROM_FLAGS += --change-section-lma .eeprom=0 --no-change-warnings


## Objects that must be built in order to link
OBJECTS = lcd-class.o 

## Objects explicitly added by the user
LINKONLYOBJECTS = 

## Build
all: $(TARGET) lcd-class.hex lcd-class.eep lcd-class.lss size

## Compile
lcd-class.o: ../lcd-class.cpp
  $(CPP) $(INCLUDES) $(CFLAGS) -c  $<

##Link
$(TARGET): $(OBJECTS)
   $(CPP) $(LDFLAGS) $(OBJECTS) $(LINKONLYOBJECTS) $(LIBDIRS) $(LIBS) -o $(TARGET)

%.hex: $(TARGET)
  avr-objcopy -O ihex $(HEX_FLASH_FLAGS)  $< $@

%.eep: $(TARGET)
  -avr-objcopy $(HEX_EEPROM_FLAGS) -O ihex $< $@ || exit 0

%.lss: $(TARGET)
  avr-objdump -h -S $< > $@

size: ${TARGET}
  @echo
  @avr-size -C --mcu=${MCU} ${TARGET}

## Clean target
.PHONY: clean
clean:
  -rm -rf $(OBJECTS) lcd-class.elf dep/* lcd-class.hex lcd-class.eep lcd-class.lss lcd-class.map


## Other dependencies
-include $(shell mkdir dep 2>/dev/null) $(wildcard dep/*)

Das ist jetzt die Standard kompilliermethode für C Programme, ich weiß 
nicht ob man bei C++ andere Flags braucht.


Vielleicht gibt's ja hier den Ein oder Anderen, der selbst in C++ 
entwickelt und mir weiterhelfen kann. :)


Danke schonmal :)

Gruß Marcel

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

Was ist denn genau im Binary angekommen?  Hast du's mal disassembliert
oder dir wenigstens die Symboltabelle angesehen?

Btw., {UNIX|GNU} make benutzt per Konvention CXX für den C++-Compiler
und CXXFLAGS für die Compileroptionen dafür.  CPP ist der
C-Präprozessor, CPPFLAGS sind die Optionen für das Präprozessieren.
Spielt bei explizit geschriebenen Regeln zwar keine große Geige, aber
man tut im Allgemeinen gut daran, sich an Konventionen zu halten, weil
das am wenigsten Verwirrung stiftet auf Dauer.

[NurSo (Gast)]

Blöde Frage,

hast Du nur die Klasse gebaut, oder auch eine Instanz davon erzeugt :-)

[P. S. (Gast)]

Marcel schrieb:

> Vielleicht gibt's ja hier den Ein oder Anderen, der selbst in C++
> entwickelt und mir weiterhelfen kann. :)

Bestimmt, dafuer muesstest du aber ein uebersetzbares Minimalprojekt und 
wenigstens die Ausgaben eines deiner Versuche posten.

[Marcel (Gast)]

so, Problem gelöst.

(ja: ich hatte in dem Programm auch ein Objekt von der Klasse erstellt)

woran es lag, weiß ich nicht genau, aber ich nehme an es lag daran, dass 
ich Klasse und Methoden alles in einer .h Datei hatte.

Nach dem ich Klasse und Methoden in .h und .cpp aufgeteilt hatte lief es 
dann.


Danke trotzdem :)

Marcel

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

Marcel schrieb:
> woran es lag, weiß ich nicht genau, aber ich nehme an es lag daran, dass
> ich Klasse und Methoden alles in einer .h Datei hatte.

»ich nehme an...«

Assumptions are the root of all evil.

Eine .h-Datei wird durch den Präprozessor genau an der Stelle
reingezogen, wo das #include steht.  Was da drin steht, ist dem
Präprozessor sche***egal, und der Compiler guckt sich nur an, ob
das gültiger C++-Code ist (der bekommt zwar noch eine Info darüber,
dass das aus einem .h stammte, aber die ist nur dafür da, damit er
den Debugger entsprechend leiten kann, sonst interessiert den das
nicht).

Zwar ist es nicht sinnvoll, die komplette Implementierung der Klasse
in eine .h-Datei zu packen (abgesehen von inline-Implementierungen
natürlich), aber solange die .h-Datei nicht von mehreren .cpp-Dateien
reingezogen wird, sollte das keinen Unterschied für den Compiler
ergeben.  In letzterem Falle würdest du aber nicht zu wenig an
Implementierung "sehen", sondern zu viel, d. h. der Linker müsste
sich dann beklagen, dass er bestimmte Dinge zweimal bekommen hat.

[Andreas F. (aferber)]

Jörg Wunsch schrieb:
> Zwar ist es nicht sinnvoll, die komplette Implementierung der Klasse
> in eine .h-Datei zu packen (abgesehen von inline-Implementierungen
> natürlich), aber solange die .h-Datei nicht von mehreren .cpp-Dateien
> reingezogen wird, sollte das keinen Unterschied für den Compiler
> ergeben.

Ausser der Header wurde irgendwann mal als Kopie von einem anderen 
angelegt und dabei vergessen, den Header-Guard anzupassen. Das kann dann 
zu den lustigsten Effekten führen ;-)

Andreas

[Rolf Magnus (Gast)]

Andreas Ferber schrieb:
> Ausser der Header wurde irgendwann mal als Kopie von einem anderen
> angelegt und dabei vergessen, den Header-Guard anzupassen.

Oh ja, dieses fiese Problem kenne ich auch. Sowas kann einen echt dazu 
bringen, an sich selbt zu zweifeln.

[Marcel (Gast)]

Dann war das anscheinend bei mir das Problem.

Ich hatte noch ein anderes Projekt mit der header Datei.
Wenn ich einen Fehler im aktuellen Programm hatte (beim Kompillieren) 
und bin dann zum Problem gesprungen, war ich plötzlich in der 
gleichnamigen header Datei des anderen Projekts.
Habe ich kein Fehler gemacht, wurde die aktuelle header Datei 
verwendet/kompilliert und alles war problemlos.

War schon merkwürdig und ich wusste echt nicht woran es lag.


Gruß

[Karl H. (kbuchegg)]

Marcel schrieb:
> Dann war das anscheinend bei mir das Problem.

Das lässt sich leicht feststellen:
Benutzt du Include Guards?
Wenn ja, ist dir einer untergekommen, der nicht mit dem 
Dateiinhalt/Dateinamen übereingestimmt hat?


Was auch oft fies ist, sind Include-Pfade die man dem Compiler pauschal 
vorgibt. Da werden dann schon mal includes reingezogen, die man so nicht 
oder von einem ganz anderen Verzeichnis haben wollte.

1 oder 2 Include Pfade sind ok. Ich hab aber auch schon Projekte 
gesehen, bei denen mehr als 20 Include Pfade vorhanden waren, weil die 
verschiedenen Basisfunktionalitäten in entsprechend viele 
Subverzeichnisse aufgeteilt wurden. Da dann nachzuvollziehen, welcher 
include von welchem Verzeichnis kommt, ist eine Sysiphusarbeit.

Moral von der Story: Organisation ist gut. Übertreibt man es aber, dann 
wird sie zum alles behindernden Selbstläufer.

[P. S. (Gast)]

Karl heinz Buchegger schrieb:

> Moral von der Story: Organisation ist gut. Übertreibt man es aber, dann
> wird sie zum alles behindernden Selbstläufer.

Das Problem an der Story ist ja nicht die Organisation, sondern die 
Faulheit einfach alle Include-Pfade einzubinden, statt die Dateien mit 
Pfad zu includen.