On Tue, Apr 24, 2012 at 06:46:35PM -0600, Dwayne Reid wrote: > Good day to all. >=20 > This is an incredibly newbie-type question, but I'm stumped. >=20 > I've been writing code in assembler for 'conventional' 12-bit-core=20 > and 14-bit-core PIC chips for a LONG time now. I've got a bunch of=20 > code-writing techniques that make the whole process fairly painless. >=20 > These early PICs have only 4 RAM banks: zero through three. I have=20 > macros that deal with the MSB of the 7-bit address so that I get=20 > Message 302 warnings only when I haven't properly set up the bank=20 > bits. These macros save me an awful lot of time when my fingers go=20 > faster than my mind. >=20 > In part, these macros are: >=20 > #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. >=20 > What happens is that MPASMWIN spits out a message 302 warning if I=20 > don't use the BB1 or RB1 macro on a register that is in RAM bank 1 or=20 > 3. Conversely, the assembler spits out a warning if use either macro=20 > when I shouldn't be using the macro with a register that is in RAM bank 0= or 2. >=20 > Like I mentioned above, these simple macros save me loads of time in=20 > tracking down stupid banking errors. Plus - I get completely empty=20 > .ERR files - this helps reassure me that I've probably caught all the=20 > RAM bank switching that is needed. >=20 > Now I'm starting a project with my very first enhanced PIC16=20 > architecture PIC - the 12F1840. This little sucker has 32 RAM banks=20 > - and an easy way to actually set the bank bits (banksel and movlb). >=20 > But: now I get all these darned message 302 warnings about checking=20 > to see if I actually did set the bank bits. >=20 > I *really* don't want to disable those warnings - they are a useful=20 > troubleshooting tool. What I'm wondering if anyone has techniques to=20 > 'mask' the message on a case-by-case basis. >=20 > In other words, I want to be able to do something like: >=20 > movlw b'00110011' > banksel SOMERAM > movwf SOMERAM >=20 > but do *SOMETHING* that persuades MPASMWIN that the RAM location is=20 > really in RAM bank 0, so that I don't get the warning message. Or:=20 > do something that hides the warning, again, on a case-by-case basis. >=20 > I know that there are a LOT of people using these newer chips and I=20 > was hoping that someone has a technique that hides the warning if the=20 > bank bits have actually been diddled. >=20 > My first thought was to write a macro that invokes banksel, turns off=20 > the warning, writes the RAM location, then turns the warning back=20 > on. Something along the lines of: >=20 > BS_movwf macro arg > banksel arg > errorlevel -302 > movwf arg > errorlevel 302 > endm >=20 > Usage would be: > movlw b'00110011' > BS_movwf (SOMERAM) >=20 > Of course, I'll have to do this for all possible operations, which=20 > seems tedious. >=20 > 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 doesn'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 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 only generate the movlb if the bank changes.=20 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 gener= ate the movlb if they differ) to optimize SETBSR. Hope this helps, BAJ >=20 > Many thanks! >=20 > dwayne >=20 > --=20 > 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 >=20 > --=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 .