conversion of uint32_t to float - strange behaviour

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

Dear AVRfreaks,

I have a strange behaviour trying to convert uint32_t to float.

Actually my ADC function

  ReadADCvalue();

returns an uint32_t value of 37881 e.g..

Using

  float calc = (float) ReadADCvalue();
or either
  float calc = ReadADCvalue();

returning both calc as 103417.000 !!

 

Thes size of the ADC value might not be a problem, as setting

  float calc = 37881;

shows calc as 37881.000 , as expected.

 

Any ideas where I go wrong?

Thanks!

This topic has a solution.
Last Edited: Wed. Nov 21, 2018 - 03:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Your two numbers when displayed in hex are:

 37881  =  0x93f9

103417 = 0x193f9

 

Could your display function be truncating the real ADC return value?

 

Can you post a small complete program that demos the issue?

 

Jim

 

 

 

 

 

 

Last Edited: Wed. Nov 21, 2018 - 02:17 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ki0bk wrote:
Can you post a small complete program that demos the issue?

Yes, that will be quite interesting.  I'm curious about what ADC is used, with such a high result.  Also, how is the "bad" result being determined?

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

Last Edited: Wed. Nov 21, 2018 - 02:31 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

My guess is that the compiler is being lied to.

My guess is that you do not really know what the function is returning.

Ensure that both the function file and the user file #include the header for the function.

I note that that the complained of values do not share bit pattern,

hence my suspicion that you do not know what the function returns.

 

Future experiments can be done on a PC if you use a dummy function that just reads values off a table.

If you succeed on the PC, but fail on the AVR, you can get rid of the printf's and assign to volatile.

That will remove the vagaries of formats and variadic functions.

A debugger or simulator can provide the output.

Iluvatar is the better part of Valar.

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

skeeve wrote:
I note that that the complained of values do not share bit pattern,

Actually they do, see post #2, the smaller one has the MSB bit stripped off, I suspect the OP used the wrong printf qualifier to display the ADC value, unsigned integer instead of unsigned long!

 

Jim

 

 

 

 

 

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

...simple mistake, big effect!

 

ki0bk is right!!

 

I was using

sprintf (StrDisplay, "ADC: %u", ADCvalue_Temp);

instead of

sprintf (StrDisplay, "ADC: %lu", ADCvalue_Temp);

so the controller is working quite fine!

 

BTW... The ADC I'm using is a 22Bit mcp3551 with a PT1000 temperature sensor.

 

Many thanks!!