Searching \ for 'MPLAB Bank changing problem' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/mems.htm?key=bank
Search entire site for: 'MPLAB Bank changing problem'.

Truncated match.
PICList Thread
'MPLAB Bank changing problem'
1999\04\25@131946 by Ron Dickinson

flavicon
picon face
I have recently migrated to Picstart Plus and MPLAb V4.00

Code which used to assemble correcly with MPASM for DOS (and still does)
now kicks up an error for each of the lines using Bank 1.  I assume that
BSF STATUS,RP0 is not acceptable.  Why not?

I must be doing something stupid and the help files have not helped.

This is typical code for P16C74 but the same happens on other chips.

       BSF     STATUS,RP0      ; Select bank 1
       MOVLW   B'00000000'
       MOVWF   TRISB           ; Port B as all outputs
       MOVLW   B'00001111'
       MOVWF   TRISA           ; Set port A as inputs for A/D
       MOVLW   B'00000111'     ; TMR0 pre-scalar /256
       MOVWF   OPTION_REG      ; 256uS per count Internal clock
       CLRF    PIE1            ; Disable all peripheral interrupts
       BCF     STATUS,RP0      ; Select bank 0


Message[302]: Register in operand not in bank 0.  Ensure that bank bits
are correct. ie saying that TRISB, TRISA etc are not in bank 0

These are warnings and not errors so if the simulation is single
stepped, the RP0 bit is changed properly.  Any ideas?

Thanks in anticipation

Ron
--
  /\
  []       Ron Dickinson
  []     <<<<<        >>>>>
  []     Compusolve-Redilec
 /--\    Derbyshire England
 !!!!    +44 01246 - 570281

1999\04\25@132815 by DAZLOGAN

picon face
Im not really sure about this, but aren't the TRIS commands obsolete now ??

1999\04\25@173546 by Mike Morrin

flavicon
face
At 06:07 pm 25/04/99 +0100, Ron Dickinson wrote:
>I have recently migrated to Picstart Plus and MPLAb V4.00
>
>Code which used to assemble correcly with MPASM for DOS (and still does)
>now kicks up an error for each of the lines using Bank 1.  I assume that
>BSF STATUS,RP0 is not acceptable.  Why not?
>
>Message[302]: Register in operand not in bank 0.  Ensure that bank bits
>are correct. ie saying that TRISB, TRISA etc are not in bank 0
>

Just go into the project/edit project box, and set the node properties for
each file to warning level "warn+err".  It worked for me.

regards,
Mike

1999\04\26@042311 by Nigel Orr

flavicon
face
At 18:07 25/04/99 +0100, you wrote:
>Code which used to assemble correcly with MPASM for DOS (and still does)
>now kicks up an error for each of the lines using Bank 1.  I assume that
>BSF STATUS,RP0 is not acceptable.  Why not?

As you said, it's a warning, it is just a reminder that you are trying to
access a Bank 1 register, so you can check you have done the BSF STATUS,RP0
first (MPLAB can't or doesn't check for you).  If you are confident that
all your Bank 1 accesses are correct, then add:

       ERRORLEVEL -302         ; Stops info error messages

at the top of you code- that will suppress _all_ '302' warnings, and leave
all other messages intact.  You can add similar lines for other similarly
unhelpful messages, but 302 is the only one that I usually get...

>Message[302]: Register in operand not in bank 0.  Ensure that bank bits
>are correct. ie saying that TRISB, TRISA etc are not in bank 0

It isn't saying that they aren't correct- just that it hasn't checked so
you need to ensure it yourself- it's a bit ambiguous, and I thought the
same as you at first...

>These are warnings and not errors so if the simulation is single
>stepped, the RP0 bit is changed properly.  Any ideas?

Just add the ERRORLEVEL code and check everything carefully, or you could
try to access bank 1 using indirect addressing e.g.

       movlw TRISA
       movwf FSR
       bsf INDF,2

has the same effect as

       bsf STATUS,RP0
       bsf TRISA,2
       bcf STATUS,RP0

but might not cause the warning (I haven't checked!)

It depends on your application whether either approach is suitable- use the
top one when you have to rapidly change one register in bank 1, and still
access registers in Bank 0 (once the FSR is loaded, you only need one
instruction to alter that register subsequently), and use the bottom one
when you need to change lots of Bank 1 registers (eg during initialisation).

Nigel
--
Nigel Orr                  Research Associate   O   ______
       Underwater Acoustics Group,              o / o    \_/(
Dept of Electrical and Electronic Engineering     (_   <   _ (
    University of Newcastle Upon Tyne             \______/ \(

1999\04\27@031948 by Caisson

flavicon
face
> Van: Ron Dickinson <spam_OUTrockitTakeThisOuTspamCOMPSOLV.DEMON.CO.UK>
> Aan: .....PICLISTKILLspamspam@spam@MITVMA.MIT.EDU
> Onderwerp: MPLAB Bank changing problem
> Datum: zondag 25 april 1999 19:07

Hello Ron,

> Code which used to assemble correcly with MPASM for DOS (and still does)
> now kicks up an error for each of the lines using Bank 1.  I assume that
> BSF STATUS,RP0 is not acceptable.  Why not?
>
> I must be doing something stupid and the help files have not helped.

No, you are not.  It's nothing more than a Warning.  Like "You are going to
leave the house.  Are you dressed ?".  You _know_ you are,  but the
warning-system is not clever enough to detect it.

> Message[302]: Register in operand not in bank 0.  Ensure that bank bits
> are correct. ie saying that TRISB, TRISA etc are not in bank 0

Correct.  They are not in the _default_ bank.  And any SFR that is not in
the default bank will result in the above warning.

> These are warnings and not errors so if the simulation is single
> stepped, the RP0 bit is changed properly.  Any ideas?

You can do several things:

One: Don't respond to those messages anymore :-) but they clutter-up the
error-log, and make it difficult to see the real errors/warnings.

Two: enter something like the next lines in your Source-file

errorlevel -205,-302,-305 ;Suppress warning's
  ;205 - "Found directive in column 1."
  ;302 - "Register in Operand not in bank 0"
  ;305 - "Using default destination"

Three:
 XOR the value of the Bank #1 FSR with 0x80 (movwf TRISA^0x80).  This will
leave a value between 0x00 and 0x7F, letting the compiler think that your
FSR is in bank 0.  But because you set the Bank-bit (RP0) it _will_ access
the FSR at bank #1.

Greetz,
 Rudy Wieser

1999\04\27@031958 by Caisson

flavicon
face
> Van: Darren Logan <DAZLOGANspamKILLspamaol.com>
> Aan: .....PICLISTKILLspamspam.....MITVMA.MIT.EDU
> Onderwerp: Re: MPLAB Bank changing problem
> Datum: zondag 25 april 1999 19:26
>
> Im not really sure about this, but aren't the TRIS commands obsolete now
??

Hello Darren,

 Yes, they are Obsolete (according to Micro-chip).  No, They are still in
use.  That is, the controller that _had_ them will _have_ them, even in a
newer version.  But not allways for _all_ the I/O-ports ...  Just check out
the Data-sheets.  By the way: TRIS commands are efficient, because they do
not need the switching fore-and-back of the SFR-banks.

Greetz,
 Rudy Wieser

1999\04\27@073245 by Sebastián Dols

flavicon
face
I've been reading messages about the differences between the 12c509 and the
12c509A, but somebody knows the main differences between the 16f84 and the
16f84A? in the microchip site there are two datasheets, one for the 84 and
other for the 84A (they are *so* diferent?)

thanks in advance

1999\04\27@183721 by Ron Dickinson

flavicon
picon face
In several messages I was advised to put errorlevel codes in the source
code.
> errorlevel -205,-302,-305 ;Suppress warning's


This has cured my problem (If it was) and set my mind at rest.

Thanks to all who responded.

Ron
--
  /\
  []       Ron Dickinson
  []     <<<<<        >>>>>
  []     Compusolve-Redilec
 /--\    Derbyshire England
 !!!!    +44 01246 - 570281

1999\04\27@213719 by paulb

flavicon
face
Ron Dickinson wrote:

> Code which used to assemble correcly with MPASM for DOS (and still
> does) now kicks up an error for each of the lines using Bank 1.  I
> assume that BSF STATUS,RP0 is not acceptable.  Why not?

 It's a *version* matter in the assembler.

> I must be doing something stupid and the help files have not helped.

 "No", and "You must be joking!"

> This is typical code for P16C74 but the same happens on other chips.

 All chips with register banks.

> Message[302]: Register in operand not in bank 0.  Ensure that bank
> bits are correct. ie saying that TRISB, TRISA etc are not in bank 0

 Stating the obvious.

> These are warnings and not errors so if the simulation is single
> stepped, the RP0 bit is changed properly.  Any ideas?

 Yes, it's just a warning, but not an "intelligent" one, to *remind*
you that you should have done this, whether you have or not.

 The simple fix is to put " ERRORLEVEL -302" at the beginning of each
file (note the leading space).  The next simple way is to specify each
operation as operating on "TRISA^BANK" and similarly for TRISB, with
BANK defined as 0x80.

 The (presumably optimal) method is to define macros which set and
clear the bank bit, setting BANK to match (0x80 or 0 accordingly).
These might even include conditional code to set or clear the bank bit
only if it needs changing, using BANK as a criterion.

 This latter approach is somewhat susceptible to oddities in program
flow however.

 Another consideration is to add a construct to disable interrupts
whenever a bank other than zero is selected, so that interrupt code need
not compensate for bank switching.

<hobby_horse>

Darren Logan wrote:

> Im not really sure about this, but aren't the TRIS commands obsolete
> now ??

 Boy!  Are *you* ever going to have difficulty programming 16C5x and
12C50x series devices!

 *Not* obsolete, never will be obsolete in the forseeable future.  Not
until PICS become obsolete.  To be more precise, it is the *preferred*
method of setting the TRIS and OPTION registers in *almost all*
instances.

 This is most certainly a FAQ.  It's strange, but relates to a "people"
thing at Microchip if you follow...  Look at the archives.

 The problem is fixed *most simply* by editing " ERRORLEVEL -224" into
all your chip "personality" include files (i.e., 16C74.INC 16F84.INC
etc. - for all 14-bit core devices, unnecessary for the 12-bit cores).
It'll never again worry you!

</hobby_horse>
--
 Cheers,
       Paul B.

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