On Wed, Apr 25, 2012 at 01:52:51PM +0200, Jan-Erik Soderholm wrote: > > > Byron Jeff wrote 2012-04-25 13:25: > > 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 fo= rm > > 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 t= o. > > So as long as the code is straight line it'll only generate 302 warning= s > > when the register is not in sync with current value of BSR. > > > > BAJ > > > > OK, I think I see now. :-) > > Your reference to BANKSEL (that I quoted above) was "when used > inside your own macro", not to BANKSEL i general, right ? Actually I was asking about BANKSEL in general. But it's clear now that it doesn't track. > > Of course, if the BANKSEL is never run at all, it will not > generate any code either... :-) Correct. So it can be used in my macro. In fact it may be a good idea. Using BANKSEL would backport my macro back to the older family of chips too because BANKSEL will properly twiddle the appropriate bits, whereas mine specifically does a MOVLB, which is an enhanced 16F only instruction. Personally I'm not pressed because I'm never planning on moving back to the older chips ever. With enhanced chips in every package size, I cannot see a good reason to every move back. BAJ > > Jan-Erik. > > > > > >> > >> Jan-Erik. > >> > >> > >> > >>> 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 goo= d 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 ass= ember'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 D= wayne > >>> 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 preproc= essor > >>> 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 o= f > >>>>>> code-writing techniques that make the whole process fairly painles= s. > >>>>>> > >>>>>> These early PICs have only 4 RAM banks: zero through three. I hav= e > >>>>>> 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 g= o > >>>>>> 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 ma= cro > >>>>>> 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 empt= y > >>>>>> .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 ban= ks > >>>>>> - and an easy way to actually set the bank bits (banksel and movlb= ). > >>>>>> > >>>>>> But: now I get all these darned message 302 warnings about checkin= g > >>>>>> to see if I actually did set the bank bits. > >>>>>> > >>>>>> I *really* don't want to disable those warnings - they are a usefu= l > >>>>>> 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 i= s > >>>>>> 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 basi= s. > >>>>>> > >>>>>> 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 g= pasm > >>>>> that Joseph Julichar of Microchip augmented to support the enhanced > >>>>> architecture. But it doesn't support a BANKSEL directive that prope= rly sets > >>>>> the BSR register. So I ended up writing my own macro: > >>>>> > >>>>> SETBSR macro target > >>>>> movlb (target>> 7) ; gpasm assember's BAN= KSEL doesn't work for exhanced 16F parts. > >>>>> endm > >>>>> > >>>>> Works fine, but I had simply disabled the 302 directives. Poking ar= ound the > >>>>> manual I found the SET directive, which facilitates assembler varia= bles > >>>>> that can be changed. I figured that we can keep track of the curren= t 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 BAN= KSEL 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 wi= ll only > >>>>> generate the movlb if the bank changes. > >>>>> > >>>>> Once you have the assembler variable, you can use it the same way y= ou 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 as= sembly > >>>>> of my movlb (add an OLDBANK variable, compare it to CURBANK, and on= ly 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 > > > -- > 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 .