Cross-Cog Flagging With I/O Pins
To avoid hub read/writes in a cog that needs precise timing, I'm trying to communicate a single-bit flag to the other cogs by using the I/O system.
I couldn't find in the manual whether or not this acceptable, but I am attempting to do this with a single pin. i.e., set a particular pin as an output, then: In Cog A, toggle that pin as desired to signal Cog B, who is acting accordingly to the flag status.
I have found that it is possible to do this by reading ina; pins set as outputs are still readable.
In PASM, I'm trying to use waitpeq's:
It appears to me however that I never get past the first waitpeq instruction, even if the flagpin is high. Does waitpeq require that its source refers to a legitimate input pin? How would an experienced PASMer do this (or would they)?
I couldn't find in the manual whether or not this acceptable, but I am attempting to do this with a single pin. i.e., set a particular pin as an output, then: In Cog A, toggle that pin as desired to signal Cog B, who is acting accordingly to the flag status.
I have found that it is possible to do this by reading ina; pins set as outputs are still readable.
In PASM, I'm trying to use waitpeq's:
[FONT=courier new]'another cog is toggling the output pin addressed by "flagpin"
wait waitpeq flagset, flagpin 'wait for flag to go high
'<do the action requested by rising edge>
waitpeq flagclear, flagpin 'wait for flag to go low
'<do the action requested by falling edge>
jmp wait
flagset long 1
flagclear long 0[/FONT]
It appears to me however that I never get past the first waitpeq instruction, even if the flagpin is high. Does waitpeq require that its source refers to a legitimate input pin? How would an experienced PASMer do this (or would they)?

Comments
And yes, it has to be an existing pin, 32..63 don't count. Personallly I try to get away with hubsync but that's just me.
That way, if pin 5 is high, then flagpin & ina == flagpin
I will look into hubsync if this doesn't work out, but another reason I want to do it the original way is because the high state also will serve as CS for another chip (two birds with one stone! No pin waste either!)
waitpeq %10_0000_0000, %10_0000_0000
and
waitpeq %00_0000_0000, %10_0000_0000
The way you have it written, it looks like you are thinking flagpin is just the number of the pin and the state is a simple 0 or 1.
It is a very convenient way to do things if you happen to have a leftover pin or it is already an external signal. P.S. -- see you got it!
Cog A is definitely setting Pin 5 high, and Cog B is sitting on a
waitpeq #$20, #$20
So why it's not getting past is somewhat beyond me, unless waitpeq acts unpredictably for output pins - any other thoughts?
PUB null dira[5]~~ cognew(@entry, 0) waitcnt(clkfreq + cnt) outa[5]~~ DAT org 0 entry waitpeq mask, mask hubop $, #128 mask long |< 5 fitWhat does your actual code look like (given that the waitpeq in your last post doesn't even compile)?[FONT=courier new]CON _CLKMODE = XTAL1 + PLL16x _XINFREQ = 5_000_000 flagpin = $20 'the pin that will carry the "write" goahead flag and CS deb = $40 'a pin to set high to verify unblocking of waitpeq OBJ vgasignal : "timing" PUB start vgasignal.start(flagpin) 'start vgasignaler with the location of flag pin cognew(@debug, 0) DAT 'waitpeq block for timed execution' debug or dira, deb wait or outa, deb waitpeq flagpin, flagpin or outa, deb waitpeq flagpin, flagpin andn outa, deb jmp wait [/FONT]But the debug pin deb is initialized to $40 in the CON section.
And the jmp wait statement is intended to jump back to the wait label
debug or dira, #deb wait or outa, #deb waitpeq mask, mask or outa, #deb waitpeq mask, mask andn outa, #deb jmp #wait mask long flagpinwaitpeq flagpin, flagpin with flagpin being a constant ($20) will compile to waitpeq $20, $20, that's register 32 which will have some odd value based on the SPIN code you use (comes after DAT section and fills the remainder of the cog image).Do you really want waitpeq in both instances?
For clarity, constants are usually written in ALL_CAPS.
-Phil