Forum: Compiler & IDEs Problem beim Anlegen mehrerer EEMEM-Variablen


von Marian Neubert (Gast)


Lesenswert?

Hallo *,

beim Versuch, Variablen im EEMEM abzulegen, wirft der Compiler die 
Fehlermeldung: "Fehler: ee_data_state löst einen Abschnittstypkonflikt 
aus".

Folgendes wurde versucht:

uint8_t ee_data_state[6][4] EEMEM;
int16_t ee_data_temp[6] EEMEM;

in einem include zuvor werden Strings im EEPROM so abgelegt:

static const char menu_level0_string[] EEMEM =  "Setup          Reset";
static const char menu_level1_string[] EEMEM =  "\4     \3     \2 
\5";
(usw...)

ich verstehe momentan nicht, warum dies geschieht - nutze ich die 
Deklaration des Arrays alleinstehend in einem anderen Projekt, 
funktioniert alles.

Liegt das an der vorherigen Deklaration als "static const" (ohne die er 
aber nicht kompiliert) oder an der fehlenden initialisierung des arrays?

Benutzt wird GCC Vers. 3.4.5 (aus WinAVR-20060125)

Grüße
Marian

von Marian Neubert (Gast)


Lesenswert?

Hallo nochmal,

mir ist gerade folgendes aufgefallen:

wenn ich die Strings im EEPROM statt mit "static const char" nur mit 
"char" (also ohne static und const) ablege, funktionert es wieder.

Aber warum nur? Fest abgelegte Strings, welche sich nicht ändern, werden 
doch als const abgelegt - oder ist das bei der EEMEM-Section anders?

Grüße
Marian

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

> in einem include zuvor werden Strings im EEPROM so abgelegt:

Klingt suspekt.

Bitte poste mal compilierbaren Code, der das Problem demonstriert.

von johnny.m (Gast)


Lesenswert?

Blöde Frage: Wieso müllst Du Dein EEPROM mit Sachen zu, die eh nie 
geändert werden sollen??? Solche konstanten Sachen gehören ins Flash, 
sofern da ausreichend Platz ist.

von Marian Neubert (Gast)


Angehängte Dateien:

Lesenswert?

@johnny.m: Ich lege die Variablen aus Platzgründen im EEPROM ab. Über 
den Sinn, dies generell zu machen, kann man sich durchaus streiten ;o)

@Jörg Wunsch
Compilierbaren Code habe ich im Anhang - hier tritt der Fehler nicht 
auf. Ändert man aber in der Datei "inc/lcd_toolbox.c" die oberen 
Variablen für den EEPROM nach "static const" (einfach auskommentieren 
und die anderen kommentieren), dannt tritt das o.g. Problem auf.

Grüße
Marian

von Karl H. (kbuchegg)


Lesenswert?

> in einem include zuvor ...
> Ändert man aber in der Datei "inc/lcd_toolbox.c" die oberen
> Variablen für den EEPROM nach "static const"

Wieder einer der ein *.c File inkludiert.

Lass mich ich raten:
Du includierst dieses File ein paar mal in andere *.c ?
Dann wird in jedem dieser Files ein neuer Satz deiner
konstanten Texte angelegt. Lies mal nach, was 'static'
bei globalen Variablen macht.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Hmm, ziemliches Durcheinander da, wenn du mich fragst.  Alle C-Quellen
werden am Anfang von main.c reingezogen, warum machst du denn sowas?
#include ist (normalerweise) für Headerdateien da.

Anyway, irgendwie hängt das mit all dem Gewurschtel zusammen, ich habe
nur weder Zeit noch richtig Lust zu analysieren, warum das denn nun
wirklich bei dir passiert.

Wenn man einfach geradlinig
1
#include <avr/eeprom.h>
2
3
static const char foo[] EEMEM = "foo";

compiliert, funktioniert alles, erst im Zusammenhang mit der
Komplexität all deines Codes kommt der Fehler.  Was mir noch auffällt
ist, dass die Fehlermeldung sehr spät kommt, nachdem eigentlich
schon das ganze File lcd_toolbox.c durch den Compiler durch ist.
Irgendwas da drin muss den Compiler dazu bringen, dass er diese
Variablen sowohl in .eeprom als auch in .data ablegen will (oder
sowas).

GCC 4.x schmeisst übrigens tütenweise Warnungen raus für deinen Code:
1
avr-gcc -I"./inc"  -mmcu=atmega8 -Wall -gdwarf-2 -DF_CPU=8000000UL  -Os -fsigned-char -MD -MP -MT main.o -MF dep/main.o.d  -c  main.c
2
In file included from main.c:16:
3
inc/lcd_toolbox.c: In function 'write_menus':
4
inc/lcd_toolbox.c:65: warning: pointer targets in passing argument 1 of 'eeprom_read_byte' differ in signedness
5
inc/lcd_toolbox.c:71: warning: pointer targets in passing argument 1 of 'eeprom_read_byte' differ in signedness
6
inc/lcd_toolbox.c:77: warning: pointer targets in passing argument 1 of 'eeprom_read_byte' differ in signedness
7
inc/lcd_toolbox.c:83: warning: pointer targets in passing argument 1 of 'eeprom_read_byte' differ in signedness
8
inc/lcd_toolbox.c:89: warning: pointer targets in passing argument 1 of 'eeprom_read_byte' differ in signedness
9
inc/lcd_toolbox.c:95: warning: pointer targets in passing argument 1 of 'eeprom_read_byte' differ in signedness
10
inc/lcd_toolbox.c:102: warning: pointer targets in passing argument 1 of 'eeprom_read_byte' differ in signedness
11
inc/lcd_toolbox.c:113: warning: pointer targets in passing argument 1 of 'eeprom_read_byte' differ in signedness
12
inc/lcd_toolbox.c:119: warning: pointer targets in passing argument 1 of 'eeprom_read_byte' differ in signedness
13
inc/lcd_toolbox.c:125: warning: pointer targets in passing argument 1 of 'eeprom_read_byte' differ in signedness
14
inc/lcd_toolbox.c:131: warning: pointer targets in passing argument 1 of 'eeprom_read_byte' differ in signedness
15
inc/lcd_toolbox.c:135: warning: pointer targets in passing argument 1 of 'eeprom_read_byte' differ in signedness
16
inc/lcd_toolbox.c:139: warning: pointer targets in passing argument 1 of 'eeprom_read_byte' differ in signedness
17
inc/lcd_toolbox.c: In function 'write_to_position':
18
inc/lcd_toolbox.c:170: warning: statement with no effect
19
inc/lcd_toolbox.c: In function 'write_settings_menu':
20
inc/lcd_toolbox.c:248: warning: pointer targets in passing argument 1 of 'eeprom_read_byte' differ in signedness
21
main.c: In function 'read_sensordata_from_eeprom':
22
main.c:193: warning: pointer targets in passing argument 1 of 'eeprom_read_word' differ in signedness
23
main.c: In function 'write_sensordata_to_eeprom':
24
main.c:202: warning: pointer targets in passing argument 1 of 'eeprom_write_word' differ in signedness
25
main.c: At top level:
26
inc/lcd_toolbox.c:19: error: menu_level2_string causes a section type conflict
27
inc/lcd_toolbox.c:21: error: desc_condition_string causes a section type conflict
28
inc/lcd_toolbox.c:22: error: desc_output_string causes a section type conflict
29
inc/lcd_toolbox.c:23: error: desc_alarm_string causes a section type conflict
30
inc/lcd_toolbox.c:24: error: desc_hysteresis_string causes a section type conflict
31
inc/lcd_toolbox.c:25: error: desc_address_string causes a section type conflict
32
inc/lcd_toolbox.c:26: error: desc_target_value_string causes a section type conflict
33
inc/lcd_toolbox.c:29: error: desc_choose_sensor_string causes a section type conflict
34
inc/lcd_toolbox.c:17: error: menu_level0_string causes a section type conflict
35
inc/lcd_toolbox.c:18: error: menu_level1_string causes a section type conflict
36
inc/lcd_toolbox.c:20: error: menu_level3_string causes a section type conflict
37
inc/lcd_toolbox.c:27: error: desc_reset_string1 causes a section type conflict
38
inc/lcd_toolbox.c:28: error: desc_reset_string2 causes a section type conflict
39
make: *** [main.o] Error 1

von Marian Neubert (Gast)


Lesenswert?

@Karl heinz Buchegger

mir ist schon bewusst, was ein "static" bei variablen verursacht - aber 
bei einem EEMEM-value sollte es meines verständnisses nach damit keine 
probleme geben, da die werte eh an festen adressen liegen - ein kopieren 
in den SRAM findet ja nicht statt

das mit den *.c-includes ist sicher noch ein problem, was ich 
korrigieren muss, aber ich weiß, das diese Dateien nur 1x includiert 
werden.

von Karl H. (kbuchegg)


Lesenswert?

Marian Neubert wrote:

> das mit den *.c-includes ist sicher noch ein problem, was ich
> korrigieren muss, aber ich weiß, das diese Dateien nur 1x includiert
> werden.

Habs grad gesehen.
Wenn schon, dann hast du das wenigstenss konsequent
durchgezogen. Jede 'Compilation Unit' kommt nur einmal
durch den Compiler. Damit hast du nicht das Problem,
von dem ich urspünglich dachte du hättest es.

Trotzdem würde ich jetzt mal hergehen und das richtig
stellen. Mit diesem Monsterjob tust du dir selbst und
dem Compiler nichts Gutes.



von Marian Neubert (Gast)


Lesenswert?

Hmm, ist schon ein wenig komisch - mit GCC 3.4.6 (und dem mitgeleiferten 
Makefile) wirft er eigentlich nur eine Warnung, keine Fehler:

avr-gcc -I"./inc"  -mmcu=atmega8 -Wall -gdwarf-2 -DF_CPU=8000000UL  -Os 
-fsigned -char -MD -MP -MT main.o -MF dep/main.o.d  -c  main.c
inc/lcd_toolbox.c: In function `write_to_position':
inc/lcd_toolbox.c:171: warning: statement with no effect
avr-gcc -mmcu=atmega8  main.o   -L"C:\WinAVR\avr\lib"   -o main
avr-objcopy -O ihex -R .eeprom  main main.hex
avr-objcopy -j .eeprom --set-section-flags=.eeprom="alloc,load" 
--change-section -lma .eeprom=0 -O ihex main main.eep

Ich werde nun mal versuchen, die einzelnen Funktionen, welche jetzt noch 
in den .c-Dateien stehen in Headerfiles "umzubauen". Jetzt kenne ich 
aber leider nicht die GCC-Interna: wo ist der Unterschied, ob ich die 
c-Files oder die h-Files einbinde?

Grüße

von Karl H. (kbuchegg)


Lesenswert?

Die einzelnen c Files, die du durch den Compiler schickst
werden kürzer.

-> bessere Turnaround Zeiten, da nicht bei jeder kleinen
Änderung alles kompiliert werden muss, sondern nur die
Teile die sich auch geändert haben.

von Oliver (Gast)


Angehängte Dateien:

Lesenswert?

"Ich werde nun mal versuchen, die einzelnen Funktionen, welche jetzt 
noch
in den .c-Dateien stehen in Headerfiles "umzubauen". "

Nö. Bitte nicht. .c bleibt bitte .c. Nur überlass das zusammenbauen dem 
linker. Dazu gibst du die Sourcefiles alle schön brav im makefile an, 
und natürlich musst du die System-includes alle wieder auskommentieren, 
und dazu deine auch noch includieren.

ALLERDINGS:

Ich habs aus Spass mal gemacht - zumindest für lcd_toolbox.c. Das 
Problem bleibt aber. Interesanterweise wandert der Fehler, je nachdem, 
welche Zeile man auskommentiert. (GCC 4.x)

Siehe Anlage (nur kompilieren, linken geht natürlich nicht). Da habe ich 
aus Spass mal die allererste var "usergraphics" auskommentiert. Das 
würde so nicht laufen, aber ist ja erstmal auch egal. Irgendwie gefällt 
dem Compiler der Mix aus static und nicht static nicht.

Oliver

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
Noch kein Account? Hier anmelden.