Having to use Bank Statements / Code Compatiiblity Buffered Serial

Yendor

Hi everyone, long time no post!

I've been struggling with a problem for a while, got it solved, and now curious on why it seems like there is an issue with code compatibility.

For example:· Our friend, the buffered serial code in the interupt has been seen in examples using·the following:

RX_Buffer:
    MOV FSR, #rxBuf    ' get buffer address
    ADD FSR, rxHead    ' point to head
    MOV IND, rxByte    ' move rxByte to head
    INC rxHead     ' update head
    CLRB rxHead.4        ' keep 0 - 15
  ENDASM

The only way I got it to work was by moving the banks around:

RX_Buffer:
    MOV FSR, #rxBuf    ' get buffer address
 Bank $00
    ADD FSR, rxHead    ' point to head
 Bank $30
    MOV IND, rxByte    ' move rxByte to head
 Bank $00
    INC rxHead     ' update head
    CLRB rxHead.4        ' keep 0 - 15
  ENDASM

The address locations of the above variables:
rxBuf: $3x
rxhead: $10
rxByte: $0F

If you only new how happy and excited I am·to get this to finally work!··Can some one help me shed the light on why I would need to add all the bank statements, on seemingly compatible code?···Would forcing variables to certain banks help?··Tips would be appreciated!


·

Guenther Daubach

Yedndor,

MOV FSR, #rxBuff

sets the FSR to "point" into rxBuff in bank $30 which is fine.

Next,

ADD FSR, rxHead

will fail, because rxHead is located in bank $10, where FSR addresses bank $30.

MOV IND, rxByte

is fine because rxByte is at $0f, i.e. in the global register area.

INC rxHead
CLRB txHead.4

will fail again because FSR still points into bank $30, where rxHead is in bank $10.

The following should work:

MOV w, #rxBuff
Bank $10
ADD w, rxHead
MOV FSR, w
MOV IND, rxByte
Bank $10
INC rxHead
CLRB rxHead.4

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,

G

Yendor

Thanks Gunther, always a pleasure!

I'll try it out w/ your code tonight - I do like what's happening better, in yours.·· Yeah, was failing all over the place, and thanks to your sx sim, I finally figured it out, but was bittersweet when the coide·didn't work 'as is'.

With my example, it just seems we're at the mercy of the compiler 'where' it addresses the variables, and learn that sample code may not always work as listed, but then again we get the fun of troubleshooting!

Rodney

Post Edited (Yendor) : 1/27/2010 2:20:11 PM GMT

PJMonty

Rodney,

Can you post the original sample code and mention where it came from?

Thanks,
PeterM

Zoot

It looks like some of Jon and Al (NR) Williams assembly ISR serial routines. That code, which is widely copied, has all of the serial registers in a single bank (8 byte buffer, Rx/Tx bit counters, bit width counters, buffer head/tail, etc). It's possible Yendor may have moved some of the variables around without seeing how that might impact the serial assembly code. SX/B would have handled recoding/compiling if the serial code was all SX/B, but not for assembly chunks.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php

Yendor

Zoot, Peter,

Thank you for your responses as well, and sorry for the delayed response back!

Yes, it was from some of Jon's N&V columns·(good detective work Zoot!)·- the source code is from 2005, so it could have been simply the SX/B compiler differences between now an then.

I recompiled the unmodified original code (attached), and var's were at the same address as above.

It's really no biggie, I should have been wiser, as I've witnessed this in my own code.

Bottom line is that the issue has been resolved and I'm happy, so I'm not going to·dwell on why and just keep moving·forward.·

I think there's some new statements from what I remember in SX/B 2.0 that I can force varaibles to certain banks, keep what I have ,or use Gunther's code.

So I guess my question, is there a common practice that you guys use to catch 'bank' issues within ASM, or it's just a matter of diving deep?··

Many thanks!

PS - boy, I·was quite surprised that this was still at the top of the forum after a couple of days!·· I appreciate you guys still participaing and helping!

JonnyMac

Indeed, that code is very old (SX/B 1.0) and I dare say I got away with it. Why? Well, it worked (I do in fact test my code before publishing) because, in the SX28, rxByte falls into the global bank. As Rodney pointed out I tend to use 8-byte buffers now so that the serial stuff can be moved around with all variables in the same bank. Again, I was lucky with this program and didn't even know it. In the SX28 (using SX/B) the first three bytes of user variables are global. In the SX48 you only get one.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon McPhalen
Hollywood, CA

Guenther Daubach

Rodney,

in Assembly, I use some naming conventions that help to keep the banks in order. Here is an example of how I declare banks and registers:

org $10
Ser = $
Ser_TxHighPC ds 1
Ser_TxLowPC ds 1
Ser_TxCountPC ds 1
Ser_TxDividePC ds 1
Ser_RxBytePC ds 1
Ser_RxCountPC ds 1
Ser_RxDividePC ds 1

As you can see, I assign a name to each bank, like "Ser" in this example. I then prefix the names of all registers in this bank with the bank name, followed by an underscore.

In the code, something like

bank Timer
mov Ser_TxHighPC, #'?'

should look really suspicious, as a register in bank "Ser" is referred to after bank "Timer" has been selected.

It is getting more problematic when you need to copy from a register in one bank to a register in another bank. In simple cases, you may use the W register as temporary storage, as in

bank Timer
mov w, Timer_Count
bank Serial
mov Serial_TxLow, w

Always be aware that the W register is used as temporary storage by almost all comopund statements, so this code will fail:

bank Timer
mov w, Timer_Count
mov Timer_Count, #200 ; w is used as temporary storage !
bank Serial
mov Serial_TxLow, w

When you replace the compound statement by what the assembler generates, you will immediately notice the problem:

bank Timer
mov w, Timer_Count
;

---

; mov Timer_Count, #200
;
mov w, #200 ; This overwrites the value of Timer_Count in w
mov Timer_Count, w
;

---

bank Serial
mov Serial_TxLow, w ; 200 is written to Serial_TxLow but not Timer_Count

For such cases, it is a good idea to have a temporary register defined in the global area, as such registers can always be accessed, no matter which bank is selcted. Here is an example:

bank Timer
mov Temp, Timer_Count
mov w, #200
mov Timer_Count, w
bank Serial
mov Serial_TxLow, Temp

Enough for now....

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,

G

Zoot

I think his question relates to SX/B "knowing" about assembly bank requirements. Rodney -- when using assembly, you must take care of banking yourself, so if you move variables around from an SX/B example that mixes ASM and SX/B, you should go through the ASM very carefully to make sure it will still be OK with the new register assignments, esp. when using a different SX device.

Following Guenther's suggestions, remember that when mixing SX/B and ASM, the __PARAM1 vars are all global and are always available to you in ASM -- they are *only* used by SX/B instructions. This is quite nice as it gives you 4-5 global vars for moving data between banks, stashing return values, pin masks, etc., when in ASM.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php

Yendor

Excellent - thank you both so much·for the tips and detailed·responses!

Rodney