Goertzel Question: How to Check for new Result without Blocking

Christof Eb.

Hi, sorry, another question about Goertzel mode.
In the examples I know of, there is a XCONT immediately followed by a GETXACC. The xcont will wait to complete the previous sampling, so GETXACC reads the last full sampling.

If I want to use the cog in parallel to Goertzel, how can I check, if there is new data completed without blocking?
Thank you! Christof

Wuerfel_21

The XMT event flag gets set when the streamer is ready to accept a new XCONT/XZERO, so you could use POLLXMT to check for that ( or assign an IRQ to the XMT event ).

AJL

XFI is the streamer finished event, as opposed to streamer empty (XMT)

After some number of complete NCO cycles, both accumulators can be simultaneously captured into holding registers and cleared using the GETXACC instruction. GETXACC writes the captured cosine accumulation into D and places the captured sine accumulation into the next instruction's S value. Subsequent GETXACC instructions will return the same values until a new streamer command executes.

So, it seems you could have a non-blocking processing loop that includes a JXFI pointing to a XCONT / GETXACC X / MOV Y, 0 sequence to handle the streamer ops.

evanh

That doesn't read well. The "some number" isn't very precise wording. I'd imagine the number is exactly what was specified in the previous command.

Wuerfel_21

@AJL said:
XFI is the streamer finished event, as opposed to streamer empty (XMT)

XFI is when the streamer completely runs out of data, XMT is when the command buffer is ready. I think he wants the latter.

evanh

I've been looking at Chip's examples and I'm unsure if the extra buffer is present in Goertzel mode. I don't see any mention in the docs of the buffering being any different but the code comments and the long command times would suggest there is only room for the operating command. If a second command could be buffered then the "get prior Goertzel acc's" comment wouldn't be in phase.

EDIT: Although, there isn't really anything to compare result phase with I don't think. GETXACC could be pulling out results from two commands earlier and no one would know.

Christof Eb.

I don't think, that there is double buffering for the accumulators. Just the actual sum is read, I think. Therefore it must be xfi, otherwise the result will be dependent on the time. Must try.

Wuerfel_21

No, if you wait for XFI, there will be a disruption in streamer activity (I think, not sure what goes on in DDS mode when the streamer runs out of commands). Eitherhow, your sampling rate would go funky.

AJL

@Wuerfel_21 said:
No, if you wait for XFI, there will be a disruption in streamer activity (I think, not sure what goes on in DDS mode when the streamer runs out of commands). Eitherhow, your sampling rate would go funky.

Ok, If XMT is the relevant event then the processing loop could contain a JXMT pointing to the XCONT / GETXACC X / MOV Y, 0 sequence.

POLLXMT could be use with conditionally executed code to feed the next streamer command and get the results, but that needs a flag free to hold the condition. The downside of using JXMT is slightly longer execution time because of the branches.

Christof Eb.

Some update:
1. If the number of cycles of the streamer is done without buffered command waiting, DDS (and accumulation) stops.

2. There is no double buffer. If two XCONTs are done with no GETXACC between them, the summation just goes on. The accumulator's values grow. This means that the exact timing of getxacc in relation to the wished cycles is important. So if polling is used, Goertzel/DDS must stop.

At the moment for continuous DDS I resolve to a second cog, which will be blocked. ((Kind of silly to dedicate a cog which could do the Goertzel in software....))
Thanks for the inputs!!!