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:
dbankif eecon1 ;make sure bank set properly
bsf eecon1, wr ;start the EEPROM write
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.
See also: www.piclist.com/techref/microchip/devices.htm?key=pic
You must be a member of the
piclist mailing list
(not only a www.piclist.com member) to post to the