Converting EEPROM to floats

Go To Last Post
8 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey guys, this isn't a problem, mearly announcing a great idea I came across.

I was wondering how to convert a block of data (four bytes) from EEPROM into a float, when the data is read into an unsigned long from eeprom_read_word. I found on the butterfly GCC port a .h file with a simple workaround, much more elegant that I would have come up with, so simple yet so brilliant.

It worked as such (psudocode):

union
{
   unsigned int b[2]
   float f
} FT

In this manner, you set the two uints to the two halves of the read word data, and then the float is read from the union due to shared memory. Brilliant.

I believe this came from the GCC mailing list. Just thought I'd make this little gem known.

- Dean :twisted:[/code]

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

Last Edited: Tue. Mar 1, 2005 - 05:13 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Dean, thanks for making this trick explicitly known here, but in fact this is a programming technique being used for decades. In fact, we aren't talking about any conversion, it's just a matter of automatically interpreting a given/constant value in different number systems. So, if you know your data source provides binary data which in fact is already in float (or whatever) form, use your trick above to handle it elegant within a program.

-- Thilo

Einstein was right: "Two things are unlimited: the universe and the human stupidity. But i'm not quite sure about the former..."

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Meh, well it's still a good trick.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

abcminiuser wrote:
I was wondering how to convert a block of data (four bytes) from EEPROM into a float, when the data is read into an unsigned long from eeprom_read_block.

I cannot get what is your goal.
Whay you the use two ints in union?
If you want to write/read float to/from EEPROM you can just do it directly (using eeprom_xxxx_block).
If you want access to internals of float representation then two ints are inadequate.

Regards,

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If your runnign out of room - and are already using eeprom_read_word to save space (I believe it's smaller than read_block and can be more convenient in some instances) then this is a good idea. You read two words into the ints in the union, then the nature of the shared-memory space union combines the data into the double or float variable.

This is usefull in many situations, not just for EEPROM. My application uses fixed point maths rather than floating point because, like I said, low ROM space and so rather than havign to shift variables and combine, this simplifies the whole process.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

abcminiuser wrote:
If your runnign out of room - and are already using eeprom_read_word to save space (I believe it's smaller than read_block and can be more convenient in some instances) then this is a good idea. You read two words into the ints in the union, then the nature of the shared-memory space union combines the data into the double or float variable.

You're forgetting the overhead of setting up, and returning from the second function call.

If you're really interested in saving space, then you need to write two test programs, one that does 2 calls to eeprom_read_word, and one that does 1 call to eeprom_read_block, and account for all the assembly to setup and call the functions.

You may be right. But you may be wrong in your assumption.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You'd still be much better off to load all the stuff from EEPROM by defining a structure and using a single block read, IMNSHO. The great thing about using a structure is that you don't ever have to worry about what the data types are, everything is taken care of, and one read_block is all you need. You don't need to shift variables and combine, and you don't need to make any assumptions about the size of an int, or byte-ordering (little-endian or big-endian).

Four legs good, two legs bad, three legs stable.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Yes, in my particular situation, read_block happens to be better, as I am only using read_byte. I just put it here because I thought it was a novel idea, one that shows a good use of the C language. Perhaps you can all start adding your own "ingenious" snippits.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!