Complicated macros are like bear traps hiding in your code.

Seriously, how many people actually go to the trouble of debugging their 
macros as if they were regular programs - in my experience not many. 

Just look at the example below:

_T0CON &= ~(1<<T0PS2 | 1<<T0PS1 | 1<<T0PS0)

and then:

_T0CON |= (0<<T0PS2) | (0<<T0PS1) | (0<<T0PS0)

I strongly belive that once you start trying to get the assembler source 
code to be too clever that it is time to use tools with the cleverness 
built in.

And personally if I were forced to use bit IDs, I would use something like

CARRY = (STATUS << 3) | C

recovering the bit within the SFR then becomes a simple mater of:

(CARRY & 7)

and recovering the SFR to which the bit belongs becomes:

(CARRY >> 3)

This allows your macros to do RAM page selecting, testing for invalid bit 
IDs as params etc.


Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB
optimising PIC compiler, LITE edition free for personal non-commercial use



On Tue, 8 Jul 2008, Tamas Rudnai wrote:

>  > I prefer to specify individual bits like this, but leave bit fields (such
> > as the three prescaler bits here) in binary, as in:
> >
> >  movlw  1<<TMR0ON | b'101'<<T0PS0   ; turn on TMR0, prescale = 64
> 
> 
> You can make it even complicated:
> 
> 
> ON     equ    1
> OFF    equ    0
> 
> _T0CON = 0
> 
> TMR0     macro    s
>             if s == ON
> _T0CON |= 1<<TMR0ON
>                 exitm
>             endif
>             if s==OFF
> _T0CON &= ~(1<<TMR0ON)
>                 exitm
>             endif
> 
>         error Invalid parameter to TMR0 macro s
>         endm
> 
> T0PS     macro    s
> _T0CON &= ~(1<<T0PS2 | 1<<T0PS1 | 1<<T0PS0)
> _T0CON |= (1<<PSA)
>             if s == .1
>                 exitm
>             endif
>             if s == .2
> _T0CON &= ~(1<<PSA)
> _T0CON |= (0<<T0PS2) | (0<<T0PS1) | (0<<T0PS0)
>                 exitm
>             endif
>             if s == .4
> _T0CON &= ~(1<<PSA)
> _T0CON |= (0<<T0PS2) | (0<<T0PS1) | (1<<T0PS0)
>                 exitm
>             endif
>             if s == .8
> _T0CON &= ~(1<<PSA)
> _T0CON |= (0<<T0PS2) | (1<<T0PS1) | (0<<T0PS0)
>                 exitm
>             endif
>             if s == .16
> _T0CON &= ~(1<<PSA)
> _T0CON |= (0<<T0PS2) | (1<<T0PS1) | (1<<T0PS0)
>                 exitm
>             endif
>             if s == .32
> _T0CON &= ~(1<<PSA)
> _T0CON |= (1<<T0PS2) | (0<<T0PS1) | (0<<T0PS0)
>                 exitm
>             endif
>             if s == .64
> _T0CON &= ~(1<<PSA)
> _T0CON |= (1<<T0PS2) | (0<<T0PS1) | (1<<T0PS0)
>                 exitm
>             endif
>             if s == .128
> _T0CON &= ~(1<<PSA)
> _T0CON |= (1<<T0PS2) | (1<<T0PS1) | (0<<T0PS0)
>                 exitm
>             endif
>             if s == .256
> _T0CON &= ~(1<<PSA)
> _T0CON |= (1<<T0PS2) | (1<<T0PS1) | (1<<T0PS0)
>                 exitm
>             endif
> 
>         error Invalid parameter to T0PS macro s
>         endm
> 
> 
> setTMR0 macro
>         movlw    _T0CON
>         movwf    T0CON
>         endm
> 
> setTimer0
>         ; preparing Timer0 settings
>         TMR0(ON)
>         T0PS(.256)
>         ; make the settings live
>         setTMR0
> 
> Not sure if that makes things more productive or less error prone - you may
> can write extensive macro sets like this which will be MCU independent
> however.
> 
> Tamas
> 
> 
> On Tue, Jul 8, 2008 at 10:18 AM, Xiaofan Chen <xiaofanc@gmail.com> wrote:
> 
> > On Tue, Jul 8, 2008 at 2:42 PM, David Meiklejohn <david@gooligum.com.au>
> > wrote:
> > > Chris wrote:
> > >>
> > >> You could in principle specify the 0 bits too:
> > >>
> > >>   movlw (1 << TMR0ON) | (1 << T0PS2) | (0 << T0PS1) | (1 << T0PS0)
> > >>
> > >> and similarly for the other 0 bits, which I haven't got handy.
> > >
> > > I prefer to specify individual bits like this, but leave bit fields (such
> > > as the three prescaler bits here) in binary, as in:
> > >
> > >  movlw  1<<TMR0ON | b'101'<<T0PS0   ; turn on TMR0, prescale = 64
> > >
> > > I do like Olin's method, but otoh, it seems reasonable to expect that
> > > someone working on the code will have the data sheet at hand.
> >
> > I agree that we need to consult the dustsheet. But still I think
> > Olin's method is much better and clearer. I understand people
> > who are proficient with C like to use "<<" or ">>" but it is
> > not as clear in the context of assembly programming.
> >
> >
> > Xiaofan
> > --
> > http://www.piclist.com PIC/SX FAQ & list archive
> > View/change your membership options at
> > http://mailman.mit.edu/mailman/listinfo/piclist
> >
> 
> 
> 
> -- 
> Rudonix DoubleSaver
> http://www.rudonix.com
> -- 
> 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