Hallo !
Ich habe ein lange funktionierendes Programm für einen Mega32 erweitert.
Nun läuft das Ding zwar an, aber es bleibt an einer bestimmten Stelle
hängen. Das hatte ich früher schon mal - zu viel Speicher benötigt.
Derzeit sieht die Ausgabe des avr-gcc so aus:
avr-objcopy: --change-section-lma .eeprom=0x00000000 never used
11
12
Creating Extended Listing: psuctrl.lss
13
avr-objdump -h -S psuctrl.elf > psuctrl.lss
14
15
Creating Symbol Table: psuctrl.sym
16
avr-nm -n psuctrl.elf > psuctrl.sym
17
18
Size after:
19
psuctrl.elf :
20
section size addr
21
.text 22422 0
22
.data 692 8388704
23
.bss 863 8389396
24
.stab 1632 0
25
.stabstr 198 0
26
.debug_aranges 512 0
27
.debug_pubnames 4201 0
28
.debug_info 24239 0
29
.debug_abbrev 6788 0
30
.debug_line 19513 0
31
.debug_frame 3104 0
32
.debug_str 5322 0
33
.debug_loc 13478 0
34
.debug_ranges 1104 0
35
Total 104068
36
37
AVR Memory Usage:
38
-----------------
39
Device: atmega32
40
41
Program: 23114 bytes (70,5% Full)
42
(.text + .data + .bootloader)
43
44
Data: 1555 bytes (75,9% Full)
45
(.data + .bss + .noinit)
46
47
-------- end --------
Angehängte Dateien:
controller.c/.h: Der eigentliche Source Code.
libgaul.tar: TAR Datei mit Utility Library (wird auch in anderen
Projekten erfolgreich eingesetzt)
Makefile: ...
Sieht also doch gut aus, oder?
Bin für jeden Hinweis dankbar !!!
Viele Grüße
Frank DG1SBG
hier sind ein paar stellen die mir merkwürdig vorkommen:
> tRelayID get_relay_id( tRelayID nID )> {> return (tRelayID) nID;> }
der sinn des cast bzw der gesamten funktion ist mir nicht ganz klar
> uint8_t nTmpSREG = SREG; // Save status
dafür ist der compiler da, das macht man doch nicht selber
damit könntest du schon etwas sparen.
Marcus Kunze schrieb:
> hier sind ein paar stellen die mir merkwürdig vorkommen:>>> tRelayID get_relay_id( tRelayID nID )>> {>> return (tRelayID) nID;>> }>> der sinn des cast bzw der gesamten funktion ist mir nicht ganz klar
Reine Abstraktion. Das könnte ein paar Byte sparen, wenn dies
weggelassen würde. Aber: Meine Frage ist ein wenig anders gelagert.
Lt. Compiler habe ich noch Platz ...
>> uint8_t nTmpSREG = SREG; // Save status> dafür ist der compiler da, das macht man doch nicht selber
Aha. Und wie?
>> damit könntest du schon etwas sparen.
Muss ich denn???
Danke!
Frank
gast schrieb:
>> tRelayID get_relay_id( tRelayID nID )>> {>> return (tRelayID) nID;>> }>>> das ist echt witzig ^^
Nicht unbedingt. Das ist die Umsetzung zwischen Software-Ebene und
Hardware-Ebene. Wenn ich die Relays anders beschalte bzw. verdrahte,
kann ich hier die Addressierung zentral ändern. Zur Zeit bedeutet die
Funktion: Die Relays sind so mit Nummern versehen, dass diese sich
direkt als das Bit des Ports nehmen lassen. Das muss nicht immer so
sein, v.a. wenn das selbe Grund-Programm für mehrere ähnliche Projekte
verwendet wird.
Das ist einfach eine Abstraktionsebene (mehr).
Gruß,
Frank
P.S. Ich lach auch gerne - nur gerade eben nicht mehr. Das Programm
läuft immer noch nicht. ;-)
>> uint8_t nTmpSREG = SREG; // Save status> dafür ist der compiler da, das macht man doch nicht selber
Aha. Und wie?
einfach weglassen, damit sparst du schon mal 1byte ram
Du hast das SRAM zu fast 76% mit Variablen gefüllt und zusätzlich in
einigen Funktionen ziemlich viel lokal auf dem Stack liegen.
Ich würde da abspecken oder versuchsweise auf den pinkompatiblen, aber
grösseren Atmega644P wechseln
(http://www.atmel.com/dyn/resources/prod_documents/doc8001.pdf)
Marcus Kunze schrieb:
>>> uint8_t nTmpSREG = SREG; // Save status>> dafür ist der compiler da, das macht man doch nicht selber>> Aha. Und wie?>> einfach weglassen, damit sparst du schon mal 1byte ram
???
Äh - wie kann denn der Compiler ahnen, dass ich das SREG sichern
will/muss ?
Es gibt da wohl inzwischen ein Makro, ja, aber weglassen ? (Ich bin nur
Gelegenheits-µC-Programmierer - ich komm einfach nicht drauf, wie der
Compiler das ohne irgendwas hinbekommt).
Danke!
Gruß,
Frank
Ja ich weiss, es gibt Leute die sagen es darf nur ein return geben, aber
ich das ist mal ein schönes Beispiel dafür das es das ganze nicht
lesbarer macht.
Frank Goenninger schrieb:
> Marcus Kunze schrieb:>>>> uint8_t nTmpSREG = SREG; // Save status>>> dafür ist der compiler da, das macht man doch nicht selber>>>> Aha. Und wie?>>>> einfach weglassen, damit sparst du schon mal 1byte ram>> ???> Äh - wie kann denn der Compiler ahnen, dass ich das SREG sichern> will/muss ?
Vergiss das einfach. Marcus hat nur nicht durchschaut, was du da machst.
Ich würde an deiner Stelle allerdings <util/atomic.h> benutzen.
Stefan B. schrieb:
> Du hast das SRAM zu fast 76% mit Variablen gefüllt und zusätzlich in> einigen Funktionen ziemlich viel lokal auf dem Stack liegen.
Yep. Das ist sicherlich das Problem ...
>> Ich würde da abspecken oder versuchsweise auf den pinkompatiblen, aber> grösseren Atmega644P wechseln> (http://www.atmel.com/dyn/resources/prod_documents/doc8001.pdf)
Ist bestellt ;-)
Danke!
Gruß,
Frank
Stefan Ernst schrieb:
> Frank Goenninger schrieb:>> Marcus Kunze schrieb:>>>>> uint8_t nTmpSREG = SREG; // Save status>>>> dafür ist der compiler da, das macht man doch nicht selber>>>>>> Aha. Und wie?>>>>>> einfach weglassen, damit sparst du schon mal 1byte ram>>>> ???>> Äh - wie kann denn der Compiler ahnen, dass ich das SREG sichern>> will/muss ?>> Vergiss das einfach. Marcus hat nur nicht durchschaut, was du da machst.> Ich würde an deiner Stelle allerdings <util/atomic.h> benutzen.
Jau. Sicherlich. Der Ur-Quelltext stammt noch aus einer Zeit, als es
atomic.h noch nicht gab...
Danke übrigens - ich dachte schon, ich hätte was Grundlegendes nicht
mitbekommen.
Gruß,
Frank