bankA issues

Ok, now I have Darrel Taylor's "Instant Interrupts" running, with PBP and assembly interrupts.

Now, I find that I need yet another assembly-language routine (not interrupt-driven) to calculate an internet checksum (I need a 24-bit counter).

I have been putting all the assembly-language variables in bankA - which is now full. My assembly ISRs have some temporary variables that PBP doesn't read or write to, but on the advice of people smarter than me, I have those located in bankA as well.

My question is - Is it safe to not declare the variables "local" to the assembly language program as "bankA"? Can anybody give me some advice as to how to either free up some of the bankA space, or tell me it is OK to put my assembly-local variables in "not bankA"?

Hi again Charles,

Glad you got it working, and ...

it is OK to put your assembly-local variables in "not bankA"

In this code, V24 could be located in any bank, and you don't know where it is.
CHK?RP will switch to the proper bank for you. Then it's the same as if it were in BANKA.

Code:

---

V24  VAR  BYTE[3]      ; 24-bit variable

ASM                      ; 24-bit counter
    CHK?RP    _V24
    incfsz    _V24, F
    goto      NoCarry
    incfsz    _V24 + 1, F
    goto      NoCarry
    incfsz    _V24 + 2, F
NoCarry   
ENDASM

---

So, I think you are saying

_V24 could be anywhere in memory, and the CHK?RP macro will switch
to that bank and allow the routine to execute properly.

But as a hypothetical question -

If I needed to read the value of V24 later in my (PBP) program, would I have to copy the value of _V24 into another variable that was defined as 'bankA' in order to allow my PBP program to find it? And would the same be true if I wanted to pass a variable from PBP TO an assembly routine?

Quote:

---

_V24 could be anywhere in memory, and the CHK?RP macro will switch
to that bank and allow the routine to execute properly.

---

Correct!

But, the variable is defined in PBP. Therefore, it's always accessable in PBP.

Of course, PBP can't handle 24-bit variables directly. But the array can be used like normal...

x = V24(y)
<br>

Darrel,
Shouldn't the ASM intructions include the memory access bit=1, as indicated by the bold changes, so that the command uses the bank selected by BSR rather than the access bank?

Code:

---

    CHK?RP    _V24
    incfsz    _V24, F, 1
    goto      NoCarry
    incfsz    _V24 + 1, F, 1
    goto      NoCarry
    incfsz    _V24 + 2, F, 1

---

Steve

Quote:

---

Originally Posted by SteveB

Shouldn't the ASM intructions include the memory access bit=1, as indicated by the bold changes, so that the command uses the bank selected by BSR rather than the access bank?

---

I’m responding to my own post/question. This will save Darrel the trouble and may help others.

After more careful examination of the datasheets, it looks like the default values for ‘d’ and ‘a’ are 1 for most of the 18F instructions. This is not clearly listed in “Complete PIC18 Reference Manual,” but was listed in the 18F4620 datasheet, so I missed it on first inspection. That being said, it appears that the previously listed code could be simply:

Code:

---

    CHK?RP    _V24
    incfsz    _V24
    goto      NoCarry
    incfsz    _V24 + 1
    goto      NoCarry
    incfsz    _V24 + 2

---

This would default to saving the result back to the _V24, and using BSR to select the bank. Haven't checked ALL the instructions that use these bits, nor ALL the 18Fs, so YMMV.

EDIT: I also found this note in the datasheet:

Quote:

---

Note: If the register is specified with the full 12-bit address, the assembler will automatically force the access bit to a ’0’ (when the address is in the access RAM area) or a ’1’ (for all other addresses).

---

Steve

I hope everybody doesn't start answering their own questions. :)

Nice job though! &nbsp; http://www.picbasic.co.uk/forum/images/icons/icon14.gif

DT