Check if sizeof(double) == 4 could be handled

[GoogleCodeExporter]

On some architectures, such as AVR, doubles are really just floats.

Nanopb currently assumes sizeof(double) == 8. Check if it is possible to relax 
this assumption and support double fields also on AVR.

Possible approaches:
1) Just warn about the incompatibility.
2) Convert floats to/from doubles using bitwise operations.

Original issue reported on code.google.com by Petteri.Aimonen on 28 Jan 2013 at 6:20

[GoogleCodeExporter]

I am also experiencing the same problem. Not defining message types as longs is 
not really an option for me, ideally i would like to be able to encode them as 
floats

Original comment by a...@kritikal.org on 29 Jan 2013 at 10:38

[GoogleCodeExporter]

Trouble with implementing the conversion is that nanopb currently uses the same 
PB_HTYPE for fixed64 & double. The conversion would have to be done only for 
double, not fixed64. This just requires a generator format change, so it breaks 
compatibility and is a bit laborous.

Can you elaborate on why you need to define 'double' in the .proto and 'float' 
is not ok?

Original comment by Petteri.Aimonen on 29 Jan 2013 at 1:07

[GoogleCodeExporter]

There is an existing application that happily uses longs for certain fields. 
All i am trying to do is getting an arduino to interact with the existing 
application so changing the type is not an options. What i tried to do is set 
the value on the DynamicMessage to float but as long as the .proto definition 
is long this still fails. Only when i change the definition to float the 
arduino is happy but then the rest of the application is not. I suppose this 
behavior could be controlled by a nanopb option so that it can be enabled only 
if running on an arduino?

Original comment by a...@kritikal.org on 29 Jan 2013 at 1:14

[GoogleCodeExporter]

apologies i meant happily uses doubles not longs.

Original comment by a...@kritikal.org on 29 Jan 2013 at 1:14

[GoogleCodeExporter]

Hmm, would you be ok with the following solution?

https://code.google.com/p/nanopb/source/browse/#git%2Fexample_avr_double

It requires you to call double_to_float() and float_to_double() manually, but 
doesn't require changes to nanopb core.

Original comment by Petteri.Aimonen on 29 Jan 2013 at 8:11

[GoogleCodeExporter]

Thanks for the prompt reply. As my 'other application' is a java sever, should 
i be using 

http://docs.oracle.com/javase/1.4.2/docs/api/java/lang/Double.html#doubleToRawLo
ngBits(double)

or 

http://docs.oracle.com/javase/1.4.2/docs/api/java/lang/Double.html#doubleToLongB
its(double)

to encode the doubles as longs?

Original comment by a...@kritikal.org on 31 Jan 2013 at 3:40

[GoogleCodeExporter]

You don't need to modify the Java end.

Due how the protocol buffers format works, you can replace 'double' in the 
.proto with 'fixed64' because they are the same size. You will want to make a 
separate copy of the message or the whole .proto file for the AVR end and edit 
that.

Original comment by Petteri.Aimonen on 31 Jan 2013 at 4:48

[GoogleCodeExporter]

This issue was updated by revision e7bf063abc2c.

Original comment by Petteri.Aimonen on 7 Feb 2013 at 3:49

• Changed state: FixedInGit

[GoogleCodeExporter]

So to summarize the results:

I decided that the conversion code will not go into nanopb. It is somewhat 
large and rarely necessary.

There is now check in place that will warn if sizeof(double) != 8.

In addition there is an example how to handle doubles manually without breaking 
message compatibility.

Original comment by Petteri.Aimonen on 7 Feb 2013 at 3:50

[GoogleCodeExporter]

Thats great news. Thanks so much for your help.

Alex

Original comment by a...@kritikal.org on 7 Feb 2013 at 3:52

[GoogleCodeExporter]

Fix released in nanopb-0.1.9.

Original comment by Petteri.Aimonen on 13 Feb 2013 at 7:19

• Changed state: FixReleased