Understanding SX48 INTPARAMFSR, RAM bank 0, etc
Zoot
Posts: 2,227
Bean -- after hours of hair pulling last night and this morning, I discovered a bug/error in the latest beta release for the SX48. This is my first SX48 project, so I know there are few differences (bank in asm, loading m, read-write-modify on setb/clrb), but this is what burned me:
SX28 list:
··· 75· =000000F7······ __INTPARAMFSR··· EQU· $F7
SX48 list
·· 63· =00000010······ __INTPARAMFSR··· EQU· $10
So if you use INTPARAMFSR in anyway, and have a regular variable at $10 (as I did), the app will be wacky. In my case, while I usually use NOCODE or NOPRESERVE in my ISRs, I often alias INTPARAMFSR registers for my own "shadow" purposes (say, to save/restore M in the ISR for apps that may change tris states in both the ISR and the mainline).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST
1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php
Post Edited (Zoot) : 3/29/2009 7:11:32 PM GMT
SX28 list:
··· 75· =000000F7······ __INTPARAMFSR··· EQU· $F7
SX48 list
·· 63· =00000010······ __INTPARAMFSR··· EQU· $10
So if you use INTPARAMFSR in anyway, and have a regular variable at $10 (as I did), the app will be wacky. In my case, while I usually use NOCODE or NOPRESERVE in my ISRs, I often alias INTPARAMFSR registers for my own "shadow" purposes (say, to save/restore M in the ISR for apps that may change tris states in both the ISR and the mainline).
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST
1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php
Post Edited (Zoot) : 3/29/2009 7:11:32 PM GMT
Comments
It is NOT a bug. The sx48/52 stores __paramX variables in rambank0
using semi_direct addressing, eg. clr fsr, mov __INTPARAMFSR,__PARAM1
You'd better use conditional compilation so you can use the same
routine name for storing/retrieving variables no matter what device.
regards peter
MOV FSR, #__INTPARAMFSR+0
MOV W, IND
MOV M, W
Which came into direct conflict and wiped out the "regular" variable in the mainline.
When I manually assign all my variables and DON'T use INTPARAMFSR in any way, I have no conflicts. This was borne out by both my list file AND by the application in action.
Now if there is something else I am missing here, please enlighten me.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST
1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php
In any case, in the following, in 2.00.18 for SX48, __INTPARAMFSR and idx are both assigned location $10:
flags VAR Byte mMov VAR flags.0 mDir VAR flags.1 mDone VAR flags.2 mUD VAR flags.2 bMode VAR flags.7 idx VAR Byte state VAR Byte tmpW1 VAR Word tmpW2 VAR Word tmpB1 VAR Byte tmpB2 VAR Byte tmpB3 VAR tmpW2_LSB tmpB4 VAR tmpW2_MSB motor VAR Byte(16) BANK mflags VAR motor(0) mpwm VAR motor(1) mact VAR motor(2) muser VAR motor(3) mtarg VAR motor(4) mramp VAR motor(5) mrate VAR motor(6) tracks VAR Byte motor(7) ' relay on/offs northSouth VAR tracks.0 eastSiding VAR tracks.1 westSiding VAR tracks.2 mountTrack VAR tracks.3 mRampCntr VAR motor(12) maccm VAR motor(13) mcntr VAR motor(14) mTmp VAR motor(15) servo VAR Byte(16) BANK svoPntr VAR servo(8) svoPin VAR servo(9) svoFrame VAR servo(10) ' ms svoPulse VAR servo(11) ' 11/12 svoPad VAR servo(12) svoFlags VAR servo(13) ' pos reached flags svoRampFrame VAR servo(14) ' every x ticks, do pos update svo VAR Byte(16) BANK ' user pos (targ) eastNorthSvo VAR svo(0) ' svo 0 eastSouthSvo VAR svo(1) ' svo 1 svoRamp VAR svo(8) ' ramp svoAccum VAR Byte(8) BANK timeCounters VAR Byte(8) BANK msCntr VAR timeCounters(0) msClock VAR timeCounters(1) msTmr VAR timeCounters(2) secCntr VAR Word @ timeCounters(3) '4 secClock VAR timeCounters(5) secTmr VAR timeCounters(6) ' 2 free miscDat VAR Byte(16) BANK buttonDat VAR miscDat(0) buttons VAR buttonDat(0) buttonLeft VAR buttons.0 buttonCtr VAR buttons.1 buttonRight VAR buttons.3 buttonBottom VAR buttons.2 buttonsLast VAR buttonDat(1) buttonsCntr VAR buttonDat(2) buttonsTmp VAR buttonDat(3) turnoutDat VAR Byte(16) BANK turnouts VAR turnoutDat(0) eastNorth VAR turnouts.0 ' svo 0 eastSouth VAR turnouts.1 ' svo 1 var3 var byte(16) bank var4 var byte(16) bank var5 var byte(16) bank var6 var byte(16) bank var7 var byte(16) bank var8 var byte(16) bank var9 var byte(16) bank var10 var byte(8) bank mSave VAR var10(0)The list output for above yields:
32 ; DEFINE SYSTEM VARIABLES 33 =00000000 __RAM EQU $00 34 =00000006 RBC EQU $06 35 =00000006 RBC_LSB EQU $06 36 =00000007 RBC_MSB EQU $07 37 =00000007 RCD EQU $07 38 =00000007 RCD_LSB EQU $07 39 =00000008 RCD_MSB EQU $08 40 =00000008 RDE EQU $08 41 =00000008 RDE_LSB EQU $08 42 =00000009 RDE_MSB EQU $09 43 =0000000A __PARAM1 EQU $0A 44 =0000000B __PARAM2 EQU $0B 45 =0000000C __PARAM3 EQU $0C 46 =0000000D __PARAM4 EQU $0D 47 =0000000E __PARAM5 EQU $0E 48 =0000000E __PARAMCNT EQU $0E 49 =0000000A __WPARAM12 EQU $0A 50 =0000000A __WPARAM12_LSB EQU $0A 51 =0000000B __WPARAM12_MSB EQU $0B 52 =0000000B __WPARAM23 EQU $0B 53 =0000000B __WPARAM23_LSB EQU $0B 54 =0000000C __WPARAM23_MSB EQU $0C 55 =0000000C __WPARAM34 EQU $0C 56 =0000000C __WPARAM34_LSB EQU $0C 57 =0000000D __WPARAM34_MSB EQU $0D 58 =0000000D __WPARAM45 EQU $0D 59 =0000000D __WPARAM45_LSB EQU $0D 60 =0000000E __WPARAM45_MSB EQU $0E 61 =000000FF TRIS_X EQU $FF 62 =000000FF __TRIS EQU $FF 63 =00000010 __INTPARAMFSR EQU $10 64 =0000000A __REMAINDER EQU __PARAM1 65 =0000000A __WREMAINDER EQU __PARAM1 66 =0000000A __WREMAINDER_LSB EQU __PARAM1 67 =0000000B __WREMAINDER_MSB EQU __PARAM2·and
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST
1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php
For the sx48/52, when fsr=0, rambank0 is enabled at $10-$1F,
that's why INTPARAMFSR equ $10
You then use direct addressing to access the ram
(indirect via IND is pointless as fsr is 0)
So for sx48/52 you would use
CLR FSR
MOV·W,__INTPARAMFSR+0
MOV M, W
That's the only way to access rambank0.
regards peter
476 0000 0064 CLR FSR ; Use BANK 0 for storage 477 0001 020A MOV __INTPARAMFSR,__PARAM1 0002 0030 478 0003 020B MOV __INTPARAMFSR+1,__PARAM2 0004 0031 479 0005 020C MOV __INTPARAMFSR+2,__PARAM3 0006 0032 480 0007 020D MOV __INTPARAMFSR+3,__PARAM4 0008 0033 481 0009 020E MOV __INTPARAMFSR+4,__PARAM5You know what, I get it, but I must be fuzzy on memory mapping for the SX48... rambank0 really has 32 bytes?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST
1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php
$00-$0F are the global bytes that are always accesible
regards peter
Are you saying that:
"bank 0" registers are really at $10-$1F and can *only* be accessed as follows:
CLR FSR
MOV fr, W· ; where fr is $10-$1F
But that $00-$0F are always the globals, e.g., without having to change banks or set FSR:
MOV fr, W ; where fr is $00-$0F
(that doesn't sound right; wouldn't FSR.4 have to be·1 to get the "globals"?)
And that $10-$Fx are "normal" in that you can either:
BANK fr
SETB/CLRB FSR.7
MOV fr, W
or
MOV FSR, #fr
MOV fr, #1
or
MOV FSR, #fr
MOV IND, #1
Shoot... 30+ SX28 projects and I'm hung up on this :-)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST
1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php
For sx18/20/28, bank0 is $10-$1F
Yes, and you don't need to set fsr.4 for the globals
You must set fsr.4 to access any bank via $10-$1F on sx18/20/28
And you can use indirect addressing for the globals except IND.
mov fsr,#5
clr ind· 'this actually does clr ra
regards peter