avr-gcc V10.0.0 and IEEE754 64bit floats

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

 

 

Hi Guys,

 

I need to work with some IEEE754 64 bit floats (actually lat and long in radians from a Trimble Thunderbolt in big endian TSIP format) - I have installed the latest V10 but am wondering how to make sure it treats the long doubles as 64 bit float.

 

Here is the link I used  https://www.mikrocontroller.net/topic/480840#6076058

 

It mentions  there are 2 new options: -mlong-double = 32/64 (default: 64) and -mdouble = 32/64 (default: 32) so that the layout of (long) double is chosen at compile time , but not sure where to put these options and if any extra libraries are need.

 

I'm using Atmel Studio 7.0

 

Any pinters as to what else I need to do ?

 

Regards Tim

 

PS I'm partially sighted so I have to use bold fonts.

 

 

Last Edited: Wed. Apr 29, 2020 - 09:19 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

See posts from SprinterSB. He's been looking at what is required to make a build of avr-gcc with 64bit doubles but, on the whole, up to now, there's never been an avr-gcc with 64 bit. If you really need that accuracy (targeting ballistic missiles at flies on the moon??) then buy ImageCraft Pro or IAR which both offer 64 bit double for AVR. I think one is about $800 and the other about $3,000..$5,000.

Last Edited: Wed. Apr 29, 2020 - 12:22 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Does it have to be AVR? Maybe ARM has more "ready" support for 64-bit double ... ?

 

Does it have to be Floating point? Could you get by with Fixed point ?

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Clawson,

 

Thanks for the reply, 

 

I've followed those posts and found them informative.

 

I think as I don't need to be able to "target flies on the moon" I'll simply convert the 64 bit float to a 32 bit version as the loss of fidelity won't be an issue.  Once in 32 bit the complier issues largely go away.

 

That said I'd stll like to understand how to enable 64 bit as per the original link - if only for acedemic puposes .

 

Regards Tim

 

 

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

Yes it has to be AVR as the chip in use is a Atmega328 - but as a learning exercise I may attempt a STM32 ARM solution if this lock down goes on much longer !

 

Fixed point is a possibllity as I'm only looking for lats and longs in the form -1.234567 and 53.123456 - it's just that Trimble sends the co-ordinates in 64 bit big endian in Radians, to getting to a simple fixed point decimal representation takes the following steps.

 

Convert 64 bit float to little endian

Convert 64 bit to 32 bit for ease of calculation

Convert radians to degrees

Display on LCD using sprintf.

 

Regards Tim

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

You appear to need 6 decimal places.

180/10**-6 = .18*10**9< .18*2**30 .

A 32-bit scaled integer is enough to hold the numbers you want to display.

I suggest converting directly from 64-bit float to 32-bit scaled integer.

If you need to bit-pick, might as well do the entire format-change at once.

When converting to degrees,

the scale on the radians ought not be the same as on the degrees.

Iluvatar is the better part of Valar.

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

All sorted now - displaying lat and lon to 5 decimal places.

 

Converted the 64 bit float a 32 bit float and then to degrees for display.

 

Never did get avr-gcc V10.0.0 working on this problem - will save that puzzle for another day.

 

Thanks for all your help - what a great forum.

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

timdf911 wrote:
All sorted now - displaying lat and lon to 5 decimal places.

 

Converted the 64 bit float a 32 bit float and then to degrees for display.

Almost.

For values in [128, 180],

the LSb of a standard 32-bit float has weight 2**-16=1/(64*1024)> 10**-5 .

You also have the 64- to 32-bit rounding error.

It might be something you can live with.

Do you do more than display the values?

 

To represent radians as a 32-bit scaled integer,

bit 30 can have weight 2.  Bit 31 is the sign bit.

The LSb whould have weight 2**-29 .

 

To represent degrees as a 32-bit scaled integer,

bit 30 can have weight 128=2**7.

Its LSb would have weight 2**-23< (10**-6)/8 .

Since a decimal display is the point of this,

you could give LSb a weight of 10**-6 .

In that case,

bit 30 would have a weight of 2**30*10**-6> 1000 .

 

Doing either conversion from 64-bit float radians is not terribly complicated.

 

Iluvatar is the better part of Valar.

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

Hi Skeeve,

 

thanks for your useful comments.

 

I'm only displaying the co-ordinates for interest purposes and have found them accurate enough to show the correct location of the GPS antenna to within a metre or so - clearly any loss of accuracy is not major.  Indeed my displayed results match exactly those displayed by the Thunderbolt monitor program running on a PC which also displays to five decimal places.

 

So all in all I'm pleased with the result - plus I learned a few things along the way which was the main objective !

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

"Dare to be naïve." - Buckminster Fuller

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

Of most interest to this thread...

  • New command-line options -mdouble=[32,64] and -mlong-double=[32,64] have been added. They allow to choose the size (in bits) of the double and long double types, respectively. Whether or not the mentioned layouts are available, whether the options act as a multilib option, and the default for either option are controlled by the new AVR configure options --with-double= and --with-long-double=.
  • A new configure option --with-libf7= has been added. It controls to which level avr-libgcc provides 64-bit floating point support by means of Libf7.