Anyone used SETPAT & WAITPAT ?

Cluso99 · 2019-03-01 02:40

I expected this to fall straight thru with either MODCZ (not sure which way round the Z works for ==)
But neither fall thru'.

                waitx   ##_clockfreq
                
                mov     match,inb
                and     match,mask
'               modcz   _set,_clr         '  C & NZ     ' INB 
                modcz   _set,_set         '  C &  Z     ' INB
                setpat  mask,match
                waitpat                                
                ...                                

match           long    $00000000         
mask            long    $C0000000

Obviously I am missing something, but what???

Dave Hein · 2019-03-01 03:39

I think you need to specify wcz with the modcz, otherwise it's basically a nop.

jmg · 2019-03-01 04:37

Dave Hein wrote: »

I think you need to specify wcz with the modcz, otherwise it's basically a nop.

Hmm, is the users intention not already clear and unambiguous ?

Cluso99 · 2019-03-01 04:42

Thanks Dave

That will be it!

Cluso99 · 2019-03-01 05:02

Interesting...

A trigger event is required to fire the waitpat.
I thought with the P1 that a waitpeq/waitpne would pass immediately if the condition was met.

                mov     match,inb
                and     match,mask
                xor     match,mask                      ' invert the SI=P31 pin
                
'               modcz   _clr,_set                   wcz ' NC & Z  (INA & D) == S
'               modcz   _clr,_clr                   wcz ' NC & NZ (INA & D) != S
                modcz   _set,_set                   wcz '  C & Z  (INB & D) == S
'               modcz   _set,_clr                   wcz '  C & NZ (INB & D) != S
                setpat  mask,match
                waitpat                                 ' wait for activity on SI=P31

jmg · 2019-03-01 05:48

Does it need that and in the second line ?

Docs say
Set pin pattern for PAT event. C selects INA/INB, Z selects =/!=, D provides mask value, S provides match value.
ie the mask in D, should not need the match also masked elsewhere ?

ersmith · 2019-03-01 12:32

jmg wrote: »

Dave Hein wrote: »

I think you need to specify wcz with the modcz, otherwise it's basically a nop.

Hmm, is the users intention not already clear and unambiguous ?

Not quite; the instruction doesn't really say which of c and z should be updated (c, z, or both).

However, if neither is updated that's probably a bug. fastspin will issue a warning in this case. I don't think PNut warns about it, but perhaps that would be a useful addtion.

cgracey · 2019-03-01 12:40

jmg wrote: »

Does it need that and in the second line ?

Docs say
Set pin pattern for PAT event. C selects INA/INB, Z selects =/!=, D provides mask value, S provides match value.
ie the mask in D, should not need the match also masked elsewhere ?

This is the test done for the event (C and Z are flag states and D and S are register values from when SETPAT executed):

event = (((C ? INB : INA) & D) == S) ^ !Z

Cluso99 · 2019-03-01 12:48

From what i saw, if the value doesn’t change, then no event will be created.
ie if you are looking for a value, and that value exists prior to performing the waitpat, then waitpat never returns.
I don’t think the P1 works this way. It just tests to see if the condition is met.

cgracey · 2019-03-01 15:01

The event occurs when the pattern is detected. If the pattern is present from the beginning, there is no event.

tomcrawford · 2019-03-01 16:25

Cluso99 wrote: »

I don’t think the P1 works this way. It just tests to see if the condition is met.

Totally. WAITPEQ and WAITPNE

Cluso99 · 2019-03-01 16:59

cgracey wrote: »

The event occurs when the pattern is detected. If the pattern is present from the beginning, there is no event.

So we have to do an additional check first now to see if the condition is met, and skip the waitpat if it’s already met?

tomcrawford · 2019-03-01 17:10

Now that I think about it:

Actually, for the 360 feedback servo, I have to measure a high period and the following low period. So on P1, I do a WAITPxx for a low, followed by a WAITPxx for a high to be certain I am measuring the whole high period (followed by another WATPxx for the end of the high period, etc). Basically, I am LOOKING for edges, so the P2 should work out better. Plus I think I can implement a timeout for the case where the servo died without feedback.

cgracey · 2019-03-01 18:11

tomcrawford wrote: »

Now that I think about it:

Actually, for the 360 feedback servo, I have to measure a high period and the following low period. So on P1, I do a WAITPxx for a low, followed by a WAITPxx for a high to be certain I am measuring the whole high period (followed by another WATPxx for the end of the high period, etc). Basically, I am LOOKING for edges, so the P2 should work out better. Plus I think I can implement a timeout for the case where the servo died without feedback.

There is a state-measuring smart pin mode that alternately measures high and low times, without missing a clock.

jmg · 2019-03-01 19:57

cgracey wrote: »

The event occurs when the pattern is detected. If the pattern is present from the beginning, there is no event.

So that means it is edge activated, and is triggered on a change-to moment ?
That would need to be made clear in the DOCs

jmg · 2019-03-01 20:01

cgracey wrote: »

There is a state-measuring smart pin mode that alternately measures high and low times, without missing a clock.

Sounds great for Duty capture to high precision, on a single smart pin. Which mode is that ?

ManAtWork · 2020-01-31 16:44

cgracey wrote: »

The event occurs when the pattern is detected. If the pattern is present from the beginning, there is no event.

So to do what WAITPNE did on the P1 I have to

                mov     match,INA
                and     match,mask
                modcz  _clr,_clr
                setpat  mask,match
                waitpat

And what if INA changes just in between the mov and the setpat? Then waitpat will wait although the condition I want to wait for is already met? Looks like a major design flaw. What is the recommended workaround?

ManAtWork · 2020-01-31 17:48

BTW, does setpat set a pattern for only one out of INA or INB or does it replace only one half of a 64 bit mask for both INA and INB? The latter would mean you can simultanously wait for pins 0..31 and 32..63 at the same time but it would have the drawback that you had to do two setpats for switching between INA and INB.

No problem, I can do everything I need with both possibilities. I just have to know. The docs are not clear about this.

AJL · 2020-02-01 11:14

ManAtWork wrote: »
cgracey wrote: »

The event occurs when the pattern is detected. If the pattern is present from the beginning, there is no event.

So to do what WAITPNE did on the P1 I have to
                mov     match,INA
                and     match,mask
                modcz  _clr,_clr
                setpat  mask,match
                waitpat                                
And what if INA changes just in between the mov and the setpat? Then waitpat will wait although the condition I want to wait for is already met? Looks like a major design flaw. What is the recommended workaround?

the P1 equivalent of what you have is

 mov match, INA 
 and match, mask
 and match, #0 wc nr
 waitpne match, mask

The P1 suffers from the same issue, but more sysclocks occur between the read and wait on the P1.

But why use that sequence? The wait instructions automatically perform the AND between INx and the mask.
So, preconditioning the flags and then executing the wait with the mask is sufficient if the mask eliminates the irrelevant bits from consideration.

My understanding is that each cog can only wait on INA or INB, not both at the same time.

The major P2 difference is that you can set up the match (or not) conditions and poll the comparison flag while doing other work, with pollpat.

ManAtWork · 2020-02-01 11:53

AJL wrote: »

The P1 suffers from the same issue, but more sysclocks occur between the read and wait on the P1.

Correct me if I'm wrong, but as I've read Chip's statement there is a fundamental difference. On the P1 WAITPEQ/PNE is level sensitive. If the condition is already met then it doesn't wait. On the P2 WAITPAT is edge sensitive. A transition from false to true is required to trigger end-of-wait. If the condition is already met before SETPAT has beed executed no event is generated and WAITPAT waits forever.

For all operations like interrupt triggering, pulse counting etc. it always important not to miss an event. A "blind spot" during setup of the wait condition is something to avoid.

But why use that sequence? The wait instructions automatically perform the AND between INx and the mask.

Because Chip said it's required:

cgracey wrote: »

event = (((C ? INB : INA) & D) == S) ^ !Z

The & is performed first, then the comparison (==). If it was the other way round then the & wasn't neccessary.

My understanding is that each cog can only wait on INA or INB, not both at the same time.

I share that feeling but to know for sure it would be good if Chip could confirm this.

AJL · 2020-02-01 22:32

ManAtWork wrote: »

AJL wrote: »

The P1 suffers from the same issue, but more sysclocks occur between the read and wait on the P1.

Correct me if I'm wrong, but as I've read Chip's statement there is a fundamental difference. On the P1 WAITPEQ/PNE is level sensitive. If the condition is already met then it doesn't wait. On the P2 WAITPAT is edge sensitive. A transition from false to true is required to trigger end-of-wait. If the condition is already met before SETPAT has beed executed no event is generated and WAITPAT waits forever.

For all operations like interrupt triggering, pulse counting etc. it always important not to miss an event. A "blind spot" during setup of the wait condition is something to avoid.

But why use that sequence? The wait instructions automatically perform the AND between INx and the mask.

Because Chip said it's required:

cgracey wrote: »

event = (((C ? INB : INA) & D) == S) ^ !Z

The & is performed first, then the comparison (==). If it was the other way round then the & wasn't neccessary.

My understanding is that each cog can only wait on INA or INB, not both at the same time.

I share that feeling but to know for sure it would be good if Chip could confirm this.

Your code doesn't need to perform the '& INx' in advance of the WAITPAT:
The SETPAT defines the conditions for the event detection circuitry, which then continually performs the '& mask' and comparison to determine whether to set the event flag.

If it is critical for level sensitivity, then you would replace the SETPAT / WAITPAT sequence with a mask and compare loop.

Untested code:

   REP 4, #0
     ALTR masked
     AND mask, INA
    CMP match, masked wz
    TJNZ continue  'TJNZ for WAITPNE, TJZ for WAITPEQ

An alternative for WAITPEQ operation, if you have a pin to spare, would be to set up a smartpin in NCO frequency mode such that IN toggles as fast as possible and then include it in the mask for SETPAT. This guarantees that even if the condition of interest already exists, a change occurs which triggers the event within two NCO base periods, preventing a stall.

Untested, but something like:

 DIRL spare
 WRPIN %0000_0000_000_0000_000_000_000_00_00110_0, spare  'NCO frequency mode, output disabled
 WXPIN $8000_0001, spare  'start with Z[31] high, single cycle base period'
 WYPIN $8000_0000, spare  'toggle Z[31] every base period, therefore IN toggles every second base period
 DIRH spare

 MODCZ _clr, _set
 SETPAT mask, match  'mask includes spare in bits of interest
 WAITPAT

Anyone used SETPAT & WAITPAT ?

Comments