Address Passing

SRLM

I'm trying to debug a problem with addresses on the Propeller. Given the code below, I expect the addresses to match on all three outputs. But they don't! Somehow, the value is getting modified when it is passed to the imu.add_register function.

What's going on here?

{ main object }
CON
  _clkmode = xtal1 + pll16x
  _xinfreq = 5_000_000

CON
'IO Pins
	DEBUG_TX_PIN  = 30
	DEBUG_RX_PIN  = 31
	
	IMU_RX_PIN = 0 'Note: direction is from Propeller IO port
	IMU_TX_PIN = 1 'Note: direction is form Propeller IO port
	
'Settings

VAR

	byte um6_packet[20] 'Note: should require only 18 bytes, but extra just in case...
	
	long	gyro_proc_xy
	long	accel_proc_xy
	long	mag_proc_xy
	long	euler_phi_theta


OBJ
	debug : "FullDuplexSerialPlus.spin"
	imu : "um6.spin"

PUB Main | i, t1, addr, roll, pitch

	addr := @euler_phi_theta
	
	debug.start(DEBUG_RX_PIN, DEBUG_TX_PIN, 0, 230400)
	waitcnt(clkfreq + cnt)
	

	debug.str(string("Starting", 10, 13))

	t1 := imu.add_register($62, addr)

	debug.str(string("hub_address: "))
	debug.hex(t1, 8)
	debug.tx(10)
	debug.tx(13)
	debug.str(string("addr: "))
	debug.hex(addr, 8)
	debug.tx(10)
	debug.tx(13)
	debug.str(string("@euler_phi_theta: "))
	debug.hex(@euler_phi_theta, 8)
	debug.tx(10)
	debug.tx(13)

IMU Object:

{ imu object }
PUB add_register(register, hub_address)
	return hub_address

Output:

Starting
hub_address: 33E883C4
addr: 00000F3C
@euler_phi_theta: 00000F3C

I'd expect to see the address of F3C for hub_address, but instead it's the address of something else. What is going on here?

I've attached the original source, although it is a bit messy. What is above is what is run.

Beau Schwabe

The code you provided works for me.. the only thing I did different on my end was to reduce the baud to 19200

kuroneko

FWIW, the code you attached doesn't compile (hub_address being used as parameter and PASM label). With that resolved I get three identical values. That said I can reproduce your values when I return hub_address like this:

hub_address             long     [COLOR="#FF0000"]{no value}[/COLOR]        'Location in the hub to store the data. ...
has_data                res               1        'length of the received packet

SRLM

kuroneko wrote: »

FWIW, the code you attached doesn't compile (hub_address being used as parameter and PASM label). With that resolved I get three identical values. That said I can reproduce your values when I return hub_address like this:

hub_address             long     [COLOR="#FF0000"]{no value}[/COLOR]        'Location in the hub to store the data. ...
has_data                res               1        'length of the received packet

That was it! Thank you!

The problem here is that it compiles under BSTC (but I assume not the Prop Tool?). As soon as I changed it so the parameter and pasm_label have different names I get the correct result.

I'm curious what happened though.

kuroneko

SRLM wrote: »

The problem here is that it compiles under BSTC (but I assume not the Prop Tool?).

I'm curious what happened though.

Odd, I get complaints with PropTool and bst (haven't tried bstc). One of those things I guess. Anyway, that long not having a value makes it an alias for the following res which in turn makes some SPIN code visible (living at this address in the binary). That's all there is to it.

SRLM

I compile on Ubuntu Linux with this command:

./tool/bstc.linux -f -p0 -l -L lib  $1 > bstoutput.txt

Found a USB Serial Device
Brads Spin Tool Compiler v0.15.3 - Copyright 2008,2009 All rights reserved
Compiled for i386 Linux at 08:17:46 on 2009/07/20
Loading Object chr_um6
Loading Object FullDuplexSerialPlus.spin
Loading Object um6.spin
Program size is 3884 longs
Compiled 765 Lines of Code in 0.031 Seconds
We found a Propeller Version 1
Propeller Load took 0.661 Seconds

Where $1 is the filename. Even when I remove the -f -p0 and -l options it will compile.

Thanks for the explanation.

kuroneko

FWIW, using v0.15.4-pre13 here I get a compilation error as well (redefinition).