mega8 Flash Verwirrung

t3h_new_one Gast 06.06.2011 10:01 #2213561

Lesenswert?

•

Hallo liebe Forengemeinde,

ich spiel gerade ein bisschen mit dem mega8 rum und habe als erste 
kleine Übung eine Uhr geschrieben, welche die Uhrzeit auf einem LCD 
anzeigt. Das Projekt wofür ich es verwenden werde ist ein "Biercounter". 
Hintergrund ist ein Leiterwagen für 1. Mai + Vatertag auf welchem ein 
Buzzer installiert wird, der eben pro getrunkenes Bier liter/std. 
ausrechnet und sonstige Spielereien. :)

Config:

Aufbau auf Breadboard
HD44780 Display
Display an PortD
Taster(high aktiv) an PC3 & PC4
AVR Studio5
mk II programmer
mega8 mit internem 1MHz Takt

Was mich stutzig macht ist folgendes:

    AVR Memory Usage
    ----------------
    Device: atmega8
    Program:    7654 bytes (93.4% Full)
    (.text + .data + .bootloader)
    Data:         13 bytes (1.3% Full)
    (.data + .bss + .noinit)

wie man sieht bin ich bereits bei 93%. Da ich aber gerne noch ein paar 
features um das Program herumgebaut hätte, bekomm ich da relativ schnell 
Probleme. Die Sourcefiles sind schnell erklärt, zum einen die LCD 
Routine ausm Tut 
(http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/LCD-Ansteuerung) 
zum anderen die Files im Anhang. Meine Frage ist nun folgende, habe ich 
mit dem neuen AVR Studio5 irgendwo einen Hund reingebracht oder ist der 
mega8 einfach so klein und damit ungeeignet für mein Projekt?

Angehängte Dateien:

biercounter.c (1,02 KB) | Codeansicht
defines.h (145 Bytes) | Codeansicht
timer.c (597 Bytes) | Codeansicht

Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden

Helfer Gast 06.06.2011 10:10 #2213580

Lesenswert?

•

▲
▼

Ich sehe auf Anhieb keine Ursache für den hohen Flashverbrauch. Es fehlt 
aber ein Codeteil (die LCD-Routinen) und die Einstellung beim 
Compilieren: Optimierung an/aus?

Ansonsten

> uint16_t millisekunden;
> uint8_t  sekunde, minute, stunde;
volatile und atomarer Zugriff fehlen siehe Artikel Interrupt

#include von *.c Dateien macht man nicht, die nimmt man anders in das 
Projekt auf.

Antwort Zitieren Bearbeiten Löschen Beitrag melden

x6 Gast 06.06.2011 10:18 #2213589

Lesenswert?

•

▲
▼

Wo sitzt eigentlich der Programm Speicher oder der Dataspeicher ?

Im Datenblatt von einem µC hat man ja zum beispiel angegeben:

• High Endurance Non-volatile Memory segments
– 32K Bytes of In-System Self-programmable Flash program memory
– 1024 Bytes EEPROM
– 2K Byte Internal SRAM



Welches ist denn nun was?

Mein eigenes Programm ist doch in den 32K Flash und meine Variablen um 
EEPROM oder wie muss man das verstehn ?

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Helfer Gast 06.06.2011 10:33 #2213618

Lesenswert?

•

▲
▼

x6, du hast einen anderen µC als t3h_new_one. t3h_new_one hat einen 
Atmega8 und der Atmega8 hat keine "32K Bytes of In-System 
Self-programmable Flash program memory" sondern "8K Bytes of In-System 
Self-programmable Flash program memory". Die Berechnung Program: 7654 
bytes (93.4% Full) bezieht sich auf diese 8K (=100%)

Antwort Zitieren Bearbeiten Löschen Beitrag melden

B. G. (smarti) 06.06.2011 10:34 #2213621

Lesenswert?

•

▲
▼

Hallo,

anhand des Codes scheint der hohe Speicherdarf nicht nachvollziehbar.

Häufige ursache ist die Verwendung von float Variablen und Berechungen 
mit diesen, beim überfliegen des Codes kann ich keine entsprechenden 
entdecken.

Auf was steht die Code optimierung?

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Oliver Gast 06.06.2011 10:43 #2213642

Lesenswert?

•

▲
▼

B. G. schrieb:
> anhand des Codes scheint der hohe Speicherdarf nicht nachvollziehbar

In den lcd-routinen wird _delay_ms() benutzt, ohne Optimierung zieht das 
die float-libs mit rein.

Oliver

Antwort Zitieren Bearbeiten Löschen Beitrag melden

Barti Gast 06.06.2011 10:45 #2213645

Lesenswert?

•

▲
▼

Ich vermute es liegt an der lcd_routines.c und fehlender Optimierung. 
Ich wette da ist die stdlib.h eingebunden (siehe "itoa") und vielleicht 
noch andere Bibliotheken. Diese blähen den Code unwahrscheinlich auf.

Ist es überhaupt standard-konform wenn man eine .c Datei im Präprozessor 
einbindet statt einer Headerdatei?

MfG Barti

Antwort Zitieren Bearbeiten Löschen Beitrag melden

t3h_new_one Gast 06.06.2011 13:28 #2213927

Lesenswert?

•

▲
▼

Mahlzeit,

danke für die Hilfe bisher.

-funsigned-char -funsigned-bitfields -Os -fpack-struct -fshort-enums -g2 
-Wall -c -std=gnu99  -mmcu=atmega8

hab die Optimiziation jetzt auf "-optimize for size" gestellt und bin 
nun bei 11.4% gelandet:

    AVR Memory Usage
    ----------------
    Device: atmega8
    Program:     930 bytes (11.4% Full)
    (.text + .data + .bootloader)
    Data:          5 bytes (0.5% Full)
    (.data + .bss + .noinit)

Damit bin ich zufrieden. Danke für die Hilfe soweit! Um den Thread zu 
verfolständigen, im Anhang alle angepassten und veränderten Files. Den 
atomaren Zugriff werd ich mir heut Mittag noch anschauen.

Angehängte Dateien:

Antwort Zitieren Bearbeiten Löschen Beitrag melden

mega8 Flash Verwirrung

Antwort schreiben