Was füllt mein .data segment?

Gast #4777443
Lesenswert?
• ▲
▼
Servus,

AVR-Studio meldet mir dass das .data Segment 288Byte groß ist. Das 
stimmt auch mit dem Angehängten Ausschnitt aus dem Map-File zusammen: 
.data start 0x60, ende 0x180.

Darin sind zwei nicht mit 0 initialisierte globale Variablen, was belegt 
jedoch den Speicher im Bereich 0x70 bis 0x180?
Angehängte Dateien:
Gast #4777496
Lesenswert?
• ▲
▼
Helmut L. schrieb:

> Schreibst doch selber oder gibt es zwei NOPs?

Ah, Mißverständnis. Mit dem Auszug aus dem Handbuch:
1
char err_str[] = "Your program has died a horrible death!";

Das ist korrekt, das wird ins RAM kopiert. Weil es eine 
vorinitialisierte Variable ist.

Was ich angenommen hatte, war der direkte Gebrauch von 
String-Konstanten. Was weiß ich, etwas wie:
1
send_uart("Das ist ein String").

Das würde nicht ins RAM kopiert werden, das meinte ich.
Gast #4777513
Lesenswert?
• ▲
▼
Und der Punkt ist, daß der Speicherverbrauch hier eben nicht in der 
.data-Sektion auftritt, sondern in .rodata.

Das erste Beispiel, was tatsächlich ins RAM kopiert würde, würde aber 
nicht in .rodata den Platz belegen, sondern in .data. Demzufolge muß es 
sich um Stringkonstanten handeln wie in meinem zweiten Beispiel, weil 
die in .rodata landen.

Und deswegen ist es in diesem Fall Unsinn, daß die ins RAM kopiert 
würden.

Was ins RAM kopiert wird, sind die Variablen version und weekdays, aber 
nicht die Strings.
Gast #4777609
Lesenswert?
• ▲
▼
Danke für die Antworten! - Ich habe tatsächlich einige Stringkonstanten 
im Code. Kann man davon ausgehen dass nur diese unbenannten 
Stringkonstanten in .rodata liegen, denn wären es irgenwelche Variablen 
sollte auch der Variablenname dabei stehen oder nicht?

Ich sehe gerade dass version und weekdays als const deklariert sind, 
trotzdem liegen sie in .data und nicht in .rodata warum?

Zu PROGMEM: Wie kann man einen direkt genutzten String z.B. 
print("Test") mit PROGMEM im Flash behalten? Oder muss ich dafür eine 
Variable string1 mit PROGMEM spezifizieren und dann übergeben 
print(string1)?
#4777631
Lesenswert?
• ▲
▼
JOs schrieb:
> Zu PROGMEM: Wie kann man einen direkt genutzten String z.B.
> print("Test") mit PROGMEM im Flash behalten? Oder muss ich dafür eine
> Variable string1 mit PROGMEM spezifizieren und dann übergeben
> print(string1)?

Es gibt da Stringfunktionen die mit Strings direkt aus dem Flash 
arbeiten koennen.

Schau dir mal die Doku zur "pgmspace.h" datei an. Diese Funktionen enden 
alle mit _P im Funktionsnamen.
Gast #4777651
Lesenswert?
• ▲
▼
JOs schrieb:
> Danke für die Antworten! - Ich habe tatsächlich einige Stringkonstanten
> im Code.

Je nach Optimierungslevel des Compilers kann das auch noch ungünstig 
werden, wenn Du die mit defines angelegt hast. Die werden ja textmäßig 
nach dem Präprozessor dupliziert, und ob der Compiler diese identischen 
Strings dann wieder zusammenfaltet, muß man gucken. Insbesondere, wenn 
Du die defines in einem Headerfile hast, welches Du in verschiedene 
C-Files einbindest, kann das haarig werden.

Wenn Du das stattdessen als globale Variable anlegst, kann es sich 
unabhängig vom Optimierungslevel nicht aufblähen.

> Kann man davon ausgehen dass nur diese unbenannten
> Stringkonstanten in .rodata liegen, denn wären es irgenwelche Variablen
> sollte auch der Variablenname dabei stehen oder nicht?

Genau.

> Ich sehe gerade dass version und weekdays als const deklariert sind,
> trotzdem liegen sie in .data und nicht in .rodata warum?

1) const besagt nicht, daß etwas nach rodata gehen muß. Das kann der 
Compiler so machen, wenn er will, aber laut C-Standard versprichst Du 
damit dem Compiler lediglich, daß Du auf diese Variablen nur lesend 
zugreifst.

2) wenn die Daten ohnehin vor dem Gebrauch ins RAM kopiert werden 
müssen, wegen der Harvard-Architektur, dann ergibt es Sinn, sie nach 
data zu linken, genau wie vorinitialisierte nicht-const-Variablen.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren