Shop OBEX P1 Docs P2 Docs Learn Events
@ operator in Spin — Parallax Forums

@ operator in Spin

David BetzDavid Betz Posts: 14,530
edited 2015-02-17 18:26 in Propeller 1
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?

Comments

  • kuronekokuroneko Posts: 3,623
    edited 2015-02-16 07:00
    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 BetzDavid Betz Posts: 14,530
    edited 2015-02-16 07:19
    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)
  • kuronekokuroneko Posts: 3,623
    edited 2015-02-16 07:31
    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 BetzDavid Betz Posts: 14,530
    edited 2015-02-16 07:45
    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.
  • kuronekokuroneko Posts: 3,623
    edited 2015-02-16 07:48
    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 BetzDavid Betz Posts: 14,530
    edited 2015-02-16 08:02
    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.
  • tonyp12tonyp12 Posts: 1,951
    edited 2015-02-16 08:16
    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 BetzDavid Betz Posts: 14,530
    edited 2015-02-16 08:20
    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
    zip
    zip
    pkt.zip
    4K
  • kuronekokuroneko Posts: 3,623
    edited 2015-02-16 08:25
    In rx you really don't want long[pbuffer]. What is PASM going to do with the first 4 bytes buffer content?
  • David BetzDavid Betz Posts: 14,530
    edited 2015-02-16 08:28
    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 BetzDavid Betz Posts: 14,530
    edited 2015-02-16 08:33
    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!
  • tonyp12tonyp12 Posts: 1,951
    edited 2015-02-16 09:09
    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 BetzDavid Betz Posts: 14,530
    edited 2015-02-16 09:25
    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.
  • tonyp12tonyp12 Posts: 1,951
    edited 2015-02-16 10:41
    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 BetzDavid Betz Posts: 14,530
    edited 2015-02-16 13:03
    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 BetzDavid Betz Posts: 14,530
    edited 2015-02-17 18:26
    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
    zip
    zip
    pkt.zip
    4K
Sign In or Register to comment.