Working with 64 bit floats in atmega

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

Im am trying to get to work with a library that enables me to use 64bit-floats on a avr, because i need more accuracy in my calculations .

I included to lib and source file in the attachements.

 

When i use the function "f_long_to_float64" to convert my float32 to a float64 and print out the memory content , it is all zero.

Has anyone worked with this library before or knows how to solve my problem. I am using a atmega164pa

My code:

int main(void){
	radius= 6371000.00;
	init_board();
	stdout = &mystdout;

	printf_P(PSTR("Start1 \n"));
	printf_P(PSTR("test\n"));
	long test1 = 52.141390 * PI * 1./180;
	float64_t test = f_long_to_float64(test1);
	 uint8_t *P;
	P=&test;
	 int i;
	for(i=0;i<sizeof(test);i++) {
		printf_P(PSTR("0x%x "),*(P+i));
	}
		return 1;
}

The output is :

Start1                                                                      
test                                                                      
0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0    

 

I hope someone can help me, thanks in advance.

 

thorb3n

 

Attachment(s): 

This topic has a solution.
Last Edited: Mon. Oct 16, 2017 - 10:00 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you switch to using either the IAR compiler or the Imagecraft "Pro" compiler they already have "double" support.

long test1 = 52.141390 * PI * 1./180;

BTW you do know that by using "long" here it will be truncated. I can tell you now that the result of this line is that test1 will hold 0.

 

52.141390 * 3.141592 * 1 is 163.80697

 

163.80697 / 180 is 0.9100387427

 

0.9100387427 stored in a long is 0.

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

thorb3n wrote:
Im am trying to get to work with a library that enables me to use 64bit-floats on a avr

What library?

Where did you get it? 

Have you followed the documetation?

Have you contacted the author for support?

 

// avr_f64.c

// Original Code by Detlef_a (Nickname in the www.mikrocontroller.net forum).
// Extensions (trigonometric functions et al.) und changes by Florian Königstein, mail@virgusta.eu .

 

, because i need more accuracy in my calculations

Floating point is not (necessarily) going to give you any more accuracy.

In fact, floating-point introduces a number of inherent in-accuracies!

 

 

When i use the function "f_long_to_float64" to convert my float32 (sic) to a float64 and print out the memory content , it is all zero.

Eh??

 

Surely, if the name is correct,  "f_long_to_float64"  converts a long - an integral type - to "float64" ?

 

And, in your code, the paramter you pass is a long - not a float:

	long test1 = 52.141390 * PI * 1./180;
	float64_t test = f_long_to_float64(test1);

In that calculation, the value of test1 will be zero -so your code seems to be working perfectly well as written!

 

EDIT

 

Cliff beat me to it.

Last Edited: Mon. Oct 16, 2017 - 09:45 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:

If you switch to using either the IAR compiler or the Imagecraft "Pro" compiler they already have "double" support.

long test1 = 52.141390 * PI * 1./180;

BTW you do know that by using "long" here it will be truncated. I can tell you now that the result of this line is that test1 will hold 0.

 

52.141390 * 3.141592 * 1 is 163.80697

 

163.80697 / 180 is 0.9100387427

 

0.9100387427 stored in a long is 0.

 

You are right. I forgot to edit it, it should be a float.

But it doesnt change the output.

This reply has been marked as the solution. 
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

thorb3n wrote:
You are right. I forgot to edit it, it should be a float. But it doesnt change the output.
No. Look at the function:

 

float64_t f_long_to_float64(long n); // Converts a long to the float64_t representing the same number

That takes long so even if you pass float it will be truncated to long and 0.9 will become 0.

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

Go on - show the actual, complete  code.

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

clawson wrote:
That takes long 

The clue is in the name - see #3 !

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

thorb3n wrote:
I am using a atmega164pa

Which has on-chip debug - so you could have seen clearly what was happening by simply stepping through the code!

 

In fact, as it doesn't depend on any hardware, you could have seen it in the simulator.

 

 

In fact, it's all standard 'C' behaviour - so you could've seen it in a 'C' program on a PC ...

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

Oh, now i get it. i was always so centered on the double to float thing, that i somehow thought it represents double.

Thanks for your help and taking your time to answer my stupid question.

I think it can be closed now

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

BTW thanks for posting this library code! That is quite a piece of work the author has done there.

 

Wonder why the author didn't go the whole hog and add the support to the compiler?

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

"Experience is what enables you to recognise a mistake the second time you make it."

"Good judgement comes from experience.  Experience comes from bad judgement."

"When you hear hoofbeats, think horses, not unicorns."

"Fast.  Cheap.  Good.  Pick two."

"Read a lot.  Write a lot."

"We see a lot of arses on handlebars around here." - [J Ekdahl]