Volatile Bit Adc_go @ Adcon0 . Go; Options

[ryeg]

What do these statment mean?

volatile bit adc_go @ ADCON0 . GO;
volatile bit adc_on @ ADCON0 . ADON;

It's one of those mysteries that I can't seem to find in the books.

Rye

[Reynard]

Hi Rye,

It is sort of shown on page 45 of the C manual.

Basically you are creating an alias for a bit address.

adc_go is the same as ADCON0.GO

Where you would say: ADCON0.GO = true;

you would say something that is clearer: adc_go = true;

Cheers

Reynard

[IanM]

What do these statement mean?

volatile bit adc_go @ ADCON0 . GO;
volatile bit adc_on @ ADCON0 . ADON;

It's one of those mysteries that I can't seem to find in the books.

Rye

Now 'linkified' to the BoostC manual and part of the PIC mid-range datasheet. I doubt you will find them in any paper book. Its quite clear *what* the statements *do*, but *what* they *mean* depends on the context in which you use them. To clarify:

'adc_go' is thus defined as a single bit variable to start conversion and check if it is finished yet and 'adc_on' is defined as another single bit variable that turns the whole ADC module on or off.

The bit syntax is a BoostC language extension. The ANSI way of doing this would be to define a bitfield structure type to map bit names to positions in the register then cast an unsigned integer address to a pointer to the bitfield. Its OK for a couple of references but rapidly gets ugly when you have hundreds of bits to 'twiddle'. With liberal use of typedefs and #define, you might even get the syntax in main.c identical, but the header files would be *F*UGLY!

Both are volatile to warn the compiler that reading from them and writing to them have side effects not defined in the ANSI C language standard - i.e. they affect hardware so not to cache them in a temporary variable or optimise out references to them.

This post has been edited by IanM: Nov 7 2009, 01:45 PM

[ryeg]

Thanks for clearing that up for me guys. I had seen the stuff in the manual (yes, I occasionally read the manual) but the examples were a bit obscure in this case.

I might suggest that Dave and Pavel consider beefing up the manual on this. Particularly the use of the .h file references.

Regards
Rye