int to float conv.

[kmp84]

Hello All,

How to convert(faster) long int to float?

Example:
int32 I32 = 123456 -> convert -> 1234.56(Float)?

Thanks!

[temtronic]

um... 1234.56 is NOT an integer as far as I know...

[kmp84]

Any ideas..?

[Ttelmah]

Now you have edited it to show what you want.
It is always slightly faster to multiply than divide.
So:

float_val=0.01*I32val;

This will perform a float multiplication (since the 0.01 is automatically a 'float', and put the result into the float val. On a PIC18 for example, the multiplication by 0.01 takes about 1/4 the time needed for /100.

As a separate comment though 'why'?.
Remember that the %w format in printf, can automatically output an integer in a 'float appearance', and that this is performed using integer maths.

So:

printf("%7.2lw", I32);

Will print the integer as 1234.56, without ever involving the time penalty of converting to float.

[RF_Developer]

I have to agree with the: "Why?" Or more to the point, what, exactly, are you concerned about?

Floating point operations take a lot longer than the equivalent integer versions. That's a fact of computing life. Personally I'm not so averse to floating point as some other people here are. I much prefer to work in scaled integers in engineering units rather than raw ADC/sensor values. that scaling will generally required at least a floating multiplcation and often an addition (for offsetting). I do avoid divisions, organising my scaling factors to make them multiplicative. I cannot, realistically, avoid doing this somewhere in my code. However, I make sure I'm only doing it once, and only after all other processing has been done, such as averaging, filtering and so on: I will do those in integers.

I do not scale each and every ADC reading. I ensure I'm only doing the floating point scaling when I have to, I do not scale each and every ADC reading. Often I will not scale until its required/requested by the outside world.

I long since (as in the mid-seventies when I was in my youth) gave up on the idea that computers were all, and only about absolute speed. Fast enough is fast enough, and while I have done code and hardware optimisation, I only do it where it is absolutely necessary as it takes a lot of time, generally for little meaningful gain. Also that alternative algorithms, i.e. doing the job in a different way, often provides far more, and far more cost-effective speed gains than keyhole optimising. By "keyhole" optimising I mean this sort of "is there a faster way to divide?" locallissed optimisation of code elements rather than lookign at the process as a whole and asking "do I need to divide at all?" I take the view that much of the computing world took decades ago: if you want something to run faster, buy a faster processor.

On a related point I generally run my PICs at their highest clock speed, only slowing them down (e.g. turning off PLLs) where lower power consumption is necessary and where the improvement is significant. As I nearly always have speed sensitive comms link and run my PICs in relatively hot environments, e.g. RF power modules, I almost never use internal clock, preferring external crystals.

So, if you're worried abotu making your code run faster, then the first question is is it already running fast enough? If so why do anything more?

[kmp84]

Hello Mr."Ttelmah" and Mr."temtronic"

Sorry for my mistake (1234.56)

This equation will do the job

[RF_Developer]

[kmp84]

Hello Mr."RF_Developer",

I know how hard and slow are floating point value for microcontrollers, but in my current project I have to communicate with PC Software that accept only float or double IEEE754 value over modbus protocol and have to adapt to it!

In this project I'm using dsPic33EP512MU810 running at 120MHz.
I have another two important question for this dsPic, but will start in another topic.

Thank you my Friends!

[temtronic]

As others have pointed out we need to know HOW you're using the number. Is it for an actual 'calculation' or just to 'display' ?
If for a 'calculation', then yes floating point is a lot slower that integer math. As well FP numbers are not precise! Computers deal in ones and zeros NOT decimal pointed numbers. That is true of ALL computers, not just PICs.
I suspect the FP math in CCS C is fairly 'optimised' for speed, though I've never looked at the code. I do know it's faster than displaying data on an LCD module and a LOT faster than my typing abilities !

Jay

[kmp84]

Hi Mr."temtronic",

[temtronic]

Since you're using Modbus and a PC, I suspect slow 'speed' may be the actual serial communications ( typically 9600 for Modbus ??) and not the FP calcuation. A PIC at 120MHz is mighty fast and should easly do the 'FP math'. Then there's the PC side of the wires. Are you using a real comport or some USB module, which OS, how many applications/progras running, etc.? All this and more will affect overall performance.

[RF_Developer]

[kmp84]

First thank you very much friends!

I'm running dsPic at 120MHz because using TCP/IP Server, two serial port at 9600 (one modbus RTU and one non-standart serial protocols) and some double floats calc. but this may not be necessary (run at 120MHz)?


Best Regards!

[temtronic]

I never have run a TCP/IP server so I can't speak about the speed needed for it but 9600 baud is about 1 character/millsecond, as a reference.
Now, 2 decades ago, I had a PIC16F877@20MHz, accept true RS232 data, modify it, and resend as true RS232 as well as display on a 2x16 LCD module, it ran fine so I see no reason why the far more powerful PIC you're using won't do the job. During those 'early' years , I also had a Z80@4MHz run a complete computer (kbd, dsp, HD, as well as 3 serial ports), 8 ISRs, so 'speed' is not necessarily required.

[Ttelmah]

Let's put it into perspective.

I'm running a cellular modem at 57600, Bluetooth at 115200, writing to an SD, performing logarithmic conversions on the data, sampling the ADC every 5000th second, running an OLED display, and scanning a keyboard on a DsPic at 32MHz, and it still spends over 80% of it's time in the 'idle' part of the code....
A float32 multiply on a DsPIC at 120MHz, takes just 1.65uSec. The division though takes 8.32uSec. Still a lot better, but neither is exactly major.

Worth also adding that I hope the poster does realise that on the PIC24/30/33, the float32 already is an IEEE float. No conversion needed.