as we know from all the "007-Bond" episodes someone names "M" played a leading rule.
That's the case with the ARM-GCC toolchain as well: To use the math library you have to include an "m" into the "Additional Library" to be found
Project -> Build settings -> Linker
and all runs well!
M.JPG 60.1 K
Thanks Bob! Glad to know it's such an easy fix.
Dear I try the cordic implementation, but with a very dangerous result.
With a psoc3 kit, with only the cordic, all work fine.But when implemented the system in a different application ( with the same API) the calculus of the angle ( vectoring mode) is incorrect.The wrost things is that calculus change changing the clock supplied to cordic. And never correct .The clock system is 48 Mhz, the cordic from 4 Mhz to 24 Mhz.
Any body tested the cordic in field , out of demo behaviour ? The author do similar test ?.I dedicated a lot of work, but without a good result !
Best regards Giovanni
I found the problem, and a do a workaround, but i desire a confirm from the rfms author.
In my application the calculated angle is correct if add at the value the INIT_ANGLE.Like that instead of a output values starting from 0° to 90°, the output was -45° to + 45°
Cordic at 8 bit
I use Cordic 2.0 for a angular encoder, in an industrial product with satisfied result.
But for a large number of application, it's sufficient a resolution of 8 bit, with an improvement of speed.Now with psoc3 at with a cordic clock 24 Mhz take near 16 usec to convert.
At 8 bit (is a recursive algoritm) maybe near 8 microsec, and less resource.
A division of angle about 256*4 is sufficient in a lot industrial application.
For this reason, i try to do a version with 8 bit, and after testing on real application , post on this forum .
I give a look on verilog file and udb path programming, but without correctly understand the how the cordic is implemented ( special udb).
If rfms give some info it's appreciate or collaborate with him , it's the best.
my reference is :