Wenn ich mehrere Zahlen-Variablen ins EEPROM speichern möchte, muß ich
mir dafür die Funktion eeprom_write_block hernehmen oder geht das auch
mit eeprom_write_byte.
Falls ja, ich versuche gerade 2 Variablen zu schreiben und zu lesen:
1
volatileuint8_tnKonfig;
2
volatileuint8_tlight;
3
4
volatileuint8_tEEMEMeeprom_tasten=1;
5
volatileuint8_tEEMEMeeprom_lcd=2;
6
7
intmain(void)
8
{
9
init();// Einschaltsequenz starten
10
sei();// Interrupts aktivieren
11
12
lcd_update();
13
14
nKonfig=(eeprom_read_byte(&eeprom_tasten));
15
light=(eeprom_read_byte(&eeprom_lcd));
16
...
Der compiler kommt mir jedoch mit einer Warnung:
../main.c:351: warning: passing argument 1 of '__eerd_byte_m8' discards
qualifiers from pointer target type
Über die Dekoration volatile würde ich zumindest bei den EEPROM-Daten
nochmal nachdenken. Die dürften seltenst sinnvoll in einer ISR geändert
werden... Ohne volatile kommt auch die Warnung nicht.
Hallo, habe auch genau dieses Problem, dass die Warnung kommt. Aber ich
möchte die Variable im EEPROM in einer ISR ändern, nämlich wenn über den
RXT interrupt Parameter geändert werden, welche im EEPROM stehen.
Wegcasten kann man diese Warnung auch nicht! Was also tun damit die
Warnung verschwindet?
Ich Grabe die Leiche wieder aus, dann spare ich mir einen neuen Beitrag.
Ingo
Ingo schrieb:> Aber ich> möchte die Variable im EEPROM in einer ISR ändern
EEPROM schreiben kostet pro Byte 8ms. Möchtest Du wirklich, daß Dein
Programm abschmiert, weil die CPU so elendig lange stehen bleibt?
Generell hat man für EEPROM-Daten immer eine Arbeitskopie im SRAM.
Und nur bei Bedarf wird der EEPROM damit geupdatet.
Entweder im Main, damit die Interrupts weiter laufen.
Oder ganz clever im EEPROM-Interrupt ohne jede Zeitvergeudung.
Ingo schrieb:> Ich Grabe die Leiche wieder aus, dann spare ich mir einen neuen Beitrag.
Nicht gut, da Dein Problem ja ein völlig anderes ist.
Peter
Nein ist kein Anderes, ist absolut das selbe. Du weißt weder ob sich
mein ganzes Programm in einer ISR abspielt oder sonst was. Also nur die
eigentliche Frage beantworten. Trotzdem danke für den Hinweis.
Ingo
Ingo schrieb:> Du weißt weder ob sich> mein ganzes Programm in einer ISR abspielt
Ich gehe eben von einem sinnvollen Programmkonzept aus.
Kann gut sein, daß ich damit manchen besser einschätze, als er ist.
Aber Du hast irgendwie doch recht, wir wissen garnichts.
Du hast nichts mitgeteilt, also können wir auch nicht helfen.
Jeder weiß eigentlich, bei Programmierfragen ist ein Quellcode als
Anhang und die exakte Fehlermeldung mit Zeilennummer das mindeste.
Peter
Ingo schrieb:> Ja, aber wenn ich das so schreiben würde:>
1
>volatileunsignedinttemp=0;
2
>...
3
>temp=eeprom_read_byte(&eeFooByte));
4
>
> meckert der Compiler.
'meckert der Compiler' ist keine vernünftige Fehlermeldung.
Auch wenn es manchmal nicht so aussieht: Fehlermeldungen haben einen
Grund und der Grund ist in der Fehlermeldung enthalten. Ich gebe zu,
manchmal ist es schwer den Grund zu entdecken, wenn man die C-Syntax
noch nicht so drauf hat.
> volatile unsigned int temp=0;> ...> temp = eeprom_read_byte (&(unsigned int)eFooByte));> [/c]>> kommt er mir dem "&" durcheinander hält es für eine logische UND> Verknüpfung.
Nö, das tut er nicht.
Eine Und Verknüpfung hat immer eine linke Seite und eine rechte Seite
a & b
Das ist hier nicht der Fall, also kann es auch kein Und sein. Das weiß
auch der Compiler. Und du kannst davon ausgehen, dass der Compiler die
C-Syntax sehr viel besser kennt als du.
Aber: Durch das Umcasten eines Bytes zu einem unsigned int, hast du eine
temporäre Variable erzeugt (eben den unsigned int) und von dem kannst du
nicht die Adresse nehmen. Daher kann "&(unsigned int)eFooByte" nicht
richtig sein.
Das ist aber auch nicht das was du wolltest.
Du wolltest die Adresse von eFooByte nehmen.
Und das schreibt sich als
&eFooByte
und dann diese Adresse als die Adresse eines unsigned int aufgefasst
wissen:
(unsigned int*)&eFooByte
Damit, dass du links vom = einen unsigned int hast, hat das herzlich
wenig zu tun. Du kannst nicht dadurch, dass du der Funktion den
Adressdatentyp eines unsigned int unterjubelst (selbst wenn du das
richtig gemacht hättest - "(unsigned int*) &eFooByte" ) die Funktion
dazu bringen, dass sie etwas anderes tut als ein einzelnes Byte
auszulesen.
Also: Wie lautet die Fehlermeldung im genauen Wortlaut. Damit fängt
jegliche Analyse an. "meckert der Compiler" ist kein genauer Wortlaut.
Und dann sieht man sich eben alle Datentypen der beteiligten Operationen
an und kontrolliert, wo man den Fehler gemacht hat.
Eine Warnung bezüglich Datentypen kann man IMMER wegcasten. Letzten
Endes ist ein derartiger Cast die Anweisung an den Compiler: "Halt's
Maul, ich weiß es besser." Nur sollte man auch sicher gehen, dass man es
auch wirklich besser weiß.
Das heist dann ja auch so:
((unsigned int*)&eFooByte))
Natürlich gehen mehrere Variablen ins EEPROM, kannst die Adresse
jedesmal ändern, musst nur aufpassen, dass du nix überschreibst.
writeword belegt zB 2 Adressen, steht aber alles hier auf
Anleitungsseiten
Hallo, danke für die Antworten. Ich habe diesen Tread wieder aufgemacht,
weil ich die Warnung (erster Beitrag) auch bekomme, wenn ich die
Variable volatile mache. Mein Cast ist offensichtlich falsch gewesen, so
wie es Karl-Heinz und Martin geschrieben haben.
Ich habe nur das selbe Problem gehabt wie der TE, jedoch will ich keine
2 Variablen oder sonst was machen, geht nur darum das volatile
wegzucasten.
Danke
Ingo
wobei sich allerdings die Frage erhebt, wozu man EEMEM Variablen
überhaupt als volatile markiert.
Diese 'Variablen' sind nur ein Hilfskonstrukt, damit man eine
Adressallokierung im EEPROM bekommt. Machen kann man mit diesen
Variablen sowieso nichts, ausser die eeprom_xxxx Funktionen mit ihren
Adressen aufrufen. Und die kann ein Compiler sowieso nicht
wegoptimieren.