Are bit-variables in PICC a good idea

I'm not sure it matters a lot how you specify bit addresses for hardware. You generally don't change CPU architectures for a product a whole lot. There's no way you could change from a PIC to an AVR and simply recompile your C code and expect it to run. You would have to change all your bit addresses as I doubt if different architectures from different companies would keep bits in the same positions.

Now, for bit positions in something that is fixed (like in some standard communications protocol), you'd probably want to use C as it is independent of the actual hardware used, so you could in theory re-use such code on different hardware.

It really depends on whether your priority is efficiency or portability (or a compromise between these) A good technique is to use a typedef based on the platform, something like :

#if __TARGET__ == __SOME_TARGET_WHOSE_COMPILER_SUPPORTS_BITS__ #else typedef int bit ; /* or is it bit int - I can't remember */ #endif

You can then use the C convention that 0 is false and anything else is true to make your code portable.

It is almost always a bad idea to define absolute addresses as "magic numbers" in source code. The link process should give you a much more maintainable and portable way to do this

the

8-bit 0x20

operator)

in

wider

The syntax for typedef declarations is the same as for "normal" declarations. The "typedef" keyword is placed where you might otherwise place a storage-class specifier such as "static" or "extern". So,

/* declare an variable `a' of type int */ static int a;

/* declare a type alias `b' for type int */ typedef int b; /* declare a function `f', which returns a pointer to a function which returns a pointer to char */ extern char *(*f())();

/* declare a type alias `f' for a function which returns a pointer to a function which returns a pointer to char */ typedef char *(*f())();

Jeremy.

[...] [...]

These are two separate issues:

1) Double-underbar prefix. Keep it. If you (or your user) wants to hide the "ugliness", use a macro defined in a header a la _Bool and bool in stdbool.h

2) The only real feature this provides over _Bool is the ability to specify the location of the bit in memory. And the only reasons to do this (that I can imagine) are to specify control and status bits in hardware registers, or to assemble bit masks into bytes or words in order to handle packages of bits. For both these operations I prefer masking and shifting operations because the actual operations used and the order they are taken can be (must be) specified in the code, so (for example) possible interactions with interrupt service routines are more visible.

FWIW, I generally avoid bitfield structures except when 1) the compiler doesn't support a native bit type like _Bool, and 2) I have several boolean variables I need to define that are not necessarily related to one another. Something like the following:

struct bits { unsigned b0 :1; unsigned b1 :1; unsigned b2 :1; unsigned b3 :1; unsigned b4 :1; unsigned b5 :1; unsigned b6 :1; unsigned b7 :1; } my_status_bits;

#define boost_switch_position my_status_bits.b0 #define is_warmup_mode my_status_bits.b1 /*etc.*/

But even then, you have to be careful about using these in ISRs. Something like

is_warmup_mode = TRUE;

isn't generally atomic.

What's a "modern CPU?"

For the PIC or an 8051, with memory-mapped registers, it makes sense. For a Pentium running Windoze, it doesn't.

HTH,

-=Dave

--
Change is inevitable, progress is not.