-         

Ergebnis 1 bis 6 von 6

Thema: Was bringt _BV()

  1. #1
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    30.09.2004
    Ort
    In der Nähe von Esslingen am Neckar
    Beiträge
    706

    Was bringt _BV()

    Anzeige

    Hi Leuts,
    hab ne simple Frage!!:
    oft werden Bits mit _BV() gesetzt! zb:
    Code:
    UCSRB = _BV(RXCIE) | _BV(TXCIE) | _BV(RXEN) | _BV(TXEN);
    man kann die Bits doch auch so setzen!:
    Code:
    UCSRB = (1<<RXEN)|(1<<TXEN)|(1<<RXCIE)|(1<<TXCIE);
    was ist besser? ist _BV(); ne Bibliotheksfunktion?
    Gruß Michi

  2. #2
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    04.11.2003
    Ort
    Dresden
    Alter
    53
    Beiträge
    409
    Hallo Michael,

    rein codemäßig bringen beide Varianten keinen Unterschied.

    Aus

    UCSRB = _BV(RXCIE) | _BV(TXCIE) | _BV(RXEN) | _BV(TXEN);

    wird

    ldi r24,lo8(-40)
    out 42-0x20,r24

    und aus der (1<<x) Variante genauso. Das heißt beide Konstantenausdrücke werden vom Compiler aufgelöst und dementsprechend richtig ausgerechnet übersetzt.

    Auch beim Zugriff auf Ports macht es keinen Unterschied welche Variante benutzt wird.
    Sowohl PORTB |= _BV(PB2); als auch PORTB |= 1<<PB2;
    wird zu: sbi 56-0x20,2

    Viele Grüße
    Jörg

  3. #3
    Erfahrener Benutzer Robotik Einstein Avatar von Felix G
    Registriert seit
    29.06.2004
    Ort
    49°32'N 8°40'E
    Alter
    34
    Beiträge
    1.780
    prinzipiell sind die Varianten natürlich gleichwertig,
    aber ich bevorzuge dennoch die (1 << x) Variante, da diese Compilerunabhängig ist.
    So viele Treppen und so wenig Zeit!

  4. #4
    Erfahrener Benutzer Robotik Einstein Avatar von SprinterSB
    Registriert seit
    09.06.2005
    Ort
    An der Saar
    Beiträge
    2.801
    Zitat Zitat von Joerg
    Das heißt beide Konstantenausdrücke werden vom Compiler aufgelöst und dementsprechend richtig ausgerechnet übersetzt.
    Zitat Zitat von Felix G
    prinzipiell sind die Varianten natürlich gleichwertig,
    aber ich bevorzuge dennoch die (1 << x) Variante, da diese Compilerunabhängig ist.
    Die Ausdrücke sind nicht nur gleichwertig, sondern ein und dasselbe. _BV() wird nicht vom Compiler ausgewertet, sondern ist lediglich ein Macro und wird damit vom Präprozessor aufgelöst.

    Zitat Zitat von ./avr/include/avr/sfr_defs.h
    #define _BV(bit) (1 << (bit))
    avr/sfr_defs.h wird von avr/io.h includet, so daß man es eh dabei hat.

    In sfr_defs.h werden auch Sachen defined wie
    bit_is_clear(sfr, bit)
    loop_until_bit_is_set(sfr, bit)
    etc...

    Mit der Compilerabhängigkeit ist das so ne Sache.
    Hardwarenahe Dinge werden durch verschiedenen Compiler meist verschieden ausgedrückt, wie zB die Definition von Interrupts und Signals. Alles andere hat mit dem Compiler eigentlich nix zu tun. Jedenfalls lassen sich Makros wie bit_is_clear() leichter portieren als wenn man immer selber hinschreibt, zu was das Makro expandiert. Beim Compilerumstieg braucht man dann nämlich nur eine Zeile im Header anzufassen und nicht die ganze Quelle nachzukontrollieren.
    Disclaimer: none. Sue me.

  5. #5
    Erfahrener Benutzer Robotik Einstein Avatar von Felix G
    Registriert seit
    29.06.2004
    Ort
    49°32'N 8°40'E
    Alter
    34
    Beiträge
    1.780
    Zitat Zitat von SprinterSB
    Jedenfalls lassen sich Makros wie bit_is_clear() leichter portieren als wenn man immer selber hinschreibt, zu was das Makro expandiert. Beim Compilerumstieg braucht man dann nämlich nur eine Zeile im Header anzufassen und nicht die ganze Quelle nachzukontrollieren.
    Wenn man aber keine Makros verwendet muss man garnichts nachkontrollieren, denn Standard-C versteht jeder Compiler.
    So viele Treppen und so wenig Zeit!

  6. #6
    Erfahrener Benutzer Roboter Experte
    Registriert seit
    30.09.2004
    Ort
    In der Nähe von Esslingen am Neckar
    Beiträge
    706
    Hi,
    Danke!! Danke!!
    Mal schauen was ich so verwende! Bisher hab ich immer die (1<<PD5)
    Variante benutzt!
    Gruß Michi

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •