falsches Rechenergebnis mit unit32_t EEprom Variablen

[Helge (Gast)]

Hallo zusammen,

ich habe ein Problem mit dem Einlesen einer uint32_t -Variablen über die 
Funktion 'eeprom_write_dword'.

Ich definiere die Variablen hiermit:

uint32_t eeSteigungA EEMEM =0;
uint16_t RxyA;

speichere die Variable so:

eeprom_write_dword (&eeSteigungA, Wert);

und will dann in einer Funktion diese Rechnung durchführen:

RxyA = 1234567890/eeprom_read_dword (&eeSteigungA);

und gebe es über UART dann an den PC aus:

USART_Transmit_String(utoa(RxyA,buffer,10));

Die Varaiable &eeSteigungA ist 9-stellig, also größer als uint16_t.
Leider ist das Eregebnis in der Ausgabe nicht das, was es sein sollte.
Mit eeprom_write_word und entsprechend kleinerer Stellenzahl 
funktioniert die Vorgehensweise.
Anscheinend verschluckt eeprom_read_dword ein paar Stellen, aber warum ?

Vielleicht kann mir hier jmd. den Tip geben.

Danke,
Helge

[Julian B. (julinho)]

Helge schrieb:
> utoa ist für 16-Bit unsigned int, eventuell mußt du noch casten.

[Helge (Gast)]

Danke für die schnelle Antwort,

RxyA sollte aber doch nur 2 Stellen, warum muss ich hier dann eine 
unit32_t Variable übergeben ?

[Karl H. (kbuchegg)]

Ich würde mir halt mal das Ergebnis von

    eeprom_read_dword (&eeSteigungA);

ausgeben lassen und vergleichen, ob es identisch ist mit dem Wert den 
ich rein geschrieben habe.

Und dann mal die Berechnung durchführen und ansehen, welcher Wert da 
wirklich raus kommt.

[Julian B. (julinho)]

Helge schrieb:
> RxyA sollte aber doch nur 2 Stellen, warum muss ich hier dann eine
> unit32_t Variable übergeben ?

Weil RxyA in Abhängigkeit von eeSteigungA auch größer als 16 bit sein 
kann, das kann der Compiler nicht wissen.

[Helge (Gast)]

Warum eeprom_read_dword die verschluckt, weiß ich jetzt.
Ich lese es über UART und die atoi-Funktion ein, und da kann eben nicht 
mehr als 16bit geben.

Was mir aber noch ein Rätsel ist, ist die Tatsache, dass ich, wenn
ich eine Konstante über 16 bit groß wähle, ein richtiges Ergebnis 
erhalte,
multipliziere ich es aber mit einen Faktor, bekomme ich einen Überlauf.

RxyA = 123450000/eeprom_read_dword (&eeSteigungA); >>mit SteigungA 12345
wird 1000 ausgegeben

RxyA = 12345*1000/eeprom_read_dword (&eeSteigungA); >> Überlauf.

Wenn ich in der Rechnung als niemals über den 16-bit Überlauf kommen 
darf,
warum wird dann erste Rechnung richtig ausgegeben ?

Helge

[Fabian O. (xfr)]

Im ersten Fall wird mit 32 Bit gerechnet, da 123450000 nicht in 16 Bit 
passt. Im zweiten Fall sind dagegen beide Zahlen in 16 Bit darstellbar, 
also wird auch nur mit 16 Bit gerechnet. Bei der Multiplikation 12345 * 
1000 gibt es dann entsprechend schon den Überlauf.

Abhilfe: Einen der Werte zu 32 Bit machen:

RxyA = 12345*1000UL/eeprom_read_dword (&eeSteigungA);

[Helge (Gast)]

Fabian O. schrieb:
> Abhilfe: Einen der Werte zu 32 Bit machen:RxyA =
> 12345*1000UL/eeprom_read_dword (&eeSteigungA);

Klasse, funktioniert !
Danke