slots and hserptr

[johndk]

I'm managing a large program which spans multiple slots on my 28x2. It seems that when I use background receive mode (i.e. hsersetup B14400_8, %00111) the hserptr gets corrupted when I switch between slots. The code works fine and the pointer is accurate when I don't switch. And the routines I've moved to another slot also worked fine with background receive when everything is in slot 0 . When run from the other slot the routines also work fine, but somehow the switching back and forth affects the pointer.

Is this a confirmed issue?

Is there a workaround?

 

[johndk]

Just found a workaround. I issue the command hserptr = sp_rcv_buf to reset the pointer after I return from a slot function. But why should the pointer get touched when moving between slots?

 

[hippy]

According to the documentation on RUN; "Variables and pin conditions are not reset, so can be shared between the programs. However all other system functions, such as the gosub/return stack, are reset when the second program starts".

I would take it that 'hserptr' / 's_w5' is a system variable and therefore reset to 0 on a RUN command.

That seems to be the case in this test -

#Picaxe 28X2
#Terminal 9600
#Slot 0
Pause 5000
SerTxd( "Enter Slot 0 :", #hSerPtr, CR, LF )
hSerPtr = 111
SerTxd( "Leave Slot 0 :", #hSerPtr, CR, LF )
Run 1

#Picaxe 28X2
#Slot 1
SerTxd( "Enter Slot 1 :", #hSerPtr, CR, LF )
hSerPtr = 123
SerTxd( "Leave Slot 1 :", #hSerPtr, CR, LF )
Run 0

 

[johndk]

Thanks Hippy,

I understand why gosub and return stack can not be carried across the slot boundaries. But I don't understand why pointers, which are really no different than variables, should be affected. That is not to say that they aren't. It just doesn't seem logical to me.

At least there's a workaround to keep me running.