waitpe and wait pinne

RS_Jim · 2021-10-12 23:57

I was working on converting some spin cpde to spin2 when I found wait pine and pinne no longer seem to exist. What would be the equivalent?
Jim

rogloh · 2021-10-13 01:07

@RS_Jim said:
I was working on converting some spin cpde to spin2 when I found wait pine and pinne no longer seem to exist. What would be the equivalent?
Jim

Use SETSEn D/#, where n is a selectable event matcher HW resource ID numbered from 1 to 4 (there are 4 of these per COG), and D/# is the condition to setup the matcher against, as shown in the table below. You'll want one of the those INA/INB values if it is an individual pin being tested, followed by a WAITSEn (again n from 1-4, but the same value as used in the prior SETSEn) to do the waiting.

SETSEn D/# accepts the following configuration values:

%000_00_00AA = this cog reads LUT address %1111111AA
%000_00_01AA = this cog writes LUT address %1111111AA
%000_00_10AA = odd/even companion cog reads LUT address %1111111AA
%000_00_11AA = odd/even companion cog writes LUT address %1111111AA

%000_01_LLLL = hub lock %LLLL rises
%000_10_LLLL = hub lock %LLLL falls
%000_11_LLLL = hub lock %LLLL changes

%001_PPPPPP = INA/INB bit of pin %PPPPPP rises
%010_PPPPPP = INA/INB bit of pin %PPPPPP falls
%011_PPPPPP = INA/INB bit of pin %PPPPPP changes

%10x_PPPPPP = INA/INB bit of pin %PPPPPP is low
%11x_PPPPPP = INA/INB bit of pin %PPPPPP is high

Alternatively if you are looking at a specific pattern on a group of pins on a port you can look at the WAITPAT and SETPAT instructions although these can be a little more complex to setup as you need to set the flags and masks correctly, and I think there needs to be a transition into the state before it will trigger. i.e it doesn't trigger if you are already in the desired state initially (unlike the P1 IIRC).

AJL · 2021-10-13 02:36

Untested P2 equivalent of WAITPEQ State, Mask, Port

  TESTB Port, #0 WC      ; Set C flag to Port  A = 0 , B = 1
  MODZ _CLR              ; Z flag = 0 means match on equal
  SETPAT Mask, State     ; prepare pattern matching
  WAITPAT                ; wait for pattern match

As SETPAT ( and WAITPAT) clear the event flag, it may not match in the circumstance that the pins are already in that state; the documentation isn't completely clear:

POLLPAT/WAITPAT event flag

Cleared on SETPAT
Set whenever (INA & D) != S after 'SETPAT D/#,S/#' with C=0 and Z=0.
Set whenever (INA & D) == S after 'SETPAT D/#,S/#' with C=0 and Z=1.
Set whenever (INB & D) != S after 'SETPAT D/#,S/#' with C=1 and Z=0.
Set whenever (INB & D) == S after 'SETPAT D/#,S/#' with C=1 and Z=1.
Also cleared on POLLPAT/WAITPAT/JPAT/JNPAT.

A disadvantage of the P2 approach is that it requires more setup, and in many cases both flags must be set in the appropriate state for the WAIT action, meaning that any flags needed after the WAIT must be saved before, and fetched after.
An advantage of the P2 approach is that once the pattern is set, only a generic WAITPAT needs to be issued each time, meaning that for simple cases the setup can be done at initialisation, and then both flags can be carried through the WAIT action.

If the flag isn't set on a pre-existing condition then, to ensure that case is captured the first time you would need something like:

  MOV temp, Mask         ; Preserve the mask
  TESTB Port, #0 WC      ; Set C flag to Port  A = 0 , B = 1
 if_nc AND temp, INA     ; Only test INA bits in Mask
 if_c AND temp, INB      ; Only test INB bits in Mask
  ANDN temp, State WZ    ; INx AND Mask AND !State = 0 means a match
 if_z JMP continue
  MODZ _SET              ; Z flag = 1 means match on equal
  SETPAT Mask, State     ; prepare pattern matching
  WAITPAT                ; wait for pattern match
continue

but again, if the State, Mask, and Port remain unchanged then subsequent WAITs can just use the WAITPAT alone.

rogloh · 2021-10-13 03:32

All the above stuff that AJL mentioned is why I believe when waiting for a single pin's state or transition, it is much easier to just use a SETSEn and WAITSEn wherever possible. Also the specified pin number already determines whether it is from port A or B and is one less thing to worry about and makes the code more portable to work with any pin. But if you need to match a pattern from several pins in a group, you still need the WAITPAT approach.

AJL · 2021-10-13 04:04

I can't argue with that advice :-)

RS_Jim · 2021-10-13 12:10

In this case, I am waiting for a single pin. Thanks guys, I will get it implimented and let you know how it goes.
Jim

JonnyMac · 2021-10-13 14:12

@RS_Jim said:
In this case, I am waiting for a single pin. Thanks guys, I will get it implimented and let you know how it goes.

For a single pin you can use testp. This bit of code waits for the SCL pin to go high before proceeding (from my I2C driver)

                testp     scl                           wc      ' check for clock stretch
    if_nc       jmp       #$-1

This is the equivalent of waitpeq with a single-bit mask. Use if_c for the equivalent of waitpne.

ozpropdev · 2021-10-13 23:08

Another advantage of using WAITxxx is the timeout feature.

From the docs.
By doing a SETQ right before one of these instructions, you can supply a future CT target value which will be used to end the
wait prematurely, in case the event-occurred flag never went high before the CT target was reached. When using SETQ with
'WAITxxx WC', C will be set if the timeout occurred before the event; otherwise, C will be cleared.

rogloh · 2021-10-14 00:04

Perhaps WAITxxx also saves power vs repeated jumping in a loop. Needs to be proven though for a P2 as I'm not sure what inputs made it into the clock gating stuff when Chip put that in.

IncVoid · 2021-10-23 18:24

in spin i just used a
repeat until Pinread(Pin)==1 or something similar.

Can you also just read and mask INA with what you want? simpler as a bitfield? (INA & Mask)== pattern?

Worked fine for me using the ping))) distance sensor waiting for the return pulse to make the pin go high.
The timeout feature seems nice, Ive hung up a few times because I either didnt pulse the ping long enough or didnt wait long enough after etc. would of been nice to have a lil timeout based onuseable range of the ping))) etc

On a side note whats the latest version of propeller ide? or prop tool I guess.
Ive been using 2.2.0 alpha and i found a bug in the if statement. the block executes only on a conditional.

"if !Var" wont work even tried if (0) and if (1) etc. somethin about it was funky. It was late, but "if NOT Var" worked.

just getting back into the swing of things and wondering how much hair pulling Ill save myself by upgrading. Im always hesitant because its an old win7 box.

Wuerfel_21 · 2021-10-23 18:53

@IncVoid said:
"if !Var" wont work even tried if (0) and if (1) etc. somethin about it was funky. It was late, but "if NOT Var" worked.

if !var will only execute if var is -1 (! is bitwise NOT). Also, use ifnot var instead of if NOT var, it's better

IncVoid · 2021-10-23 23:34

Ouch! thatd what I get for not asking what other values will happen. Yes I see that now. My 0 scenario turns into -1. and the only condition that could possibly fail the IF NOT(-1), any bit set to 0 will trigger the statement. I realize why my hardcoded 0 scenario and 1 returned the same results. i moved stuff around to make sure it wasnt a problem elsewhere.

I only wanted the condition to execute on all zero.
I shoulda just did ==0
is IFNOT faster than if NOT or is it a syntax highlighting readability?

msrobots · 2021-10-24 00:58

My guess is that it is faster since it does not require to evaluate a expression.

Not sure, FlexProp does eliminate this maybe thru optimization, but PropTool does not really optimize things so it might be slower there.

So a IFNOT might be faster as an IF NOT.

Mike

waitpe and wait pinne

Comments