Byron Jeff wrote 2012-04-25 12:30: > On Wed, Apr 25, 2012 at 11:16:06AM +0200, Jan-Erik Soderholm wrote: >> 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. > > Really? Not an MPASM user, so I'm unsure. Yes, it is possible when writing *own* macros, of course. Olin Lathrops tool-set has been like that "always". With some complementary macros to "invalidate" the saved setting after returning from a CALL and so on. But the question is/was about BANKSEL i MPASM, not ? Jan-Erik. > Just in case, I updated my macro > to do exactly that. Of course it only works properly on straight line cod= e. > So there probably needs to be a complementary one that forces a MOVLB whe= n > coming in/out of a subroutine. And of course interrupts should be good an= d > 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 doe= sn'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 Dwayn= e > 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 preprocesso= r > 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 > >> >> 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 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 d= oesn'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 d= oesn'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 >>> >> -- >> 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 .