DSP Robotics Support

Why does this DSP code output "400" and only "400"?

because x needs to be multiplied with 20 before you do log10
so it should be :

Nubeat7 - are you sure?
It's not log10 of (20*x) but 20 times log10(x).
Totally different formula.

For some reason you have to reverse the order. Or - use the multiplier externally. Ranges: >=0

tester wrote:

Code: Select all

streamin in;
streamout out;

out = log10(in)*20;

Thanks tester, this works fine.

Of course, this is mathematically nonsensical, but it works now.

It doesn't work with extra parenthesis in the original order either; I had tried that.

It's a bug in the code compiler. (If you connect a text box to the String output of the DSP primitive, you get to see the compiler's assembly code.)

In the original form of the equation, the 'log10(x)' result is put into in register xmm0. The '20' value is then read from memory - straight into the same register! - and then gets multiplied by itself. 20 * 20 = 400!

So, you did nothing wrong - the alternative version just does things in a different order that the compiler doesn't mess up!

Nubeat7 wrote:because x needs to be multiplied with 20 before you do log10

thanks tester, AFTER the log10

This code doesn't work either.


Input values are
y = 3.58509
a = 0
b = 16
c = 1

Clearly not as easy to follow but... it just spits out 0. I did it out manually and it gives me 0.8125, which is exactly what I was looking for.

Even if I change all the input values it just spits out 0.

There is a limitation per lenght in "code", line lenght (some sort of asm translation limit). This is in manual, and I encountered it too. I would split this equation into smaller pieces, and thus - it should be easier to figure out which part is not working if that's still the case.

//edit:

Like this:



Works here.

But generally these parts can be done with regular prims (add, sub, multiply, etc).

this is what i thought too but i think its not the reason..
from user guide:

"One limitation of the code component is that you can only have 8 successive operations in an
expression. For example, the expression:
a = 0+1+2+3+4+5+6+7+9+10;
is not allowed because there are 9 addition operations in a row. You can easily get round this by
splitting the expression up into smaller sections using brackets ‘(‘ and ‘)’. For example:
a = (0+1+2+3+4)+(5+6+7+9+10);"

so after the code is very nested it shouldnt be a problem,
if you just put the -1* to the end of the code it works,

if its at the beginning assembly tries to use register xmm999 which does the error, but maybe it is still because of the same problem, you have to think that there are only 8 registers in use so if there is to much to remember i think this can happen..

I would be careful anyway. Having too many things in one line - may lead to easy mistakes (human factor).