@ operator in Spin

David Betz

Can someone remind me of the rules for using the @ operator. I think I'm getting in trouble by trying to pass the address of variables to PASM code. Does that work? Or do I need to put those variables in a DAT section?

VAR
    long foo

DAT

bar long 0

PUB test | x
    x := @foo ' do I get a hub address here?
    x := @bar ' do I get a hub address here?

kuroneko

David Betz wrote: »

VAR
    long foo

DAT

bar long 0

PUB test | x
    x := @foo ' do I get a hub address here?
    x := @bar ' do I get a hub address here?

Yes to both questions. Only @ usage in DAT sections needs special care.

David Betz

kuroneko wrote: »

Yes to both questions. Only @ usage in DAT sections needs special care.

Thanks! I guess I must be doing something else wrong then. Here is the code I'm trying to get to work. You'll notice that I use @ a lot to pass the address of variables to my COG code through a mailbox.

CON
  _clkmode    = xtal1 + pll16x
  _xinfreq    = 5_000_000

  #0
  OP_RESULT
  OP_ADD
  OP_SUB
  
OBJ
  pkt : "packet_driver"

VAR
  long type
  long buffer[4]
  long length

PUB main | sts

  outa[18..16] := %100
  dira[18..16] := %111

  pkt.start(31, 30, 115200)

  repeat
  
    length := 16
    sts := pkt.rx(@type, @buffer, @length)
  
    if sts == 0
      case type
        OP_ADD:
          outa[17..16] := %01
          buffer[0] := buffer[0] + buffer[1]
        OP_SUB:
          outa[17..16] := %10
          buffer[0] := buffer[0] - buffer[1]
        other:
          outa[17..16] := %11
          buffer[0] := $deadbeef
    else
      outa[23] := 1
      dira[23] := 1

    pkt.tx(OP_RESULT, @buffer, length)

kuroneko

Not knowing your packet driver code, it's hard to tell. But rx takes @length and @type whereas tx takes length and the op as is which is odd.

Makes sense in a way. So we need to see some more.

David Betz

kuroneko wrote: »

Not knowing your packet driver code, it's hard to tell. But rx takes @length and @type whereas tx takes length and the op as is which is odd.

Makes sense in a way. So we need to see some more.

I can certainly post all of the code but it's pretty messy at the moment. My main question is if the addresses I'm passing to the buffer, length, and type variables will work with rdlong and wrlong within the PASM code.

kuroneko

David Betz wrote: »

My main question is if the addresses I'm passing to the buffer, length, and type variables will work with rdlong and wrlong within the PASM code.

Since all of them are longs I don't see a problem here.

David Betz

kuroneko wrote: »

Since all of them are longs I don't see a problem here.

Okay, I'll look for my bug somewhere else. Thanks for your help.

tonyp12

Probably something in your packet driver code.
You probably using @ again inside it, though the var you passed to it was the @address.
So attach the complete zip file

David Betz

tonyp12 wrote: »

Probably something in your packet driver code.
You probably using @ again inside it, though the var you passed to it was the @address.
So attach the complete zip file

Okay, here is the code. Unfortunately, it's littered with stuff I added for debugging. View at your own risk! :-)

pkt.zip

kuroneko

In rx you really don't want long[pbuffer]. What is PASM going to do with the first 4 bytes buffer content?

David Betz

kuroneko wrote: »

In rx you really don't want long[pbuffer]. What is PASM going to do with the first 4 bytes buffer content?

Ah, that's a good point. I'll try fixing that. I was passing so many parameters by reference that I got carried away with that one I guess! :-)

David Betz

David Betz wrote: »

Ah, that's a good point. I'll try fixing that. I was passing so many parameters by reference that I got carried away with that one I guess! :-)

I just fixed that and it helps a lot! Thanks!! Still some bugs to find but some of the mysterious behavior has certainly reduced dramatically. Dereferencing that pointer essentially passed a wild pointer to the PASM with the predictable bad results. Thanks for your help!

tonyp12

It's hard to follow the code as mailbox repoints to buffer that repoints again etc.
Can you explain what the structure and data you are trying to pass to cog and I will try show how I would do the mailbox.

David Betz

tonyp12 wrote: »

It's hard to follow the code as mailbox repoints to buffer that repoints again etc.
Can you explain what the structure and data you are trying to pass to cog and I will try show how I would do the mailbox.

Well, if the mailbox points to a buffer which then points to something else then there is a bug. The mailbox is simply a structure containing five elements, a command for the driver to execute, a packet type, a buffer address, a buffer length, and a status code that indicates whether the operation was successful. The only deviation from that is in the rx code where instead of a type and length the request takes a pointer to the type since it is an output parameter and the length is passed by reference because on call it is the size of the buffer and on return it should be the size of the actually message received.

tonyp12

How about not using a mailbox?, everything you need fits in one long, so PAR will point to it
Length is lower 9 bit so you can use it in the pasm as is, with movs.

con
OP_ADD %01<<9
OP_SUB %11<<9  ' cog uses: [test t1,op_mask wz wc] to find if 0,1 or 3

var
word packet_address '16bit address  [make sure these word vars are the first word var after the var longs]
word packet_opr_len '2bit + 9bit  [as you need it to be aligned to a long address and Prop tool does sort them]


cognew (entry,@packet_address)

packet_address := @buffer1
packet_opr_len := OP_ADD | 24
repeat until packet_opr_len == 0 'cog writes a 0 long to PAR address when done

David Betz

Thanks for the suggestion for the alternate interface but I'd like to stick to my mailbox interface for now and fix the bugs. :-)

David Betz

I fixed my bugs. It turns out they had nothing to do with improper use of the @ operator. I've attached the working code in case anyone is interested. I've also cleaned it up a bit so it might be possible to understand it! :-)

pkt.zip