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 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'v= e > 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 > 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 ? Of course, if the BANKSEL is never run at all, it will not generate any code either... :-) Jan-Erik. >> >> 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 BANKS= EL 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 BANKS= EL 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 > -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .