# Trigonometry and Exp/Log functions

ManAtWork
Posts:

**1,512**
in Propeller 2

ManAtWork
Posts: **1,512**

in Propeller 2

## Comments

10,565I don't know about log functions but I can get most of my trig needs satisfied with

rotxy() , polxy(), xypol(), qsin()andqcos().These functions all use integers.

These are listed starting at the bottom of page 10 in the Spin2 doc.

2,166You working on s-curve acceleration by any chance?

I don't

needit but I will want it at some point. Wondering about the most efficient approach with the P2.Craig

1,512Acceleration profiles for CNC and motion control can easily done all with integers. You usually have a fixed upper limit to all numbers so overflows are not an issue. And the sale numbers are high enough to justify lots of work for coding and optimization.

For projects that are more in the "research" and single unit area I'd prefer floating point numbers. I don't want to worry about overflows and I don't want to spend much time on finding the optimum range and scaling factors.

The barometric altitude formula, for example, is nonlinear and requires a pow() function. In the Elev-8 flight controller firmware this is avoided by linear interpolation with a large table. It's possible but it makes it hard to apply corrections. An explicit formula is much easier to handle.

BinFloat.spin2 works very well. And if I use FlexSpin I have dead code removal. I only call that pow() function 25 times a second so performance is not an issue.

2,166@ManAtWork

You have handled s-curve with integers?

I'm sure it's possible and in fact, I'm not convinced that the 'S' is even that critical due to motor response, etc.

Craig

1,735Exp and log are cordic operations, so if they are not present, a few asm lines will do the trick. They are 5:27<>32:0 so I needed several experiments to fully understand how they works (and I used them for synth's ADSR)

2,166Man, I should have thought about the synth stuff. Wow my needs are obviously trivial

Craig

1,735I didn't manage to do 16 voices and 6-op FM in one cog So the next iteration will be 4-op thing. With a nice control panel for which I already did a 32 bpp video driver

5,404BinFloat still works with the modern PNut compiler (I updated it to change the names of a few functions to avoid conflict). The add/sub/mul/div it provides are IEEE compliant, whereas the PNut ones aren't. I forget which tests fail, I think some NaN ones and a few rounding tests. If you want to use the compiler built-ins the easy thing to do would be to change the definitions of add/sub etc. to use +. -. and so on. I don't know what effect this would have on the accuracy of the trig functions; there might be a few more rounding errors.

1,512S-curves are in fact rather trivial when you have a pre-computed trajectory. You simply output the velocity profile without any ramps at all (infinite acceleration, rectangular brick walls). Then you run a moving average filter over it and you get a triangular profile with linear ramps. Run another moving average filter and you get S-curves. Voilà.

Yes I might do that and create a trimmed version of BinFloat. I don't care about bit-for-bit IEEE compliancy as long as I get ~20 bits or better accuracy or something like that. Some day, Parallax has to provide their own math library, I think. But for me it's perfectly OK to use both, built in add/mul and Trig/Exp of BinFloat.

NaN is pretty handy to handle errors. If one of the sensor values is invalid (GPS signal is too weak or receiver needs more time to start up and scan for satellites, for example) I could put NaN there and all results that use that input are automatically flagged NaN, too.

36I get what you are saying! Very interesting... in the past I've always treated two adjacent moves as separate adding the decel velocity of the prior to the accel of the current to get the composite velocity durring the overlap....

1,153Reminds me of Bezier Curves.