Memory location confusion

Danico

Have come across a problem that am hoping someone can explain to me what is going wrong?!

When running this code:

CON
   
  _clkmode = xtal1 + pll16x                     ' Crystal and PLL settings.
  _xinfreq = 5_000_000                          ' 5 MHz crystal.
 
OBJ
  mon     : "Monitor"    
 
VAR
  byte flag   
  byte Data[noparse][[/noparse]20]
  
PUB start | item
'' Starts 'Monitor' in another cog using pins 31 and 30 at 19200 baud.
'' Use a terminal program on the host machine to communicate.
  mon.start(31, 30, 19200)
  flag := 136
  
  repeat item from 0 to 20
    Data[noparse][[/noparse]item] := item
  
  cognew(@entry, @Data)
    
DAT                     org
entry                   mov     DataAddr,par       ' the Data array address
                        mov     DataValu,#170
                        wrbyte  DataValu,DataAddr
                        
halt                    jmp     #halt
DataAddr    long        0
DataValu    long        0

and using Chips 'monitor' code to examine the memory, get a strange result.
In the spin code, 'flag' is 0x88 and Data[noparse][[/noparse]0] to 0, and in the asm code, Data[noparse][[/noparse]0] is re-assigned to value 0xAA.
But this is the memory dump when run -

0220-6F 64 48 EC 23 32 00 00 AA 00 01 02 03 04 05 06 odH.#2..........

So instead of Data[noparse][[/noparse]0] becoming 0xAA, the variable 'flag' does, and Data[noparse][[/noparse]0] remains unchanged.

Can someone tell me what is going wrong?
Thanks,
D

kuroneko

From a quick glance, your parameter address is not long aligned. Meaning SPIN will happily take @Data (which I believe is 4n+1) but clear the lower to bits. So what your assembler code actually sees is the address of flag. There is only 14bit reserved for a parameter address, that's where the long alignment requirement comes from.

Quick fix, swap flag and data[noparse]/noparse.

Danico

kuroneko,

I think you are spot on with the reason for this issue -·have worked around the problem.

Guess I need to modify my way of thinking, the prop is happiest when we work with its native longs, but my drummed in way of thinking is to·use the minimum amount of memory at all times.· Why use a long when a (word or) byte will do, why use a byte when a bit will do?· Of course can use·bytes as required, just need to consider that they need to remain long aligned.

Thanks for your help!

kuroneko

There is nothing wrong with your approach as such. It's just that the parameter address is limited to 4n (i.e. what you'll see in the par register). You can obviously work around that issue by storing your byte array address in a long and pass the address of that long into your PASM code. In there you extract the address first and then use it, e.g.

rdlong  addr, par
...
wrbyte  data, addr

northcove

repeat item from 0 to [s]20[/s] [b]19[/b]
    Data[noparse][[/noparse]item] := item

You've written 21 elements into a 20 element array.