Forum: Compiler & IDEs eeprom_read_word()


von Malte Marwedel (Gast)


Lesenswert?

Ich dachte, ich hätte die EEProm Funktionen langsam verstanden aber bei
dem Quellcode:
u16 globalupdays _attribute_ ((section (".eeprom"))) = {0};
u16 uptimedays;
Und in einer Funktion dann:
uptimedays = eeprom_read_word(&globalupdays);

Gibt der Compiler eine Warnung aus: passing arg 1 of
`eeprom_read_word' form incompatible pointer type
Ersetze ich read_word durch read_byte und u16 globalupdays durch u08
globalupdays gibt es keine Warnungen.
Was habe ich falsch gemacht?

von Jörg Wunsch (Gast)


Lesenswert?

Kann ich nicht nachvollziehen:

% cat foo.c
#include <avr/eeprom.h>
#include <inttypes.h>

uint16_t eefoo;
uint16_t foo;

void
readfoo(void)
{
        foo = eeprom_read_word(&eefoo);
}
% avr-gcc -W -Wall -c -mmcu=at90s8515 -O foo.c
%

von OldBug (Gast)


Lesenswert?

Weis jetzt nicht, wie das deklariert ist:

u16

vielleicht liegts ja daran...

Gruß,
Patrick...

von Jörg Wunsch (Gast)


Lesenswert?

Bei meinem Beispiel fehlte zwar das _attribute_ ..., aber es ist
kein Unterschied, auch mit der korrekten Deklaration bleibt es ohne
Warnung.

von Malte Marwedel (Gast)


Lesenswert?

Also wenn ich wie in dem Beispiel von Jörg, anstelle von u16
globalupdays mit uint16_t deklariere funktionierts ohne Warnungen.
u16 steht bei mir für unsigned short.
Wenn ich mir die inttypes.h ansehe ist uint16_t als unsigned int
definiert.
Laut
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccelng/htm/basic_42.asp
würde
#typedef unsigned int uint16_t;
also 4 anstelle von 2 Byte belegen, und somit aus meiner sicht genau so
viel wie
#typedef unsigned long uint32_t;
Wo wäre dann denn der Unterschied zwischen uint16_t und uint32_t? Auch
reichen mir 16 Bit.

von OldBug (Gast)


Lesenswert?

Warum benutzt die eine Dokumentation, die nicht zum Produkt passt?
Schon mal versucht, mit ner Bedienungsanleitung vom Motorrad Auto zu
fahren? :-)

Wenn u16 bei Dir für unsigned short steht, und der Funktionsprototyp
für eeprom_read_word uint16_t verlangt, welcher mit unsigned int
deklariert wurde, dann hast Du zwei verschiedene Typen vermischt. Und
das klagt der Compiler - völlig zu recht - an.

Gruß,
Patrick...

von Jörg Wunsch (Gast)


Lesenswert?

Die [u]intNN_t Definitionen in <inttypes.h> (*) sind ja genau für den
Zweck bestimmt, daß man damit Datentypen bekommt, die unabhängig von
der zugrundeliegenden Architektur eine bestimmte Bitbreite besitzen.

Das ist C-Standard (ISO-C99 allerdings, nicht ISO-C90 alias
ANSI-C89)!

(*) Eigentlich sollten sie in <stdint.h> stehen, aber das müssen wir
erst noch machen.  <inttypes.h> zieht aber per Standard die
Definitionen aus <stdint.h> ohnehin mit rein, insofern ist das auch
zukunftssicher.

von Malte Marwedel (Gast)


Lesenswert?

Ok, hab in meinem Quelltext die Definitionen für u08 u16 u.s.w an die
Definitionen in inttypes.h angepasst.
typedef uint16_t u16;

http://jubal.westnet.com/AVR/doc/avr-libc-user-manual/group__avr__inttypes.html
jetzt mit der Doku zufrieden? :-)

von OldBug (Gast)


Lesenswert?

Nö, ist die falsche Location! ;-)

http://savannah.nongnu.org/projects/avr-libc/

Gruß,
Patrick...

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
Noch kein Account? Hier anmelden.