Byte per #define vorinitialisieren

[Johannes (menschenskind)]

Moin

Habe hier 2 RGB LEDs und wollte diese über ein Define mit einer Farbe 
ansteuern.
Da ich es übersichtlicher gestalten wollte, habe ich es jeweils mit 
diesen beiden Wegen probiert:

#define LED_1 (1<<P4OUT3)|(0<<P4OUT2)|(1<<P4OUT1)
#define LED_2 ~P4OUT6|P4OUT5|P4OUT4

Doch leider ist bei der Ausgabe auf

LED_PORT = (LED_1 | LED_2);

der komplette Port auf 0xFF

Wenn ich die defines nun mit #define LED_1 0x0A und 0x30 mache, 
funktioniert es.

Ich dachte ich hätte Bitmanipulation verstanden...

Danke für eure Hilfe! :)

[Stephan B. (matrixstorm)]

Bitte Grundlagen lesen und verstehen!

Deine LED_2 ist flasch definiert. Dort werden nur die Bitpositionen aber 
nicht deren Werte (Potenzen) definiert und negiert.

MfG

[Thomas E. (thomase)]

Johannes Hofmann schrieb:

Warum machst du das denn einmal so...
> [c]#define LED_1 (1<<P4OUT3)|(0<<P4OUT2)|(1<<P4OUT1)

... und beim anderen mal so?
> #define LED_2 ~P4OUT6|P4OUT5|P4OUT4

Weil es egal ist? Oder ist eins davon falsch?

mfg.

[Tobias L. (murxwitz)]

evtl. mal testweise zusätzliche Klammern setzen
P4OUTX richtig definiert?

edit: zu langsam

und ja bei LED_2 fehlt was

[Johannes (menschenskind)]

Grundlagen sind ja nicht unbekannt, das Verständnis ergibt sich bei mir 
aber besser durch Anwendung.

Ok und warum funkioniert das bei LED_1 nicht?
Es sollte ja dann 0b00001010 sein.

2 Varianten, weil ich ausprobieren möchte was geht und was nicht, auch 
um meinen Code übersichtlicher zu machen.
Ports usw. alles richtig. Leuchtet ja ;)

[Stephan B. (matrixstorm)]

1.) NOT bindet staerker als UND bzw. ODER
2.) UND bindet staerker als ODER
3.) im Zweifel Klammern verwenden!

(4.) MAKROS MAKROS MAKROS!)

1 und 2 sind wie Punkt vor Strich - nur fuer Logik

vermutlich willst du folgendes:

#define LED_1 ((1<<P4OUT3)|(0<<P4OUT2)|(1<<P4OUT1))
#define LED_2 (~((1<<P4OUT6)|(1<<P4OUT5)|(1<<P4OUT4)))

bzw.:

#define LED_1 (_BV(P4OUT3)|_BV(P4OUT1))
#define LED_2 (~(_BV(P4OUT6)|_BV(P4OUT5)|_BV(P4OUT4)))

MfG

[Johannes (menschenskind)]

Muss noch mal nachhaken, denn im Moment ist es so dass

LED_PORT = (0<<P4OUT3) | (0<<P4OUT2) | (1<<P4OUT1);

eine andere Farbe als

LED_PORT = 0x02;

ergibt.

Meiner Meinung nach müsste doch beim 1. Ausdruck 0000 0010 rauskommen, 
aber leider ist es 0000 0100.

Was ist an der Bitverschiebung falsch?

Weil in der Chipspezifischen Headerdatei ist das ja so korrekt 
angegeben:

enum {
  P4OUT0          = 0x0001,
  P4OUT1          = 0x0002,
  P4OUT2          = 0x0004,
  P4OUT3          = 0x0008,
  P4OUT4          = 0x0010,
  P4OUT5          = 0x0020,
  P4OUT6          = 0x0040,
  P4OUT7          = 0x0080
};

[oigh (Gast)]

1<<2 == 0b100

[Irgend ein Gast (Gast)]

Du nimmst den Wert 0b0001 und schiebst dies zwei Stellen (P4OUT1=0x0002) 
nach rechts.
Also aus 0b0001 wird 0b0100:-)

[Stephan B. (matrixstorm)]

Uh - enums!

mach lieber #define.

Und ja, der Fehler is offensichtlich:

Johannes Hofmann schrieb:
> P4OUT1          = 0x0002,

P4OUT1 markiert das 2. Bit - also 2^2 (2 hoch 2) = 4 = 0b100.

Bitpositionen werden von "0" beginnend gezaehlt. Da die erste Stelle 
einer Zahl, die "Einer" sind. Im Dualen also 2^0.

MfG Stephan

[Johannes (menschenskind)]

Na das mit dem enum ist direkt aus der Headerdatei vom MSP zitiert.

Aha, also multiplizieren anstatt schieben.
Hatte das bloß in meinem Kopf verdreht, weil in einer anderen 
Headerdatei
BIT0, BIT1 usw. direkt mit deren Zahlenwerten definiert wurden.
Und so hab ich das einfach "portiert"...