Getting a pointer into ptra in inline pasm

R Baggett

I am trying to convert 'Goertzel_ultrasonic.spin2' to inline PASM to be called regularly and act as a tone decoder. Tests have shown the theory to be sound, but I can't spare a cog as used in the original.

My current hangup seems to be loading the LUT. The original code just does this:

goertzel        setq2   #$200-1                 'load lut from table
                rdlong  0,ptra++

Which clearly works when called like this:

coginit(newcog, @goertzel, @table)

But how do I get a pointer to table into ptra in inline assembly?
This doesn't seem to work:

org
                mov ptra, ptr

I include the whole object, with most of the start pasm commented out, it runs 'correctly' as commented, but if i uncomment the rdlong (Line 45), it crashes with what appears to be memory corruption..

What is the correct way to do this?

JonnyMac

I don't think ptra is available for inline PASM (because it's used by the interpreter). I know that ptrb is okay.

R Baggett

OK, I changed to ptrb. Things are different now, If I comment the rdlong, I get to the debug statement at the bottom, and the number read from ptrb agrees with the number placed in ptrb, so that problem is solved.
Unfortunately, that wasn't the whole problem.
Uncommenting rdlong results in never reaching the second debug statement.

Because on further research:
According to SPIN language documentation, with inline code: "Avoid writing to $130..$1D7 and LUT RAM, since the Spin2 interpreter occupies these areas."

I don't know the details here, but it seems what I am trying to do may be impossible.

Wuerfel_21

If you're going to use the memory area for intense calculation and are not using interrupts, you can just store the interpreter's stuff away somewhere else, load your LUT data, do your thing and finally restore the original contents.

R Baggett

@Wuerfel_21 said:
If you're going to use the memory area for intense calculation and are not using interrupts, you can just store the interpreter's stuff away somewhere else, load your LUT data, do your thing and finally restore the original contents.

Hmmmm. I guess I really don't need to even load the LUT in the start method..

and then when I want to check for the tone, I could swap the interpreter's data for the sine tables before issuing setq/xcont, then I would need to wait out the cycles, and then put it back after getxacc.. Doable..I guess...

Maybe some other stuff is easier to combine and save a cog...

Thanks!

(Brain so sore...)