On Wed, Apr 25, 2012 at 11:16:06AM +0200, Jan-Erik Soderholm wrote: > Byron Jeff wrote 2012-04-25 04:51: >=20 > > Note you can use BANKSEL instead of the movlb if you like, > > which will only generate the movlb if the bank changes. >=20 > Are you saying that BANKSEL in some way tracks the current > state of the bank-bits? Are you sure? I think BANKSEL > always will create the apropriate MOVLB command. Really? Not an MPASM user, so I'm unsure. Just in case, I updated my macro to do exactly that. Of course it only works properly on straight line code. So there probably needs to be a complementary one that forces a MOVLB when coming in/out of a subroutine. And of course interrupts should be good and save/restore the BSR register. Here's my first crack at it: SETBSR macro target if (target >> 7) !=3D (CURBANK >> 7) movlb (target >> 7) ; gpasm assember's BANKSEL doesn'= t work for exhanced 16F parts. CURBANK set (((target >> 7) & 0x1f) << 7) ; Force bank from 0-31 endif endm It seems to work. What actually fails are the types of defines that Dwayne has below. Unsure as to why gpasm chokes on it. No a hugh problem as virtually every Unix box which will run gpasm has an actual C preprocessor that can handle it. BTW I prime CURBANK in the beginning with a bank 33, which is out of range and forces generation of MOVLB and a reset of CURBANK. BAJ >=20 > Jan-Erik. >=20 >=20 > Byron Jeff wrote 2012-04-25 04:51: > > On Tue, Apr 24, 2012 at 06:46:35PM -0600, Dwayne Reid wrote: > >> Good day to all. > >> > >> This is an incredibly newbie-type question, but I'm stumped. > >> > >> I've been writing code in assembler for 'conventional' 12-bit-core > >> and 14-bit-core PIC chips for a LONG time now. I've got a bunch of > >> code-writing techniques that make the whole process fairly painless. > >> > >> These early PICs have only 4 RAM banks: zero through three. I have > >> macros that deal with the MSB of the 7-bit address so that I get > >> Message 302 warnings only when I haven't properly set up the bank > >> bits. These macros save me an awful lot of time when my fingers go > >> faster than my mind. > >> > >> In part, these macros are: > >> > >> #define BB1(reg,bit) (reg^0x80),(bit) ;bit in bank 1 > >> #define RB1(reg) (reg^0x80) ;reg in bank 1 > >> ;usage is: bcf BB1(_SOMEBIT) > >> ;usage is: movwf RB1(SOMEREG) > > > > Interesting idea. I usually just disable the warnings. > >> > >> What happens is that MPASMWIN spits out a message 302 warning if I > >> don't use the BB1 or RB1 macro on a register that is in RAM bank 1 or > >> 3. Conversely, the assembler spits out a warning if use either macro > >> when I shouldn't be using the macro with a register that is in RAM ban= k 0 or 2. > >> > >> Like I mentioned above, these simple macros save me loads of time in > >> tracking down stupid banking errors. Plus - I get completely empty > >> .ERR files - this helps reassure me that I've probably caught all the > >> RAM bank switching that is needed. > >> > >> Now I'm starting a project with my very first enhanced PIC16 > >> architecture PIC - the 12F1840. This little sucker has 32 RAM banks > >> - and an easy way to actually set the bank bits (banksel and movlb). > >> > >> But: now I get all these darned message 302 warnings about checking > >> to see if I actually did set the bank bits. > >> > >> I *really* don't want to disable those warnings - they are a useful > >> troubleshooting tool. What I'm wondering if anyone has techniques to > >> 'mask' the message on a case-by-case basis. > >> > >> In other words, I want to be able to do something like: > >> > >> movlw b'00110011' > >> banksel SOMERAM > >> movwf SOMERAM > >> > >> but do *SOMETHING* that persuades MPASMWIN that the RAM location is > >> really in RAM bank 0, so that I don't get the warning message. Or: > >> do something that hides the warning, again, on a case-by-case basis. > >> > >> I know that there are a LOT of people using these newer chips and I > >> was hoping that someone has a technique that hides the warning if the > >> bank bits have actually been diddled. > >> > >> My first thought was to write a macro that invokes banksel, turns off > >> the warning, writes the RAM location, then turns the warning back > >> on. Something along the lines of: > >> > >> BS_movwf macro arg > >> banksel arg > >> errorlevel -302 > >> movwf arg > >> errorlevel 302 > >> endm > >> > >> Usage would be: > >> movlw b'00110011' > >> BS_movwf (SOMERAM) > >> > >> Of course, I'll have to do this for all possible operations, which > >> seems tedious. > >> > >> Any thoughts? > > > > Not only a thought, I think I have a solution. I use a version of gpasm > > that Joseph Julichar of Microchip augmented to support the enhanced > > architecture. But it doesn't support a BANKSEL directive that properly = sets > > the BSR register. So I ended up writing my own macro: > > > > SETBSR macro target > > movlb (target>> 7) ; gpasm assember's BANKSEL doe= sn't work for exhanced 16F parts. > > endm > > > > Works fine, but I had simply disabled the 302 directives. Poking around= the > > manual I found the SET directive, which facilitates assembler variables > > that can be changed. I figured that we can keep track of the current ba= nk > > in the macro. Since we only need the bank, I decided the shift the targ= et > > down, then shift it back up: > > > > SETBSR macro target > > movlb (target>> 7) ; gpasm assember's BANKSEL doe= sn't work for exhanced 16F parts. > > CURBANK set ((target>> 7)<< 7) > > endm > > > > Note you can use BANKSEL instead of the movlb if you like, which will o= nly > > generate the movlb if the bank changes. > > > > Once you have the assembler variable, you can use it the same way you d= id > > with the older chips: > > > > #define BB(reg,bit) (reg^CURBANK),(bit) ;verify reg is in CURBANK > > #define RB(reg) (reg^CURBANK) ;verify reg is in CURBANK > > > > I did a quick test, and it looks like a winner. Try it. > > > > Now that I see this method, it looks like I could do conditional assemb= ly > > of my movlb (add an OLDBANK variable, compare it to CURBANK, and only g= enerate > > the movlb if they differ) to optimize SETBSR. > > > > Hope this helps, > > > > BAJ > > > > > > > >> > >> Many thanks! > >> > >> dwayne > >> > >> -- > >> Dwayne Reid > >> Trinity Electronics Systems Ltd Edmonton, AB, CANADA > >> (780) 489-3199 voice (780) 487-6397 fax > >> www.trinity-electronics.com > >> Custom Electronics Design and Manufacturing > >> > >> -- > >> http://www.piclist.com PIC/SX FAQ& list archive > >> View/change your membership options at > >> http://mailman.mit.edu/mailman/listinfo/piclist > > > --=20 > http://www.piclist.com PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist --=20 Byron A. Jeff Department Chair: IT/CS/CNET College of Information and Mathematical Sciences Clayton State University http://cims.clayton.edu/bjeff --=20 http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .