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
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
> in einem include zuvor werden Strings im EEPROM so abgelegt:
Klingt suspekt.
Bitte poste mal compilierbaren Code, der das Problem demonstriert.
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.
@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
> 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.
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 |
@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.
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.
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
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.
"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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.