Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
???
08/25/06 19:44
Read: times


 
#123050 - #define and the preprocessor
Responding to: ???'s previous message
... are to be avoided as much as possible, for all of the reasons shown in this thread.

For example, rather than doing something like:
#define CP1OEN  0x01
#define T0E     0x02
#define INT0E   0x04
#define T1E     0x08
#define INT1E   0x10
#define T2E     0x20
#define T2EXE   0x40
#define SYSCLKE 0x80

I've started using an idiom I saw in the O'Reilly book "Practical C Programming." Like this:
enum _XBR1 {
    CP1OEN	= 1 << 0,		// Comparator 1 Output Enable bit
    T0E		= 1 << 1,		// T0 Enable Bit
    INT0E	= 1 << 2,		// /INT0 enable bit
    T1E		= 1 << 3,		// T1 enable bit
    INT1E	= 1 << 4,		// /INT1 enable bit
    T2E		= 1 << 5,		// T2 Enable bit
    T2EXE	= 1 << 6,		// T2EX enable bit
    SYSCKE	= 1 << 7		// Sysclk output enable bit
};

Here are the advantages:
a) It's obvious which bit in the register you're dealing with. Kinda self-documenting!
b) No issues/confusion with preprocessor, CP1OEN for example is simply a constant and it has a type.

Note that the compiler will optimize the shift operations into constants: 1 << 1 will be 0x02, for example.

The only disadvantage I can see is that you can't re-define them with a compiler command-line option, but for things like register bit definitions, you'd never do that, anyways.

-a

List of 32 messages in thread
TopicAuthorDate
SDCC Nooby Question            01/01/70 00:00      
   Ok got it            01/01/70 00:00      
      it\'s ok in Keil            01/01/70 00:00      
         Yes...            01/01/70 00:00      
            The reason is...            01/01/70 00:00      
               C first            01/01/70 00:00      
                  Learning C            01/01/70 00:00      
                     if this is cut and paste then            01/01/70 00:00      
                        Semi-colon was it            01/01/70 00:00      
                           C is fidgety about error declaration            01/01/70 00:00      
                           Syntax error            01/01/70 00:00      
                              Going back and looking...            01/01/70 00:00      
                                 It means            01/01/70 00:00      
                                    Preprocessor output            01/01/70 00:00      
                                 explanation            01/01/70 00:00      
                        Semicolon            01/01/70 00:00      
                           yes, Andy you are absolutely correct            01/01/70 00:00      
                              Semicolon - example            01/01/70 00:00      
                           backwards            01/01/70 00:00      
                              HUH?            01/01/70 00:00      
                                 try this            01/01/70 00:00      
                     Dallas app notes            01/01/70 00:00      
                     False economy            01/01/70 00:00      
                        OK            01/01/70 00:00      
                     Learning from the tools            01/01/70 00:00      
                        #define and the preprocessor            01/01/70 00:00      
                           are you sure?            01/01/70 00:00      
                              Yes!            01/01/70 00:00      
                           Hmmm...            01/01/70 00:00      
   SDCC Manual            01/01/70 00:00      
      Err... ya think?            01/01/70 00:00      
         Looks clear enough to me            01/01/70 00:00      

Back to Subject List