Shop OBEX P1 Docs P2 Docs Learn Events
Anyone used SETPAT & WAITPAT ? — Parallax Forums

Anyone used SETPAT & WAITPAT ?

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???

Comments

  • I think you need to specify wcz with the modcz, otherwise it's basically a nop.
  • jmgjmg Posts: 15,140
    edited 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 ?
  • Cluso99Cluso99 Posts: 18,066
    Thanks Dave :smiley:
    That will be it!
  • Cluso99Cluso99 Posts: 18,066
    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
    
  • jmgjmg Posts: 15,140
    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 ?

  • 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.

  • cgraceycgracey Posts: 14,133
    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
  • Cluso99Cluso99 Posts: 18,066
    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.
  • cgraceycgracey Posts: 14,133
    The event occurs when the pattern is detected. If the pattern is present from the beginning, there is no event.
  • 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

  • Cluso99Cluso99 Posts: 18,066
    edited 2019-03-01 17:00
    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?
  • tomcrawfordtomcrawford Posts: 1,126
    edited 2019-03-01 17:11
    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.
  • cgraceycgracey Posts: 14,133
    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.
  • jmgjmg Posts: 15,140
    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
  • jmgjmg Posts: 15,140
    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 ?
  • 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?
  • 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.
  • 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.

  • 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.

  • 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
    
    
Sign In or Register to comment.