_|| in flash? eeprom_read_byte()

Klar, weil du nur das Zeichen 'F' in den EEPROM schreibst, ohne eine 
abschließende '\0' um den String zu terminieren. Du behandelst beim 
Ausgeben quasi ein einzelnes Zeichen als kompletten String.


> char *addr = "0x01";
Das ist aber auch Quatsch! Was versuchst du denn eigentlich zu machen? 
Das Programm sieht sehr eigenartig aus.
Schon mal ein C-Buch in Erwägung zu ziehen, bevor du auf die Creme de la 
Creme (Mikrocontroller in C) losgehst?

http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#EEPROM

Martin schrieb:
> Hi,
>
> ich bin in C tatsächlich nicht fit :). Habe aber schon einiges gelesen.
> Ich raffe das meistens eh erst dann, wenn ich es in der Praxis anwende.
>
> Ich habe deine Variante getestet. Schreibe ich "\0" hinter meinem
> Zeichen, nimmmt der das nicht an. Der Compiler sagt:
>
> main.c:215:43: warning: multi-character character constant
> main.c: In function 'main':
> main.c:215: warning: large integer implicitly truncated to unsigned type

Da kann man so nix zu sagen, außer: Code zeigen. Und außerdem habe ich 
'\0' geschrieben und nicht "\0" (Ja, das ist ein Unterschied. Einzelnes 
Zeichen vs. String).

> Der Link von dir beschreibt das direkte Zugreifen auf ein EEPROM. Warum
> das Rad neu erfinden?
Was anderes als Direkt zugreifen machst du doch auch nicht?

> char *addr = "0x02";
> Wie soll ich sonst deklarieren?
Na, wie wärs mit richtig? So wie es da jetzt steht legst du einen String 
an und benutzt die RAM-Adresse des Strings irgendwie im EEPROM, wobei 
der String nie benutzt werden würde. Also dermaßen am Ziel vorbei, 
vorbeier geht es nicht mehr.

char* addr = (char*) 0x02;

wäre zum Beispiel ein Anfang, mal so aus der Hüfte getippt. Aber warum 
lässt du die EEPROM Variablen nicht direkt vom Compiler verwalten? Der 
reserviert für dich dann den EEPROM Speicher, sodass du nicht aus 
versehen zwei Variablen überlappend anlegst. Siehe den Artikel.

> Bei allen anderen Varianten meckert der
> Compiler. Bzw. gibt Warnings aus. Das hier ist die einzige Variante die
> ohne Warning funktioniert.
Und das heißt dann, dass die richtig ist? Is klar!

> Kann es sein das in dem Header eeprom.h das "\0" fehlt?
Nein, das kann nicht sein (Mal davon abgesehen, dass diese Aussage 
einfach keinen Sinn ergibt).

Du solltest wirklich erst mal anfangen ein C Tutorial oder ein C Buch 
(besser) durchzulesen. Alles andere macht es nur noch komplizierter.

Martin schrieb:
> char *addr = "0x02";
> Wie soll ich sonst deklarieren? Bei allen anderen Varianten meckert der
> Compiler. Bzw. gibt Warnings aus. Das hier ist die einzige Variante die
> ohne Warning funktioniert.

Um das beantworten zu können, müsstest du erst mal erklären, was das 
überhaupt werden soll. Falls du einfach an die Adresse 0x02 im EEPROM 
schreiben willst, sähe das z.B. so aus:

1

uint16_t addr = 0x02;

2

eeprom_write_byte((uint_8 *)addr, 'F');

> Kann es sein das in dem Header eeprom.h das "\0" fehlt?

Was sollte das dort auch zu suchen haben?
Dein Problem ist dies:

1

 char data;

2

...

3

 lcd_string(&data);

Du hast ein einzelnes Zeichen, und übergibst dann die Adresse dieses 
Zeichens an eine Funktion, die unter der Adresse einen String erwartet. 
Mit dem EEPROM und was darin steht, hat das Problem rein gar nichts zu 
tun.

1

 uint8_t myByte;

2

..

3

 lcd_string(&myByte);

Was für ein "offizielles Beispiel" soll das denn sein?
Du machst da exakt den gleichen Fehler wie oben. Nochmal: das Problem 
hat mit dem EEPROM und seinem Inhalt nicht das geringste zu tun.

Genau, siehe 1. Antwort:

Simon K. schrieb:
> Klar, weil du nur das Zeichen 'F' in den EEPROM schreibst, ohne eine
> abschließende '\0' um den String zu terminieren. Du behandelst beim
> Ausgeben quasi ein einzelnes Zeichen als kompletten String.

Oder auch von Stefan:

Stefan Ernst schrieb:
> Dein Problem ist dies: char data;
> ...
>  lcd_string(&data);
> Du hast ein einzelnes Zeichen, und übergibst dann die Adresse dieses
> Zeichens an eine Funktion, die unter der Adresse einen String erwartet.
> Mit dem EEPROM und was darin steht, hat das Problem rein gar nichts zu
> tun.


PS: Du hast übrigens anscheinend nicht das Geringste verstanden vom dem 
Artikel. Bei der Variable eeFooByte muss das Schlüsselwort EEMEM 
angegeben werden! Ansonsten macht der Code keinen Sinn, da eeFooByte im 
RAM liegt, du aber auf der gleichen Adresse im EEPROM rumwerkelst.