Attiny85 Pin als Eingang

[tinyy (Gast)]

Ich will den PinB3 auf input schalten, und abfragen wenn er auf high ist 
soll PortB4 toggeln und ansonsten ausgehen. Aber die LED(PB4) ist immer 
an, was haeb ich falsch gemacht?

int main(void)
{
  DDRB  |=  ((1<<DDB4) | (0 << DDB3)); // B4: output; B3: Input
  PORTB  |=  ((1<<PB4) | (1<<PB3)); 
  
    while (1) 
    {
   if (PINB3==1)
   {
    // PORTB |= (1<<PB4);
   PORTB ^= ( 1 << PB4 );
   }
   else
   {
     PORTB &= ~(1<<PB4);
   }

[Rufus Τ. F. (rufus)]

tinyy schrieb:
> if (PINB3==1)

Was ist das?

[tinyy (Gast)]

ich vergleiche Pinb3 ob es high ist.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

tinyy schrieb:
> ich vergleiche Pinb3 ob es high ist.
Nein, du vergleicht, ob die Definition von PINB3 den Wert 1 hat. Und mit 
an Sicherheit grenzender Wahrscheinlichkeit ist das nicht der Fall.

Sieh dir mal an, wie andere das machen...

Etwa so:

   if (PINB & (1<<PB3))
   {
    // PORTB |= (1<<PB4);

[Rufus Τ. F. (rufus)]

Das willst Du, Du tust es aber nicht.

So dürftest Du mehr Chancen haben:

if (PINB & (1 << PB3))
...

[tinyy (Gast)]

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?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

tinyy schrieb:
> wieso kann ich dann nicht "if (PINB & 1)".
Damit würdest du Pin B0 abfragen.

> Wieso muss ich erst die 1 an
> diese Stelle verschieben und dann vergleichen?
Musst du nicht. Du kannst für die Abfrage des Pin B3 auch so schreiben:

   if (PINB & 8)
   ...

Oder so:

   if (PINB & 0x08)
   ...

Oder sogar so:

   if (PINB & 010)
   ...

Dann musst du eben gut Kopfrechen können, um aus den beliebigen 
Zahlensystem den PB3 herauszuknobeln...

[tinyy (Gast)]

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

[René H. (Gast)]

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é

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

tinyy schrieb:
> Was verstehe ich nicht?
Zahlensysteme...
8 dezimal = 8 hexadezimal = 10 oktal = 00001000 binär
Und der µC arbeitet letztlich binär.

[Kolja (Gast)]

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? :-)

[René H. (Gast)]

Sorry, eine Stelle verrutscht.

:/)
Grüsse,
René

[tinyy (Gast)]

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

Das wäre aber 0x4.

[Kolja (Gast)]

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

Falsch. Das ist 4!

[Einer K. (Gast)]

tinyy schrieb:
> was haeb ich falsch gemacht?

Einiges!

Du meinst vermutlich sowas:

int main(void)
{
  DDRB  |=  (1 << DDB4);  // B4: output;
  DDRB  &= ~(0 << DDB3);  // B3: Input
  
  PORTB  |=  (1 << PB4);  // PB4 High
  PORTB  |=  (1 << PB3);  // PB3 Pullup on
  
  while (1) 
  {
    if (PINB & (1<<PB3))
    {
      PINB =  ( 1 << PB4 ); // Toggle Pin
    }
    else
    {
      PORTB &= ~(1 << PB4); // set low
    }
  }  
  return 0;
}

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?

[tinyy (Gast)]

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:

PINB = 0000 1000 mit
(1<<PB3)= 0000 1000

Und ich vergleiche Bitweise.

[Kolja (Gast)]

tinyy schrieb:
> Und ich vergleiche Bitweise.

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

[Einer K. (Gast)]

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. (Firma: Titel) (lkmiller) (Moderator)]

tinyy schrieb:
> Warum jetzt mit PB3 statt PINB3 vergleichen?
Du könntest auch PD3 oder PINC3 nehmen.
Es ist egal. Alle haben den numerischen Wert 3.

Im "Sinne des Erfinders" ist es allerdings, wenn du PINB3 zur Maskierung 
auf einem Pins verwendest. Und wenn du einen Code zu lesen bekommst, wo 
nicht geplante Definitionen miteinander verwendet werden, dann sollte 
die gelbe Warnlampe angehen und du das Schlimmste vermuten: nämlich, 
dass nicht PD3 in dieser gemischten Abfrage falsch ist, sondern PINB:
if (PINB & (1<<PD3))...

[HildeK (Gast)]

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

  PORTB  |=  (1 << PB4);  // Ausgang B4 auf HIGH setzten
  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
            ^^^

[Einer K. (Gast)]

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:

int main(void)
{
  DDRB  |=  (1 << DDB4);  // B4: output;
  DDRB  &= ~(1 << DDB3);  // B3: Input
  
  PORTB  |=  (1 << PORTB4);  // PB4 High
  PORTB  |=  (1 << PORTB3);  // PB3 Pullup on.. 
  
  while (1) 
  {
    if (PINB & (1<<PINB3))
    {
      PINB = ( 1 << PINB4 ); // Toggle Pin
    }
    else
    {
      PORTB &= ~(1 << PORTB4); // set low
    }
  }  
  return 0;
}

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.

[Rufus Τ. F. (rufus)]

Arduino Fanboy D. schrieb:
> 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);

Magst Du erklären, was der Unterschied zwischen den Symbolen PB4 und 
PORTB4 ist?

[Einer K. (Gast)]

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.

[HildeK (Gast)]

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 :-)

[Rufus Τ. F. (rufus)]

Arduino Fanboy D. schrieb:
> Es ist ein semantischer Unterschied.
> Der Wert ist identisch. Das weißt du doch auch, oder?

Und für welche Verwendung sind Deiner Ansicht nach die Symbole PB0 bis 
PB7 gedacht?

[Einer K. (Gast)]

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.

[Einer K. (Gast)]

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. (rufus)]

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

Magst Du bitte meine Frage beantworten?

[Einer K. (Gast)]

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.

[HildeK (Gast)]

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.

#define PINB    _SFR_IO8(0x16)
#define PINB5   5
#define PINB4   4
.
.
#define DDRB    _SFR_IO8(0x17)
#define DDB5    5
.
.
#define PORTB   _SFR_IO8(0x18)
#define PB5     5
.
.

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

[Einer K. (Gast)]

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. (rufus)]

Arduino Fanboy D. schrieb:
> Dort findet sich in io.h ein #include <avr/portpins.h>

Ist die relevant? Ist nicht (für den Tiny85) die iotnx5.h relevant?

In der ist klar eine Zuordnung zu erkennen:

#define PINB    _SFR_IO8(0x16)
#define PINB5   5
#define PINB4   4
#define PINB3   3
#define PINB2   2
#define PINB1   1
#define PINB0   0

#define DDRB    _SFR_IO8(0x17)
#define DDB5    5
#define DDB4    4
#define DDB3    3
#define DDB2    2
#define DDB1    1
#define DDB0    0

#define PORTB   _SFR_IO8(0x18)
#define PB5     5
#define PB4     4
#define PB3     3
#define PB2     2
#define PB1     1
#define PB0     0

avr/io.h bindet in Abhängigkeit des Controllertyps als erstes 
avr/iotn85.h
ein, das wiederum bindet avr/iotnx5.h ein.

Und damit sind obige Definitionen schon mal vorhanden.

portpins.h bildet Alternativen nur für die Bitnummern der PORT-Register, 
nicht aber für die PIN- oder die DDR-Register.

Du meinst, daraus ableiten zu können, daß das die Definitionen sind, die 
man verwenden soll, wenn man auf Bits in PORT-Registern zugreift?

Ich hab' den Eindruck, daß das sehr, sehr viele AVR-Anwender anders 
sehen.

Die nutzen die Definitionen aus der zum Controller gehörenden 
io.h-Variante, d.h. Bitnamen, die zum jeweiligen Register passen.

Da es keine nochmals abgeleiteten Varianten aus PINB0, DDB0 etc. gibt, 
ist also "portpins.h" eine nicht orthogonale Sonderlocke, die ich 
deswegen schon getrost ignorieren würde.

[Einer K. (Gast)]

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.

[Rufus Τ. F. (rufus)]

Arduino Fanboy D. schrieb:
> Die Datei wird eingebunden, egal ob du sie ignorieren möchtest oder
> nicht!

Du bist jetzt sehr gründlich nicht auf meine Argumentation eingegangen. 
Stattdessen blubberst Du etwas von "Wackelpudding".

Ist eine Diskussion mit Dir tatsächlich komplett sinnlos?

[spess53 (Gast)]

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

[Einer K. (Gast)]

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. (rufus)]

Arduino Fanboy D. schrieb:
> Ich glaube übrigens nicht, dass sie die Datei portpins.h
> ausliefern/einbinden, damit man sie ignoriert.

Und warum gibt es dann keine korrespondierende Datei für DDRx und PINx?

[Einer K. (Gast)]

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:

DDRB  &= ~(1 << DDB3);
PORTB &= ~(1 << PORTB4);
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)

DDRB  &= ~(1 << PB3);
PORTB &= ~(1 << PB4);
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:

PORTB &= ~(1 << PORTB4);
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. (jar)]

Arduino Fanboy D. schrieb:
> Deine provokanten und inhaltsleeren Fragen erinnern mich (verzeihe mir
> bitte den Vergleich) ganz stark an des Kurt Bindl seine Fragen.

ich würde jetzt sagen "der will doch nur spielen" e.i. einfach 
ignorieren.
erinnert mich irgendwie an den als er noch firefly hiess und kein 
Moderator war.

[Einer K. (Gast)]

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.

[HildeK (Gast)]

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:

#if defined(PB4) && !defined(PORTB4)
#  define PORTB4 PB4
#elif defined(PORTB4) && !defined(PB4)
#  define PB4 PORTB4
#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):

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

/* Port Data Register (generic) */
#define    PORT7        7
#define    PORT6        6
.
.

/* Port Data Direction Register (generic) */
#define    DD7          7
#define    DD6          6
.
.

/* Port Input Pins (generic) */
#define    PIN7         7
#define    PIN6         6
.
.

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

DDRB  &= ~(1 << DD3);
PORTB &= ~(1 << PORT4);   
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):

DDRB  &= ~(1 << DDB3);
PORTB &= ~(1 << PB4);   // so ist im DB auch der Pin gekennzeichnet
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.

[HildeK (Gast)]

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:

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

#define LED0      PORT_B0
#define LED0_oe    DDR_B0
#define LED1       PORT_B1
#define LED1_oe     DDR_B1
#define INPUT     PIN_B2
#define INPUT_oe  DDR_B2

#define EIN  0      // zum LEDs schalten beim STK500
#define AUS  1   
#define HIGH 1    // für Inputs
#define LOW  0

int main()
{
  LED0_oe  = 1;    // Auf Output schalten
  LED1_oe  = 1;
  INPUT_oe = 0;    // auf Input schalten
   
  LED0 = AUS;      // LED0-Port auf aus
  LED1 = EIN;     // LED1-Port auf ein
  
  if(LED1 == EIN) LED0 = EIN;  // auch Abfragen sind möglich
  if(LED0 == EIN) LED1 = AUS;
  
  LED0  ^= 1;         // Toggle
  PORTB ^= (1<<PB0);  // entspricht dieser bekannten Version
  PINB   = (1<<PB0);  // oder auch der

  LED1 ^= 1;  // Toggle

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

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

Hat was für die Lesbarkeit, oder?

[Einer K. (Gast)]

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.