Searching \ for 'PIC16C64A Bank bits' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/microchip/memory.htm?key=bank
Search entire site for: 'PIC16C64A Bank bits'.

Truncated match.
PICList Thread
'PIC16C64A Bank bits'
1998\04\27@051753 by Carl Wainwright

flavicon
face
Just a short question

Using MPLAB 3.4 I am getting weird results with bank bit errors

I have macros which set and reset bit RP0 bit in the status register.

bk0 MACRO
       bcf rp0
      ENDM

bk1 MACRO
       bsf rp0
      ENDM

I have declared a block at 0xA0 for 3 bytes as bank0 is full up!

       cblock 0xA0
               SW_VER_HIGH
               SW_VER_LOW
               SW_BUILD
       endc

some defines

       #define ver_build               0
       #define ver_high                1
       #define ver_low         0

I have written the following code to store the version number in memory

       bk1
       movlw   ver_high
       movwf   SW_VER_HIGH
       movlw   ver_low
       movwf   SW_VER_LOW
       movlw   ver_build
       movwf   SW_BUILD
       bk0

And the assembler returns messages(not errors) on the "movwf" lines of
bank bits not set properly. If I emulate the code with pic-master I can
clearly see the bank bits being set.

Questions:

       1) Am I doing anything wrong?
       2) Is this a reported error with the assembler
       3) Should I just ignore the messages


Carl Wainwright                                                Tel : +44
(0) 1635 584014
Graduate Design Engineer                               Fax : +44 (0)
1635 584098
Controlware Communications Systems Ltd
Gateway House
Newbury Business Park
Newbury
Berkshire
RG14 2PZ

1998\04\27@060540 by Neil Strong

flavicon
face
part 0 297 bytes
Yes!

OR .....

Put

ERRORLEVEL -305

At the top of your listing ( I think it is 305 - anyway, it's whatever the error number is in your listing )

Someone published a method a couple of weeks ago to get around this by setting or clearing bit 8 in the address ..... Can't remember which?

Neil.

1998\04\27@061824 by g.daniel.invent.design

flavicon
face
dear Carl, v3.31.00 gives this message:

Message[302] c:\dir\incl.asm [line No] : register in operand not in bank
0. ensure that bank bits are correct.

my code still works with these messages.

I seem to recall that this was a required improvement for a betta
version v3.4x bug fix so maybe the microchip team compiled mplab 3.4
with some old S/W initially.

try updating to the latest version of mplab (non betta).; else suffer or
revert to v3.31.00 (runs well)

Carl Wainwright wrote:
{Quote hidden}

1998\04\27@062206 by g.daniel.invent.design

flavicon
face
see errorlevel correction: (using mplab v3.31.00 any way)

Neil Strong wrote:
>
> 3) Should I just ignore the messages
>
> Yes!
>
> OR .....
>
> Put
>
> ERRORLEVEL -302
>
> At the top of your listing ( I think it is 305 - anyway, it's whatever the err
or number is in your listing )
>
> Someone published a method a couple of weeks ago to get around this by setting
or clearing bit 8 in the address ..... Can't remember which?
>
> Neil.
>
>     ---------------------------------------------------------------
>
>                 Part 1.2       Type: application/ms-tnef
>                            Encoding: base64

1998\04\27@142113 by Mike Keitz

picon face
On Mon, 27 Apr 1998 09:34:08 +0100 Carl Wainwright
<spam_OUTCWainwrightTakeThisOuTspamCWARE.CO.UK> writes:
>bk0 MACRO
>        bcf rp0
>       ENDM

Is this right?  It should be bcf STATUS,RP0.

[...]
>And the assembler returns messages(not errors) on the "movwf" lines of
>bank bits not set properly. If I emulate the code with pic-master I
>can
>clearly see the bank bits being set.

Everything is working correctly.  The assembler doesn't try to see if you
set the bank bits, since that would require simulating the entire
program.  The situation is the same as trying to access special function
registers in bank 1.  You can either use an errorlevel directive to stop
the messages, or modify the direct access instructions to turn off the
high bit, e.g.
       movwf   SW_BUILD^0x80
The xor with 80 changes the address of A0 into 20.  Since the page bit is
already set, the proper byte in RAM is accessed.  Using an XOR instead of
an AND gives some protection against treating a bank 0 variable as if it
were in bank 1.  Then the xor would set the high bit, and the warning
message would appear.

Try to put variables which are generally or only accessed indirectly
(buffers, arrays) in page 1.  Since the FSR holds a full 8-bit address,
they can be accessed indirectly without needing to set the RP0 bit.

If an interrupt can occur while the RP0 bit is set and the ISR saves W to
RAM, the possibility of saving W to a location in page 1 must be
considred.  The simplest way to do this is to allocate two bytes of RAM
for saving W, one in page 0 and another directly "on top of" the page 0
location in page 1:
isrsavew        equ     0x20
isrsavew1       equ     0xA0
Then allocate the other variables starting at 21 and A1.  The save and
recall W and STATUS routines from Microchip work this way.

_____________________________________________________________________
You don't need to buy Internet access to use free Internet e-mail.
Get completely free e-mail from Juno at http://www.juno.com
Or call Juno at (800) 654-JUNO [654-5866]

1998\04\28@083040 by Alex Torres

picon face
{Quote hidden}

This is becouse PIC's assembler works with 7-bit adresses.

>         2) Is this a reported error with the assembler
>         3) Should I just ignore the messages

Yes, you may ignore it, you may switch it off by the compiler's directive,
but the best way is to use :
   movwf SW_VER_HIGH ^ 0x80 (and orther registers the same)

==============================
Alex Torres, Kharkov, Ukraine (exUSSR)
altorspamKILLspamgeocities.com
2:461/28 FidoNet
http://www.geocities.com/SiliconValley/Lab/6311

More... (looser matching)
- Last day of these posts
- In 1998 , 1999 only
- Today
- New search...