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
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
staticconstcharfoo[]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:
@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
