To Float or not to float?

[foxOnTheRun]

Assumption: in the code I always use RAW unsigned int values when working with sensors.

All right so, floats operations are really handy to display some neat data on the LCD, float is the format of values from sensors, floats give those juicy right comma placed numbers and it's a joy to waste countless days to fine tune them, filters, smooth, numeric tricks...

..but float operations are so slooooww and once inserted in the code, they simply make it's size/execution explode istantly!

So, I'm trying to avoid them at all costs.

In my code I had:

[temtronic]

quick comment

Stick with integer math.

I've used thousands of the LM35/LM34s over the past 2 decades and no 2 are identical,same holds true for the gain of op amps, so really unless this is a 'one off' project you're just playing with numbers for the sake of numbers.No amount of 'clever math tricks' will get two boards to be the same.
Reality is that if the sensor reads 20*C that's fine to us humans. 19.99996 or 20.123456 is NOT important.

[SherpaDoug]

If val_temp is coming from an A/D reading your LM35 you probably aren't getting more than 12 bits, and in most applications 8 bits will do fine. Properly scaled 8 bits gives better than 0.5% resolution.

I have used floats for occasional debug. But I don't think I have ever used floats in actual final code shipped to a customer.
_________________
The search for better is endless. Instead simply find very good and get the job done.

[Ttelmah]

and some more comments:

Float's are _not_ the 'format of values from sensors'. Numbers arriving from sensors will always be integers

Think for a moment about things like DVM's. _scaled integers_ are what they display.

Digital filters commonly use scaled integers as well.

Anything requiring repeatable precision avoids float's at all costs (look at financial calculations for example).

Now, yes, your approach is a start. However you need 'L' in the %w declaration.
Then remember that float on the PIC16/18, only handles at best 6.5 decimal digits. The last four digits in your constant in the original value were doing nothing. You hardware is unlikely to be doing better than 0.1% accuracy anyway, so 90% of the values being displayed by the float, are 'fallacious'...
Remember also division is always slower than multiplication (except for constant using a binary value - 2,4 etc.).
So start by reciprocating your value.
*0.609327, would immediately be several times faster.
Now remembering the comment about binary divisions, multiply by 256
So:

[foxOnTheRun]

[foxOnTheRun]

[foxOnTheRun]

[foxOnTheRun]

[SherpaDoug]

Consider the difference between floats and fixed point numbers. You can calculate integer millidegrees much faster than you can true floats, and use %w to put the decimal where it belongs for display. The idea is that for most real world values the decimal point really doesn't need to float at all. If a thermometer is going to display 6.5 degrees, or 65.4 degrees or 654.3 degrees, the decimal does not move.
_________________
The search for better is endless. Instead simply find very good and get the job done.

[foxOnTheRun]

[Ttelmah]

Glad you have worked out a solution that suits.

It might be quite 'informative', to just run this part of the code in MPLAB simulator, and time it. The division by 64, should only take perhaps a dozen machine cycles now, and the multiplication perhaps a couple of hundred cycles. Also the actual output in printf, will also be faster. The %w format, is only having to divide by ten in integer, for each digit, versus the %f version is having to do a float division for each digit.
I'd be expecting something around 10* speed gain.

Best Wishes

[FvM]

Digital signal processing of sensor data partly requires complex arithmetic, e.g. applying higher order polynomials or exponential functions. Although everyhing can be done in integer fixed point with respective coding effort, these calculations are an obvious domain of float arithmetic.

If lower speed and slightly higher code size aren't an issue, you can expect faster project completion and less hidden faults utilizing float, if complex calculations are involved.

[foxOnTheRun]