Anther Teensy 3.2 question.. Math..

jim lee

jim lee

Well-known member
Does it do 32 bit math operations? Or just 16 bit? I think Arduinos typically only do the 16 bit stuff.

Many thanks!

-jim lee
 
Actually, I see that it's listed as 32 bit processor. Do I need to use double to get the precision? I have some picky math in my immediate future.

-jim lee
 
Your question has the words "double" and "precision", which are normally used when talking about floating point numbers.

Teensy 3.2 uses software emulation for floating point math. It works, but speed isn't wonderful, especially for 64 bit double precision.

Teensy 4.0 has a hardware floating point unit that computes 32 and 64 bit floating point math very fast.
 
Well, the speed should be fine for this. I only need to calculate it twice per second. As for the 4.x teensy? I'm getting there. I only have about 1/2 dozen 3.2 teensy's left. Then I will be switching over.

P.S. Thanks for letting me know the precision. This new bit is calling for 64 bit doubles multiplied by 10^17 to force them into signed long ints. ( I don't write the specs. I just have to implement them.)

-jim lee
 
Ok got one more issue..

int64_t the compiler thinks its a "long long" ? How can I bailing-wire together an int64_t? Is it even possible?
 
jim lee said:
How can I bailing-wire together an int64_t? Is it even possible?
Click to expand...

Should be no issue at all. Can confirm int64_t works fine.

However, only recent versions of Teensyduino have Serial.print() support for int64_t. With older versions you could still print them, buy only with Serial.printf().
 
What's going on. This is converting GPS data (read in as text string) to NMEA2000 data packet. (binary) They are looking for latitude/longitude in degrees. Then multiplied by 10^16 and stuffing the result into a signed 64 bit integer. Kinda' makes sense because it's tough to spec. how to pass a float, whereas passing an integer is pretty easy to spec.

Now, you are all saying this is a non-issue. It was quite late when I ran into this. Maybe I was just tired and missed something? I'll go fine tooth my code this morning and see if I can figure out what's going on.

Thanks again for helping!

-jim lee
 
jim lee said:
They are looking for latitude/longitude in degrees. Then multiplied by 10^16 and stuffing the result into a signed 64 bit integer.
Click to expand...
Almost makes sense. The dynamic range of the value is small so a float is wasted on it and fixed point is perfect. But 64 bits is way too big and for fixed point you would multiply by a power of two. Like 2^23. Which would provide a range of +255 to -256 with 23 fractional bits. Or resolution of less than an inch worst case.
 
Like I said it was late and I was tired. Just because the function is declared in the .h file doesn't mean I don't need to actually write it in the .cpp file.

Thanks again for the help. What you were all telling me pointed me in the right direction to re-visit what I'd written, more carefully.

-jim lee
 
UhClem said:
Almost makes sense. The dynamic range of the value is small so a float is wasted on it and fixed point is perfect. But 64 bits is way too big and for fixed point you would multiply by a power of two. Like 2^23. Which would provide a range of +255 to -256 with 23 fractional bits. Or resolution of less than an inch worst case.
Click to expand...

For what its worth. When sending gps locations I like to use int32_t and multiply the double location by 10 million

Using 4 bytes this gives 1.1cm precision
Storing gps locations in a float gives best case 1.1 meter precision.
 
Yes, I know. But in this case I have no say in the matter. Some are specced for int32_t and some are insisting on int64_t. I notice that the instruments that I'm using to display the values (marine applications) are using the int32_t versions of the data. I've heard that factory folks like the higher precision. Maybe they are trying to use it as an electric ruler?

-jim lee
 
You must log in or register to reply here.
Back
Top