waitpe and wait pinne
RS_Jim
Posts: 1,768
in Propeller 2
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
Comments
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.
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).
Untested P2 equivalent of WAITPEQ State, Mask, Port
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:
but again, if the State, Mask, and Port remain unchanged then subsequent WAITs can just use the WAITPAT alone.
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.
I can't argue with that advice :-)
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
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)
This is the equivalent of waitpeq with a single-bit mask. Use if_c for the equivalent of waitpne.
Another advantage of using WAITxxx is the timeout feature.
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.
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.
if !var
will only execute if var is -1 (! is bitwise NOT). Also, useifnot var
instead ofif NOT var
, it's betterOuch! 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?
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