Cross-Cog Flagging With I/O Pins

Lombard · 2014-06-07 15:40

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:

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

kuroneko · 2014-06-07 16:09

What is flagpin? In your case it has to be an exact match for flagset or it's stuck there. As for precise timing, be prepared for cog/pin dependent delays.

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.

Lombard · 2014-06-07 16:28

Oh, that's where I was going wrong. Flagpin is a mask that has a 1 over the pin of interest, and 0's elsewhere. That is what I want to AND with ina, but the statement should actually be

'flagpin is %0001_0000 for example
waitpeq    flagpin,  flagpin

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!)

Tracy Allen · 2014-06-07 16:29

Keep in mind that flagpin has to be a mask. That is, suppose you want to test logical pin 9. Then written out the tests would be.
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!

Lombard · 2014-06-07 16:48

It still does not seem to be working.

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?

kuroneko · 2014-06-07 16:51

Does cog A set pin 5 as output?

Lombard · 2014-06-07 16:53

Yes it does indeed

kuroneko · 2014-06-07 16:58

Beats me. Works for me, this code resets the board after about one second:

PUB null

  dira[5]~~
  cognew(@entry, 0)

  waitcnt(clkfreq + cnt)
  outa[5]~~
  
DAT             org     0

entry           waitpeq mask, mask
                hubop   $, #128

mask            long    |< 5

                fit

What does your actual code look like (given that the waitpeq in your last post doesn't even compile)?

Lombard · 2014-06-07 17:14

Oh, in that post I just replaced the variable flagpin with the literal value that is in the register. I believe that the problem has to do with how flagpin is being initialized. Here is a more truthful rendition:

[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]

kuroneko · 2014-06-07 17:25

Where does the jmp wait go? IOW what value is deb?

Lombard · 2014-06-07 17:32

Does the value of deb have an impact on the effect of jmp? The way you use IOW there makes me think that your intent is that they are the same question worded differently.

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

kuroneko · 2014-06-07 17:42

If deb is a constant (just realised it, need more coffee) then you probably want something like this:

debug     or       dira, #deb
wait      or       outa, #deb
          waitpeq  mask, mask
          or       outa, #deb
          waitpeq  mask, mask
          andn     outa, #deb
          jmp      #wait

mask      long     flagpin

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

Lombard · 2014-06-07 17:45

Ah, yes, the label and constants are literals. A beginner's mistake - and may there be many more to come!

Phil Pilgrim (PhiPi) · 2014-06-07 19:12

jmp wait should be jmp #wait, as kuroneko pointed out, I now see.

For clarity, constants are usually written in ALL_CAPS.

-Phil

Cross-Cog Flagging With I/O Pins

Comments