How to use symbolic names for bits within registers?

Good day to all.

I'm continuing my journey as a PBP newbie and have another reasonably simple question:

How can I use bit names within PBP statements?

One recurring problem I have when porting code between different PICs is the location of the a/d converter go/done bit. Its easy in assembler: I simply define that bit in my header files and the proper bit is used even when I change processors. Eg: #define _GO_DONE ADCON0,1

But it doesn't seem to work in PBP.

This works:

adcon0.1 = 1

This doesn't work:

adcon0.GO_DONE = 1

even though GO_DONE has been equated to 1 in the appropriate header file (M16F88X.inc)

I'm sure its simple - could someone point me in the correct direction?

Many thanks!

dwayne

PS - the a/d go/done bit is the most common bit I need to change - it moves between .1 or .2, depending upon which PIC I'm currently targeting.

dwayne

Hi again Dwayne,

When you compile a PBP program, it first goes through PBPW or PBPL.exe which generates an ASM file.
The ASM file is then passed on to either PM.exe or MPASM.exe to be assembled into a .hex file.

The bit names you are referring to are only defined at the ASM level, but since PBP compiles first ... it has no idea what those bits are. And due to the way PBP optimizes code space, it needs to know where the bits are when it compiles.

So you actually have to look up the bits in the datasheet. :(

Then you just ...

Code:

---

GO_DONE  VAR ADCON0.1

GO_DONE = 1
WHILE GO_DONE : WEND
; get result

---

Unfortunately, there's no way to change bit locations according to the chip being compiled for within PBP.

Of course, you could always read the ADC at the ASM level, in which case you could use the predefined constants.
Or use ADCIN and not worry about it.

hth,

Sorry for the late reply - just back from a short (too short!) vacation.

Actually, Darrel, what you posted helps a lot. Again, I'm going through PBP code written by others and trying to make it both more easily maintainable as well as easier to read. The suggestion you made does exactly that - gives me a single place where I can make the changes needed when switching between different PICs.

I don't think that I can use ADCIN - I *think* that program execution halts while waiting for the ADC result and I can't tolerate the delay.

I'm avoiding adding my own ASM stuff for now, at least until I get a better sense of the landscape.

Many thanks!

dwayne