Byron Jeff wrote 2012-04-25 04:51: > Note you can use BANKSEL instead of the movlb if you like, > which will only generate the movlb if the bank changes. 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. Jan-Erik. 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 bank = 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 se= ts > the BSR register. So I ended up writing my own macro: > > SETBSR macro target > movlb (target>> 7) ; gpasm assember's BANKSEL doesn= 't work for exhanced 16F parts. > endm > > Works fine, but I had simply disabled the 302 directives. Poking around t= he > manual I found the SET directive, which facilitates assembler variables > that can be changed. I figured that we can keep track of the current bank > in the macro. Since we only need the bank, I decided the shift the target > down, then shift it back up: > > SETBSR macro target > movlb (target>> 7) ; gpasm assember's BANKSEL doesn= '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 onl= y > generate the movlb if the bank changes. > > Once you have the assembler variable, you can use it the same way you did > 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 assembly > of my movlb (add an OLDBANK variable, compare it to CURBANK, and only gen= erate > 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 .