Hi, i am playing with a ms5611 pressure sensor. In the calculations it requires int64 variables. However flowcode only gives options for int32, i.e ulong.

Does this mean that its not possible to use this sensor with flowcode??

## int64 is it possible ??

### Re: int64 is it possible ??

Hi Cobra,

That might depend on which microcontroller you are using, and how much precision you really need. What I'm thinking is that you could read all of the coefficients from the register values, then convert them to float variables using the "int2float()" function. Then use the same formulas as given, but using floats instead of integers - that will allow you to hold the very big numbers in 32bits of space.

You will lose precision that way, though, as 32bit floats only have 24 significant digits (scaled by powers of two when representing very big or small numbers). You would need to experiment to find out what kind of resolution you end up getting - it can be worked out in theory, but with so many terms in the equations, it's far too tricky for my maths skills!

If you really need the full precision of the chip, the only alternative would be to use two 32bit integers to represent a 64 bit one. But that makes the maths very complex indeed, especially for signed values - you would have to program the flowchart to work out when bits "carry over" between the two halves for every little step of the calculations. Some googling might manage to find you some 'C' code that does it though, in which case you could possibly use 'C' icons, or the 'Supplemental Code' box to define the functions. No idea how much memory that kind of code would need though - I would have though it would be fairly similar to the memory used by the floating point functions.

Cheers,

Steve.

That might depend on which microcontroller you are using, and how much precision you really need. What I'm thinking is that you could read all of the coefficients from the register values, then convert them to float variables using the "int2float()" function. Then use the same formulas as given, but using floats instead of integers - that will allow you to hold the very big numbers in 32bits of space.

You will lose precision that way, though, as 32bit floats only have 24 significant digits (scaled by powers of two when representing very big or small numbers). You would need to experiment to find out what kind of resolution you end up getting - it can be worked out in theory, but with so many terms in the equations, it's far too tricky for my maths skills!

If you really need the full precision of the chip, the only alternative would be to use two 32bit integers to represent a 64 bit one. But that makes the maths very complex indeed, especially for signed values - you would have to program the flowchart to work out when bits "carry over" between the two halves for every little step of the calculations. Some googling might manage to find you some 'C' code that does it though, in which case you could possibly use 'C' icons, or the 'Supplemental Code' box to define the functions. No idea how much memory that kind of code would need though - I would have though it would be fairly similar to the memory used by the floating point functions.

Cheers,

Steve.

### Re: int64 is it possible ??

Hi steve, thanks for your reply.

It appears to be the OFF calculation in the pressure formula causing problems. The result being given is just too big for the ulong variable to hold and results in a negative number. I assume a float variable wouldnt be able to hold this value either??

Im using a pic18f series chip.

It appears to be the OFF calculation in the pressure formula causing problems. The result being given is just too big for the ulong variable to hold and results in a negative number. I assume a float variable wouldnt be able to hold this value either??

Im using a pic18f series chip.

### Re: int64 is it possible ??

That shouldn't be a problem when the maths is done using floats - once the registers are converted to float, you'll need to make sure that all of your 'intermediate' variables are also floats.cobra1 wrote:I assume a float variable wouldnt be able to hold this value either??

You might be familiar with the "E" notation for writing very big and small decimal values, sometimes called "scientific notation" - for example 1.23e8 = 1.23 * (10^8) = 123,000,000

Notice how the 'E' version saves space - no need to write out all those pesky zeros!

But notice that there's no extra 'detail' - just those same three digits of precision; if we change the first part to '1.24', the number jumps by a million!

Float numbers work exactly the same way - though it's all hidden away so we don't need to worry too much about it.

When a float number is stored, the actual bits are coded in a very particular way. Part of the value (the mantissa) gives the 'detail' - like the '1.23' in the example above - and another part (the exponent) represents how many bits to shift the value to make it bigger or smaller; but powers of two instead of ten.

Just as the '10^' part of an 'E' number moves the position of the decimal point, the exponent of a float moves the "binary point" - the point can 'float around', hence the name.

The float can now represent a far wider range of numbers using the same number of bits - just as with the decimal, a whole load of zeros just don't need storing.

There are eight bits used for the exponent in a 32bit float, allowing the point to be shifted by 127 places in either direction. So the biggest possible value is nearly 2^128 - which will be plenty big enough for the sensor calculations.

The trade off is that you lose some precision when doing maths. You've used up 8 bits for the exponent part, and you need one more for the sign - leaving you with only 23 bits to represent the "detail" of the number. The upshot of this is that for extremely large numbers, big gaps open up between the numbers where there are values that you just can't represent, so they get rounded to the nearest one that is possible. For a 32bit float, once you count beyond a few million, you can't even get every single whole number any more!

However, in this case, you might not lose too much precision. The original register values are starting out with only 16bits of precision anyway, and a lot of the maths is multiplying and dividing by exact powers of two - those are a special case, as they'll only change the 'exponent' part of the float, and leave all of the mantissa bits alone (on many machines, they'll execute faster as well).