mal wieder eine EEPROM Frage

[oberallgeier]

Danke für den Zuspruch - ich zweifle bei neuen Abschnitten von C schon öfters an meinen Fähigkeiten. Und danke für Deine Hilfe.

      int16_t muell;
      muell     = 7;
      eeprom_busy_wait();
      eeprom_write_word ( &eeSeroff[10], muell ); 

Sorry, das mit dem Adressoperator hatte ich vermutet, nein, das hatte ich in Beispielen schon gesehen. Da gibt er mir nur leider auch ne Warnung ab:
pointer targets in passing argument 1 of '__eewr_word_m328p' differ in signedness

In der Zwischenzeit habe ich entgegen meinen Gepflogenheiten das Ganze geflasht - trotz Warnungen sowohl beim EEPROM-Schreiben als auch beim EEPROM-Lesen. In der Ausführung bringt der Lesezugriff die Bestätigung, dass das Schreiben erfolgreich und korrekt war. Anm.: Den Schreibwert setze ich nach dem Schreibbefehl zu 0 um Selbstbetrug zu vermeiden - und die Gleichheit der Typdeklaration(en) der Beteiligten ist auch geprüft.

Bleibt also (nur) die Frage - was bewegt den Compiler zu dieser Warnung. Klappen tuts ja

[schorsch_76]

pointer targets in passing argument 1 of '__eewr_word_m328p' differ in signedness

Der Compiler hast (fast) immer Recht.

Definition von eeprom_write_word:
void eeprom_write_word (uint16_t *__p, uint16_t __value)

Was gibst du rein? Einen pointer auf ein int16_t. Die Funktion erwartet ein uint16_t. Andere "signedness" In dem Fall kann das ignoriert werden.

Gruß
Georg

[oberallgeier]

... Was gibst du rein? ... int16_t. Die Funktion erwartet ein uint16_t ...

Danke Schorsch. Grad hatte ich (nochmal) nachgegrübelt, nachgesehen und war draufgekommen, dass es auch ein avr-libc-user-manual gibt mit ner site über EEPROM Handling. Und schon hatte es geklappt. Aber da hattest Du schon Deinen Hinweis gepostet. Jedenfalls - vielen Dank, die Warnungen sind abgeschaltet. Dumm, eigentlich hätte ich das Vorzeichen benötigt.

Der Compiler hat (fast) immer Recht.

[schorsch_76]

Dumm, eigentlich hätte ich das Vorzeichen benötigt.

Der Compiler hat (fast) immer Recht.

In deinem Fall sollte das auch mit dieser Funktion klappen. In dieser Funktion wird dann dein int16_t so behandelt als ob es ein uint16_t sei. ABER: Es wird ja nicht gerechnet sondern nur gespeichert. Es geht, in diesem Fall, nichts verloren. Auch beim lesen, kommt dann genau die Zeichenfolge wieder raus.

Diese Warnung ist dann wichtig, wenn du damit rechnest. Hier wäre bsp. -7 als uint16_t 32768+7 (Zweierkomplement). Aber die Bitfolge ist exakt dieselbe. Das 2^15 Bit ist das Vorzeichenbit. Bei uint16_t ist das ein einfacher Summand in der Zahl wie jede andere Zahl auch. Bei int16_t ist das 2^15 Bit das Vorzeichen.

Warum machen die Prozessoren das so? Weil mit dem Zweierkomplement eine Subtraktion fast wie eine Addition ausgeführt werden kann

Gruß
Georg

[markusj]

argument 1 of '__eewr_word_m328p' differ in signedness

Sooo schlecht sind die Meldungen vom GCC auch nicht, im Grunde ist die Lösung ganz einfach:

uint16_t eeprom_read_word (const uint16_t *__p) 

Der Pointer ist vom Typ const unsigned int16. Dein Array besteht aus signed int16. Der Compiler bemängelt, dass der Zeiger der eigentlich auf einen vorzeichenlosen 16-Bit-Integer zeigen sollte in Wirklichkeit auf einen vorzeichenbehafteten Integer zeigt. Die Warnung ist in dem Kontext harmlos, du kannst sie durch einen Cast ruhigstellen: (uint16_t *)

mfG
Markus

Nachtrag: Verdammt, zu langsam und die zweite Seite nicht gesehen ...

[oberallgeier]

... schlecht ... vom GCC auch nicht ... zu langsam ... zweite Seite nicht gesehen ...

Die Meldungen und eben auch die Warnungen nehme ich seit den ersten paar C-Monaten schon ernst. Ach - und zu langsam bist Du nicht. Lieber langsam und deutlich als eine schnelle, nichtssagende Bemerkung. Und ich finde es prima, dass ich mit Deiner/eurer Hilfe in diese eher tieferen Details reinkomme.

Danke für alle klaren Hinweise und Erklärungen, ich hab wieder etwas dazu gelernt (und arbeite an dem Thema noch ein bisschen weiter). Schönen Sonntag allen, ich habe Neuschnee, s..kalt, Tourenschi stehen an der Türe - gleich gehts rauf in die Berge...