_BV()

Go To Last Post
21 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What does mean?
Thanks in advance

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

BV=Bit Value.

If you want to change the state of bit 6 in a byte you can use _BV(6) which is is equivalent to 0x40. But a lot us prefer the completely STANDARD method and simply write (1<<6) for the same thing or more specifically (1<<

For example if I want to set bit 6 in PORTB I'd use:

PORTB |=  (1 << PB6);

though I guess I could use:

PORTB |= _BV(6);

or

PORTB |= _BV(PB6);

But, like I say, personally I'd steer clear of _BV() as it is non standard and non portable. After all it is simply:

#define _BV(n) (1 << n)

anyway.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

FYI, the answer is also found in the avr-libc user manual.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

By the way... I find myself *always* using the bit constants (like PB2) with _BV()... was there any reason why avrlib defines the constants as the bit number instead of an 8 bit mask (like 0x04 for PB2 instead of 2)?...
Besides being more workful, this definition is more error prone.

Embedded Dreams
One day, knowledge will replace money.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Nuno wrote:
was there any reason why avrlib defines the constants as the bit number instead of an 8 bit mask (like 0x04 for PB2 instead of 2)?...

Having them defined as a bit number makes them usable in assembly language with the cbi and sbi instructions. If you defined them as bit masks, you'd need a second set for use with cbi and sbi.

Don Kinzer
ZBasic Microcontrollers
http://www.zbasic.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dkinzer wrote:
(...)
Having them defined as a bit number makes them usable in assembly language with the cbi and sbi instructions. If you defined them as bit masks, you'd need a second set for use with cbi and sbi.

True, but... the tool is a C compiler, so it should be focused on C and not assembly...

Embedded Dreams
One day, knowledge will replace money.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nuno wrote:
True, but... the tool is a C compiler, so it should be focused on C and not assembly...

Your perspective is a result of your looking at WinAVR through "C" glasses. WinAVR is perfectly suitable for either C or assembly language development or, as I use it, for mixed C/assembly language development. The bit definitions are in a .h file and are usable from either C or assembly language.

Don Kinzer
ZBasic Microcontrollers
http://www.zbasic.net

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dkinzer wrote:
(...)Your perspective is a result of your looking at WinAVR through "C" glasses. WinAVR is perfectly suitable for either C or assembly language development or, as I use it, for mixed C/assembly language development. (...)

Yes, I know it's perfectly capable of it. But the main advantage of using WinAVR is C. For assembly only I would stick to AVR Studio. And when using mixed C/assembly in a project, people try to minimize the assembly parts, doing as much as possible in C so, C is still "the star".

Embedded Dreams
One day, knowledge will replace money.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Oh that's right, the avr-gcc toolchain should have been designed for ONLY the use you personally plan to make!

A lot of people have combined .c and .S projects and I'd guess that before you are finished you too will find yourself making use of avr-as as well as avr-gcc (well in fact you DO use avr-as everytime you compile a .c file - but that maybe isn't quite so obvious too you)

Remember that the entire world does NOT revolve around just the C programming language.

Cliff

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The basic reason is that Atmel always defined them that way (but that's
certainly due to the CBI/SBI instructions, yes).

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hey. AVR GCC was designed for assembly, C, C++ (with caveats), *and* Ada. ;)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> ...*and* Ada.

Though arguably, Ada uses its own IO space abstraction (as far as
I know).

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Should WinAVR contain some example Ada programs along with .c and .S examples? ;)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Do you want to contribute some?

However, the current examples are from avr-libc, where Ada examples would
clearly not be applicable to.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jörg,

I think the last time I looked at an Ada program was about 23 years ago! I'd just be interested to see some examples that are compilable with avr-gcc. Presumably there are some test cases somewhere that are used for regression testing the compiler if nothing else?

Cliff

PS Actually a Google lead me to this:

http://avr-ada.sourceforge.net/e...

with a rather familiar name at the top!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Oh that's right, the avr-gcc toolchain should have been designed for ONLY the use you personally plan to make!

I didn't said that.
clawson wrote:
A lot of people have combined .c and .S projects and I'd guess that before you are finished you too will find yourself making use of avr-as as well as avr-gcc

As I said before, we tend to avoid asm as much as possible (in fact, we can say it's a "good programming practice" to do it).
clawson wrote:
(well in fact you DO use avr-as everytime you compile a .c file - but that maybe isn't quite so obvious too you)

Not manually, so I don't care.
clawson wrote:
Remember that the entire world does NOT revolve around just the C programming language.

I didn't said that either. Nor the world revolves around assembly, and yet, they made the defines in a way that it's easier to use in assembly than C!! So there should be some reason.
Look, I just mentioned that I'm always using the defines with the _BV (), which is because I program more in C than assembly. Since the "strongness" of WinAVR is that it has a C (or whatever higher-level language you prefer) compiler, it seems logical to me that people will do as much as possible in C, otherwise, I think everybody would stick to AVRStudio for just assembly.
That's why I questioned why do we have more work with the defines when using C than assembly.
dl8dtl wrote:
The basic reason is that Atmel always defined them that way (but that's
certainly due to the CBI/SBI instructions, yes).

Now, this sounds like a reason. You didn't give single one, Cliff!

Embedded Dreams
One day, knowledge will replace money.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Nuno wrote:
dl8dtl wrote:
The basic reason is that Atmel always defined them that way (but that's
certainly due to the CBI/SBI instructions, yes).

Now, this sounds like a reason. You didn't give single one, Cliff!

Actually, we don't necessarily need to follow Atmel on this. We could define all the headers with bitmasks, then provide a conversion macro for assembly use. Modern computers are up to the task, as dl8dtl always says ;).

Honestly however, the (1 << x) construct doesn't bother me much - in fact I've grown accustomed to it. I think I'd find code such as:

PORTD |= PD2;

Disconcerting if the above was applied.

- Dean :twisted:

Make Atmel Studio better with my free extensions. Open source and feedback welcome!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

> Actually, we don't necessarily need to follow Atmel on this.

It would simply make us artificially incompatible with any other
C code written for the AVR.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

clawson wrote:
Jörg,

I think the last time I looked at an Ada program was about 23 years ago! I'd just be interested to see some examples that are compilable with avr-gcc. Presumably there are some test cases somewhere that are used for regression testing the compiler if nothing else?

Cliff

PS Actually a Google lead me to this:

http://avr-ada.sourceforge.net/e...

with a rather familiar name at the top!

It's on my todo list to add avr-ada to the WinAVR package. The latest issue is that for me to build Ada in GCC, I really need to have a native GCC 4.x compiler, which in my case means a GCC 4.x compiler for MinGW. Currently the MinGW group does not have this available, I would have to go build my own, Rolf gave me directions, I haven't had time, yada, yada, yada. But, hey! I'll get there. :)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dl8dtl wrote:
It would simply make us artificially incompatible with any other
C code written for the AVR.

Ah, so you mean that this is so already on the "older" compilers, including the "original" IAR (this was the first one, right?)?

Embedded Dreams
One day, knowledge will replace money.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Cliff:

> PS Actually a Google lead me to this:

> http://avr-ada.sourceforge.net/e...

> with a rather familiar name at the top!

Oh, and it looks quite nice. ;-)

Maybe some day I'll learn Ada, too...

Nuno:

> Ah, so you mean that this is so already on the "older" compilers,
> including the "original" IAR (this was the first one, right?)?

I think IAR was the first C compiler for the AVR, yes, as the IAR
folks have been involved in the processor design (which we now all
benefit from, btw.). And yes, all known AVR C compilers do it that
way.

Jörg Wunsch

Please don't send me PMs, use email if you want to approach me personally.