Getting a pointer into ptra in inline pasm

R Baggett · 2026-02-17 17:15

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 · 2026-02-17 18:22

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 · 2026-02-17 19:02

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 · 2026-02-17 19:10

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 · 2026-02-17 19:31

@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...)

SaucySoliton · 2026-02-17 21:13

I did this and didn't experience problems because I used flexspin. Since it compiles everything to machine language it doesn't care what I do to the LUT.

The time to generate a sine table using the cordic is probably insignificant compared to the time required to detect an audio tone.

This may be a can of worms, but perhaps with flexspin the goertzel could be started and left running.

ManAtWork · 2026-02-18 11:19

I don't know exactly what your application does and when it needs to detect the beep tone. But my guess is that it needs to listen all the time. So I think this won't work by just calling the Goertzel code from time to time. As @Wuerfel_21 pointed out, the Goertzel results are not double buffered so the XCONT and GETXACC instructions need to be exactly timed. The calculations only use a small fraction of the available cog resources but it needs to be ready at the exact time slots. So I think you need a cog.

There may be a trick so you don't need a fully dedicated cog. Maybe one of the cogs already used by your application has some spare memory and time left so the Goertzel handling code can run in an interrupt, feed the streamer and fetch the result and write it to hub RAM before continuing with whatever else it needs to do.

R Baggett · 2026-02-18 12:16

@ManAtWork said:
I don't know exactly what your application does and when it needs to detect the beep tone.

This application only needs to check at specific times,

As @Wuerfel_21 pointed out, the Goertzel results are not double buffered so the XCONT and GETXACC instructions need to be exactly timed. The calculations only use a small fraction of the available cog resources but it needs to be ready at the exact time slots. So I think you need a cog.

Yes, but I do have enough time to wait out 42 mS for a detection (~100 cycles at 2400 HZ) and then grab the result...

There may be a trick so you don't need a fully dedicated cog. Maybe one of the cogs already used by your application has some spare memory and time left so the Goertzel handling code can run in an interrupt, feed the streamer and fetch the result and write it to hub RAM before continuing with whatever else it needs to do.

That still needs the LUT, I would need to bring a whole cogs worth of code to PASM.. worth considering...

And then speaking of a whole cog of pasm...

@SaucySoliton said:
I did this and didn't experience problems because I used flexspin. Since it compiles everything to machine language it doesn't care what I do to the LUT.

The time to generate a sine table using the cordic is probably insignificant compared to the time required to detect an audio tone.

This may be a can of worms, but perhaps with flexspin the goertzel could be started and left running.

I don't know that the finished application will fit if compiled.. But I'm gonna find out and /or figure out how to get some mix of compiled and interpreted code in the same application.

I think I am at that point in the learning curve of PASM where the lights start to come on... Lots to think about.

evanh · 2026-02-18 13:23

Flexspin provides, by language extensions, specifying instalment of functions/methods into LUTRAM. Details on second page of general.md under heading of "Functions in COG or LUT memory". So you can even put Spin2 code in LUTRAM.

Getting a pointer into ptra in inline pasm

Comments