piclist 2008\07\07\095741a >
Thread: Code packing
www.piclist.com/techref/microchip/devices.htm?key=pic
face picon face BY : email (remove spam text)(Olin Lathrop)



David Duffy wrote:
> I still use absolute mode and
> never use the device include files.

Really bad idea.

> I have my own port definitions

At best you won't screw up and then you have something similar to the
Microchip files.  There are subtle differences between PICs and there are
different flavors of some of the peripherals.  The chances are slim that you
get all those things right from PIC to PIC, and silly anyway since Microchip
has already done that for you.

> I also have a boat load of #defines like this:
> #define carry   status,0
> #define zero    status,2
> #define rp0     status,5
> #define rp1     status,6
> #define irp     status,7

I don't think this is such a good idea, but in any case it is independent of
using your own processor include file.  Just defining string substitution
macros for the bits doesn't get you much and will probably get you into more
trouble than it will help with banked SFRs.

Individual SFR bits are rarely manipulated in main code.  Manipulation of a
particular peripheral is generally isolated to the module that deals with
it.  Most of the time you set up the configuration registers once, then
maybe check or clear the interrupt condition bit later.  For initialization,
you want to set up the whole register.  That is best served with a MOVLW,
MOVWF, with each bit of course carefully documented in the comments.

If you want to do something like this, think of the next higher level up
purpose of manipulating a particular bit in main line code.  For example,
you probably read the STATUS,Z bit to implement a conditional like "IF xxx =
0".  I've got macros SKIP_Z and SKIP_NZ for that purpose.  That and other
macros are in STD.INS.ASPIC at http://www.embedinc.com/pic.  In particular,
take a look at SKIP_WGT and SKIP_WLE.  Those are a lot clearer in the code
than any direct manipulation of STATUS,C.

> #define rd      eecon1,0        ;eeprom read bit
> #define wr      eecon1,1        ;eeprom write bit
> #define wren    eecon1,2        ;eeprom write enable
> #define wrerr   eecon1,3        ;eeprom write error
> #define eepgd   eecon1,7        ;eeprom data/program select
>
> I started doing this long ago so that I didn't have to remember what
> register the various bits belonged to.

Really bad idea.  Again, these are bits you only manipulate in special code
just for accessing the EEPROM, so the references are well contained.  But
another issue you have overlooked is that you do still need to know what
register the bits are in because you need to make sure the bank is set
properly before the access.  If I really wanted to do this for some reason,
I would wrap this in a macro like:

ee_write  macro
         dbankif  eecon1       ;make sure bank set properly
         bsf      eecon1, wr   ;start the EEPROM write
         endm

Actually in this case I'd probably encapsulate the whole EEPROM write
process in a macro, including writing the AAh and 55h signatures, etc.

> I had a go last night at using
> the device inc files but of course then all the bit names clashed.

It's going to be tough, but the longer you wait the worse it will be to
eventually fix your mess.


********************************************************************
Embed Inc, Littleton Massachusetts, http://www.embedinc.com/products
(978) 742-9014.  Gold level PIC consultants since 2000.
<004801c8e039$b0abdcb0$0300a8c0@main> 7bit

See also: www.piclist.com/techref/microchip/devices.htm?key=pic
Reply You must be a member of the piclist mailing list (not only a www.piclist.com member) to post to the piclist. This form requires JavaScript and a browser/email client that can handle form mailto: posts.
Subject (change) Code packing

month overview.

new search...