[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [avr-gcc-list] efficiency of assigning bits
From: |
Royce & Sharal Pereira |
Subject: |
Re: [avr-gcc-list] efficiency of assigning bits |
Date: |
Fri, 18 Mar 2005 23:20:45 +0530 |
User-agent: |
Opera M2(BETA3)/8.0 (Win32, build 7522) |
On Fri, 18 Mar 2005 22:29:30 +0530, E. Weddington <address@hidden> wrote:
PORTD = (PORTD & (unsigned char)~(_BV(0))) | (unsigned
char)_BV(1)|_BV(2)|_BV(3));
Whew! What a long winded way to do things! This takes less time/energy
to enter:
PORTD &= ~(1 | (1<<1) | (1<<2));
1. What you wrote above is different than what I wrote above. Follow the
parentheses carefully to understand why.
Exactly my point-readability! I correct my statement to:
PORTD = (PORTD & ~(1<<0)) | (1<<1) | (1<<2);
I feel this is still more readable.
2. In your opinion. Others may differ. In fact it is not always clear
which bits are getting set or why. If you use symbolic names in place of
the bit numbers, then it stands a better chance of being mnemonic. I
prefer not having "magic numbers" in the source code.
For example, can you tell me offhand what this does on a mega128 without
looking at the datasheet?
TIMSK |= (1<<5);
No?
However if you write it like this:
TIMSK |= _BV(TICIE1);
Then you can at least make out that this is setting the Timer 1 Input
Yes, in this case your point is valid. Bit names were not used however in
the PORTD example.
#define STATUS_LED 3
//......
PORTA |= _BV(STATUS_LED);
What if the above code was for a prototype board, which then needed to
be re-layed out? What if the status LED needed to move to a different
I'm still comfortable with :
#define STATUS_LED 3
PORTA |= 1<< STATUS_LED;
I prefer standard C statements as much as possible. But like you said,
it's my opinion. Thats also the reason I don't mourn the demise of the
sbi() & cbi() macros ;)
3. IIRC, a constant defaults to an *integer*, which on the AVR is 16
bits. It does not default to an unsigned char. So you still have the
same problem and you will still have to typecast the constants.
I dont know...check this code result (from the .lss file):
PORTD= (PORTD & ~1) |(1<<2) |(1<<3);
924: 82 b3 in r24, 0x12 ; 18
926: 8e 7f andi r24, 0xFE ; 254
928: 8c 60 ori r24, 0x0C ; 12
92a: 82 bb out 0x12, r24 ; 18
--Royce.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
- Re: [avr-gcc-list] efficiency of assigning bits, (continued)
- Re: [avr-gcc-list] efficiency of assigning bits, E. Weddington, 2005/03/17
- Re: [avr-gcc-list] efficiency of assigning bits, Royce & Sharal Pereira, 2005/03/17
- Re: [avr-gcc-list] efficiency of assigning bits, E. Weddington, 2005/03/18
- Re: [avr-gcc-list] efficiency of assigning bits, E. Weddington, 2005/03/18
- Re: [avr-gcc-list] efficiency of assigning bits, Ned Konz, 2005/03/18
- Re: [avr-gcc-list] efficiency of assigning bits, E. Weddington, 2005/03/18
- Re: [avr-gcc-list] efficiency of assigning bits, Royce & Sharal Pereira, 2005/03/18
- Re: [avr-gcc-list] efficiency of assigning bits, Dave Hansen, 2005/03/18
- Re: [avr-gcc-list] efficiency of assigning bits, David Brown, 2005/03/21
- Re: [avr-gcc-list] efficiency of assigning bits, Dave Hansen, 2005/03/21
- Re: [avr-gcc-list] efficiency of assigning bits,
Royce & Sharal Pereira <=
- Re: [avr-gcc-list] efficiency of assigning bits, E. Weddington, 2005/03/18
- Re: [avr-gcc-list] efficiency of assigning bits, Jim Brain, 2005/03/18
- Re: [avr-gcc-list] efficiency of assigning bits, Graham Davies, 2005/03/19
- Re: [avr-gcc-list] efficiency of assigning bits, Jim Brain, 2005/03/19
- Re: [avr-gcc-list] efficiency of assigning bits, David Brown, 2005/03/21
- Re: [avr-gcc-list] efficiency of assigning bits (getting OT), Graham Davies, 2005/03/21
- Re: [avr-gcc-list] efficiency of assigning bits (getting OT), David Brown, 2005/03/21
- Re: [avr-gcc-list] efficiency of assigning bits (getting OT), Jim Brain, 2005/03/21
- Re: [avr-gcc-list] efficiency of assigning bits (getting OT), E. Weddington, 2005/03/21
- Re: [avr-gcc-list] efficiency of assigning bits (getting OT), E. Weddington, 2005/03/21