Unterschied zwischen (PIND & 0b00000010) == 0b00000010 und PIND == 0b00000010

[Zwei_Fragende (Gast)]

Hallo!
Wir haben folgendes Problem:

Warum funktioniert
if ((PIND & 0b00000010) == 0b00000010) richtig und
if (PIND == 0b00000010) nicht?
(zweites if reagiert wie PIND = 0b0000010)

rein "logisch" betrachtet ist ja im richtigen fall PIND & 0b00000010 
gleich dem erwarteten. warum können wir es dann nicht direkt 
vergleichen?


schönen sonntag und vielen dank für die antwort

[Martin (Gast)]

... schönen sonntag und vielen dank für die antwort ...

Gern geschehen: aber für welche Antwort?

[Peter D. (peda)]

Einmal testest Du nur einen Pin und das andere mal alle 8.


Peter

[andz (Gast)]

Mal auf deutsch:

das "& 0b00000010" maskiert, so wird nur das zweite Bit verglichen, weil 
vor dem vergleich alle anderen Bits auf 0 gesetzt werden.
Würde man das nicht tun, so würde der Vergleich nicht funktionieren wenn 
eines der anderen Bits auch auf 1 wäre, da man die ja auf 0 vergleicht.

Gruß

[Zwei_Fragende (Gast)]

angenommen die if-abfragen schalten eine led.
warum leuchtet im zweiten fall immer die led, während im ersten alles 
erwartungsgemäß funktioniert?

[Ohforf S. (ohforf)]

Zwei_Fragende schrieb:
> angenommen die if-abfragen schalten eine led.
> warum leuchtet im zweiten fall immer die led, während im ersten alles
> erwartungsgemäß funktioniert?

Ich vermute, dass offene Eingänge als '1' gelesen werden.

[Zwei_Fragende (Gast)]

wenn die offenen eingänge als 1 erkannt werden, müsste
PIND so aussehen: 0b11111111
das wäre ungleich Ob00000010
dh. die led dürfte nicht leuchten

[Michael H. (michael_h45)]

> If ((PIND & 0b00000010) == 0b00000010) richtig
sei PIND mal 0b10110001. dein IF macht also folgendes damit:
           & 0b00000010
           = 0b00000000 (-> FALSE)

sei PIND mal 0b10110011. dein IF macht also folgendes damit:
           & 0b00000010
           = 0b00000010 (-> TRUE)


> if (PIND == 0b00000010) nicht?
sei PIND mal 0b10110001. dein IF macht also folgendes damit:
          == 0b00000010
          -> FALSE

sei PIND mal 0b10110011. dein IF macht also folgendes damit:
          == 0b00000010
          -> FALSE

alles klar?

[Zwei_Fragende (Gast)]

Michael H. schrieb:
> alles klar?

nein!
wenn das if false wäre dürfte die LED nicht leuchten, tut sie aber.
warum?

[Michael H. (michael_h45)]

Weil die LEDs auf dem STK500 invertiert sind?
0 == led leuchtet
1 == led aus.

[grunzi (Gast)]

welche led denn? du / ihr habt doch von gar keiner geschrieben

also ich finde es ganz logisch, dass
if(a==b) und if(a&0b00000001 == b) 2 paar schuhe sind. michael hat sich 
die mühe gemacht, ein beispiel zu basteln. habs jetzt nicht überprüft, 
aber mit mit & maskierst du doch die sache.

omas sind charakterisiert durch art der schuhe, rock und haarfarbe.

omaeins hat grüne schuhe und nen gelben rock an.

if(omaeins == oma mit grünen schuhen und gelbem rock und grünen haaren)
liefert falsch.

und

if(omaeins & maske für nur die schuhpartie) == grüne schuhe)
liefert richtig

mhm hat das jetzt geholfen?

[Zwei_Fragende (Gast)]

es hat vermutlich nicht mit dem stk500 zu tun, denn am port selbst liegt 
spannung an

[Michael H. (michael_h45)]

was, wie? port, led, spannung???
wie soll denn hier jemand was verstehen, der nicht vor eurem aufbau 
sitzt?

also, jetz mal raus mit einer klaren aufbaubeschreibung.

[g457 (Gast)]

Ihr zwei, zeigt doch mal den kompletten(!) Code, ggf. als Anhang(!). 
Irgendwo(anders) habt ihr da einen Wurm drin.

[Zwei_Fragende (Gast)]

aufbau: stk500
verbindung von sw1 -> pd1 und led1 -> pb1
quelltext wie folgt

#include <avr/io.h>

int main()
{
  DDRB = 0b00000010; 
  PIND = 0b00000000;
  PORTD = 0b0000010;

  int i = 1;
  while (i == 1)
  {
    if (PIND == 0b00000010) //Bei diesem Statement leuchtet die LED immer
    {
      PORTB = 0b00000010;

    }
    else 
    {
      PORTB = 0b00000000;

    }
  };

  return 0;
}

[Michael H. (michael_h45)]

Michael H. schrieb:
> Weil die LEDs auf dem STK500 invertiert sind?
> 0 == led leuchtet
> 1 == led aus.

...

[Zwei_Fragende (Gast)]

die frage ist, warum wir dann spannung am pin selbst gemessen haben? 
(oder messfehler?)

bzw. warum funktioniert der direkte vergleich dann nicht?

[Michael H. (michael_h45)]

Zwei_Fragende schrieb:
> bzw. warum funktioniert der direkte vergleich dann nicht?
Beitrag "Re: Unterschied zwischen (PIND & 0b00000010) == 0b00000010 und PIND == 0b00000010"
Das mal nochmal in aller Ruhe durchlesen.
Und das hier kann auch nicht schaden: Bitmanipulation

[g457 (Gast)]

> aufbau: stk500

Randnotiz (wurde schon darauf hingewiesen): beim STK500 sind die LEDs 
active-low.

>    if (PIND == 0b00000010) //Bei diesem Statement leuchtet die LED immer
>    {
>        PORTB = 0b00000010;
>    }
>    else
>    {
>        PORTB = 0b00000000;
>    }

Die LED leuchtet immer, also wird immer der else(!)-Zweig ausgeführt. 
Das wird er nur, wenn die Bedingung 'PIND == 0b00000010' immer falsch 
ist. Wenn ich das richtig interpretiert hab, dann habt ihr D.1 auf Input 
mit Pullup gesetzt, der Rest vom PortD ist Input ohne Pullup. Ich 
vermute jetzt mal ganz wild, dass ihr den Rest vom PortD nicht auf ein 
festes Niveau gezogen habt (per Pullup/-down), also ist der Rest vom 
PortD floating ('mal so mal so').

Ergo wird PIND immer 'irgendwas' liefern, mal 0b101001x1 (x ist der 
Zustand des Tasters), mal 0b001100x0, und mal irgendwas anderes. 
Vielleicht auch irgendwall mal 0b00000010. Aber eben nur vielleicht. 
Deswegen wird obige Bedingung (fast) immer falsch sein.

Aber eigentlich interessiert ihr euch bei der Abfrage ja nur für den 
einen Eingang, den einen an dem der Taster hängt. Das kann man dann auch 
ausdrücklich so formulieren:
    if (PIND & 0b00000010)
    [Rest wie gehabt]
Das maskiert alle uninteressanten Eingänge aus. Übrig bleibt genau der 
Zustand vom Taster, nämlich genau '0b0000010'/true oder 
'0b00000000'/false. Und sonst nix.

Gibt übrigens auch einen schönen Artikel [1] dazu (am besten den Rest 
auch noch gleich lesen ;-)

HTH

[1] 
http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Eing.C3.A4nge_.28Wie_kommen_Signale_in_den_.C2.B5C.29