2013-07-18 15 views
7

Ho un programma che richiede 4 byte e li converte in un float IEEE-754. I byte vengono trasferiti fuori ordine, ma posso rimetterli in ordine correttamente. Il mio problema è trasferirli su un float. Le parti rilevanti di codice:Cast byte array a float

//Union to store bytes and float on top of each other 
typedef union { 
    unsigned char b[4]; 
    float f; 
} bfloat; 

//Create instance of the union 
bfloat Temperature; 

//Add float data using transmitted bytes 
MMI.Temperature.b[2] = 0xD1;//MMIResponseMsg[7]; 
MMI.Temperature.b[3] = 0xE1;//MMIResponseMsg[8]; 
MMI.Temperature.b[0] = 0x41;//MMIResponseMsg[9]; 
MMI.Temperature.b[1] = 0xD7;//MMIResponseMsg[10]; 

//Attempting to read the float value 
lWhole=(long) ((float)MMI.Temperature.f); 
//DEBUGGING 
stevenFloat = (float)MMI.Temperature.f; 

lWhole è una lunga e stevenFloat è un galleggiante. Durante il debug posso vedere che i valori che assegno all'array di byte vengono memorizzati correttamente, tuttavia i valori di stevenFloat e lWhole non sono corretti. Sembrano al passaggio del mouse vicino a 0, o vicino ai valori massimi del float/long. Un lungo e float sono entrambi a 32 bit con il mio compilatore.

Qualcuno sa perché questo non funziona? Mi è sembrato corretto quando ho ricevuto il codice su cui lavorare e sembra essere una soluzione comune online, sono solo perplesso.

+0

Sei sicuro che stanno trasferiti fuori uso? Quando ho inserito '0x41d7d1e1' in un convertitore esadecimale, ho ottenuto ~ 27, che sembra un buon numero. –

+5

Un problema di endianità? –

+0

cosa ti aspetteresti di ottenere da '0xD1E141D7'? – triclosan

risposta

10

In effetti, questo è un problema endianness:

#include <stdio.h> 
#include <stdint.h> 

int main() 
{ 
    union { 
     uint8_t bytes[4]; 
     float f; 
    } fun1 = { .bytes = { 0x41, 0xd7, 0xd1, 0xe1} }, fun2 = { .bytes = { 0xe1, 0xd1, 0xd7, 0x41} }; 

    printf("%f\n%f\n", fun1.f, fun2.f); 

    return 0; 
} 

Questo stampa:

-483860023749617123328.000000 
26.977480 
+0

come hai deciso che '-483860023749617123328.000000' è meglio di' 26.977480' – triclosan

+0

Non l'ha fatto, ha appena presentato entrambe le opzioni per l'autore di decidere tra ... –

+6

@triclosan Forse perché '-483860023749617123328.000000' è un'impossibilità fisica, sia in gradi Celsius, Fahrenheit o Kelvin? –