Attiny85 Pin als Eingang

ich vergleiche Pinb3 ob es high ist.

Danke, aber verstehe diese ganzen doppelten Namen noch nicht...

wieso kann ich dann nicht "if (PINB & 1)". Wieso muss ich erst die 1 an 
diese Stelle verschieben und dann vergleichen?

Und wieso liegt er an der 8. Stelle? Pinb3 liegt an der 3. Stelle im 
Register PINB. Was verstehe ich nicht?

tinyy schrieb:
> Und wieso liegt er an der 8. Stelle? Pinb3 liegt an der 3. Stelle
> im Register PINB. Was verstehe ich nicht?

Wie kommst Du auf die 8 Stelle :-).
Binär: 0000 0100 = 8 Dezimal.

Grüsse,
René

tinyy schrieb:
> Was verstehe ich nicht?

Das Binärsystem.

Der Pin 3 liegt nicht an 8. Stelle, sondern das Bit an Stelle 3 hat den 
Zahlenwert 8.
0000 = 0
0001 = 1
0010 = 2
0100 = 4
1000 = 8

Jetzt klarer? :-)

Sorry, eine Stelle verrutscht.

:/)
Grüsse,
René

René H. schrieb:
> Binär: 0000 0100.

Das wäre aber 0x4.

René H. schrieb:
> Binär: 0000 0100 = 8 Dezimal.

Falsch. Das ist 4!

tinyy schrieb:
> was haeb ich falsch gemacht?

Einiges!

Du meinst vermutlich sowas:

1

int main(void)

2

{

3

  DDRB  |=  (1 << DDB4);  // B4: output;

4

  DDRB  &= ~(0 << DDB3);  // B3: Input

5

6

  PORTB  |=  (1 << PB4);  // PB4 High

7

  PORTB  |=  (1 << PB3);  // PB3 Pullup on

8

9

  while (1) 

10

  {

11

    if (PINB & (1<<PB3))

12

    {

13

      PINB =  ( 1 << PB4 ); // Toggle Pin

14

    }

15

    else

16

    {

17

      PORTB &= ~(1 << PB4); // set low

18

    }

19

  }  

20

  return 0;

21

}

tinyy schrieb:
> wieso kann ich dann nicht "if (PINB & 1)". Wieso muss ich erst die 1 an
> diese Stelle verschieben und dann vergleichen?

> if (PINB & 1)
entspricht
> if (PINB & 0b000001)
Du willst aber
> if (PINB & (1<<PB3))
Welches zu diesem wird
> if (PINB &  0b001000)

Du siehst den Unterschied?

Arduino Fanboy D. schrieb:
> if (PINB & (1<<PB3))

Warum jetzt mit PB3 statt PINB3 vergleichen? Ich komme ziemlich 
Durcheinander Mit registernamen und Pinnamen usw.

Also muss ich mir das so vorstellen:

1

PINB = 0000 1000 mit

2

(1<<PB3)= 0000 1000

Und ich vergleiche Bitweise.

tinyy schrieb:
> Und ich vergleiche Bitweise.

Richtig.
Du mußt schauen, ob der vom PINB gelesene Wert an der dritten Stelle 
eine 1 hat.

tinyy schrieb:
> Warum jetzt mit PB3 statt PINB3 vergleichen?
PINB3 ist voll korrekt.
Nimm das.

> if (PINB3==1)
Hier hast du es allerdings falsch verwendet.

Lothar M. schrieb:
> Du könntest auch PD3 oder PINC3 nehmen.
> Es ist egal. Alle haben den numerischen Wert 3.

Ist das zu 100% sicher? Bei den Ports vielleicht ...
Ich würde mich nicht darauf verlassen und bei dem Tiny85, der keinen 
Port C oder D besitzt, wird der Compiler beide in der io.h eh nicht 
finden. Außerdem: was soll ich denken, wenn ich ein für den Tiny85 
geschriebenes Programm sehe und dort von PORTC, PINC und DDRC die Rede 
ist?

Außerdem, ähnliche Definitionen und Vorgehensweisen nutzt man ja auch 
bei den  Registern und da passt es häufiger mal nicht.
Es empfiehlt sich, die Schreibweise

1

  PORTB  |=  (1 << PB4);  // Ausgang B4 auf HIGH setzten

2

  PORTB  &= ~(1 << PB3);  // Ausgang B3 auf LOW setzen

anzugewöhnen und mal durchzudenken.

@Arduino Funboy
Das hier ist es nicht ganz - stell dir vor, B3 war vorher Ausgang :-):
  DDRB  &= ~(0 << DDB3);  // B3: Input
            ^^^

Arduino Fanboy D. schrieb:
> DDRB  &= ~(0 << DDB3);  // B3: Input
Hasste recht!

Besser:
 DDRB  &= ~(1 << DDB3);  // B3: Input

Macht zum Glück nichts aus, da INPUT der  default nach dem Reset.

Sind übrigens noch mehr Unsauberkeiten drin!
> PORTB  |=  (1 << PB4);
Obwohl ich es hier mit PB4 tute, ist es dennoch nicht ganz korrekt.
Besser:
 PORTB  |=  (1 << PORTB4);

Meine übliche Schreibweise wäre eher:
 PORTB  |=  _BV(PB4);
Oder:
 led.setHigh();


Das korrigierte Gesamtprogramm sieht dann so aus:

1

int main(void)

2

{

3

  DDRB  |=  (1 << DDB4);  // B4: output;

4

  DDRB  &= ~(1 << DDB3);  // B3: Input

5

6

  PORTB  |=  (1 << PORTB4);  // PB4 High

7

  PORTB  |=  (1 << PORTB3);  // PB3 Pullup on.. 

8

9

  while (1) 

10

  {

11

    if (PINB & (1<<PINB3))

12

    {

13

      PINB = ( 1 << PINB4 ); // Toggle Pin

14

    }

15

    else

16

    {

17

      PORTB &= ~(1 << PORTB4); // set low

18

    }

19

  }  

20

  return 0;

21

}

HildeK schrieb:
> Ist das zu 100% sicher? Bei den Ports vielleicht ...

Ich bin mir sicher, dass das bei allen AVRs der Fall ist, welche mir 
bisher unter die Finger gekommen sind.
Und von irgend einer Ausnahme habe ich noch nicht gehört.
PORTB4 und DDB4 kommen in meinen Programmen nicht vor.
Wenn, dann PB4.

Es ist ein semantischer Unterschied.
Der Wert ist identisch. Das weißt du doch auch, oder?

Merke, es ist der Wunsch des TE es so zu machen!
Nicht meiner.

tinyy schrieb:
> Warum jetzt mit PB3 statt PINB3 vergleichen? Ich komme ziemlich
> Durcheinander Mit registernamen und Pinnamen usw.

Arduino Fanboy D. schrieb:
> Macht zum Glück nichts aus, da INPUT der  default nach dem Reset.

Deshalb mein Hinweis:

HildeK schrieb:
> stell dir vor, B3 war vorher Ausgang :-)

HildeK schrieb:
> Arduino Fanboy D. schrieb:
>> Macht zum Glück nichts aus, da INPUT der  default nach dem Reset.
>
> Deshalb mein Hinweis:
>
> HildeK schrieb:
>> stell dir vor, B3 war vorher Ausgang :-)
Wo du Wahr hast, da hast du Wahr.

Mehr, als dir zustimmen, kann ich nicht!
Hmmm... doch...
Danke, dass du mich auf den Lapsus aufmerksam gemacht hast.

Rufus Τ. F. schrieb:
> Und für welche Verwendung sind Deiner Ansicht nach die Symbole PB0 bis
> PB7 gedacht?
Wofür sind deiner Ansicht nach die Symbole PORTB4, PINB4 und DDB4 
gedacht?

Tipp:
Ich heiße nicht Atmel.
Also ist es doch recht unwahrscheinlich, das ich weiß, wie Atmel denkt, 
gedacht hat.

Rufus Τ. F. schrieb:
> Arduino Fanboy D. schrieb:
>> Wofür sind deiner Ansicht nach die Symbole PORTB4, PINB4 und DDB4
>> gedacht?
>
> Magst Du bitte meine Frage beantworten?

Ich kann meine Antwort gerne nochmal in anderen Worten wiederholen.
Ich weiß nicht GENAU, was Atmel sich dabei gedacht hat!
Denn ich bin nicht Atmel

Wenn du mit der Antwort nicht zufrieden bist, dann ist und bleibt das 
dein Problem.

Arduino Fanboy D. schrieb:
> Wofür sind deiner Ansicht nach die Symbole PORTB4, PINB4 und DDB4
> gedacht?

Ist PORTBx überhaupt definiert?
In der iotnx5.h sehe ich nur PINBx, DDRBx, PBx. Zumindest in meiner 
WINAVR-20100110.

1

#define PINB    _SFR_IO8(0x16)

2

#define PINB5   5

3

#define PINB4   4

4

.

5

.

6

#define DDRB    _SFR_IO8(0x17)

7

#define DDB5    5

8

.

9

.

10

#define PORTB   _SFR_IO8(0x18)

11

#define PB5     5

12

.

13

.

Ich wüsste auch nicht, was man außer den drei Definitionen unterscheiden 
müsste.

HildeK schrieb:
> Ist PORTBx überhaupt definiert?

Ja!

HildeK schrieb:
> Zumindest in meiner
> WINAVR-20100110.
Ich nutze die mit Arduino gelieferte ToolChain.
Sollte also aktueller sein.

Dort findet sich in io.h ein #include <avr/portpins.h>

Und wenn du in diese Datei schaust, findest du auch die Definition von 
PORTBx

@Rufus
Warum das so organisiert ist?
KA, ich bin nicht Atmel!
(vermutlich hätte ich das anders gebaut)

Rufus Τ. F. schrieb:
> die ich

Projiziere deine Vorstellung von der Welt, auf die Welt!
Und du wirst deine Vorstellungen bestätigt sehen.

Dann sind sie auch richtig, denn bestätigt.
Oder?

----

Interessante Sache!
Du fragst mich , was die Atmels sich dabei gedacht haben...
Kommst dann mit so einem Wackelpudding an Erklärungen, wie du die Welt 
siehst.

Rufus Τ. F. schrieb:
> ich
> deswegen schon getrost ignorieren würde.
Die Datei wird eingebunden, egal ob du sie ignorieren möchtest oder 
nicht!

Die Welt wird einfacher, leichter zu bewerten, zu beurteilen, wenn 
anfängt Dinge auszublenden, zu ignorieren.
Nur leider werden die logischen Schlüsse, welche man aus diesen 
Vereinfachungen ableitet, mit zunehmender Vereinfachung, immer 
irrationaler.

Von dir hätte ich eine so reduzierte Weltsicht nicht erwartet.
Aber offensichtlich scheinst du dazu zu neigen.

Hi

Das ist eigentlich ganz einfach: In der Anfangszeit hat Atmel die 
Bezeichnung, z.B. Port B (PB7..PB0)(beim AT90S4414) benutzt. Später 
wurde die Bezeichnung PORT3 eingeführt. Und aus Kompatibilitätsgründen 
werden damit beide Bezeichnungen gültig.

MfG Spess

Rufus Τ. F. schrieb:
> Du bist jetzt sehr gründlich nicht auf meine Argumentation eingegangen.

Rufus Τ. F. schrieb:
> Du meinst, daraus ableiten zu können,
Darauf bin ich eingegangen!
OK, vielleicht hast du die Antwort nicht verstanden, kann ja sein ...

Dann noch mal klarer:
Ich werde mich nicht deiner Projektion anpassen.


Übrigens:
Bisher hast du mich noch nicht nach "meiner" Meinung gefragt!
Nur, was sich die Atmel Leute dabei gedacht haben mögen.

Ich glaube übrigens nicht, dass sie die Datei portpins.h 
ausliefern/einbinden, damit man sie ignoriert.
Das kann man natürlich tun, ist aber sicherlich nicht der Zweck.

Rufus Τ. F. schrieb:
> Ist eine Diskussion mit Dir tatsächlich komplett sinnlos?
Wenn dir diese Projektion zusagt, und du sie anwendest, dich dem 
entsprechend verhältst, dann wird das wohl so sein!
Deine Entscheidung.

Rufus Τ. F. schrieb:
> Und warum gibt es dann keine korrespondierende Datei für DDRx und PINx?

Deine provokanten und inhaltsleeren Fragen erinnern mich (verzeihe mir 
bitte den Vergleich) ganz stark an des Kurt Bindl seine Fragen.

Ich ziehe mal ein paar Zeilen aus dem obigen Programm raus:

1

DDRB  &= ~(1 << DDB3);

2

PORTB &= ~(1 << PORTB4);

3

PINB = ( 1 << PINB4 );

Syntax, ist ok
Semantik ist ok
Programm ist damit korrekt lauffähig.

Bei mir würde das eher so aussehen
(wobei es eigentlich nicht wichtig ist, wie ICH das tue, sondern eher 
warum)

1

DDRB  &= ~(1 << PB3);

2

PORTB &= ~(1 << PB4);

3

PINB = ( 1 << PB4);

Syntax, ist ok
Semantik ist brauchbar, da man erkennen kann, was gemeint ist.
Programm ist damit korrekt lauffähig.



Dann setze ich mal 2 Zeilen gegeneinander:

1

PORTB &= ~(1 << PORTB4);

2

PORTB &= ~(1 << PB4);

Dort ist die Semantik in der ersten Zeile eine Nuance klarer.
Etwas konsequenter umgesetzt.
Ein mehr an Klarheit ist doch immer besser, oder?

Joachim B. schrieb:
> e.i. einfach ignorieren.

Wenn der Rufus mich für einen Idioten hält, dann ist der bei mir genau 
an der richtigen Adresse.

Arduino Fanboy D. schrieb:
> Ich nutze die mit Arduino gelieferte ToolChain.
> Sollte also aktueller sein.
>
> Dort findet sich in io.h ein #include <avr/portpins.h>
>
> Und wenn du in diese Datei schaust, findest du auch die Definition von
> PORTBx

Danke. Ja, ist in dem 'alten' WINAVR auch enthalten, hatte ich bisher 
nur nicht gesehen:

1

#if defined(PB4) && !defined(PORTB4)

2

#  define PORTB4 PB4

3

#elif defined(PORTB4) && !defined(PB4)

4

#  define PB4 PORTB4

5

#endif

Damit akzeptiert deinen Quelltext auch mein Compiler und umgekehrt - die 
Portabilität wäre auch das Wichtigste.

Und dann gibt es auch noch generische Definitionen (gekürzt):

1

/* Define Generic PORTn, DDn, and PINn values. */

2

3

/* Port Data Register (generic) */

4

#define    PORT7        7

5

#define    PORT6        6

6

.

7

.

8

9

/* Port Data Direction Register (generic) */

10

#define    DD7          7

11

#define    DD6          6

12

.

13

.

14

15

/* Port Input Pins (generic) */

16

#define    PIN7         7

17

#define    PIN6         6

18

.

19

.

Demnach deutet alles darauf hin, dass deine Erfahrung
Arduino Fanboy D. schrieb:
> HildeK schrieb:
>> Ist das zu 100% sicher? Bei den Ports vielleicht ...
>
> Ich bin mir sicher, dass das bei allen AVRs der Fall ist, welche mir
> bisher unter die Finger gekommen sind.
sogar Fakt für alle ist, sonst würde der Teil wenig sinnvoll sein.

Demnach geht genauso

1

DDRB  &= ~(1 << DD3);

2

PORTB &= ~(1 << PORT4);   

3

PINB = ( 1 << PIN4 );

Scheint für jeden Gusto was vorhanden zu sein. Ich nehme immer, weil so 
mit dem Thema begonnen (z.B. im Forumstutorial):

1

DDRB  &= ~(1 << DDB3);

2

PORTB &= ~(1 << PB4);   // so ist im DB auch der Pin gekennzeichnet

3

PINB = ( 1 << PINB4 );

Die Semantik ist imho dann am klarsten, wenn man das, was man 
programmiert hat, auch nach einiger Zeit noch versteht :-). Ich 
persönlich bin nicht darauf angewiesen, dass es andere auch genauso gut 
verstehen, weil ich nur eine private Anwendungen habe.

Nachtrag:
In letzter Zeit bevorzuge ich die über die sbit.h von Peter D. 
vorgestellte Variante.
Ein einfaches Programm sieht dann so aus und ist noch viel 
verständlicher und mir viel sympathischer:

1

#include "sbit.h"  // (c) Peter Dannegger

2

3

#define LED0      PORT_B0

4

#define LED0_oe    DDR_B0

5

#define LED1       PORT_B1

6

#define LED1_oe     DDR_B1

7

#define INPUT     PIN_B2

8

#define INPUT_oe  DDR_B2

9

10

#define EIN  0      // zum LEDs schalten beim STK500

11

#define AUS  1   

12

#define HIGH 1    // für Inputs

13

#define LOW  0

14

15

int main()

16

{

17

  LED0_oe  = 1;    // Auf Output schalten

18

  LED1_oe  = 1;

19

  INPUT_oe = 0;    // auf Input schalten

20

21

  LED0 = AUS;      // LED0-Port auf aus

22

  LED1 = EIN;     // LED1-Port auf ein

23

24

  if(LED1 == EIN) LED0 = EIN;  // auch Abfragen sind möglich

25

  if(LED0 == EIN) LED1 = AUS;

26

27

  LED0  ^= 1;         // Toggle

28

  PORTB ^= (1<<PB0);  // entspricht dieser bekannten Version

29

  PINB   = (1<<PB0);  // oder auch der

30

31

  LED1 ^= 1;  // Toggle

32

33

  if (INPUT == HIGH) LED1 ^= 1;  // Input-Abfrage

34

  if (INPUT == LOW)  LED0 ^= 1;

35

36

  while(1)  asm("NOP");  // nur wegen Simulator

37

}

Hat was für die Lesbarkeit, oder?

HildeK schrieb:
> Hat was für die Lesbarkeit, oder?
Ja.
Wäre ich (tiefer) in der C Welt verhaftet, würde ich mir sicherlich 
davon was abschauen.
Es Assimilieren.