Electronics > Microcontrollers

Microcontroller coding style for bit assignments

(1/3) > >>

tsmz:
There are quite a few coding styles for microcontrollers, especially when it comes to setting bits in registers. While they are all functionally and computationally equivalent (the compiler will most likely take care of replacing everything with constants), they do differ in style quite a lot.
I was wondering on the advantages and disadvantages of the various styles and what people use and why.

Style 1:
BITx definitions

--- Code: ---#define BIT1 0x01
#define BIT2 0x02
#define BIT3 0x04
#define BIT4 0x08
#define BIT5 0x10
#define BIT6 0x20
#define BIT7 0x40
#define BIT8 0x80

// LED on Port1.5
#define MY_LED BIT6

// program code

P1OUT |= BIT3;
P1OUT ^= MY_LED;

--- End code ---


Style 2:
Bitshifts

--- Code: ---// LED on Port1.5
#define MY_LED 5

// program code
P1OUT |= (1<<3);
P1OUT ^= (1<<MY_LED);

--- End code ---

Style 3:
Direct usage of constants

--- Code: ---// LED on Port1.5
#define MY_LED 0x20;

// program code
P1OUT |= 0x04;
P1OUT ^= MY_LED;

--- End code ---

Are there any other styles? What do you use and why? What should one use? I've seen several styles in code so far. I'll keep back my own preference until later to not give a preference from the start.

Bored@Work:

--- Quote from: tsmz on June 18, 2011, 08:24:37 pm ---I was wondering on the advantages and disadvantages of the various styles and what people use and why.
--- End quote ---

There aren't any technical advantage or disadvantages of the various styles.

The only reason to use a particular style is because it is the common style on the particular platform you are working on. The value in using the platform's typical style is in consistency on that platform. Which in turn contributes to maintainability.

If you see someone imposing his one personal style on every platform, instead of using the platform's normal style, you know you are dealing with one of those annoying jokers who have no clue and make a marginal issue (the style) a matter of life and death.

Psi:
i use style 2.

Only because when i learned avr's that's what all the examples used.

westfw:
fourth style: C bitfields:

--- Code: ---struct ioport {
  bit0:1;
  bit1:1;
  bit2:1;
  bit3:1;
  bit4:1;
  bit5:1;
  bit6:1;
  bit7:1;
} *porta = (0x123);

porta->bit0 = 1;
porta->bit7 = 0;
--- End code ---

Fifth style: non standard compiler extensions:

--- Code: ---  PORTA.5 = 1;

// or

  bit statbit @ PORTA.4;
  statbit = 1;
 
--- End code ---

In general, you're at the mercy of the manufacturer or compiler vendor for the constants in include files for the CPUs in use, and should stick with similar structures for bits within user defined structures/etc.  (although they may come with their own standards.)  This may be influenced by whether the particular CPU architecture has instructions that have arguments that are bit numbers or not.  PIC and AVR (and many microcontrollers) feature such instructions, but other CPUs (say, the x86 and MSP430) do not.

tsmz:
Compilers will calculate the value of the bitshift and write a constant in the code. So (1<<3) is really equivalent to 0x04. Styles 1 to 3 are equivalent, you won't find a compiler that messes up these things.
Style 4 is quite elegant, but I wouldn't be so sure if all compilers will do the right thing.

By the way, i = i + 1 and i += 1 are identical and will thus most likely be optimized in the same way by a decent compiler. Compilers are quite good today and will, if you don't mess up their configuration, compute constant expressions at compile time.

Personally, I use style 2 because I think it's the clearest way to express things. Also, numbering is absolutely obvious with this. Since the BITx definitions usually start with BIT1, but ports are numbered from 0 to y, PORT1.0 will actually be set by P1OUT |= BIT1, which I think is slightly ugly and confusing. It's much nicer and clearer to use P1OUT |= (1<<0), even if it doesn't look as obvious at first.

Navigation

[0] Message Index

[#] Next page

There was an error while thanking
Thanking...
Go to full version