On Wed, Apr 25, 2012 at 12:44:45PM +0200, Jan-Erik Soderholm wrote: > > > 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 ? Not exactly. Dwayne wanted to keep the 302 warnings on, but use some form of macros and defines to check the current bank, whether or not it was generated with BANKSEL or MOVLB. It's not clear if his set of macros guaranteed that the bank bits RP0/RP1 were set correctly or not. What I've generated will generate both the MOVLB and will track what BSR is set to. So as long as the code is straight line it'll only generate 302 warnings when the register is not in sync with current value of BSR. BAJ > > Jan-Erik. > > > > > Just in case, I updated my macro > > to do exactly that. Of course it only works properly on straight line c= ode. > > So there probably needs to be a complementary one that forces a MOVLB w= hen > > 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 ban= k from 0-31 > > endif > > endm > > > > It seems to work. What actually fails are the types of defines that Dwa= yne > > 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 preproces= sor > > 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 o= r > >>>> 3. Conversely, the assembler spits out a warning if use either macr= o > >>>> when I shouldn't be using the macro with a register that is in RAM b= ank 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 th= e > >>>> 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 t= o > >>>> '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 th= e > >>>> bank bits have actually been diddled. > >>>> > >>>> My first thought was to write a macro that invokes banksel, turns of= f > >>>> 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 gpa= sm > >>> that Joseph Julichar of Microchip augmented to support the enhanced > >>> architecture. But it doesn't support a BANKSEL directive that properl= y 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 arou= nd the > >>> manual I found the SET directive, which facilitates assembler variabl= es > >>> 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 ta= rget > >>> 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. > >>> > >>> 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 asse= mbly > >>> of my movlb (add an OLDBANK variable, compare it to CURBANK, and only= generate > >>> 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 > > > -- > http://www.piclist.com PIC/SX FAQ & list archive > View/change your membership options at > http://mailman.mit.edu/mailman/listinfo/piclist -- Byron A. Jeff Department Chair: IT/CS/CNET College of Information and Mathematical Sciences Clayton State University http://cims.clayton.edu/bjeff -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .