Reading float32 from EEPROM produces garbage

[Entropia]

Hi. I've followed CCS advice on how to write four byte values into EEPROM. This works as expected. I receive uint32 over UART and write that into EEPROM. When I read back the EEPROM via PICkit3, it is as expected. I convert the float value to uint32 in the sending end to be able to use ASCII protocol with simple parsing using atoi32.

However, when I read EEPROM in my program to a float32, I get garbage. For example; I write 0x412925A0 into EEPROM. This is around 10.57 in float32. When I do printf("%f", eepromRead32(0)) I get basically garbage. I don't have the actual garbage values on hand but it's way off and I also checked that it's no bit reversal or anything simple like that either. When I read it back to %Lu (uint32) the value is exactly what I expect. So there is definitely something fishy going on with float variable in the compiler... Anyone got any hints?

I'm using a PIC18F26K20 with PCWHD 4.133.

Here's my EEPROM handling functions (just tidied up CCS ones):

[RF_Developer]

Sounds like floating point format confusion. CCS on most PICs do not use IEEE754 floating point format. They use a modified version of of defined by Microchip. That means that when you send bytes from outside, which are most probably IEE754, the CCS compiler's float routines cant understand them.

There are a some ways round this. You can send the bytes as you are doing and use the routines found in ieeefloat.c to convert to/from Microchip float to IEEE754 float32. Note CCS has no support/equivalent for doubles or extended on most PICs, just 32 bit floats. Beware, the PIC routines don't support the full range of NaNs and related stuff. Even then, byte order may cause trouble, so watch out!

Another alternative is to go the traditional route from the days when every compiler on every computer had its own floating point format (IEEE754 is comparatively new) and so floats were never sent in their binary form. THey were either converted to a scaled integer, or more commonly sent in human-readable ASCII.

[Entropia]

Thanks for the reply. I am indeed feeding it IEEE-754 single floats. Actually the system that produces these floats is a PIC24 but I assume it can handle those.

I will see what I can do about this...

[Entropia]

ieeefloat.c's f_IEEEtoPIC provided the necessary solution for me. Fourtunately it is only 68 bytes when compiled! Thanks again RF_Developer!