64bit doubles on an M0?

[gregcope]

Hi,

Are doubles 32bit (like Atmel 328/1284) or 64bit on the Ardunio M0 core like the Arduino Due?

Reason for asking is GPS fix accuracy can be improved as you increase the number of significant digits after the decimal from floats (up from 6).  This is specifically for low values of "how far have I moved from a point".  Most of the haversign functions I have seen rely on a float style lat/long.

See here; http://arduiniana.org/2013/09/greater-accuracy-with-tinygps-13/

A google has returned little and I have no idea where to look...

[mah115]

I believe the hardware can do it, but I'm not entirely sure about the Arduino implementation.

Try this test program:
http://forum.arduino.cc/index.php?topic=153909.0

[TomWS]

Are doubles 32bit (like Atmel 328/1284) or 64bit on the Ardunio M0 core like the Arduino Due?

Are you sure doubles are 32 bit in the AVR code?  Floats are 32bit, I'd expect doubles to be IEEE 64bit format.

[gregcope]

"Double precision floating point number. On the Uno and other ATMEGA based boards, this occupies 4 bytes. That is, the double implementation is exactly the same as the float, with no gain in precision."

https://www.arduino.cc/reference/en/language/variables/data-types/double/

[Felix]

Haven't looked into it but my guess is if Arduino doesn't support it then it's a compiler limitation.

[gregcope]

Sounds like it is supported on some Arduino's

"On the Arduino Due, doubles have 8-byte (64 bit) precision."

https://www.arduino.cc/reference/en/language/variables/data-types/double/

[TomWS]

"Double precision floating point number. On the Uno and other ATMEGA based boards, this occupies 4 bytes. That is, the double implementation is exactly the same as the float, with no gain in precision."

https://www.arduino.cc/reference/en/language/variables/data-types/double/

Ah, so that explains some of the nonsensical use of doubles in some publicly available libraries...  they are still nonsensical, but no one has had to pay the price until they start using the newer processors.

[gregcope]

@tomWS

Can you expand on;

"but no one has had to pay the price until they start using the newer processors."

One idea, instead of me recoding lots of stuff to work around the float accuracy is move to a Moteino M0, that hopefully the Ardunio core supports the IEEE 64bit format and I change a load of floats to double.  This is what Mikal Hart, author of TinyGPS++ suggests in this page; http://arduiniana.org/2013/09/greater-accuracy-with-tinygps-13/ where he writes;

t is worth mentioning that if you are using an ARM or x86–that is, a processor that can support 64-bit C++ “double”s–you can gain still a bit more accuracy by changing all the “float”s in TinyGPS.h and TinyGPS.cpp to “double”

[TomWS]

Can you expand on;

"but no one has had to pay the price until they start using the newer processors."

Since M0 doesn't have FPU, any floating point math will require all SW which will affect performance.  However, if you compare an AVR chip to M0, the M0 will still be vastly faster (and enough storage to hold the extra data) than the AVR processor.  Still, if you compare the software calculation speed using floats vs doubles on the same processor & clock, the float calculations should, realistically, be 2-3X+ faster.

However, my comment was more factored by libraries, like DS18B20, returning doubles....

[gregcope]

Ah.   I see the issue with Ds18B20 and doubles!

I am not using that lib due to the

Code: [Select]

delay

s.  Not the doubles.

I see your point, because on more memory limited architectures those are going to create issues.

I am going to move to the M0 anyway.  Its faster, larger memory, more UARTs, a physically smaller that a Mega, that it makes life easier.

[TomWS]

I am going to move to the M0 anyway. ... that it makes life easier.

Good luck with that...

[mah115]

I am going to move to the M0 anyway.  Its faster, larger memory, more UARTs, a physically smaller that a Mega, that it makes life easier.

You'll also get a zillion bits you need to set correctly, multiple clock domains to synchronize, an event system you have to configure just right to get your interrupts to work, no code examples in the datasheet, and a lot of gotchas that are glossed over in the documentation or not even mentioned.  If you don't need all the fancy features, just use an Atmega.  It took me a week just to get pulse width capture working properly.